Spis treści
Dlaczego CDN i dynamiczny HTML się nie wykluczają
CDN nie musi oznaczać wyłącznie statycznych plików. Dzięki fragmentacji widoku i inteligentnym kluczom cache można buforować większość HTML, a część wrażliwą serwować dynamicznie. Efekt to niższy TTFB dla gości i szybszy LCP przy zachowaniu poprawności sesji.
Klucz polega na rozdzieleniu tego, co wspólne dla wszystkich, od tego, co per użytkownik. Jeśli szablon strony i treść główna są wspólne, a różni się jedynie pasek „Witaj, Jan”, koszyk czy banner A/B, to wystarczy „dziurawić” dokument na te fragmenty zamiast wyłączać cache dla całości.
Wzorce architektoniczne: fragmenty i ESI
Edge Side Includes (ESI) pozwala dzielić dokument na fragmenty renderowane i cache’owane niezależnie. Główny HTML może mieć długi TTL, a małe inkludy dla koszyka czy personalizacji pobierane są z originu lub z krótkiego mikrocache. To minimalizuje fragmentację wspólnego cache i ogranicza obciążenie serwera.
Alternatywą dla ESI jest składanie na krawędzi: funkcje edge lub workers wstrzykują fragmenty do buforowanego szablonu. Ten wzorzec sprawdza się, gdy nie masz wsparcia ESI, ale dysponujesz logiką na edge. Fragmenty, które nie mogą być współdzielone (np. saldo konta), oznacz jako no-store i pobieraj wyłącznie po HTTPS z autoryzacją, bez zapisywania we wspólnym cache.
Dla elementów półdynamicznych zastosuj mikrocache 10–60 s. Przykład to licznik stanów magazynowych, kursy walut, listy bestsellerów. Taki bufor wygładza skoki ruchu i pozwala uniknąć „thundering herd”, a użytkownik nie odczuwa opóźnień.
BYO cache keys: jak budować klucze, by nie pofragmentować cache
BYO cache keys oznacza, że sam definiujesz, co wchodzi do klucza cache. Wspólny błąd to dokładanie do klucza wszystkiego, co widać w żądaniu. Zamiast tego włącz tylko te wymiary, które realnie zmieniają HTML.
Praktyczny szablon klucza:
- Ścieżka i wybrane parametry wpływające na widok – np.
?page=,?sort=,?color=. - Bucket urządzenia – desktop vs mobile, jeśli layout się różni.
- Region lub strefa cenowa – kraj, waluta, strefa podatkowa w postaci znormalizowanego koszyka, np.
eu|usd|vat20. - Wersja szablonu – numer builda, aby po deployu naturalnie przewietrzyć cache.
Czego nie dodawać do klucza: parametry śledzące (utm_*, gclid, fbclid), całe nagłówki Cookie oraz nietrwałe identyfikatory sesji i tokeny CSRF.
Jeśli platforma wspiera tagowanie obiektów, dodaj nagłówek lub metadane typu „Surrogate-Key: post:123, cat:shoes”. Dzięki temu unieważnisz właściwe fragmenty po publikacji lub zmianie cen, bez czyszczenia całego cache.
Strategie personalizacji bez niszczenia cache
1) „Hole punching” dla elementów per użytkownik
Buforuj dokument bez stanu użytkownika, a personalizację wstrzykuj jako ESI lub dynamiczny fetch na edge. Dla koszyka, licznika „recently viewed” czy banera konta ustaw no-store i krótki timeout.
2) Personalizacja po stronie klienta
Główny HTML i dane publiczne idą z cache, a per-user detale dociągane są AJAX-em z endpointu chronionego tokenem. Ten endpoint nie trafia do współdzielonego cache, za to dokument HTML zachowuje wysoki hit ratio.
3) Warianty oparte na bucketach
Zamiast tworzyć setki wariantów, użyj kilku kubełków: 2–4 segmenty geograficzne, 2 layouty RWD, 2–3 koszyki cenowe. Klucz cache zawiera tylko kubełek, a nie pełny wektor cech użytkownika.
4) Serwowanie warunkowe, ale kontrolowane
Jeżeli musisz zmienić całe drzewo DOM (np. inny hero dla kampanii), dodaj do klucza jedną kontrolowaną zmienną, np. campaign=A lub campaign=B. Unikaj łączenia jej z parametrami śledzącymi.
Uzupełnienia: stosuj stale-while-revalidate, rozważ Early Hints 103 i pamiętaj o crossorigin dla fontów.
Inwalidacja, spójność i bezpieczeństwo
Bezpieczny cache zaczyna się od reguły: odpowiedzi z Set-Cookie i prywatnymi danymi nie mogą trafiać do współdzielonego cache. Ustaw Cache-Control: no-store dla stron konta, checkoutu, paneli i API z danymi wrażliwymi. Z kolei treści publiczne oznacz public, max-age=..., stale-while-revalidate=....
Inwalidację opieraj na tagach lub ścieżkach. Po publikacji artykułu unieważnij jego URL oraz listy, które go zawierają. Po zmianie ceny produktu unieważnij karty produktu, listy kategorii i bloki rekomendacji. Unikaj „purge all”.
Dbaj o idempotencję i metody HTTP. GET może być buforowany, POST nie. Endpointy AJAX tylko do odczytu serwuj jako GET z odpowiednimi nagłówkami. Jeżeli musisz użyć POST, wyłącz cache i włącz zabezpieczenia.
Pomiar efektów i kontrola jakości
Mierz w terenie p75 LCP, TTFB dokumentu, hit ratio per ścieżka. Osobno oceniaj „guest” vs „logged-in”.
Sprawdzaj, czy prywatne dane nie trafiają do cache. W próbkach HTML szukaj tokenów i identyfikatorów. W DevTools weryfikuj, że elementy per użytkownik ładują się osobno i mają Cache-Control: no-store.
Diagnozuj fragmentację – jeśli hit ratio spada, zwykle winne są parametry UTM albo zbyt wiele wymiarów w kluczu. Znormalizuj parametry, ogranicz liczbę bucketów i trzymaj stabilny build id w kluczu.
Dobre praktyki dla e-commerce i treści
E-commerce: cache kategorii i kart produktu dla gości, bypass koszyka i checkoutu. Liczniki stanów i ceny w mikrocache. Rekomendacje z krótkim TTL lub no-store.
Portale i blogi: długi TTL dla artykułów, listy z stale-while-revalidate, widgety „najczęściej czytane” w mikrocache. Kategorie korzystają z BYO keys dla sortowania i filtrów.
SaaS i panele: marketing publiczny cache’uj agresywnie, aplikację właściwą traktuj jak prywatną – HTML no-store, API zabezpieczone, ewentualny cache po stronie klienta.
Podsumowując
CDN i dynamiczne treści współgrają, jeśli rozdzielisz wspólny szablon od danych per użytkownik. Zastosuj ESI lub składanie na krawędzi do „dziurawienia” dokumentu, a BYO cache keys zredukuje fragmentację i podniesie hit ratio. Personalizację realizuj przez fragmenty, buckety i żądania klienta, a prywatne dane trzymaj poza współdzielonym cache. Dodaj stale-while-revalidate, mądre inwalidacje i monitoring p75 LCP oraz TTFB – to da szybki serwis bez kompromisów na bezpieczeństwie i poprawności sesji.
