W przypadku edytowalnego publicznego dokumentu wybierz rewalidację, jeśli czytelnicy powinni otrzymywać aktualną treść, a niezmienione strony mają pozostać możliwe do ponownego wykorzystania. Wybierz no-store, jeśli wymogi publikacji wyraźnie zabraniają przechowywania danych w pamięci podręcznej HTTP.

Ten przewodnik jest przeznaczony dla osoby zarządzającej publicznym dokumentem z poziomu komputera Mac. Zadanie polega na wybraniu zasad obsługi odpowiedzi, a następnie sprawdzeniu ich w Terminal przy użyciu syntetycznej strony zawierającej wyłącznie neutralny tekst, na przykład „Przewodnik po kształtach, wersja pierwsza”. Potrzebujesz strony testowej i dostępu do konfiguracji hostingu albo dostawcy, który może skonfigurować nagłówki odpowiedzi.

Która zasada buforowania pasuje do dokumentu?

Zacznij od wymogów publikacji. Czy stronę trzeba sprawdzać przed każdym ponownym użyciem, czy istniejąca kopia może pozostać dostępna przez krótki czas, czy też pamięci podręczne HTTP nie mogą przechowywać odpowiedzi? Są to różne wymagania określone w RFC 9111: HTTP Caching.

Wymóg publikacji Kandydat na nagłówek odpowiedzi Znaczenie dla pamięci podręcznej HTTP
Sprawdzanie przed każdym ponownym użyciem Cache-Control: no-cache Przechowywanie jest dozwolone; ponowne użycie wymaga pomyślnej walidacji.
Dopuszczenie krótkiego okresu świeżości Cache-Control: max-age=300, must-revalidate Ponowne użycie jest dozwolone, gdy odpowiedź jest świeża; po utracie świeżości wymagana jest pomyślna walidacja.
Wykluczenie przechowywania odpowiedzi Cache-Control: no-store Pamięć podręczna nie może przechowywać odpowiedzi ani użyć jej do obsługi kolejnego żądania.

Pięciominutowe okno to przykładowy wybór, a nie zalecane ustawienie domyślne. Wybierz je tylko wtedy, gdy dokument może być ponownie używany przez taki czas. Samo must-revalidate nie wymaga sprawdzenia, dopóki odpowiedź jest świeża. Te rozróżnienia wynikają z dyrektyw odpowiedzi w RFC 9111.

Załóżmy, że w syntetycznym przewodniku po kształtach korekta z „trzech przykładów” na „cztery przykłady” powinna zostać sprawdzona przy następnym pobraniu. Zacznij od no-cache i działającego walidatora. Jeśli wymóg stanowi, że pamięci podręczne HTTP nie mogą przechowywać odpowiedzi dotyczącej tego dokumentu, wybierz no-store. Częste edycje same w sobie nie oznaczają, że przechowywanie musi być wykluczone.

Zapisz wymóg przed zmianą ustawień, na przykład: „Sprawdź dokument przed ponownym użyciem”. Dzięki temu uzyskasz konkretne kryterium akceptacji, a nazwie ustawienia nie pozwolisz decydować o zasadach.

Co sprawia, że rewalidacja działa?

Walidator identyfikuje wersję, którą klient już otrzymał. ETag przekazuje znacznik encji, a Last-Modified — znacznik czasu modyfikacji. RFC 9110 zaleca wysyłanie dostępnych walidatorów przy pomyślnym pobieraniu dokumentów; preferowane są zarówno silny znacznik encji, jak i data modyfikacji. Zobacz HTTP Semantics, validators oraz 200 OK.

Poniższe pola nagłówków odpowiedzi są przykładami, a nie kodem konfiguracji serwera. Zakładają, że treść odpowiedzi stanowi syntetyczny przewodnik po kształtach:

Cache-Control: no-cache
ETag: "shape-guide-v1"

Przy kolejnym żądaniu klient może wysłać If-None-Match: \"shape-guide-v1\". Jeśli ten znacznik nadal pasuje do wybranej reprezentacji, warunkowe GET otrzyma 304 Not Modified bez treści odpowiedzi. Jeśli znacznik już nie pasuje, zwykła obsługa żądania może zwrócić zmieniony dokument. Zasady te opisano w sekcji RFC 9110 dotyczącej żądań warunkowych.

Wymogiem implementacyjnym jest to, by walidator odzwierciedlał wersję dokumentu. Nie kopiuj przykładowego znacznika do stałej konfiguracji i nie pozostawiaj go bez zmian po edycjach. Poproś dostawcę hostingu o spójne generowanie walidatorów i sprawdzanie warunków przychodzących żądań.

Ile transferu można uniknąć w przypadku niezmienionej odpowiedzi?

Rozważ wyraźnie przykładowe obliczenie: treść dokumentu ma 80 000 bajtów, a klient pobiera ją 100 razy bez żadnych edycji. Jedna pełna odpowiedź, po której następuje 99 pomyślnych walidacji, przesyła 80 000 bajtów treści zamiast 8 000 000 bajtów — różnica wynosi 7 920 000 bajtów.

To obliczenie pomija nagłówki, kompresję, narzut połączenia i wszelkie działania aplikacji. Dotyczy wyłącznie przesyłania treści. W objaśnieniu buforowania HTTP Google opisuje ten sam mechanizm: pasujący walidator pozwala zwrócić 304 bez treści, a klient korzysta z wcześniej otrzymanej zawartości. Rzeczywiste oszczędności zależą od częstotliwości zmian dokumentów i sposobu wysyłania żądań przez klientów.

Gdzie skonfigurować te zasady?

Skonfiguruj odpowiedź HTTP generowaną przez usługę hostingu, serwer lub warstwę dostarczania treści. Powyższe przykłady nagłówków opisują wymagany rezultat; nie są uniwersalnymi poleceniami dla platformy publikacyjnej.

Jeśli edytor pozwala zmieniać tylko tekst dokumentu, obejście oparte na znacznikach nie zapewni równoważnej kontroli. Standard HTML WHATWG nie definiuje Cache-Control jako obsługiwanej dyrektywy pragma http-equiv i wyjaśnia, że dyrektywy pragma są w dużej mierze odrębne od nagłówków HTTP. Zobacz HTML Standard: Pragma directives.

Obsługiwaną metodą jest użycie udokumentowanej przez dostawcę hostingu konfiguracji nagłówków odpowiedzi albo poproszenie go o wdrożenie tej konfiguracji. W omówieniu robotów indeksujących Google również kieruje wydawców do dostawcy hostingu lub systemu zarządzania treścią w sprawie wdrożenia buforowania HTTP. Warto w takim zgłoszeniu wskazać dokument, wybrane zasady i sposób obsługi walidatorów, a następnie zapytać, jak zweryfikować dostarczoną odpowiedź.

Zmiana opcji żądania w JavaScript ma węższy zakres. Standard WHATWG definiuje tryb pamięci podręcznej Fetch no-store, który działa tak, jakby nie było pamięci podręcznej HTTP, natomiast no-cache wysyła żądanie warunkowe, gdy dostępna jest odpowiednia odpowiedź z pamięci podręcznej. Tryby te dotyczą danego żądania; ustawienie jednego z nich w skrypcie nie konfiguruje zasad odpowiedzi serwera dla dokumentu. Zobacz tryby pamięci podręcznej w standardzie Fetch.

Jak przetestować rewalidację na komputerze Mac?

Użyj syntetycznego publicznego dokumentu testowego, który możesz edytować. Przed rozpoczęciem ustaw jego treść na „Przewodnik po kształtach, wersja pierwsza” i zadbaj o dostarczanie wybranych nagłówków odpowiedzi. Trzymaj ten test z dala od rzeczywistych treści dokumentów, by zmiana była oczywista i odwracalna.

Otwórz Terminal i uruchom poniższe polecenia w tej samej sesji. Wyświetlą prośbę o rzeczywisty adres URL testu i walidator zwrócony przez tę stronę; nie zakładają żadnego przykładowego adresu. Jeśli pierwsze żądanie zakończy się niepowodzeniem, przekieruje dalej lub zwróci coś innego niż oczekiwana odpowiedź dokumentu, przerwij test.

printf '%s\n' 'Paste the full URL of your synthetic public test page:'
IFS= read -r page_url

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header - --output /dev/null --url "$page_url"

printf '%s\n' 'Paste its ETag value exactly, including quotes:'
IFS= read -r page_etag

check_page() {
  curl --silent --show-error --connect-timeout 5 --max-time 20 \
    --dump-header - --output /dev/null \
    --header "If-None-Match: $page_etag" --url "$page_url"
}

check_page

Polecenia wykonują żądania GET, wyświetlają otrzymane nagłówki i celowo odrzucają treść odpowiedzi. Limity czasu ograniczają czas nawiązania połączenia i transferu; błędy pozostają widoczne. Opcje te są opisane w podręczniku curl. Pierwsze żądanie powinno ujawnić wybraną wartość Cache-Control oraz ETag. Jeśli nie ma znacznika, nie wpisuj wymyślonej wartości — najpierw zapewnij obsługę walidatorów.

Skopiuj całą wartość znacznika, łącznie z otaczającymi ją cudzysłowami i ewentualnym prefiksem W/. Gdy reprezentacja jest niezmieniona i znacznik pasuje, żądanie warunkowe powinno zwrócić 304. Odpowiedź 304 nie może zawierać treści i musi zawierać określone metadane, które towarzyszyłyby równoważnej odpowiedzi 200, w tym ETag i Cache-Control, jeśli mają zastosowanie. Zobacz RFC 9110: 304 Not Modified.

Przetestuj edycję, zachowując stary walidator

Zmień syntetyczny dokument na „Przewodnik po kształtach, wersja druga: cztery przykłady”. Gdy aktualizacja dotrze na stronę testową, zachowaj stary znacznik w tej samej sesji Terminal i uruchom poniższe polecenie:

check_page

W przypadku tego celowo zmienionego dokumentu oczekuj, że nowa treść będzie dostępna w zwykłej pomyślnej odpowiedzi wraz ze zaktualizowanym walidatorem. Następnie ponownie uruchom początkowe polecenia z nowym znacznikiem i sprawdź niezmienioną wersję. W ten sposób przetestujesz obie sytuacje: wykrycie zmiany i rozpoznanie braku zmian.

Obserwacja Kolejny krok diagnostyczny
Pierwsze żądanie zwraca przekierowanie Użyj końcowego adresu URL dokumentu i rozpocznij test od nowa.
Niezmienione żądanie warunkowe zwraca 200 Sprawdź, czy znacznik został skopiowany poprawnie i czy obsługa żądań warunkowych jest włączona.
Celowa edycja treści nadal powoduje zwrócenie 304 ze starym znacznikiem Zbadaj dostarczanie aktualizacji i generowanie walidatorów, zanim zaczniesz polegać na rewalidacji.
Dostarczone zasady różnią się od konfiguracji Sprawdź ustawienia hostingu i dostarczania odpowiedzialne za końcową odpowiedź.
Żądanie przekracza limit czasu lub kończy się niepowodzeniem Rozwiąż problem z pobieraniem, zanim zaczniesz interpretować zachowanie pamięci podręcznej.

To wskazówki diagnostyczne, a nie dowód konkretnej przyczyny. Procedura sprawdza odpowiedź i wymianę warunkową; nie ustala, jak zachowa się każda przeglądarka. Oceniając no-store, sprawdź bezpośrednio tę dyrektywę odpowiedzi. Ręcznie skonstruowane żądanie warunkowe nie sprawdza, czy przeglądarka przechowała odpowiedź.

Co to oznacza dla wyszukiwarki Google?

Aktualna dokumentacja robotów indeksujących Google opisuje obsługę ETag z If-None-Match oraz Last-Modified z If-Modified-Since. Zaleca ETag robotom Google i informuje, że poszczególne roboty mogą różnie korzystać z buforowania. Zobacz Overview of Google crawlers and fetchers.

Dokumentacja ta stwierdza również, że inne dyrektywy buforowania HTTP nie są obsługiwane, a osobno sugeruje max-age jako możliwą wskazówkę do ponownego indeksowania obok Last-Modified. Z uwagi na te udokumentowane ograniczenia nie zakładaj, że zasady no-store lub no-cache przeznaczone dla przeglądarek określają harmonogram pobierania przez Googlebota. Wdróż i przetestuj walidatory jako udokumentowaną metodę pobierania warunkowego.

Google wyjaśnia, że 304 sygnalizuje jego systemom przetwarzania, że treść się nie zmieniła; w przypadku wyszukiwarki poza tym nie wpływa na indeksowanie. Pomyślna odpowiedź 200 również nie gwarantuje indeksowania. Informacje te opisano w How HTTP status codes affect Google’s crawlers.

Wybierz zasady zgodne z wymaganiami dotyczącymi dokumentu i zachowaj wyniki testu: pierwszą odpowiedź, niezmienioną odpowiedź warunkową oraz odpowiedź po celowej edycji. W przypadku publicznego dokumentu, który trzeba sprawdzać przed ponownym użyciem, rewalidacja jest praktycznym punktem wyjścia. Wybierz no-store, jeśli samym wymogiem jest wykluczenie przechowywania w pamięci podręcznej HTTP.

Źródła