Cache pełnych stron

P2Lab Cache zastępuje domyślny HTTP cache store Shopware i serwuje kompletne odpowiedzi HTML dla cache’owalnych tras storefrontu. Gdy strona jest już w cache, następny odwiedzający dostaje ją bez dotykania silnika szablonów, bazy danych ani bootu frameworka — tylko warstwa HTTP.

Co się cache’uje

Każda odpowiedź storefrontu klasyfikowana jest jako jeden z typów cache:

Typ	Co obejmuje
product	Strony detalu produktu (`frontend.detail.page`)
category	Strony kategorii (`frontend.navigation.page`)
listing	AJAX-owe listingi + odpowiedzi filtrów (`frontend.navigation.page.ajax`, `frontend.navigation.filter`)
cms	Strony CMS i home page (`frontend.home.page`, `frontend.cms.page`)
buybox	Odpowiedzi async buybox (domyślnie off)

Przełącz każdy typ osobno w Settings → Speed Boost → Dashboard → Cacheable Routes.

Co nie jest cache’owane

P2Lab Cache stosuje te same reguły co standardowy HTTP cache Shopware do pomijania:

Zalogowani klienci (sesyjne cookie + customer context)
Koszyki z przynajmniej jedną pozycją
POST / PUT / DELETE — cache’owane są tylko odpowiedzi GET
Odpowiedzi z Cache-Control: no-store lub private
Odpowiedzi ustawiające wrażliwe cookies
Żądania z nieignorowanymi parametrami query

Plugin dodaje jedno dodatkowe pokrętło: Ignored Query Parameters (zobacz Filtrowanie parametrów query). Każdy parametr na liście jest usuwany z klucza cache — więc ?utm_source=newsletter i goły URL dzielą ten sam wpis.

Przepływ lookup cache

Dla każdego cache’owalnego żądania GET:

Oblicz klucz cache — URL + sales channel + currency + theme + wyczyszczony query string.
Lookup w backendzie — Filesystem, Redis lub APCu (cokolwiek jest skonfigurowane).
Jeśli znaleziono i nie wygasło → serwuj z cache (HIT). Wyślij nagłówki Cache-Control i, jeśli debug mode jest on, nagłówki X-P2Lab-Cache-*.
Jeśli nie znaleziono → niech Shopware wyrenderuje odpowiedź, przechwyć ją, zapisz pod kluczem cache z odpowiednim TTL i tag setem, potem zwróć (MISS).

Co jest zapisywane

Każdy wpis cache zapisuje:

Pełne body odpowiedzi HTTP (opcjonalnie skompresowane gzipem)
Nagłówki odpowiedzi, które Shopware ustawia
Tag set cache wyliczony dla tej odpowiedzi — używany później do inwalidacji
Metadane używane przez dashboard: rozmiar oryginalny, rozmiar w cache, czas generowania, czas obsługi HIT, typ

Metadane każdego wpisu są też persistowane w bazie (p2lab_cache_entry), więc dashboard może raportować liczby niezależnie od wybranego backendu.

TTL i świeżość

Trzy ustawienia kontrolują, jak długo wpis żyje:

Cache TTL (domyślnie: 1 dzień) — TTL po stronie serwera. Wpis jest usuwany z backendu po tym czasie.
max-age (domyślnie: 0) — Cache-Control: max-age=… wysyłany do przeglądarki. 0 oznacza, że przeglądarka musi revalidować za każdym razem (cache i tak serwuje odpowiedź szybko).
s-maxage (domyślnie: 6 godzin) — Cache-Control: s-maxage=… wysyłany do shared cache między Tobą a przeglądarką.

Zobacz Nagłówki Cache-Control, jak trzy się łączą.

Kompresja

Gdy Enable Cache Compression jest on (domyślnie), zapisany payload jest gzip-kompresowany na wybranym poziomie. Body odpowiedzi HTTP wysłane do klienta nie jest kompresowane przez to ustawienie — tym zajmuje się osobno serwer www.

Typowe oszczędności:

Poziom	Ratio	Koszt CPU
1	~30%	bardzo niski
3	~40%	niski
6	~50%	zbalansowany (rekomendowany)
9	~55%	najwyższy

Zobacz Kompresja po notatki strojące.

Czyszczenie per typ

Dashboard ma przycisk Clear all plus per-type clears (Products / Categories / Listings / CMS / Buybox). Używaj ich zamiast czyszczenia całego cache Symfony, gdy chcesz tylko upuścić wycinek — np. po deployu samego CMS.

Statystyki

Dla każdego wpisu plugin notuje:

count per typ
total cached size vs total original size → total space saved
average generation time (render MISS)
average cache-hit time (obsługa HIT)

Dashboard odświeża to w czasie rzeczywistym podczas warmupów. Zobacz Dashboard admin.