Nagłówki Cache-Control

P2Lab Cache kontroluje cztery niezależne lifetime cache na każdej cache’owalnej odpowiedzi. Źle dobrana kombinacja albo over-cachuje stale treści na edge’u, albo under-cachuje i tracisz korzyść szybkości.

Wszystkie cztery są konfigurowane pod Settings → Speed Boost → Dashboard → Configuration.

Cztery lifetime

Server TTL (`serverTtl`)

Jak długo wpis żyje wewnątrz cache Twojego origin (Filesystem / Redis / APCu). Domyślnie 1 dzień.

Gdy to wygasa, następne żądanie triggeruje regenerację niezależnie od jakichkolwiek nagłówków HTTP.

Ustaw to na swoją “maksymalną tolerowalną staleness” — jak długo akceptowalne jest, by strona siedziała w cache bez czyjegokolwiek dotknięcia.

`Cache-Control: max-age` (browser)

Jak długo przeglądarka może reużyć cache’owaną odpowiedź bez revalidacji przeciw Twojemu origin. Domyślnie 0 (bez cache browsera).

0 oznacza, że każde załadowanie strony trafia Twój origin (który prawdopodobnie serwuje z cache — szybko — ale roundtrip się zdarza). Podbij do np. 300 (5 minut), jeśli chcesz, by przeglądarka pominęła roundtrip na krótkie okno.

`Cache-Control: s-maxage` (shared cache)

Jak długo shared cache między przeglądarką a Twoim origin (Varnish, Nginx, CDN, który nie rozumie CDN-Cache-Control) może reużyć odpowiedź. Domyślnie 6 godzin.

Gdy Varnish otrzymuje odpowiedź z s-maxage: 21600, zapisuje odpowiedź na 6 godzin i serwuje kolejne żądania z własnej pamięci — bez trafiania w Twój origin (chyba że odpali jawny purge).

`CDN-Cache-Control: max-age` (tylko CDN)

CDN-specyficzna dyrektywa rozpoznawana przez Cloudflare, Fastly i Akamai. Domyślnie wyłączone (nagłówek niewysyłany).

Wartość ma zastosowanie tylko na CDN i tylko dla tych CDN-ów, które ją rozumieją. Przeglądarki i inne shared cache ignorują nagłówek.

Używaj, gdy chcesz różnych czasów cache na CDN vs innych shared cache (np. 1 dzień na CDN, 6 godzin na Varnishu).

Jak się łączą

Dla każdego żądania warstwy cache działają niezależnie:

[Browser] ←─ Cache-Control: max-age=0
            ↓
[CDN]     ←─ CDN-Cache-Control: max-age=86400
            ↓
[Varnish] ←─ Cache-Control: s-maxage=21600
            ↓
[Origin / P2Lab Cache] ←─ serverTtl=86400
            ↓
[Render Shopware]

Typowy setup “szybki ale dokładny”:

serverTtl: 86400 (1 dzień — długo, bo inwalidacja i tak purguje)
max-age: 0 (niech browser zawsze sprawdza)
s-maxage: 21600 (Varnish serwuje przez 6 godzin, potem re-fetchuje)
CDN-Cache-Control: 86400 (CDN serwuje przez 1 dzień; CDN purge przy deployu)

“Maksymalna szybkość, akceptuj trochę staleness”:

serverTtl: 86400
max-age: 300 (browser trzyma przez 5 minut)
s-maxage: 86400 (Varnish trzyma przez 1 dzień; deploye muszą triggerować purge)
CDN-Cache-Control: 86400

“Zawsze świeże, bez staleness”:

serverTtl: 3600
max-age: 0
s-maxage: 0
CDN-Cache-Control: disabled

Zakres kanału sprzedaży

Wszystkie cztery są per kanał sprzedaży. Typowo: kanał B2B z s-maxage: 0 (bez shared cachingu) i kanał B2C z dłuższymi czasami.

A co z inwalidacją?

Cztery lifetime są expiry-based. Inwalidacja jest event-based i działa niezależnie:

Save produktu ze Smart inwalidacją purguje dotknięte wpisy z origin cache natychmiast, niezależnie od serverTtl.
Xkey purge do Varnisha upuszcza odpowiedź z Varnisha natychmiast, niezależnie od s-maxage.
Przeglądarka nie jest purgowana — max-age wciąż ma zastosowanie. Ustaw max-age: 0, jeśli nie możesz tolerować stale stron w cache browsera.
CDN jest purgowany tylko, jeśli skonfigurowałeś purge CDN osobno (nie ship’ujemy tej integracji out of the box).

Nadpisania per trasa

Plugin ustawia te same nagłówki na każdej cache’owalnej odpowiedzi. By nadpisać dla konkretnej trasy (np. niższe s-maxage dla strony wrażliwej na stock), dodaj custom event subscriber, który mutuje odpowiedź.

Nagłówki Cache-Control

Cztery lifetime

Server TTL (serverTtl)

Cache-Control: max-age (browser)

Cache-Control: s-maxage (shared cache)

CDN-Cache-Control: max-age (tylko CDN)