HTTP
Buforowanie odpowiedzi HTTP

Uwagi

Odpowiedź pamięci podręcznej dla wszystkich przez 1 rok

Cache-Control: public, max-age=31536000

public oznacza, że odpowiedź jest taka sama dla wszystkich użytkowników (nie zawiera żadnych spersonalizowanych informacji). max-age za kilka sekund. 31536000 = 60 * 60 * 24 * 365.

Jest to zalecane w przypadku zasobów statycznych, których nigdy nie należy zmieniać.

Buforuj spersonalizowaną odpowiedź przez 1 minutę

Cache-Control: private, max-age=60

private określa, że odpowiedź może być buforowana tylko dla użytkownika, który zażądał zasobu, i nie może być ponownie użyta, gdy inni użytkownicy zażądają tego samego zasobu. Jest to odpowiednie w przypadku odpowiedzi zależnych od plików cookie.

Przestań używać buforowanych zasobów bez uprzedniego sprawdzenia na serwerze

Cache-Control: no-cache

Klient zachowa się tak, jakby odpowiedź nie była buforowana. Jest to odpowiednie w przypadku zasobów, które mogą w nieprzewidziany sposób zmienić się w dowolnym momencie i które użytkownicy muszą zawsze widzieć w najnowszej wersji.

Odpowiedzi no-cache będą wolniejsze (duże opóźnienia) ze względu na konieczność kontaktowania się z serwerem za każdym razem, gdy są używane.

Jednak w celu zaoszczędzenia przepustowości klienci mogą nadal przechowywać takie odpowiedzi. Odpowiedzi no-cache nie będą wykorzystywane do zaspokajania żądań bez kontaktu z serwerem za każdym razem, aby sprawdzić, czy buforowaną odpowiedź można ponownie wykorzystać.

Żądaj, aby odpowiedzi nie były w ogóle przechowywane

 Cache-control: no-store

Instruuje klientów, aby nie buforowali odpowiedzi w żaden sposób i nie zapominali o niej jak najszybciej.

Ta dyrektywa została pierwotnie zaprojektowana z myślą o wrażliwych danych (dziś zamiast tego należy użyć HTTPS), ale można jej użyć, aby uniknąć zanieczyszczania pamięci podręcznej odpowiedziami, których nie można ponownie wykorzystać.

Jest odpowiedni tylko w szczególnych przypadkach, w których dane odpowiedzi są zawsze różne, np. Punkt końcowy interfejsu API, który zwraca dużą liczbę losową. W przeciwnym razie można zastosować no-cache i ponowną walidację w celu zachowania odpowiedzi „nieuleczalnej”, przy jednoczesnym zachowaniu pewnej przepustowości.

Przestarzałe, nadmiarowe i niestandardowe nagłówki

• Expires - określa datę, w której zasób staje się przestarzały. Polega na tym, że serwery i klienci mają prawidłowe zegary i poprawnie obsługują strefy czasowe. Cache-control: max-age ma pierwszeństwo przed Expires i jest ogólnie bardziej niezawodny.

• dyrektywy post-check i po pre-check są niestandardowymi rozszerzeniami programu Internet Explorer, które umożliwiają stosowanie nieaktualnych odpowiedzi. Standardową alternatywą jest stale-while-revalidate .

• Pragma: no-cache - przestarzały w 1999 roku . Zamiast tego należy użyć Cache-control .

Zmiana buforowanych zasobów

Najprostszym sposobem na ominięcie pamięci podręcznej jest zmiana adresu URL. Jest to stosowane jako najlepsza praktyka, gdy adres URL zawiera wersję lub sumę kontrolną zasobu, np

http://example.com/image.png?version=1
http://example.com/image.png?version=2

Te dwa adresy URL będą buforowane osobno, więc nawet jeśli …?version=1 była buforowana na zawsze , nową kopię można natychmiast pobrać jako …?version=2 .

Nie używaj losowych adresów URL do omijania pamięci podręcznej. Zamiast tego użyj Cache-control: no-cache lub Cache-control: no-store . Jeśli odpowiedzi z losowymi adresami URL zostaną wysłane bez dyrektywy no-store , zostaną niepotrzebnie zapisane w pamięci podręcznej i wypchną bardziej przydatne odpowiedzi z pamięci podręcznej, co obniży wydajność całej pamięci podręcznej.