Cache HTTP i TTL: działanie, strategie i wpływ na SEO

Cache HTTP i TTL (Time To Live) to dwa fundamentalne pojęcia związane z wydajnością stron internetowych. Cache umożliwia tymczasowe przechowywanie zasobów (obrazów, CSS, JavaScript) blisko użytkownika, dzięki czemu nie muszą być pobierane ponownie przy każdej wizycie. TTL określa, jak długo zasób może pozostawać w tym cache, zanim zostanie uznany za przestarzały. Prawidłowo skonfigurowane mechanizmy te znacznie skracają czasy ładowania, odciążają serwer źródłowy i poprawiają Core Web Vitals, co ma bezpośredni wpływ na SEO.

Czym jest cache HTTP?

Cache HTTP to mechanizm pozwalający różnym komponentom łańcucha dostarczania stron internetowych przechowywać lokalną kopię pobranych zasobów. Gdy przeglądarka ładuje stronę po raz pierwszy, pobiera każdy zasób z serwera. Jeśli zasoby te są opatrzone nagłówkami HTTP wskazującymi, że mogą być buforowane, przeglądarka (i/lub CDN) zachowuje ich kopię. Przy kolejnych wizytach zasób jest serwowany z lokalnego cache zamiast być ponownie pobierany z serwera, co jest zdecydowanie szybsze.

W łańcuchu dostarczania zasobów webowych istnieje kilka poziomów cache. Cache przeglądarki przechowuje zasoby bezpośrednio na urządzeniu użytkownika, na dysku twardym lub w pamięci operacyjnej. Cache CDN (zwany również edge cache) przechowuje zasoby na serwerach sieci dostarczania treści zlokalizowanych geograficznie blisko użytkowników. Cache serwerowy (reverse proxy cache, np. Varnish lub Nginx) przechowuje zasoby po stronie hostingu, zanim jeszcze trafią do sieci.

Nagłówki Cache-Control: jak definiować zachowanie cache

Nagłówek HTTP Cache-Control to główny mechanizm, za pomocą którego serwer przekazuje instrukcje dotyczące buforowania. Jest wysyłany z każdą odpowiedzią HTTP i może zawierać kilka kombinowanych dyrektyw. Oto najważniejsze z nich:

• max-age=N: zasób może być przechowywany w cache przez N sekund. Przykład: max-age=31536000 = 1 rok. Najczęściej stosowana dyrektywa dla zasobów statycznych.
• s-maxage=N: podobnie jak max-age, ale dotyczy wyłącznie współdzielonych cache (CDN, reverse proxy), a nie cache przeglądarki. Umożliwia różne polityki dla CDN i przeglądarki.
• no-cache: zasób może być buforowany, ale cache musi zawsze weryfikować u serwera, czy jest jeszcze aktualny przed jego serwowaniem (poprzez ETag lub Last-Modified).
• no-store: zasób nie może być nigdzie i w żaden sposób buforowany. Stosować wyłącznie dla bardzo wrażliwych treści (dane osobowe, transakcje).
• public: zasób może być buforowany przez dowolny cache, w tym współdzielone cache CDN.
• private: zasób może być buforowany wyłącznie przez przeglądarkę użytkownika, nie przez pośrednie cache.
• immutable: wskazuje, że zasób nigdy nie zmieni się w trakcie swojego okresu ważności (max-age). Przeglądarka nie wyśle żądania walidacji nawet po wygaśnięciu TTL.

W przypadku statycznych obrazów w sklepie e-commerce optymalna dyrektywa to zazwyczaj: Cache-Control: public, max-age=31536000, immutable. Ta kombinacja wskazuje, że obraz może być buforowany publicznie przez rok i że nie ulegnie zmianie. Jeśli obraz się zmieni (nowe zdjęcie produktu), URL musi się zmienić, aby ominąć cache: technika zwana "cache bustingiem" przez wersjonowanie URL.

TTL (Time To Live): jak długo przechowywać zasób w cache?

TTL (Time To Live) to czas, przez który buforowany zasób jest uznawany za świeży (fresh) i może być serwowany bezpośrednio bez sprawdzania serwera źródłowego. Jest wyrażony w sekundach w nagłówku max-age. Po upływie tego czasu zasób jest uznawany za przestarzały (stale): może być nadal serwowany w pewnych sytuacjach, ale cache powinien go ideowo ponownie zwalidować.

Wybór TTL to kompromis między dwoma sprzecznymi celami: maksymalizacją wykorzystania cache (długi TTL = mniej żądań do serwera) a gwarantowaniem, że użytkownicy otrzymują aktualne treści (krótki TTL = zmiany propagują się szybko). Dla zasobów rzadko zmieniających się, jak obrazy produktów, optymalny jest długi TTL (1 rok). Dla zasobów często zmieniających się, jak ceny czy stany magazynowe, konieczny jest krótki lub zerowy TTL.

• 1 rok (31 536 000 sekund): obrazy produktów, wersjonowane CSS/JS, czcionki webowe — stabilne zasoby z wersjonowaniem URL
• 1 miesiąc (2 592 000 sekund): obrazy marki lub kategorii aktualizowane okazjonalnie
• 1 godzina do 1 dnia: treści półdynamiczne, strony kategorii, listy produktów
• 0 lub no-store: strony koszyka, strony płatności, dane zalogowanego użytkownika — nigdy nie buforować

Inwalidacja cache: jak zarządzać zmianami treści

Długoterminowe buforowanie rodzi oczywiste pytanie: co się dzieje, gdy treść się zmienia? Jeśli obraz jest buforowany przez 1 rok, ale zostanie zmieniony po 2 miesiącach, odwiedzający będą nadal widzieć starą wersję przez 10 miesięcy. Tu właśnie wchodzą strategie inwalidacji cache.

Najbardziej niezawodna strategia to wersjonowanie URL (URL versioning lub cache busting). Zasada: URL zasobu zawiera unikalny identyfikator, który zmienia się za każdym razem, gdy zasób ulega zmianie. Na przykład /images/produkt-but-v2.webp zamiast /images/produkt-but.webp. Lub poprzez parametr: /images/produkt.jpg?v=1705234567. Gdy obraz się zmienia, URL się zmienia, a cache traktuje ten nowy URL jako zupełnie nowy zasób, bez problemów z przestarzałą treścią.

Inną strategią jest API purge CDN: nowoczesne sieci CDN udostępniają API pozwalające natychmiastowo unieważniać określone URL-e lub grupy URL-i w ich cache. Gdy sprzedawca zmienia obraz w panelu administracyjnym, wywołanie API do CDN unieważnia cache dla tego obrazu. Kolejne wizyty pobierają nową wersję bezpośrednio z serwera źródłowego, która jest następnie ponownie buforowana.

Cache CDN vs cache przeglądarki: komplementarność i różnice

Cache CDN i cache przeglądarki uzupełniają się i służą różnym celom. Cache CDN przynosi korzyści wszystkim odwiedzającym, nowym i powracającym: obraz zbuforowany na węźle CDN w Warszawie jest szybko serwowany każdemu odwiedzającemu w Polsce, niezależnie od tego, czy wcześniej odwiedził Twój sklep. Cache przeglądarki przynosi korzyści wyłącznie powracającym odwiedzającym, na ich własnym urządzeniu: jeśli użytkownik pobrał już obraz podczas poprzedniej wizyty, jego przeglądarka serwuje go z lokalnego dysku bez żadnego żądania sieciowego.

W praktyce oba poziomy cache się uzupełniają: cache CDN zmniejsza opóźnienie przy pierwszym załadowaniu strony (nowy odwiedzający lub wygasły cache przeglądarki), natomiast cache przeglądarki całkowicie eliminuje sieć przy powtarzanych wizytach na tym samym urządzeniu. Zasób z max-age=31536000 będzie wymagał żądania sieciowego tylko raz w roku na urządzenie, co jest bardzo istotnym zyskiem wydajnościowym dla stałych odwiedzających.

ETag i Last-Modified: warunkowa walidacja cache

Nawet po wygaśnięciu TTL przeglądarka nie jest zmuszona do pobierania zasobu od nowa. Może wysłać warunkowe żądanie, aby sprawdzić, czy zasób się zmienił: jeśli nie, serwer odpowiada kodem HTTP 304 (Not Modified) bez treści odpowiedzi, oszczędzając przepustowość i jednocześnie potwierdzając aktualność zbuforowanego zasobu.

ETag (Entity Tag) to unikalny identyfikator generowany przez serwer dla określonej wersji zasobu, typowo hash zawartości pliku. Gdy przeglądarka wysyła warunkowe żądanie, przesyła ETag swojej zbuforowanej wersji w nagłówku If-None-Match. Jeśli serwer ma ten sam ETag (zasób się nie zmienił), odpowiada 304; w przeciwnym razie wysyła nową wersję z nowym ETagiem.

Nagłówek Last-Modified działa podobnie: serwer wskazuje datę ostatniej modyfikacji zasobu, a przeglądarka przesyła ją w If-Modified-Since przy warunkowych żądaniach. Te mechanizmy walidacji pozwalają utrzymywać cache w aktualnym stanie bez marnowania przepustowości, gdy treść nie uległa zmianie.

Jak Lexiik automatycznie zarządza cache i inwalidacją

Lexiik implementuje optymalną strategię cache dla obrazów sklepów PrestaShop, automatycznie rozwiązując problem inwalidacji, który normalnie sprawia, że długoterminowe buforowanie jest ryzykowne. Każdy obraz przesłany na Cloudflare R2 otrzymuje nagłówki Cache-Control: public, max-age=31536000, immutable — rok buforowania na wszystkich węzłach edge Cloudflare i w przeglądarkach odwiedzających.

Problem inwalidacji jest obsługiwany automatycznie przez Lexiik za pomocą dwóch mechanizmów. Po pierwsze, wersjonowanie URL: obrazy serwowane przez Lexiik CDN używają identyfikatorów w swoich URL-ach, które zmieniają się automatycznie po modyfikacji obrazu w panelu administracyjnym PrestaShop. Po drugie, automatyczne wywołania API purge Cloudflare: gdy obraz się zmienia, Lexiik wysyła żądanie purge do Cloudflare, aby natychmiastowo unieważnić cache CDN dla tego konkretnego obrazu, nie wpływając na inne. Odwiedzający otrzymują nowy obraz przy następnej wizycie, nigdy nie widząc przestarzałej wersji.

Dlaczego długoterminowy cache poprawia SEO

Roczny TTL na obrazach produktów poprawia SEO za pomocą kilku bezpośrednich i pośrednich mechanizmów. Bezpośrednio: obrazy ładowane z cache (CDN lub przeglądarka) pojawiają się w dziesiątkach lub setkach milisekund, w porównaniu z kilkoma sekundami przy pełnym pobraniu sieciowym. Poprawia to LCP, metrykę Core Web Vitals najbardziej powiązaną z obrazami, i może przenieść stronę z oceny „Słaba” na „Dobra” według progów Google.

Pośrednio, skuteczny cache zmniejsza liczbę żądań HTTP wysyłanych do serwera źródłowego. Mniejsze obciążenie serwera = lepszy TTFB (Time To First Byte) dla dynamicznej treści HTML generowanej przez Twój PrestaShop. Google zaleca TTFB poniżej 200 ms; serwer przeciążony żądaniami obrazów może mieć pogorszony TTFB wpływający na wszystkie metryki wydajności.

Wreszcie, dla powracających odwiedzających, którzy często są najbardziej skłonni do konwersji, dobrze skonfigurowany cache przeglądarki tworzy niemal natychmiastowe doświadczenie przeglądania. Strony produktów wydają się ładować błyskawicznie, a obrazy są już w pamięci. To upłynnia lejek zakupowy i zmniejsza porzucenia, z pozytywnym wpływem na metryki behawioralne, które Google może brać pod uwagę.

• Poprawione LCP: obrazy ładowane z lokalnego cache lub CDN w milisekundach
• Poprawione TTFB: mniej żądań do serwera źródłowego = mniejsze obciążenie serwera = HTML dostarczany szybciej
• Lepszy wynik PageSpeed: Google Lighthouse penalizuje brak polityki długoterminowego cache
• Oszczędność przepustowości: mniej przesyłanych danych = niższe koszty i lepsza wydajność na urządzeniach mobilnych
• Lepsze doświadczenie powracających odwiedzających: niemal natychmiastowa nawigacja dla stałych klientów