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

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

• Duże odpowiedzi wymagają wielu transferów w obie strony między przeglądarką a serwerem.
• Strona nie załaduje się, dopóki wszystkie jej krytyczne zasoby nie zostaną w pełni pobrane.
• Jeśli użytkownik korzysta z Twojej witryny, a użytkownik korzysta z abonamentu z ograniczoną transmisją danych, każde niepotrzebne żądanie dostępu do sieci jest stratą pieniędzy.

Jak uniknąć zbędnych żądań sieciowych? Pamięć podręczna HTTP przeglądarki to pierwszy wiersz obrony. Nie musi to być najbardziej wydajne ani elastyczne podejście, które ma ograniczoną kontrolę nad okresem przechowywania odpowiedzi w pamięci podręcznej. Jest skuteczne, obsługiwane we wszystkich przeglądarkach i nie wymaga dużej ilości pracy.

Ten przewodnik zawiera podstawowe informacje na temat skutecznej implementacji buforowania HTTP.

Zgodność z przeglądarką

Nie ma tak naprawdę jednego interfejsu API o nazwie HTTP Cache. Jest to ogólna nazwa zbioru interfejsów API platform internetowych. 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 pamięci podręcznej przeglądarki, aby sprawdzić, czy w pamięci podręcznej znajduje się prawidłowa odpowiedź, która może zostać wykorzystana do realizacji żądania. W przypadku dopasowania odpowiedź jest odczytywana z pamięci podręcznej, co eliminuje opóźnienia w sieci i koszty danych związane z przesyłaniem danych.

Działanie pamięci podręcznej HTTP jest kontrolowane przez kombinację nagłówków żądań i nagłówków odpowiedzi. W idealnym scenariuszu musisz kontrolować zarówno kod aplikacji internetowej (która określa nagłówki żądań), jak i konfigurację serwera WWW (która określa nagłówki odpowiedzi).

Dokładniejsze omówienie kwestii znajdziesz w artykule MDN na temat buforowania HTTP.

Nagłówki żądań: pozostań przy wartościach domyślnych (zwykle)

Chociaż w żądaniach wychodzących Twojej aplikacji internetowej jest wiele ważnych nagłówków, które powinny być uwzględnione w żądaniach wychodzących, to przeglądarka prawie zawsze konfiguruje je w Twoim imieniu podczas wysyłania żądań. Nagłówki żądań, które wpływają na sprawdzanie aktualności, takie jak If-None-Match i If-Modified-Since, wyświetlają się po prostu na podstawie tego, jak przeglądarka rozumie bieżące wartości z 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 i bez dodatkowych działań dba o buforowanie zawartości protokołu HTTP.

Nagłówki odpowiedzi: skonfiguruj serwer WWW

Najważniejszą częścią konfiguracji buforowania HTTP są nagłówki, które Twój serwer WWW dodaje do każdej odpowiedzi wychodzącej. Te nagłówki wpływają na efektywne działanie buforowania:

• Cache-Control. Serwer może zwrócić dyrektywę Cache-Control, aby określić, jak i przez jaki czas przeglądarka i inne pośrednie pamięci podręcznej powinny buforować pojedynczą odpowiedź.
• ETag. Gdy przeglądarka znajdzie wygasłą odpowiedź w pamięci podręcznej, może wysłać do serwera mały token (zwykle jest to skrót zawartości pliku), aby sprawdzić, czy plik się zmienił. Jeśli serwer zwraca ten sam token, plik jest taki sam i nie ma potrzeby jego ponownego pobierania.
• Last-Modified. Ten nagłówek spełnia ten sam cel co ETag, ale korzysta ze strategii opartej na czasie do określenia, czy zasób się zmienił, a nie ze strategii dotyczącej treści ETag.

Niektóre serwery WWW mają wbudowaną obsługę ustawiania takich nagłówków domyślnie, a inne całkowicie pomijają nagłówki, o ile ich nie skonfigurujesz. Szczegóły dotyczące konfigurowania nagłówków znacznie się różnią w zależności od używanego serwera WWW. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją serwera.

Aby zaoszczędzić Ci czasu przy wyszukiwaniu, poniżej znajdziesz instrukcje 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 zgadują, jaki typ zapisywania w pamięci podręcznej ma największy sens w przypadku danego typu treści. Prawdopodobnie potrzebujesz większej kontroli, dlatego poświęć czas na skonfigurowanie nagłówków odpowiedzi.

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

Przy konfigurowaniu nagłówków odpowiedzi serwera WWW należy wziąć pod uwagę 2 ważne scenariusze.

Długotrwałe buforowanie wersji adresów URL

W odpowiedzi na żądania dotyczące adresów URL, które zawierają „odcisk cyfrowy” lub informacje o wersji, i które nigdy nie mają się zmieniać, dodaj do swoich odpowiedzi atrybut Cache-Control: max-age=31536000.

Ustawienie tej wartości informuje przeglądarkę, że gdy będzie musiała załadować ten sam adres URL w ciągu następnego roku (31 536 000 sekund; maksymalna obsługiwana wartość), może natychmiast użyć tej wartości z pamięci podręcznej HTTP bez konieczności wysyłania żądań sieciowych do serwera WWW. Wspaniale, dzięki unikaniu korzystania z sieci od razu zyskujesz niezawodność i szybkość.

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

Ponowna weryfikacja serwera w przypadku niewersji adresów URL

Nie wszystkie wczytywane adresy URL są objęte wersjami. Być może przed wdrożeniem aplikacji internetowej nie można dodać haszowania do adresów URL zasobów. Każda aplikacja internetowa wymaga plików HTML – te pliki nigdy nie będą zawierać informacji o wersjach, ponieważ nikt nie będzie chciał korzystać z Twojej aplikacji internetowej, jeśli będzie musiał pamiętać, że URL, który należy otworzyć, to https://example.com/index.34def12.html. Co więc można zrobić z tymi adresami URL?

To jeden ze scenariuszy, w których trzeba przyznać się do porażki. Sama pamięć podręczna HTTP nie jest wystarczająco zaawansowana, aby całkowicie uniknąć sieci. (nie martw się – wkrótce dowiesz się więcej o pracownikach usługowych, którzy udzielą Ci potrzebnego wsparcia, by awansować na Twoją korzyść). Możesz jednak wykonać kilka czynności, aby żądania sieciowe były jak najszybsze i efektywne.

Te wartości Cache-Control pomogą Ci precyzyjnie określić, gdzie i w jaki sposób niewersowane adresy URL są przechowywane w pamięci podręcznej:

• no-cache. Informuje to przeglądarkę, że przed użyciem wersji adresu URL przechowywanej w pamięci podręcznej musi ona dokonać ponownej weryfikacji na serwerze za każdym razem.
• no-store. To spowoduje, że przeglądarka i inne pośrednie pamięci podręczne (np. CDN) nigdy nie będą zapisywać żadnej wersji pliku.
• private. Przeglądarki mogą zapisywać plik w pamięci podręcznej, ale pośrednie – nie.
• public. Odpowiedź może być przechowywana w dowolnej pamięci podręcznej.

Zapoznaj się z dodatkiem: schemat blokowy Cache-Control, aby zwizualizować proces wybierania wartości Cache-Control do użycia. Pamiętaj też, że Cache-Control może akceptować listę dyrektyw rozdzielonych przecinkami. Zobacz Załącznik: Cache-Control przykłady.

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

Ustawienie ETag lub Last-Modified sprawi, że prośba o ponowną weryfikację będzie znacznie skuteczniejsza. W rezultacie aktywują nagłówki żądania If-Modified-Since lub If-None-Match, które zostały wymienione w nagłówkach żądań.

Gdy prawidłowo skonfigurowany serwer WWW zobaczy nagłówki przychodzących żądań, może sprawdzić, czy wersja zasobu, którą przeglądarka znajduje w swojej pamięci podręcznej HTTP, jest zgodna z najnowszą wersją na serwerze WWW. W przypadku znalezienia dopasowania serwer może odpowiedzieć, wysyłając odpowiedź HTTP 304 Not Modified, co jest odpowiednikiem polecenia „Hej, dalej używaj tego, co już masz!”. Podczas wysyłania odpowiedzi tego typu można przesłać bardzo mało danych, więc zwykle trwa to znacznie szybciej niż wysyłanie kopii rzeczywistego zasobu.

Podsumowanie

Pamięć podręczna HTTP to skuteczny sposób na zwiększenie wydajności wczytywania, ponieważ zmniejsza liczbę zbędnych żądań sieciowych. Jest obsługiwany we wszystkich przeglądarkach i nie wymaga dużo pracy.

Warto zacząć od tych konfiguracji Cache-Control:

• Cache-Control: no-cache dla zasobów, które należy ponownie zweryfikować na serwerze przed każdym użyciem.
• Cache-Control: no-store dla zasobów, które nie powinny być przechowywane w pamięci podręcznej.
• Cache-Control: max-age=31536000 na potrzeby zasobów mających różne wersje.

Nagłówek ETag lub Last-Modified może też pomóc skuteczniej weryfikować wygasłe zasoby pamięci podręcznej.

Więcej informacji

Jeśli chcesz dowiedzieć się czegoś więcej niż tylko podstawy korzystania z nagłówka Cache-Control, zajrzyj do przewodnika Jake Archibalda dotyczące sprawdzonych metod dotyczących buforowania i atrybutu max-age.

Wskazówki optymalizacji wykorzystania pamięci podręcznej przez powracających użytkowników znajdziesz w artykule Uwielbiaj pamięć podręczną.

Dodatek: więcej wskazówek

Jeśli masz więcej czasu, możesz skorzystać z tych dodatkowych metod optymalizacji wykorzystania pamięci podręcznej HTTP:

• Używaj spójnych adresów URL. Jeśli udostępniasz te same treści pod różnymi adresami URL, będą one pobierane i zapisywane wiele razy.
• Ogranicz 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 na oddzielny plik i zastosowanie krótkotrwałej strategii buforowania w przypadku często aktualizowanego kodu i strategii długiego buforowania w przypadku kodu, który nie zmienia się zbyt często.
• Zapoznaj się z nową dyrektywą stale-while-revalidate, jeśli w swojej zasadzie Cache-Control dopuszczasz pewien poziom nieaktualności.

Załącznik: schemat blokowy Cache-Control

Załącznik: przykłady (Cache-Control)