Załóżmy, że biblioteka zmieniła na stronie dzisiejsze godziny otwarcia, ale niektórzy odwiedzający nadal widzą poprzednie. Najpierw trzeba rozróżnić, czy nie zmieniono źródła na serwerze, czy przeglądarka wykorzystała zapisaną odpowiedź, czy też pośredni serwer podał starszą wersję. Samo kilkakrotne odświeżenie strony nie wyjaśnia, na którym etapie leży przyczyna.
Pamięć podręczna HTTP przechowuje otrzymane odpowiedzi i wykorzystuje je ponownie, gdy pozwalają na to warunki. Na fikcyjnym przykładzie publicznych godzin otwarcia połączymy instrukcje przechowywania i ponownej walidacji w Cache-Control z ETag i odpowiedzią 304. Poniższe wymiany są skróconymi przykładami objaśniającymi, a nie pomiarami prawdziwej biblioteki lub konkretnego serwera. Celem jest zrozumienie, którą odpowiedź i kiedy wolno ponownie wykorzystać, zamiast traktowania wyłączenia wszystkich pamięci jako gotowego rozwiązania.
1. Osobno pytaj o zapis, sprawdzanie i udostępnianie
Czytając politykę buforowania, zapisz trzy pytania: czy wolno zapisać odpowiedź, czy przy kolejnym żądaniu wolno od razu wykorzystać jej kopię i czy można udostępniać ją wielu użytkownikom? Zezwolenie na zapis nie oznacza nieograniczonego ponownego użycia, a sprawdzenie aktualności nie daje automatycznie prawa do udostępniania innym. Standard buforowania HTTP RFC 9111 definiuje te warunki odrębnymi dyrektywami. Poniżej omawiamy dyrektywy odpowiedzi bez dodatkowego argumentu zawierającego nazwy pól.
| Pytanie do rozstrzygnięcia | Dyrektywa odpowiedzi | Znaczenie, które trzeba odróżnić |
|---|---|---|
| Czy nie wolno zapisać odpowiedzi? | no-store | Zakaz zapisu na potrzeby późniejszego wykorzystania |
| Czy przed użyciem trzeba sprawdzić kopię? | no-cache | Zapis jest możliwy, lecz ponowne użycie wymaga udanej walidacji |
| Czy odpowiedź można dzielić między użytkowników? | private | Wyklucza zapis we współdzielonej pamięci, ale nie zakazuje zapisu w pamięci prywatnej |
Jeśli publiczne godziny otwarcia często zmieniają się pod tym samym adresem, można rozważyć wymaganie sprawdzenia także zapisanej kopii przed jej użyciem. Strona spersonalizowana różni się od publicznego rozkładu już warunkami udostępniania. private dotyczy współdzielonych pamięci i nie zastępuje logowania ani sprawdzania uprawnień. Łączenie ustawień o różnych celach może sprawić, że poprawiając szybkość, błędnie określimy odbiorców informacji.
W zestawieniu polityki zapisz nie tylko dyrektywę, lecz także jej uzasadnienie. Odnotuj, czy rozkład jest informacją publiczną wymagającą kontroli zmian, czy logo jest plikiem o stałej treści i czy pod jednym adresem pojawiają się dane osobiste. Taka tabela jest punktem wyjścia do klasyfikacji rzeczywistych odpowiedzi, a nie kompletną konfiguracją dla wszystkich witryn. Trzeba również odróżniać miejsca zapisu, na przykład przeglądarkę i CDN.
2. Nie wybieraj no-cache i no-store wyłącznie według nazw
Nazwa no-cache łatwo kojarzy się z zakazem zapisu, ale w odpowiedzi nakazuje walidację zapisanej kopii przed ponownym użyciem. Jeśli serwer potwierdzi brak zmian, można ponownie użyć przechowanej treści. no-store przeciwnie: poleca nie przechowywać tej odpowiedzi. Ponieważ decyzja o zapisie różni się od sprawdzenia przy następnym żądaniu, nie należy oczekiwać identycznego działania obu ustawień.
W kontekście pamięci podręcznej fresh oznacza stan, w którym polityka dopuszcza ponowne użycie bez dodatkowej walidacji. Nie jest to gwarancja, że administrator w międzyczasie nie zmienił treści. Jeśli max-age wyznacza czas ponownego używania, zapisana odpowiedź może być wybierana w tym okresie także po zmianie źródła. Najpierw określ dopuszczalne opóźnienie aktualizacji, a potem powiąż je z dyrektywami. Nie kopiuj dowolnie długiego czasu przechowywania jako uniwersalnej odpowiedzi na problemy z wydajnością.
Przewodnik MDN po buforowaniu HTTP wyjaśnia, że dodanie no-store do nowej odpowiedzi nie usuwa wcześniej zapisanej odpowiedzi dla tego samego URL. Jeśli stara kopia nadal jest użyteczna i nowa odpowiedź nie jest pobierana, nowy nagłówek także może nie dotrzeć. Nie traktuj no-store jako polecenia wyczyszczenia każdej pamięci ani warunku wystarczającego do ochrony prywatności. Sprawdź też czas życia poprzednich odpowiedzi i procedurę aktualizacji pamięci, którymi zarządzasz.
3. Prześledź jedną ponowną wizytę z ETag i 304
Niech fikcyjny adres /hours.json początkowo informuje o zamknięciu o 18:00. Poniżej pokazano skróconą postać HTTP/1.1 z potrzebnymi elementami; inne nagłówki wymagane w rzeczywistej odpowiedzi pominięto. hours-v1 jest w tym przykładzie wybranym przez serwer identyfikatorem reprezentacji, a nie wzorem obliczania czasu ani prawdziwym skrótem pliku.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}Jeśli przeglądarka zapisała tę odpowiedź, przy następnym żądaniu warunkowym może przesłać wartość ETag w If-None-Match. Gdy warunek pasuje do aktualnie wybranej reprezentacji i serwer uzna, że nie nastąpiła zmiana, odpowiada 304 Not Modified. Kolejny blok pokazuje skrócone żądanie i odpowiedź po nim. Nie jest to przykład ponownego wysłania JSON z godzinami po odpowiedzi 304.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"Jak opisuje wyjaśnienie ETag w MDN, klient korzysta wtedy z zapisanej treści. W odpowiedzi 304 nie ma nowej treści odpowiedzi, ale żądanie i walidacja nadal oznaczają komunikację. Jeśli administrator przesunął zamknięcie na 19:00 i reprezentacja serwera się zmieniła, dla starego warunku można oczekiwać odpowiedzi 200 z nową treścią i nowym identyfikatorem. no-cache nie oznacza, że każda odpowiedź będzie miała kod 304 ani że znikną zapytania do bazy danych.
Sprawdzaj związek treści z identyfikatorem, nie tylko kod statusu. Zmiana treści przy zachowaniu starego ETag może dać nieprawidłowy wynik walidacji. Z kolei zmienianie identyfikatora przy tej samej treści może zwiększać liczbę ponownych przesłań zawartości. Po stronie serwera trzeba sprawdzić sposób generowania identyfikatora i jego związek z wybraną reprezentacją. Sama obecność ETag nie dowodzi poprawnej implementacji.
4. Rozróżniaj zmienne dokumenty i zasoby z nową nazwą
Dokument zmieniany pod stałym URL, na przykład godziny otwarcia, może wymagać innej strategii niż logo lub skrypt, któremu przy zmianie treści nadaje się nową nazwę. Gdy logo.a1.png staje się logo.b2.png, nowy dokument musi wskazywać nowy adres. Umieszczenie identyfikatora w nazwie i jednoczesne nadpisywanie treści starego pliku łamie założenie wspólnego zarządzania zawartością i adresem.
Samo przesłanie nowego pliku nie powoduje, że odwiedzający zażąda nowego adresu. Jeśli otrzymany HTML nadal wskazuje poprzednie logo, stary zasób może być używany ponownie. Dlatego oprócz ustawień pamięci dla zasobu sprawdzaj aktualizację odsyłającego do niego dokumentu. Zamiast narzucać wszystkim ten sam czas przechowywania, trzeba umieć wyjaśnić, jak duże opóźnienie zmiany jest dopuszczalne dla każdego elementu.
Podczas wdrożenia stare i nowe dokumenty mogą przez pewien czas działać równolegle. Opublikowanie nowego dokumentu przed przygotowaniem zasobów albo zbyt wczesne usunięcie poprzednich plików prowadzi do osobnych błędów. W tym fikcyjnym przypadku można sprawdzić istnienie plików wymaganych przez nowy dokument oraz dostępność plików wskazanych przez istniejące dokumenty. Zmiana nazwy pomaga w projektowaniu pamięci podręcznej, lecz nie rozwiązuje automatycznie kolejności wdrożeń ani problemów wycofania zmian.
5. W panelu Network sprawdzaj po jednej hipotezie
Zacznij od zapisu warunków odniesienia z włączoną pamięcią podręczną. Sprawdzaj razem dokładny URL z parametrami, wersję wyświetlanych godzin, status odpowiedzi, If-None-Match żądania oraz Cache-Control i ETag odpowiedzi. Nawet identyczne nazwy nagłówków żądania i odpowiedzi oznaczają warunki różnych stron; notuj, którą stronę czytasz. Dokumentacja panelu Network w Chrome DevTools pokazuje ich rozróżnianie w Headers.
| Fikcyjna sytuacja testowa | Dane oglądane łącznie | Zbyt pochopny wniosek |
|---|---|---|
| Ponowne żądanie tych samych godzin | Żądanie warunkowe, status i godzina na ekranie | Przy 304 w ogóle nie było komunikacji |
| Żądanie po zmianie godziny w źródle | Nowa treść, ETag i faktyczny URL żądania | Potwierdzenie zapisu oznacza aktualizację u wszystkich |
| Żądanie przy wyłączonej pamięci przeglądarki | Różnica między pierwszym pobraniem a zwykłym powrotem | Wynik odpowiada normalnej szybkości ponownej wizyty |
| Powrót przyciskiem Wstecz | Wystąpienie nowego żądania i przywrócony widok | Widoczny ekran oznacza nową walidację HTTP |
Następnie przetestuj wyłączenie pamięci przeglądarki jako osobny warunek. W Chrome ustawienie Disable cache obowiązuje, gdy DevTools pozostaje otwarte, więc zapisz zarówno stan narzędzia, jak i ustawienie. Pomaga to zbadać pierwsze pobranie, ale nie jest tym samym co obserwacja wykorzystania kopii przy zwykłym powrocie. Bez takiej notatki można błędnie uznać ciągłe pobieranie nowej treści za dowód, że pamięć nie działa. Zapisz warunki, aby móc wrócić do porównania z dozwolonym buforowaniem.
W czasie obserwacji nie mieszaj wielu zmian i żądań naraz. Najpierw sprawdź ponowną wizytę przy niezmienionej treści, a potem zmień jedną godzinę i zobacz różnicę odpowiedzi. Równoczesna zmiana URL dokumentu, ustawień serwera i nazw plików utrudnia ustalenie przyczyny wyniku. Gdy nie pojawi się spodziewane 200 lub 304, przed dodaniem kolejnych ustawień przeczytaj ponownie rzeczywiste żądanie i odpowiedź.
6. Sprawdź inne miejsca zapisu i kryteria zakończenia
Nie zakładaj, że wyłączenie pamięci HTTP przeglądarki usuwa także CDN przed serwerem lub inne sposoby przechowywania danych przez aplikację. Osobno sprawdzaj, czy żądanie obsługuje service worker, jaką odpowiedź wybiera serwer pośredni i czy aplikacja utrzymuje na ekranie wcześniej otrzymane dane. Ten sam widoczny URL nie oznacza, że każda warstwa korzysta z tej samej kopii.
Również powrót w historii odróżniaj od nowego żądania HTTP. Kiedy przeglądarka odtwarza widok wcześniejszej sesji, oczekiwana ponowna walidacja może nie wystąpić mimo no-cache. Nie uznawaj tego od razu za dowód ignorowania nagłówka przez serwer. Osobno notuj, czy nowe żądanie wystąpiło przy nowej nawigacji, odświeżeniu i powrocie, aby nie łączyć różnych zjawisk w jeden problem.
Kryterium zakończenia przykładu z godzinami otwarcia nie jest sam współczynnik trafień w pamięć. Sprawdź poprawne użycie kopii, gdy nic się nie zmienia, pojawienie się nowych informacji w dozwolonym czasie po zmianie oraz właściwych odbiorców współdzielonej odpowiedzi. Zapis czasu zmiany i obserwacji, warunków i faktycznej treści ułatwia innym odtworzenie sytuacji. Lepszy wynik szybkości przy długo widocznych błędnych godzinach nie spełnia pierwotnego wymagania.
Przed zastosowaniem produkcyjnym oceń politykę dla każdego rodzaju odpowiedzi oraz procedury aktualizacji i wycofywania zmian. Nie przenoś instrukcji publicznego dokumentu do odpowiedzi osobistej ani nie utożsamiaj udanej walidacji ze sprawdzeniem uprawnień. Nagłówki przekazują reguły zapisu i ponownego użycia. Wyjaśnienie, co zostało zapisane i przez jakie sprawdzenia dotarło do obecnego widoku, pozwala trafniej diagnozować nieaktualny ekran.