Nagłówki Cache-Control: jak ustawić pamięć podręczną przeglądarki dla plików strony

Czym jest nagłówek Cache-Control i co się dzieje, gdy go brakuje

Cache-Control to nagłówek odpowiedzi HTTP, czyli jedna z linii technicznych, które serwer wysyła razem z plikiem, zanim przeglądarka zobaczy jego treść. Zawiera dyrektywy sterujące pamięcią podręczną (z angielskiego cache), a więc miejscem, w którym przeglądarka odkłada kopie pobranych plików, żeby nie pobierać ich ponownie przy następnej podstronie lub następnej wizycie.

Jak opisuje opracowanie web.dev o pamięci podręcznej HTTP, każde żądanie przeglądarka najpierw porównuje z tym, co ma zapisane lokalnie. Jeśli znajdzie ważną kopię, odczytuje ją z dysku i w ogóle nie łączy się z siecią. Odwiedzający nie czeka wtedy na serwer ani nie zużywa transferu. Mechanizm działa bez dodatkowego kodu na stronie, ponieważ przeglądarka sama dopisuje do żądań potrzebne nagłówki. Po stronie właściciela witryny pozostaje konfiguracja serwera.

Zapis nagłówka jest prosty. Dyrektywy oddziela się przecinkami, a wartości liczbowe podaje po znaku równości. Dokumentacja MDN nagłówka Cache-Control zaleca pisanie dyrektyw małymi literami. Czas zawsze liczony jest w sekundach.

Cache-Control: max-age=604800
Cache-Control: public, max-age=31536000, immutable
Cache-Control: no-cache
Cache-Control: no-store

Pamięć prywatna i współdzielona

Nagłówek czytają dwa rodzaje pamięci. Pamięć prywatna należy do jednego odbiorcy i w praktyce jest nią pamięć przeglądarki. Pamięć współdzielona znajduje się między odbiorcą a serwerem i obsługuje wiele osób naraz: to serwery pośredniczące oraz sieci dostarczania treści, znane pod skrótem CDN. Rozróżnienie ma znaczenie przy stronach z logowaniem. Szerszy obraz wszystkich warstw przedstawiamy we wpisie o tym, jakie są rodzaje pamięci podręcznej strony.

Brak nagłówka nie oznacza braku pamięci podręcznej

Częste nieporozumienie polega na założeniu, że plik bez nagłówka Cache-Control nie jest nigdzie przechowywany. Jest odwrotnie: przeglądarka sama ocenia wtedy, jak długo może korzystać z kopii. Opis buforowania HTTP w MDN nazywa to buforowaniem heurystycznym i podaje, że specyfikacja zaleca ponowne użycie przez około jedną dziesiątą czasu, jaki upłynął od ostatniej modyfikacji pliku. Plik niezmieniany od roku może więc być pokazywany z kopii przez ponad miesiąc, choć nikt takiej decyzji świadomie nie podjął. Dlatego zasady przechowywania należy podawać wprost przy każdej odpowiedzi serwera.

Co oznaczają dyrektywy max-age, no-cache, no-store i immutable

Każda dyrektywa odpowiada na inne pytanie: max-age mówi, jak długo kopia jest świeża, no-cache każe ją potwierdzać przed każdym użyciem, no-store zabrania zapisu, a immutable zapewnia, że plik pod danym adresem się nie zmieni. Poniższe opisy opieramy na dokumentacji MDN.

max-age - czas świeżości w sekundach

Zapis max-age=604800 oznacza, że odpowiedź pozostaje świeża przez tydzień. W tym okresie przeglądarka korzysta z kopii bez kontaktu z serwerem. Czas liczy się od chwili wygenerowania odpowiedzi przez serwer, a nie od chwili jej odebrania. Po upływie okresu świeżości kopia staje się nieaktualna, ale nie znika: przeglądarka może zapytać serwer, czy plik się zmienił, i w razie odpowiedzi przeczącej nadal z niej korzystać. Pokrewna dyrektywa s-maxage ustala czas wyłącznie dla pamięci współdzielonych, a przeglądarka ją pomija.

no-cache - wolno zapisać, trzeba potwierdzić

Nazwa tej dyrektywy wprowadza w błąd. No-cache nie zakazuje przechowywania. Pozwala zapisać odpowiedź, ale wymaga, aby przed każdym ponownym użyciem pamięć zapytała serwer, czy kopia jest nadal aktualna. Gdy plik się nie zmienił, serwer odsyła krótką odpowiedź o kodzie 304 bez treści i przeglądarka pokazuje kopię z dysku. Gdy się zmienił, przychodzi pełna odpowiedź o kodzie 200. Odwiedzający zawsze widzi aktualną wersję, a mimo to rzadko pobiera cały plik.

no-store - zakaz przechowywania

No-store oznacza, że żadna pamięć, prywatna ani współdzielona, nie może zapisać odpowiedzi. Plik jest pobierany w całości przy każdym żądaniu. MDN zwraca uwagę, że no-store nie usuwa kopii zapisanej wcześniej pod tym samym adresem oraz odbiera stronie korzyści z szybkiego powrotu przyciskiem wstecz, dlatego w większości sytuacji lepszym wyborem jest połączenie no-cache z private.

immutable - plik, który się nie zmieni

Dopisek immutable informuje, że odpowiedź nie zmieni się w okresie świeżości, więc przeglądarka nie musi jej potwierdzać nawet wtedy, gdy odwiedzający odświeża stronę. Dyrektywa ma sens wyłącznie dla plików z wersją w adresie. Opracowanie web.dev zaznacza, że część przeglądarek ją pomija, więc należy ją traktować jako dodatek do max-age, a nie jego zamiennik.

private, public i must-revalidate

Private pozwala zapisać odpowiedź tylko w przeglądarce. Należy jej używać przy treściach dopasowanych do osoby: po zalogowaniu, w koszyku, w panelu klienta. Jej brak może sprawić, że strona z danymi jednej osoby trafi do pamięci współdzielonej i zostanie pokazana komuś innemu. Public pozwala na zapis w pamięci współdzielonej także wtedy, gdy żądanie zawierało nagłówek autoryzacji; przy zwykłych plikach nie jest konieczna. Must-revalidate, zwykle łączona z max-age, zabrania użycia nieaktualnej kopii bez potwierdzenia na serwerze.

Gdy w jednym nagłówku znajdą się dyrektywy sprzeczne, powinna zwyciężyć najbardziej restrykcyjna. MDN podaje przykład często kopiowanego zapisu łączącego private, no-cache, no-store, max-age=0 i must-revalidate, który w praktyce oznacza to samo, co samo no-store.

Do czego służą nagłówki ETag, Last-Modified i Expires

ETag i Last-Modified pozwalają przeglądarce zapytać serwer, czy posiadana kopia jest nadal aktualna, bez pobierania pliku od nowa, a Expires to starszy sposób podania terminu ważności, dziś zastąpiony przez max-age. Cache-Control określa, kiedy trzeba pytać, a te nagłówki umożliwiają samo pytanie.

Jak przebiega potwierdzanie kopii

Serwer wysyła plik razem ze znacznikiem ETag. Kiedy kopia przestaje być świeża albo obowiązuje no-cache, przeglądarka wysyła żądanie z nagłówkiem If-None-Match i zapamiętaną wartością znacznika. Jeśli znacznik na serwerze jest taki sam, serwer odpowiada kodem 304, czyli informacją, że nic się nie zmieniło, i nie dołącza treści. Jeśli jest inny, odsyła nową wersję z kodem 200. Dokumentacja nagłówka ETag w MDN wyjaśnia, że sposób tworzenia znacznika nie jest narzucony: bywa nim skrót treści, skrót daty modyfikacji albo numer wersji.

GET /index.html HTTP/1.1
If-None-Match: "33a64df5"

HTTP/1.1 304 Not Modified
ETag: "33a64df5"
Cache-Control: no-cache

Last-Modified - data ostatniej zmiany

Last-Modified działa tak samo, tyle że zamiast znacznika używa daty. Przeglądarka odsyła ją w nagłówku If-Modified-Since, a serwer odpowiada kodem 304 lub 200. Metoda oparta na dacie jest wrażliwa na różnice w ustawieniach zegarów między serwerami, dlatego web.dev zaleca ETag jako dokładniejszy. Według MDN, gdy przeglądarka wyśle oba nagłówki, pierwszeństwo ma If-None-Match, a standard zaleca, by serwer wysyłał zarówno ETag, jak i Last-Modified.

Expires - starszy sposób podania terminu

Expires zawiera konkretną datę i godzinę w czasie GMT, po której odpowiedź uznaje się za nieaktualną. Dokumentacja nagłówka Expires stwierdza jednoznacznie: jeśli odpowiedź zawiera Cache-Control z dyrektywą max-age lub s-maxage, nagłówek Expires jest pomijany. Wartość zero oznacza datę z przeszłości, czyli zasób już wygasły. Expires nie przeszkadza, ale nie należy na nim opierać konfiguracji. Jeśli serwer wysyła sam Expires bez Cache-Control, warto dopisać max-age.

Jakie czasy przechowywania ustawić dla obrazów, stylów, skryptów i HTML

Zasada wynikająca z dokumentacji jest krótka: pliki, których adres zmienia się razem z treścią, powinny mieć czas przechowywania równy rok, a dokument HTML powinien być potwierdzany przy każdym użyciu. Wszystko pomiędzy zależy od tego, czy plik ma wersję w adresie i jak często się zmienia.

Dla plików statycznych z wersją lub skrótem treści w nazwie MDN i web.dev podają ten sam zapis: max-age=31536000, czyli rok, z opcjonalnym dopiskiem immutable. Web.dev dodaje, że rok to największa obsługiwana wartość. Skoro zmiana pliku oznacza nowy adres, stara kopia nigdy nie zostanie pokazana w miejscu nowej.

Dla plików bez wersji w adresie sytuacja jest inna. Dokumentacja Chrome dotycząca czasu przechowywania zaleca, aby zasoby podrzędne nadające się do przechowywania miały czas co najmniej 30 dni. MDN radzi podobnie: przy braku pewności warto wybrać miesiąc, czyli max-age=2592000. Przez ten czas podmiana pliku pod tym samym adresem nie dotrze jednak do osób, które mają już kopię.

Dokument HTML nie może mieć wersji w adresie, bo adres podstrony ma pozostać stały dla odwiedzających i wyszukiwarek. Dlatego zalecany zapis to no-cache wraz ze znacznikiem ETag lub datą Last-Modified. Dla stron dopasowanych do osoby, na przykład po zalogowaniu, MDN podaje zapis no-cache, private.

Weźmy sklep z Poznania, który ma kilkaset zdjęć produktów, jeden arkusz stylów i kilka skryptów. Zdjęcia wgrywane przez panel dostają zwykle unikalne nazwy, więc mogą być przechowywane długo. Arkusz stylów zmienia się przy każdej poprawce wyglądu, zatem musi mieć wersję w adresie, bo inaczej stali klienci przez miesiąc oglądaliby stary układ koszyka. Strona koszyka i strona konta powinny mieć dopisek private, a karta produktu z ceną powinna być potwierdzana na serwerze.

Lepsze przechowywanie plików nie zmienia pierwszej wizyty. Skraca kolejne odsłony i powroty na stronę. O tym, jak szybkość wczytywania łączy się z oceną strony, piszemy we wpisie o tym, jak poprawić Core Web Vitals.

Jak wymusić odświeżenie po zmianie pliku

Odświeżenie wymusza się zmianą adresu pliku: nowa treść dostaje nowy adres, którego przeglądarka jeszcze nie zna, więc musi go pobrać. Nie istnieje dyrektywa, która nakazałaby przeglądarce porzucić kopię wciąż uznawaną za świeżą. MDN pisze o tym wprost: serwer nie ma możliwości unieważnienia świeżej odpowiedzi, którą odbiorca już przechowuje.

Z tego wynika cały wzorzec opisany w dokumentacji. Plikom statycznym nadaje się długi czas przechowywania, w ich adresach umieszcza się wersję, a dokument HTML, który te adresy zawiera, jest potwierdzany przy każdym wejściu. Przeglądarka dostaje aktualny dokument z nowymi adresami stylów i skryptów, pobiera tylko te pliki, których jeszcze nie ma, a resztę bierze z dysku.

bundle.v123.js
bundle.js?v=123
bundle.YsAIAAAA-QG4G6kCMAMBAAAAAAAoK.js

Pierwszy zapis to numer wersji w nazwie, drugi to parametr dopisany po znaku zapytania, trzeci to skrót treści pliku. Skrót ma tę zaletę, że zmienia się tylko wtedy, gdy zmienia się zawartość, więc pliki nietknięte przez aktualizację zachowują stary adres i pozostają w pamięci odwiedzających.

Wersje plików w WordPressie

WordPress stosuje drugi z tych sposobów. Funkcja dołączająca skrypty przyjmuje parametr wersji, który zgodnie z dokumentacją funkcji wp_enqueue_script jest dopisywany do adresu pliku jako parametr zapytania. Gdy autor motywu lub wtyczki nie poda wersji, system dopisuje numer zainstalowanej wersji WordPressa. Skutek praktyczny jest ważny: jeśli wykonawca zmienia plik, ale nie podnosi numeru wersji, adres pozostaje ten sam i osoby z zapisaną kopią nie zobaczą poprawki do końca okresu świeżości.

Kancelaria z Krakowa wymienia logo i wgrywa nowy plik pod starą nazwą. Serwer wysyła obrazy z rocznym czasem przechowywania. Osoby odwiedzające stronę po raz pierwszy widzą nowe logo, a dotychczasowi klienci stare, i tak może pozostać przez wiele miesięcy. Poprawne postępowanie to wgranie pliku pod nową nazwą i zmiana odwołania w szablonie.

Gdzie ustawia się nagłówki i jak sprawdzić, co wysyła serwer

Nagłówki pamięci podręcznej ustawia się po stronie serwera: w jego konfiguracji, w panelu hostingu, we wtyczce systemu zarządzania treścią albo w ustawieniach sieci CDN, a wynik sprawdza się w narzędziach deweloperskich przeglądarki Chrome. Dokumentacja Google odsyła w sprawie wdrożenia do dostawcy hostingu lub systemu zarządzania treścią, ponieważ sposób konfiguracji zależy od oprogramowania serwera.

Jeżeli przed witryną działa sieć CDN, może ona nadpisywać nagłówki własnymi ustawieniami, dlatego kontrolę należy wykonać na adresie, z którego pliki faktycznie trafiają do odwiedzających. O wpływie serwera na szybkość piszemy we wpisie o tym, jak hosting wpływa na szybkość i indeksowanie strony. Samo sprawdzenie nie wymaga uprawnień do serwera. Dokumentacja Lighthouse opisuje następującą ścieżkę.

1. Otwarcie narzędzi deweloperskich

   Na badanej stronie należy nacisnąć Ctrl+Shift+J, a na komputerach Mac Cmd+Option+J.

2. Przejście do karty Network

   Karta, w polskiej wersji przeglądarki opisana jako Sieć, pokazuje wszystkie pliki pobierane przez stronę. Po jej otwarciu stronę trzeba wczytać ponownie, aby lista się wypełniła.

3. Odczytanie kolumny Size

   Kolumna z rozmiarem pokazuje, czy plik został pobrany z sieci, czy wczytany z pamięci podręcznej.

4. Sprawdzenie nagłówków pliku

   Po kliknięciu nazwy pliku w kolumnie Name i przejściu do karty Headers widać nagłówki odpowiedzi, w tym Cache-Control, ETag, Last-Modified i Expires.

Dlaczego odświeżanie zniekształca wynik testu

Sposób ponownego wczytania strony zmienia zachowanie przeglądarki. Według MDN zwykłe odświeżenie powoduje, że przeglądarka dopisuje do żądania max-age=0 wraz ze znacznikami i prosi serwer o potwierdzenie. Odświeżenie wymuszone, czyli z pominięciem pamięci, zawsze pobiera pełną odpowiedź. Żaden z tych sposobów nie pokazuje tego, co widzi klient wracający na stronę z wyszukiwarki. Aby to zobaczyć, należy wpisać adres ponownie albo przejść na stronę zwykłym odnośnikiem.

Hydraulik z Łodzi poprawił na stronie numer telefonu i po odświeżeniu widział nowy, podczas gdy klienci dzwonili pod stary. Odświeżenie wymusiło pobranie świeżego dokumentu tylko na jego komputerze. Przyczyną był dokument HTML wysyłany z długim max-age zamiast no-cache.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Jak czytać zalecenie Lighthouse dotyczące pamięci podręcznej

Lighthouse wypisuje pliki statyczne, które nie mają wystarczająco długiego czasu przechowywania, i podaje przy każdym obecny czas oraz rozmiar transferu. Zalecenie nie mówi, że strona jest zepsuta, tylko że powracający odwiedzający pobierają ponownie dane, które mogłyby leżeć na ich urządzeniach.

W starszych wersjach narzędzia audyt nosił angielską nazwę Serve static assets with an efficient cache policy, co oznacza wyświetlanie zasobów statycznych z wydajną zasadą pamięci podręcznej. W nowszej dokumentacji Chrome to samo zagadnienie opisane jest jako Use efficient cache lifetimes, czyli stosowanie wydajnych czasów przechowywania. W polskiej wersji interfejsu brzmienie może się nieznacznie różnić. Uruchomienie audytu opisujemy we wpisie o tym, jak przeprowadzić audyt Lighthouse w Chrome, a odczytywanie całego raportu we wpisie o tym, jak czytać raport PageSpeed Insights.

Które pliki są oceniane

Według dokumentacji zasób jest uznawany za nadający się do przechowywania, gdy spełnia łącznie trzy warunki: jest czcionką, obrazem, plikiem multimedialnym, skryptem lub arkuszem stylów, serwer zwrócił dla niego kod 200, 203 lub 206, a nagłówki odpowiedzi nie zakazują wprost przechowywania. Dokumenty HTML nie należą do tej grupy, więc ustawienie dla nich no-cache nie pogarsza wyniku.

Tabela w raporcie ma trzy kolumny: adres zasobu, obecny czas przechowywania oraz rozmiar transferu. Rozmiar jest szacunkiem danych, których odwiedzający nie musiałby pobierać, gdyby plik był przechowywany. Od niego warto zacząć porządki: duży obraz bez nagłówka znaczy więcej niż mały plik ikony.

Pliki z obcych domen

Na liście często znajdują się zasoby, na które właściciel strony nie ma wpływu: skrypty statystyk, mapy, czatu, wtyczek społecznościowych. Ich nagłówki ustawia dostawca. To obserwacja z naszej praktyki: takich pozycji nie da się naprawić konfiguracją własnego serwera, można jedynie ocenić, czy dany dodatek jest stronie potrzebny. Dokumentacja Lighthouse zaznacza też, że dłuższy czas nie zawsze jest lepszy. Celem nie jest pusty raport, lecz stan, w którym pliki niezmienne leżą w pamięci długo, a pliki zmienne są potwierdzane.

Czy nagłówki pamięci podręcznej mają znaczenie dla robotów Google

Tak, choć w węższym zakresie niż dla przeglądarek: roboty Google korzystają z nagłówków ETag i Last-Modified, aby nie pobierać ponownie treści, która się nie zmieniła. Informacje te pochodzą z dokumentacji Google poświęconej robotom.

Infrastruktura indeksowania Google obsługuje pary nagłówków ETag z If-None-Match oraz Last-Modified z If-Modified-Since. Jeśli odpowiedź zawiera oba, roboty używają wartości ETag. Google zaleca ETag, ponieważ nie niesie ryzyka błędów w formacie daty. Dyrektywa max-age nie jest wymagana, ale pomaga robotom ustalić, kiedy ponownie odwiedzić dany adres; jej wartością powinna być przewidywana liczba sekund, przez które treść pozostanie bez zmian. Pozostałe dyrektywy pamięci podręcznej nie są przez roboty obsługiwane.

Googlebot używa pamięci podręcznej przy ponownym pobieraniu adresów na potrzeby wyszukiwarki. Dla dużych serwisów ma to wymiar praktyczny: odpowiedź 304 jest lżejsza od pełnej strony. Nie należy jednak oczekiwać, że samo dodanie nagłówków zmieni pozycje strony. To porządek techniczny, który ułatwia pracę serwerowi i robotom. Warunkiem jest poprawność: serwer, który zwraca 304 mimo zmiany treści, ukrywa aktualizację przed przeglądarkami i robotami.

Typowe pomyłki przy ustawianiu Cache-Control i kiedy potrzebna jest pomoc

Najczęstsze błędy to długi czas przechowywania dla dokumentu HTML, długi czas dla plików bez wersji w adresie oraz nadużywanie no-store. Każdy z nich daje inne objawy, więc łatwo je rozpoznać po skargach odwiedzających.

Długi max-age dla HTML objawia się tym, że zmiany treści nie docierają do stałych klientów: nowa oferta, nowy numer telefonu, poprawiony cennik. Długi max-age dla stylów i skryptów bez wersji daje rozsypany wygląd po aktualizacji, bo nowy dokument HTML spotyka się ze starym arkuszem stylów. No-store ustawione na całej witrynie sprawia, że każda podstrona pobiera wszystko od nowa.

Osobną grupą są pomyłki wynikające z nazw. No-cache bywa stosowane w przekonaniu, że blokuje zapis. Public bywa dopisywane do każdego pliku, chociaż jest potrzebne tylko przy żądaniach z autoryzacją. Brak private na stronach po zalogowaniu ma poważniejsze skutki, ponieważ dotyczy danych osób. Jeśli witryna przetwarza dane klientów, a przed nią działa pamięć współdzielona, konfigurację powinien obejrzeć specjalista, a kwestie ochrony danych warto omówić z prawnikiem.

• Dokument HTML ma no-cache oraz ETag lub Last-Modified.
• Style, skrypty i czcionki mają wersję lub skrót w adresie i roczny max-age.
• Obrazy bez wersji w nazwie mają co najmniej 30 dni, a ich podmiana odbywa się przez nową nazwę pliku.
• Strony po zalogowaniu, koszyk i panel klienta mają dopisek private.
• No-store występuje tylko tam, gdzie kopia naprawdę nie może zostać na urządzeniu.
• Sieć CDN nie nadpisuje nagłówków w sposób sprzeczny z ustawieniami serwera.
• Ponowne żądanie niezmienionego pliku kończy się odpowiedzią 304.

Samodzielnie można sprawdzić nagłówki w przeglądarce i porównać je z powyższą listą. Zmiana konfiguracji bywa trudniejsza: wymaga dostępu do serwera i przetestowania, czy wtyczki, serwer i sieć CDN nie wysyłają sprzecznych instrukcji. Pomoc jest szczególnie wskazana przy sklepach, serwisach z logowaniem oraz podczas przenosin na nowy serwer, dlatego przegląd nagłówków warto włączyć do planu, który opisujemy przy usłudze migracji domeny i hostingu. Kontrola pamięci podręcznej jest stałym elementem prac, jakie prowadzimy w ramach SEO technicznego, a jej wyniki trafiają do raportu, który powstaje podczas audytu SEO.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl