Zapobiegaj niepotrzebnym żądaniam sieciowym dzięki pamięci podręcznej HTTP

Pobieranie zasobów przez sieć jest powolne i kosztowne:

• Duże odpowiedzi wymagają przesyłania wielu informacji między przeglądarką a serwerem.
• Strona załaduje się dopiero wtedy, gdy wszystkie krytyczne zasoby nie zostaną w pełni pobrane.
• Jeśli użytkownik korzysta z Twojej witryny, mając ograniczony pakiet mobilnej transmisji danych, każde niepotrzebne żądanie sieciowe to strata pieniędzy.

Jak możesz uniknąć niepotrzebnych żądań sieciowych? Pamięć podręczna HTTP przeglądarki to Twoja pierwsza linia obrony. Nie musi to być najbardziej zaawansowane i elastyczne podejście. Masz ograniczoną kontrolę nad czasem przechowywania odpowiedzi w pamięci podręcznej, ale jest skuteczne, obsługiwane przez wszystkie przeglądarki i nie wymaga wiele pracy.

Ten przewodnik zawiera podstawowe informacje o skutecznej implementacji buforowania HTTP.

Zgodność z przeglądarką

W rzeczywistości nie istnieje pojedynczy interfejs API o nazwie HTTP Cache. Jest to ogólna nazwa zbioru interfejsów API platformy internetowej. Te interfejsy API są obsługiwane we wszystkich przeglądarkach:

Cache-Control

ETag

Last-Modified

Jak działa pamięć podręczna HTTP

Wszystkie żądania HTTP wysyłane przez przeglądarkę są najpierw kierowane do jej pamięci podręcznej w celu sprawdzenia, czy w pamięci podręcznej znajduje się prawidłowa odpowiedź, której można użyć do realizacji żądania. W przypadku dopasowania odpowiedź jest odczytywana z pamięci podręcznej, co eliminuje zarówno opóźnienia w sieci, jak i koszty danych związane z przesyłaniem.

Zachowanie pamięci podręcznej HTTP jest kontrolowane przez kombinację nagłówków żądań i nagłówków odpowiedzi. W idealnym scenariuszu będziesz mieć kontrolę zarówno nad kodem swojej aplikacji internetowej (określającej nagłówki żądań), jak i konfiguracją serwera WWW (która określa nagłówki odpowiedzi).

Bardziej szczegółowe omówienie zagadnień technicznych znajdziesz w artykule Buforowanie HTTP w MDN.

Nagłówki żądań: zachowaj wartości domyślne (zwykle)

Istnieje wiele ważnych nagłówków, które powinny być uwzględnione w żądaniach wychodzących aplikacji internetowej, ale przeglądarka prawie zawsze ustawia je w Twoim imieniu, gdy wysyła żądania. Nagłówki żądań, które wpływają na sprawdzanie aktualności wyników, takie jak If-None-Match i If-Modified-Since, pojawiają się, jeśli przeglądarka zrozumie bieżące wartości w pamięci podręcznej HTTP.

To dobra wiadomość. Możesz nadal umieszczać w kodzie HTML tagi takie jak <img src="my-image.png">, a przeglądarka automatycznie zajmie się buforowaniem HTTP bez dodatkowych działań z Twojej strony.

Nagłówki odpowiedzi: skonfiguruj serwer WWW

Częścią konfiguracji buforowania HTTP, która ma największe znaczenie, są nagłówki dodawane przez serwer WWW do każdej odpowiedzi wychodzącej. Te nagłówki mają wpływ na skuteczne działanie buforowania:

• Cache-Control Serwer może zwrócić dyrektywę Cache-Control, aby określić, w jaki sposób i jak długo przeglądarka i inne pośrednie pamięci podręczne mają zapisywać daną odpowiedź w pamięci podręcznej.
• ETag Gdy przeglądarka znajdzie nieaktualną odpowiedź w pamięci podręcznej, może wysłać do serwera niewielki token (zwykle skrót zawartości pliku), aby sprawdzić, czy plik nie uległ zmianie. Jeśli serwer zwróci ten sam token, plik jest taki sam i nie ma potrzeby ponownego pobierania go.
• Last-Modified Ten nagłówek ma taki sam cel jak ETag, ale do określenia, czy zasób się zmienił, do określania, czy zasób uległ zmianie, używana jest strategia oparta na treści (ETag).

Niektóre serwery WWW mają wbudowaną obsługę domyślnego ustawiania nagłówków, a inne całkowicie je wyłączają, chyba że zostaną one przez Ciebie skonfigurowane. Szczegółowe informacje o konfigurowaniu nagłówków różnią się w zależności od używanego serwera WWW. Szczegółowe informacje znajdziesz w dokumentacji serwera.

Aby uniknąć konieczności wyszukiwania, zapoznaj się z poniższymi instrukcjami konfigurowania kilku popularnych serwerów WWW:

• Ekspresowa
• Apache
• nginx
• Hosting Firebase
• Netlify

Pominięcie nagłówka odpowiedzi Cache-Control nie wyłącza buforowania HTTP. Zamiast tego przeglądarki skutecznie odgadną, jaki typ zachowania w pamięci podręcznej jest najbardziej sensowny w przypadku danego typu treści. Możliwe, że potrzebujesz większej kontroli nad tymi ofertami, więc poświęć trochę czasu na skonfigurowanie nagłówków odpowiedzi.

Których wartości nagłówka odpowiedzi użyjesz?

Są 2 ważne scenariusze, które należy wziąć pod uwagę podczas konfigurowania w nagłówkach odpowiedzi serwera WWW.

Długotrwałe buforowanie w przypadku adresów URL z obsługą wersji

Podczas odpowiadania na żądania dotyczące adresów URL zawierających „odcisk cyfrowy” lub informacjach o wersji, których treść nigdy nie powinna być zmieniana, dodaj do swoich odpowiedzi Cache-Control: max-age=31536000.

Ustawienie tej wartości informuje przeglądarkę, że gdy musi wczytać ten sam adres URL w ciągu roku (31 536 000 sekund; maksymalna obsługiwana wartość), może natychmiast użyć wartości z pamięci podręcznej HTTP bez konieczności wysyłania żądania sieciowego do serwera WWW. To świetnie—od razu przyzwyczaiłeś się do niezawodności i szybkości, które wiążą się z unikaniem sieci.

Narzędzia do tworzenia, takie jak webpack, mogą zautomatyzować proces przypisywania odcisków cyfrowych do adresów URL zasobów.

Ponowna weryfikacja serwera adresów URL bez wersji

Niestety nie wszystkie wczytywane adresy URL mają wersję. Być może nie możesz dodać etapu kompilacji przed wdrożeniem aplikacji internetowej, więc nie możesz dodawać haszy do adresów URL zasobów. I każda aplikacja internetowa potrzebuje plików HTML – prawie nigdy nie będą one zawierać informacji o wersji, ponieważ nikt nie będzie się czuć z chęcią posługiwaniem się Twoją aplikacją, jeśli będzie musiała pamiętać, że jej adres URL to https://example.com/index.34def12.html. Co więc możesz zrobić z tymi adresami URL?

W takiej sytuacji trzeba przyznać się do porażki. Samo buforowanie HTTP nie jest wystarczająco wydajne, aby całkowicie ominąć sieć. (Nie martw się – wkrótce dowiesz się więcej o usługodawcach, którzy dadzą nam potrzebne wsparcie). Możesz jednak wykonać kilka czynności, aby zapewnić jak najszybsze wysyłanie żądań sieciowych.

Te wartości Cache-Control pomogą Ci doprecyzować, gdzie i w jaki sposób adresy URL bez wersji są zapisywane w pamięci podręcznej:

• no-cache Oznacza to, że przed użyciem wersji adresu URL z pamięci podręcznej przeglądarka musi za każdym razem przeprowadzić ponowną weryfikację z serwerem.
• no-store Oznacza to, że przeglądarka i inne pośrednie pamięci podręczne (takie jak CDN) nigdy nie będą przechowywać żadnej wersji pliku.
• private Przeglądarki mogą zapisywać plik w pamięci podręcznej, ale pośrednie pamięci podręczne nie mogą tego zrobić.
• public Odpowiedź może być przechowywana w dowolnej pamięci podręcznej.

Aby zwizualizować proces wybierania wartości Cache-Control do użycia, zapoznaj się z Załącznikiem: schemat blokowy Cache-Control. Pole Cache-Control może też zawierać listę dyrektyw oddzielonych przecinkami. Zobacz Dodatek (przykłady: Cache-Control).

Pomocne może też być ustawienie ETag lub Last-Modified. Jak wspomnieliśmy w sekcji Nagłówki odpowiedzi, atrybuty ETag i Last-Modified służą do tego samego celu: określania, czy przeglądarka musi ponownie pobrać wygasły plik z pamięci podręcznej. Zalecamy użycie metody ETag, ponieważ jest ona dokładniejsza.

Ustawienie ETag lub Last-Modified znacznie usprawnia żądanie ponownej weryfikacji, ponieważ umożliwia aktywowanie nagłówków żądań If-Modified-Since lub If-None-Match wymienionych w nagłówkach żądań.

Gdy poprawnie skonfigurowany serwer WWW rozpozna nagłówki żądań przychodzących, może sprawdzić, czy wersja zasobu, którą przeglądarka ma już w swojej pamięci podręcznej HTTP, jest zgodna z najnowszą wersją na serwerze WWW. Jeśli uda się dopasować, serwer może odpowiedzieć HTTP 304 Not Modified, co jest odpowiednikiem polecenia „OK, kontynuuj korzystanie z tego, co już masz!”. Wysyłając tego typu odpowiedź, jest bardzo mało danych do przesłania, więc zwykle trwa to znacznie krócej niż odesłanie kopii rzeczywistego zasobu, którego dotyczy żądanie.

Podsumowanie

Pamięć podręczna HTTP to skuteczny sposób na zwiększenie wydajności wczytywania, ponieważ zredukuje się liczba niepotrzebnych żądań sieciowych. Jest ono obsługiwane we wszystkich przeglądarkach, a jego konfiguracja nie wymaga zbyt wiele pracy.

Warto zacząć od tych konfiguracji Cache-Control:

• Cache-Control: no-cache dla zasobów, które powinny zostać ponownie zweryfikowane na serwerze przed każdym użyciem.
• Cache-Control: no-store w przypadku zasobów, które nigdy nie powinny być przechowywane w pamięci podręcznej.
• Cache-Control: max-age=31536000 na potrzeby zasobów z obsługą wersji.

Nagłówek ETag lub Last-Modified może też pomóc w skuteczniejszym ponownym weryfikowaniu zasobów pamięci podręcznej, których ważność wygasła.

Więcej informacji

Jeśli chcesz dowiedzieć się więcej o korzystaniu z nagłówka Cache-Control, zapoznaj się z przewodnikiem Jake'a Archibalda na temat sprawdzonych metod dotyczących buforowania i max-age gotchas (w języku angielskim).

Przeczytaj sekcję Pokochaj pamięć podręczną, aby dowiedzieć się, jak zoptymalizować wykorzystanie pamięci podręcznej pod kątem powracających użytkowników.

Dodatek: więcej wskazówek

Jeśli masz więcej czasu, oto kolejne sposoby optymalizacji wykorzystania pamięci podręcznej HTTP:

• Używaj spójnych adresów URL. Jeśli te same treści są wyświetlane pod różnymi adresami URL, są one wielokrotnie pobierane i zapisywane.
• Minimalizuj liczbę rezygnacji. Jeśli część zasobu (np. plik CSS) jest często aktualizowana, a reszta pliku nie (np. kod biblioteki), rozważ podzielenie często aktualizowanego kodu do osobnego pliku i zastosowanie krótkotrwałej strategii buforowania dla często aktualizowanego kodu oraz długiego czasu przechowywania kodu, który rzadko się zmienia.
• Zapoznaj się z nową dyrektywą stale-while-revalidate, jeśli zasady Cache-Control dopuszczają pewien stopień nieaktualności.

Załącznik: schemat blokowy Cache-Control

Dodatek (przykłady: Cache-Control)