Przejdź do treści 
Buforowanie HTTP pozwala zaoszczędzić czas i transfer danych, ponieważ zasoby są ponownie ładowane tylko wtedy, gdy faktycznie uległy zmianie. Poprzez ETag oraz Ostatnio zmodyfikowany Sprawdzam za pomocą zapytania warunkowego, czy serwer odpowiada kodem 304 Not Modified, co znacznie zmniejsza obciążenie sieci i serwera.
Punkty centralne
Poniższe kluczowe tezy pokazują, na co zwracam uwagę podczas stosowania buforowania warunkowego z ETag oraz Ostatnio zmodyfikowany uwaga.
- Mniejszy ruch: W przypadku niezmienionych plików zwracany jest kod 304, a nie cała treść – co zauważalnie zmniejsza ilość przesyłanych danych i opóźnienie.
- Lepsza wydajność: Krótszy czas oczekiwania poprawia komfort użytkowania (UX) oraz wskaźniki Core Web Vitals, co SEO pomaga.
- Dwa mechanizmy: Nagłówki Last-Modified/If-Modified-Since oraz ETag/If-None-Match zapewniają bezpieczną weryfikację zawartości pamięci podręcznej.
- Kontrola pamięci podręcznej: Dyrektywy regulują aktualizację, odświeżanie i zachowanie w pamięciach podręcznych pośrednich.
- Połączenie: Oba metody razem zapewniają wysoką dokładność i proste rozwiązania awaryjne.
Najpierw sprawdzam, które zasoby zmieniają się naprawdę często, a które rzadko. W przypadku plików rzadko modyfikowanych ustawiam Ostatnio zmodyfikowany-czas i dodaję ETag. W przypadku odpowiedzi dynamicznych najchętniej korzystam z ETag, ponieważ każda zmiana treści jest natychmiast widoczna. W ten sposób odciążam serwery, zmniejszam opóźnienia i zapewniam powracającym użytkownikom bardzo szybkie ładowanie stron. Strategia ta wzmacnia Core Web Vitals a tym samym pośrednio widoczność.
Buforowanie warunkowe HTTP: jak sprawdzić ważność
Przy ponownym wywołaniu klient wysyła oprócz żądania GET dodatkowe nagłówki, które analizuję po stronie serwera. Jeśli zasób ma ten sam ETag Jeśli zawartość jest taka sama jak w pamięci podręcznej (If-None-Match), zwracam kod 304 Not Modified bez treści. Jeśli znacznik czasu nie uległ zmianie (If-Modified-Since), serwer również odpowiada kodem 304. Jeśli dzień lub data są nieprawidłowe, wysyłam 200 OK z nową treścią oraz zaktualizowanym Ostatnio zmodyfikowany oraz ETag. Dzięki temu oszczędzam przepustowość, aktualizuję pamięć podręczną i zapewniam zauważalnie szybsze ładowanie stron.
Last-Modified i If-Modified-Since w codziennym użytkowaniu
Nagłówek Ostatnio zmodyfikowany Używam rzeczywistej daty modyfikacji pliku, na przykład z systemu plików. Jeśli później nadejdzie żądanie z nagłówkiem `If-Modified-Since`, a zasób nie uległ od tego czasu zmianie, odpowiadam kodem 304. To rozwiązanie jest proste, łatwe do zrozumienia i idealne dla zasobów statycznych, takich jak CSS, JS czy obrazy. Ograniczenia wynikają z sekundowej siatki znaczników czasu HTTP oraz sytuacji, w których treści zmieniają się logicznie, ale nie istnieje jednoznaczny moment modyfikacji pliku. Tam, gdzie Last-Modified osiąga swoje granice, uzupełnia go ETag kontrola.
ETag i If-None-Match w systemach dynamicznych
A ETag Generuję go jako skrót, identyfikator wersji lub na podstawie kolumny bazy danych, która odzwierciedla zmiany stanu. Przy ponownym dostępie przeglądarka wysyła If-None-Match, porównuję tag z moją aktualną wartością i odpowiadam odpowiednio 304 lub 200. To porównanie wykrywa każdą znaczącą zmianę treści, bez polegania na znacznikach czasu plików. Daje to bardzo dokładne wyniki, zwłaszcza w przypadku interfejsów API, stron złożonych lub spersonalizowanych fragmentów. Ważne jest, aby zachować spójność ETagów w środowiskach klastrowych, tak aby żaden serwer nie przypisał przypadkowo innego Dzień wyprodukowane.
Właściwe łączenie ustawień Cache-Control
Z Kontrola pamięci podręcznej Określam, jak długo treści są uznawane za aktualne bez ponownego sprawdzania oraz kiedy przeglądarka przeprowadza ponowną weryfikację. Ustawiam odpowiednie wartości max-age w zależności od częstotliwości zmian i stosuję atrybut must-revalidate, gdy nieaktualne dane mogłyby mieć krytyczne znaczenie. W przypadku plików z numerami wersji odpowiedni jest długi okres ważności, podczas gdy często zmieniające się odpowiedzi mają krótszy okres ważności i można je wtedy dokładnie sprawdzić za pomocą ETag lub daty. W ten sposób łączę krótkie czasy odpowiedzi z prawidłową aktualnością. Jeśli chcesz zgłębić ten temat, znajdziesz wiele przykładów pod adresem Strategie kontroli pamięci podręcznej, z których korzystam w praktyce.
Przebieg operacji Conditional GET krok po kroku
Przy pierwszym żądaniu serwer wysyła odpowiedź 200 OK wraz z nagłówkiem Cache-Control, Ostatnio zmodyfikowany oraz ETag, a przeglądarka zapisuje te dane. Podczas kolejnej wizyty to właśnie wiek w pamięci podręcznej decyduje o tym, czy konieczna jest ponowna weryfikacja. Jeśli jest ona wymagana, przeglądarka wysyła żądanie z nagłówkami If-None-Match i/lub If-Modified-Since. Jeśli wartości są zgodne z aktualnym stanem, wysyłam 304 Not Modified, a klient nadal korzysta ze swojej pamięci podręcznej. Jeśli nie są już zgodne, następuje 200 OK z nową treścią i zaktualizowanymi Dane walidacyjne.
Porównanie: ETag a Last-Modified
Obie metody zapewniają mi kontrolę, różnią się jednak pod względem nakładu pracy, dokładności i przydatności. Ostatnio zmodyfikowany Wyróżnia się prostotą wdrożenia i przejrzystą semantyką, o ile dysponuję poprawnymi znacznikami czasu. ETag bardzo dokładnie odzwierciedla zawartość, ale jego generowanie wymaga nieco logiki. W wielu konfiguracjach łączę oba rozwiązania, czerpiąc w ten sposób korzyści z prostoty oraz dokładnego rozpoznawania. Poniższa tabela podsumowuje typowe cechy i pomaga w podjęciu decyzji.
| Aspekt | Ostatnio zmodyfikowany | ETag | Wskazówka |
|---|---|---|---|
| Tożsamość | Data ostatniej zmiany | Skrót treści lub identyfikator wersji | Czas vs. identyfikator oparty na treści |
| Wykrywanie zmian | Rozdzielczość w sekundach, pośrednia | Skupia się bezpośrednio na treści | ETag wykrywa najmniejsze Różnice |
| wdrożenie | Bardzo lekki, wystarczy system plików | Wymaga tworzenia i spójności | Klastry potrzebują jednakowych ETags |
| Użycie | Elementy statyczne | Odpowiedzi dynamiczne | To połączenie obejmuje wiele Przypadki z |
| Odpowiedzi | 304 przy niezmienionym znaczniku czasu | 304 przy identycznym tagu | 200 w przypadku zmian z nowym Wartość |
W praktyce: wydajne dostarczanie zasobów statycznych
Pliki statyczne, takie jak CSS, JS i obrazy, rzadko ulegają zmianom i nadają się do długotrwałego maksymalny wiek-Czas. W przypadku plików z wersjami ustawiam długie okresy, nawet do roku, i oznaczam je jako niezmienne, aby przeglądarka ładowała je bez dodatkowych zapytań. W przypadku zasobów bez wersji wybieram krótsze terminy i polegam na ponownej walidacji za pomocą ETag i Last-Modified. W ten sposób unikam nieaktualnych treści i ograniczam ruch. Zwracam uwagę, aby nie Sabotowanie nagłówka pamięci podręcznej dzięki temu uzyskuję wysoki wskaźnik trafień w pamięci podręcznej.
W praktyce: interfejsy API i strony dynamiczne
Jeśli chodzi o interfejsy API, zazwyczaj stawiam na ETags, który tworzę na podstawie wyników w formacie sekwencyjnym lub kolumny wersji. Jeśli rekord ulegnie zmianie, generuję nowy tag, a klienci natychmiast to rozpoznają. W przypadku treści o niepewnym znaczniku czasu często rezygnuję z Last-Modified, aby nie powstało fałszywe wrażenie aktualności. Dodatkowo kontroluję czas życia za pomocą Cache-Control i wymuszam ponowną walidację po upływie tego czasu. W ten sposób niezawodnie utrzymuję dane w aktualnym stanie, nie zwiększając niepotrzebnie rozmiaru odpowiedzi.
Testowanie i monitorowanie współczynnika trafień w pamięci podręcznej
Sprawdzam nagłówki, takie jak ETag, Last-Modified, If-None-Match i If-Modified-Since w narzędziach programistycznych. Zwracam przy tym uwagę na kody odpowiedzi, zwłaszcza 304 w porównaniu z 200, aby sprawdzić skuteczność mojej ponownej walidacji. Jeśli kod 304 pojawia się rzadko, dostosowuję ustawienia Cache-Control, okresy ważności i generowanie ETag. Logi i metryki pokazują mi, które ścieżki generują niepotrzebnie duże odpowiedzi. W celu wprowadzenia zbiorczych ulepszeń chętnie korzystam z Pakiet Conditional-Requests, które łączy konfigurację i testy.
Architektura hostingu i pułapki ETag
W konfiguracjach z wieloma serwerami należy ETag musi być niezależny od instancji, w przeciwnym razie rozpoznawanie nie zadziała. Dbam o to, aby wszystkie węzły stosowały tę samą logikę i ten sam klucz do generowania. Serwery proxy odwrotne lub sieci CDN nie mogą modyfikować etagów i powinny poprawnie przekazywać nagłówki warunkowe. W przypadku wdrożeń z odciskami palców zasobów unikam ponownego obliczania ETagów po stronie serwera, jeśli plik ma już adres URL z wersją. Spójne zasady zapobiegają niespójnym odpowiedziom i utrzymują wysoki wskaźnik trafień w pamięci podręcznej.
Świeżość a walidacja: precyzyjne stosowanie dyrektyw
Dokonuję wyraźnego rozróżnienia między Świeżość (jak długo cache może korzystać z kopii bez ponownego sprawdzania?) oraz Walidacja (jak sprawdzić, czy jest nadal ważna?). O Kontrola pamięci podręcznej reguluję oba elementy z dużą precyzją: maksymalny wiek określa czas życia obiektu po stronie klienta, s-maxage dla pamięci podręcznych współdzielonych, takich jak serwery proxy. publiczny umożliwia buforowanie w podzielonych pamięciach podręcznych, prywatny ogranicza to do przeglądarki docelowej. musisz ponownie potwierdzić wymusza wysłanie zapytania po upływie czasu, podczas gdy niezmienny zapobiega niepotrzebnym ponownym walidacjom w przypadku zasobów z numerami wersji. no-cache nie zabrania buforowania, ale wymaga zawsze ponownej walidacji; no-store natomiast całkowicie zabrania zapisywania. Starsze Wygasa- Nagłówki używam tylko jako rozwiązanie awaryjne, logikę konsekwentnie przenoszę do Cache-Control. A jeśli chcę złagodzić skutki awarii, pomagają stale-while-revalidate oraz stale-if-error, aby udostępniać treści, których ważność wkrótce wygaśnie, podczas gdy w tle aktualizuję stronę lub naprawiam błędy.
Silne i słabe ETag-i, kompresja i warianty
Świadomie rozróżniam silne i słabe czynniki potwierdzające. Silne znaczniki ETag rozpoznać dokładnie taką samą reprezentację bajtową – idealne rozwiązanie, jeśli ja również Żądania zasięgu chce obsługiwać w sposób wydajny. Słabe znaczniki ETag (Przedrostek W/) wystarczą, jeśli wystarczy zgodność semantyczna, na przykład w przypadku niewielkich, nieistotnych zmian formatowania. Ważne jest postępowanie z Kompresja: Jeśli dostarczam treści zakodowane zarówno w formacie gzip, jak i brotli, jeden tag ETag nie może obowiązywać dla wszystkich wariantów. Muszę albo utworzyć ten tag na podstawie nieskompresowanej wersji, albo dodatkowo ustawić odpowiedni Vary: Accept-Encoding, lub generuję spójne, ale różne etagi ETag dla każdego wariantu. W ten sposób zapobiegam błędnym wynikom i odpowiedziom 200, które w rzeczywistości powinny być 304. W przypadku Jeśli-zakres Łączę zapytania o zakres z walidatorem: jeśli ETag lub data są zgodne, zwracam kod stanu 206 (Partial Content); w przeciwnym razie zwracam kod stanu 200 z pełną treścią, aby klient miał spójną podstawę.
Doskonałe opanowanie nagłówków Vary i negocjacji treści
Gdy serwer dostarcza różne reprezentacje w zależności od wymagań, ustawiam Różne prawidłowo. Typowymi przykładami są Akceptowane kodowanie (kompresja), Akceptuj język (lokalizacja) lub konkretne flagi funkcji. Staram się unikać używania zmiennych nagłówków, takich jak Agent użytkownika a nawet Ciasteczko zmieniać, bo to znacznie obniża współczynnik trafień w pamięci podręcznej. Tam, gdzie konieczna jest personalizacja, oznaczam odpowiedzi jako prywatny lub no-store i wyraźnie oddzielaj je od zasobów, które można buforować publicznie. Ważne: warianty mają również wpływ na ETag – każdy wariant wymaga własnego, spójnego walidatora. W ten sposób zapewniam, że przeglądarki, serwery proxy i sieci CDN stosują tę samą logikę i żaden wariant nie zostanie przypadkowo pomylony z innym.
Zapytania warunkowe wykraczające poza GET
Żądania warunkowe działają nie tylko podczas odczytu. W przypadku metod zapisujących używam If-Match lub If-Unmodified-Sincew celu brakujące aktualizacje zapobiec. Jeśli klient podczas operacji PUT lub DELETE poda ostatnio widziany ETag poprzez If-Match jeśli stan serwera jest nadal taki sam, wprowadzam zmianę – w przeciwnym razie odpowiadam 412 Nie spełniono warunku wstępnego. Aby zapewnić dyscyplinę wśród klientów, serwer może ponadto 428 Wymagane spełnienie warunku wstępnego ustanowić. Do szybkich testów bez modelu używam HEAD, który zwraca te same nagłówki co żądanie GET; idealne rozwiązanie, gdy chcę przetestować metadane. A w przypadku 304-W odpowiedzi ponownie podaję wszystkie nagłówki istotne dla pamięci podręcznej (Cache-Control, ETag, Expires, Last-Modified), aby klient zaktualizował swoje metadane bez przesyłania treści.
Bezpieczeństwo, ochrona danych i zgodność z przepisami
Nie zapisuję danych osobowych ani treści wrażliwych w publicznej pamięci podręcznej. W tym miejscu stosuję Kontrola pamięci podręcznej: prywatna lub no-store, aby przeglądarka lub żadna instancja nie zapisywała treści. Należy zachować ostrożność w przypadku kont użytkowników i pulpitów nawigacyjnych: odpowiedzi zawierające Ustaw plik cookie lub Autoryzacja nie mogą być przypadkowo publiczne i podlegające buforowaniu. Same ETag-i mogą zostać wykorzystane jako narzędzie do śledzenia, jeśli pozostają niezmienne przez dłuższy czas. Radzę sobie z tym, aktywnie stosując walidatory tylko tam, gdzie buforowanie jest pożądane, a w przypadku tras specyficznych dla użytkownika wyłączam je lub ograniczam ich czas życia. W ten sposób łączę wydajność z wymogami ochrony danych.
Szczegóły wdrożenia i koszty związane z wydajnością
Generowanie tagu ETag nie może być droższe niż korzyści z tego płynące. W przypadku dużych plików lub kosztownych renderowań zapisuję ten tag wraz z metadanymi (sumą kontrolną pliku, skrótem kompilacji, bazą danych—wersja wiersza) i nie generuję go od nowa przy każdym żądaniu. W przypadku stron złożonych pomocna jest Strategia tworzenia wersji: Tworzę ETag z stabilnych częściowych ETagów (np. szablon, fragment danych, konfiguracja), tak aby niewielkie zmiany dawały konkretną, ale powtarzalną nową wartość. W klastrach synchronizuję logikę generowania w wspólnej bibliotece i sprawdzam ją w CI, aby żadna instancja nie odbiegała od normy. W przypadku bardzo dużych obiektów blob stosuję szybkie sumy kontrolne (CRC64) lub zapisuję skróty kompilacji zamiast generować skrót treści w locie. Tam, gdzie absolutna identyczność bajtów nie jest konieczna, wystarczą słabe ETags jako pragmatyczny kompromis.
Najczęstsze błędy i sposoby ich unikania
- Losowe ETag: Jeśli tagi są generowane na nowo przy każdym żądaniu, każda ponowna walidacja jest bezsensowna. Dbam o to, by wartości były deterministyczne i zmieniały się tylko w przypadku rzeczywistych zmian.
- Nieprawidłowe połączenie dyrektyw: no-store Używanie ETag nic nie daje – przeglądarka i tak tego nie zapisuje. Wybieram spójne kombinacje, aby uzyskać pożądane działanie.
- Nadmierna zmienność: Wariacje w polu „Vary” lub „User-Agent” powodują rozbicie pamięci podręcznej. Ograniczam użycie pola „Vary” wyłącznie do rzeczywistych zmian reprezentacji.
- Pułapki kompresyjne: Wspólny ETag dla gzip i br powoduje błędne wyniki. Prawidłowo przypisuję ETagi do konkretnych wariantów i poprawnie ustawiam nagłówek Vary.
- Odchylenie czasu: Niedokładne zegary serwerów zniekształcają wartość Last-Modified. Synchronizuję źródła czasu, aby nagłówek If-Modified-Since działał poprawnie.
- Pomyłka związana z atrybutem no-cache: Wielu rozumie to jako „nie buforować“. Chodzi jednak o „zawsze odświeżać“. Aby wprowadzić rzeczywisty zakaz, używam no-store.
Rozwiązywanie problemów, wskaźniki i przepływy pracy
Aby przeprowadzić diagnostykę, otwieram zakładkę „Sieć”: wszystko się zgadza Kontrola pamięci podręcznej? Występuje podczas rehabilitacji 304 zamiast 200? Pasuje ETag oraz Ostatnio zmodyfikowany między zapytaniem a odpowiedzią? Sprawdzam Różne, aby sprawdzić, czy warianty zostały poprawnie rozpoznane. W logach wyświetlam Trafione/chybione- Wyświetlanie współczynników, wskaźników 304 oraz średniej wielkości odpowiedzi na ścieżkę. Wraz ze wzrostem wskaźnika 304 zazwyczaj zauważalnie maleje objętość danych i czas TTFB. W testach obciążeniowych symuluję powtarzające się wywołania, aby mierzyć koszty ponownej walidacji zamiast kosztów transferu. W przypadku nieprawidłowości stopniowo eliminuję czynniki zakłócające: Set-Cookie, zbyt rygorystyczne reguły Vary, sprzeczne nagłówki, takie jak Pragma. W ten sposób szybko znajduję wąskie gardło, które obniża współczynnik trafień.
Service Worker jako dodatkowa warstwa pamięci podręcznej
Jeśli korzystam z service workera, traktuję go jako dodatkową warstwę, a nie jako warstwę sprzeczną. Pozwalam mu obsługiwać te same Kontrola pamięci podręcznej-zwracaj uwagę na sygnały i łącz strategie, takie jak stale-while-revalidate celowo z walidacją HTTP za pomocą ETag i Last-Modified. W trybie offline moduł roboczy może dostarczać zasoby, które w krótkim czasie stały się nieaktualne, a następnie ponownie je walidować w tle. Ważne jest, aby poprawnie przekazywał nagłówki warunkowe, w przeciwnym razie tracę korzyści płynące z 304 na odcinku sieciowym. W ten sposób również scenariusze PWA korzystają z prawidłowego buforowania HTTP, zamiast omijać jego mechanizmy.
Wpływ SEO i Core Web Vitals
Ulepszanie szybkich odpowiedzi UX oraz sygnały użytkowników, co sprzyja pozycjonowaniu w wynikach wyszukiwania. Szczególnie zyskują na tym powracający użytkownicy, ponieważ ich przeglądarki pobierają wiele plików bezpośrednio z pamięci podręcznej lub potwierdzają je za pomocą kodu 304. To mniejsze opóźnienie pozytywnie wpływa na wskaźniki FCP, LCP i TTFB, które obniżam dzięki ukierunkowanej ponownej walidacji. Ponadto serwer oszczędza czas obliczeniowy, który mogę wykorzystać na obsługę szczytów obciążenia lub złożonych żądań. W ten sposób zachowuję wysoką wydajność, a treści są dostarczane poprawnie i na czas.
Podsumowanie: Mój plan działania
Polegam na jasnym Połączenie na podstawie Cache-Control, Last-Modified i ETag. W przypadku zasobów statycznych wybieram długie okresy ważności i zabezpieczam się poprzez ponowną walidację, jeśli pliki nie są wersjonowane. W przypadku odpowiedzi dynamicznych generuję solidne ETagi i dbam o spójność klastrów. Następnie sprawdzam za pomocą narzędzi, metryk i logów, czy kod 304 pojawia się wystarczająco często, i dostosowuję ustawienia. W ten sposób zapewniam szybkie dostarczanie treści, mniejsze obciążenie serwerów i lepsze wrażenia użytkownika dzięki skutecznej Buforowanie HTTP.
