Mapuj politykę do zasobu, nie do serwera
Zrób inwentaryzację reprezentatywnych URL przed zmianą nagłówków: strona główna, strona treści, szkielet aplikacji, CSS, JavaScript, obrazy, fonty, API, logowanie, konto, koszyk i pliki do pobrania. Dla każdego zanotuj, czy odpowiedź jest publiczna czy spersonalizowana, czy URL zmienia się przy zmianie bajtów oraz jak szybko poprawka musi dotrzeć do odwiedzających.
Utwórz macierz polityk na podstawie tej inwentaryzacji. Publiczny zasób adresowany treścią potrzebuje innej reguły niż HTML pod stabilnym adresem. Odpowiedzi bez Cache-Control mogą być nadal buforowane heurystycznie, więc jawne reguły są łatwiejsze do przetestowania.
Okres, przez który przechowywana odpowiedź może być ponownie użyta; max-age podaje go w sekundach.
Używaj precyzyjnie terminów Cache-Control
Cache-Control mówi przeglądarkom i wspólnym cache'om, jak przechowywać i ponownie używać odpowiedź. max-age=N pozwala na ponowne użycie, dopóki odpowiedź jest świeża. s-maxage=N ustawia świeżość dla cache'ów współdzielonych i nadpisuje max-age tam, ale przeglądarki ignorują s-maxage. public pozwala dowolnemu cache'owi; private pozwala na buforowanie w przeglądarce, lecz blokuje przechowywanie w cache'ach współdzielonych.
no-cache pozwala na przechowywanie, lecz wymaga walidacji u origin przed ponownym użyciem. no-store oznacza, że cache'e nie mogą przechowywać odpowiedzi, ale nie jest to kompletna kontrola prywatności. Używaj must-revalidate, gdy serwowanie przeterminowanej zawartości po wygaśnięciu jest nieakceptowalne; niedostępny origin może wtedy zwrócić 504 zamiast przestarzałego podglądu.
Usuwa przechowywanie zamiast jedynie wymagać sprawdzenia; zarezerwuj je dla odpowiedzi, które naprawdę nie mogą być przechowywane.
Wersjonuj niemutowalne zasoby przed nadaniem długiego czasu życia
Adres URL wersjonowanego zasobu zawiera fingerprint treści lub numer wersji wydania, np. app.4f2c.js. Gdy bajty zasobu się zmienią, opublikuj inny URL i zaktualizuj referencję w HTML. Cache widzi nowy zasób, więc odwiedzający pobiorą nowy plik bez konieczności wymuszania unieważnienia w każdej przeglądarce.
Dla reprezentacji, która nie zmieni się w czasie swojej świeżości, Cache-Control: max-age=31536000, immutable to praktyczny wzorzec. immutable informuje obsługujące klienty, aby nie wykonywały warunkowej walidacji, dopóki zasób jest świeży. Nie stosuj go ani rocznego max-age do pliku o tej samej nazwie, który jest mutowalny. Zachowaj poprzednie zasoby z fingerprintem tak długo, jak długo może istnieć cache'owany HTML, który je referencuje.
HTML wybiera URL zasobów, więc sekwencjonowanie wydań musi zachować referencjonowaną generację.
Utrzymuj aktualność HTML przez walidację, nie długie buforowanie
HTML zwykle ma stabilny, czytelny dla ludzi URL i zmienia się wraz z treścią, referencjami do zasobów, flagami funkcji lub komunikatami bezpieczeństwa. Konserwatywny publiczny wzorzec dla HTML to Cache-Control: no-cache z ETag i Last-Modified, gdy platforma potrafi je poprawnie wygenerować. Przeglądarka przechowuje ciało, ale używa warunkowego żądania przed ponownym użyciem; niezmieniona odpowiedź może zwrócić 304 Not Modified bez ciała.
ETag identyfikuje wersję zasobu. Przy przeterminowanej odpowiedzi przeglądarka może wysłać go w If-None-Match; jeśli pasuje, serwer odpowiada 304, w przeciwnym razie wysyła nową reprezentację. Wytyczne RFC preferują stosowanie zarówno ETag, jak i Last-Modified w odpowiedzi 200, gdy to możliwe. no-cache nie gwarantuje walidacji przy nawigacji Back lub Forward, ponieważ przeglądarka może przywrócić snapshot historii sesji.
ETag musi zmieniać się, gdy reprezentacja się zmienia; przetestuj go między originami i wdrożeniami.
Oddziel dostarczanie publiczne od odpowiedzi spersonalizowanych i wrażliwych
Wspólny cache, taki jak CDN, może ponownie użyć jednej odpowiedzi dla wielu użytkowników. Nie pozwól mu na ponowne wykorzystanie HTML specyficznego dla konta lub danych API między różnymi użytkownikami. Dla treści spersonalizowanej, która może żyć w przeglądarce, sensiblem punktem startowym jest private, no-cache: zapobiega to przechowywaniu w cache'ach współdzielonych i wymaga walidacji. Sam nagłówek Set-Cookie nie zatrzymuje cache'owania.
Dla odpowiedzi, które nie powinny być przechowywane, użyj no-store i przejrzyj kod aplikacji, zasady CDN, service workery, pamięć przeglądarki, logi i strony błędów. Same nagłówki nie tworzą programu prywatności, zgodności ani bezpieczeństwa płatności. Zaangażuj kwalifikowanych recenzentów ds. bezpieczeństwa, prywatności i płatności, aby ocenili wrażliwe ścieżki i obowiązujące wymagania.
Przetestuj logowanie, wylogowanie, przełączanie kont i zmiany uprawnień przy ciepłych cache'ach przeglądarki i CDN.
Wdrażaj zmiany cache jako odwracalne wydanie
Zrób zrzut bazowych nagłówków i zachowania ciała dla żądań niebuforowanych i powtarzalnych. W stagingu wdrażaj najpierw wersjonowane zasoby, potem HTML, który je referuje, i testuj starszy zcache'owany HTML względem nowego origin. Sprawdź ścieżki bezpośrednie do origin i przez CDN, jeśli oba istnieją. Nagłówki w DevTools powinny pokazywać zamierzoną politykę i zachowanie przy powtórzeniach.
Prowadź manifest wydania z URL zasobów, regułami nagłówków i wersją konfiguracji. Jeśli wydanie łączy niekompatybilne pliki klienckie, przywróć kompatybilny HTML i zachowanie aplikacji, ale nie nadpisuj opublikowanego pliku z fingerprintem. Wskaż HTML na znaną-dobrą generację i zachowaj obie generacje dopóki cache'owany HTML może ich żądać. Czyszczenie cache współdzielonego nie zmusi przeglądarek do wyrzucenia świeżej odpowiedzi.
Zamieniaj błędy testów nagłówków, 404 zasobów i niezgodności wersji w zmiany do checklisty następnego wydania.