Twoja pamięć podręczna ❤️

Użytkownicy, którzy wczytują witrynę po raz drugi, będą korzystać z pamięci podręcznej HTTP, więc upewnij się, że działa ona prawidłowo.

Sam Thorogood

Ten post jest uzupełnieniem filmu Love your cache, który jest częścią Extended Content na Chrome Dev Summit 2020. Obejrzyj film:

Gdy użytkownik wczyta witrynę po raz drugi, jego przeglądarka skorzysta z zasobów znajdujących się w pamięci podręcznej HTTP, aby przyspieszyć wczytywanie. Standardy buforowania w internecie sięgają 1999 r. i są one bardzo ogólnie zdefiniowane. Określenie, czy określenie, czy plik, np. CSS, czy obraz, może zostać ponownie pobrany z sieci, czy z pamięci podręcznej, nie jest zbyt dokładny.

W tym poście omówię rozsądną i nowoczesną opcję domyślną do buforowania, która w rzeczywistości nie umożliwia buforowania. To jednak tylko ustawienie domyślne, które wiążą się z bardziej szczegółowymi niuansami. Czytaj dalej.

Uwaga: podczas tworzenia witryny należy pamiętać, że dane o wydajności takie jak podstawowe wskaźniki internetowe uwzględniają wszystkie wczytania, a nie tylko pierwsze wczytanie. Jednak wiele wskazówek Google koncentruje się na optymalizacji pierwszego wczytywania (co z pewnością ma duże znaczenie dla pozyskania użytkowników), a Lighthouse testuje witrynę tylko na pustej pamięci podręcznej.

Cele

Gdy witryna wczytuje się po raz drugi, masz 2 cele:

1. Zadbaj o to, aby użytkownicy mieli dostęp do najnowszej dostępnej wersji aplikacji. Jeśli wprowadzisz zmiany, zmiany powinny być szybko widoczne.
2. Wykonaj #1 przy pobieraniu jak najmniejszej ilości danych z sieci.

Mówiąc ogólnie, chcesz wysyłać klientom tylko najmniejszą zmianę przy ponownym wczytaniu Twojej witryny. Stworzenie takiej struktury witryny, która zapewni jak najefektywniejszą dystrybucję wszelkich zmian, jest trudne (więcej na ten temat znajdziesz w dalszej części filmu).

Oprócz tego, jeśli rozważasz zapisywanie w pamięci podręcznej, masz też inne gałki. Być może chcesz na długi czas zezwolić na przechowywanie witryny w pamięci podręcznej HTTP przeglądarki użytkownika, aby w ogóle jej nie wysyłać żądania sieciowe. albo masz mechanizm service worker, który przed sprawdzeniem, czy jest aktualna, będzie wyświetlać witrynę w trybie offline. Jest to ekstremalna opcja, która ma zastosowanie i jest używana w wielu środowiskach internetowych opartych na aplikacjach.

Wprowadzenie

Wszyscy twórcy stron internetowych są przyzwyczajeni do myślenia o „nieaktualnej pamięci podręcznej”. Wiemy jednak, prawie instynktownie, dostępne narzędzia, które pomogą Ci rozwiązać ten problem: „odświeżyć”, otworzyć okno incognito lub użyć kombinacji narzędzi programistycznych w przeglądarce, które pomogą wyczyścić dane witryny.

Zwykli użytkownicy internetu nie mają takiego luksusu. Choć naszym głównym celem jest zapewnienie użytkownikom świetnej zabawy przy drugim zakupie, ważne jest też, aby nie utknęli w trudnym miejscu ani nie utknęli w jakimś miejscu. Obejrzyj film, jeśli chcesz się dowiedzieć, jak prawie utknęliśmy w witrynie web.dev/live.

„Nieaktualna pamięć podręczna” jest często spotykaną przyczyną domyślnej wartości pamięci podręcznej z 1999 roku. Wykorzystuje nagłówek Last-Modified:

Zasoby wygenerowane w różnych momentach (na szaro) są przechowywane w pamięci podręcznej w różnych momentach, więc przy drugim wczytaniu może pojawić się kombinacja zasobów zapisanych w pamięci podręcznej i nowych

Każdy wczytany plik jest zachowywany o dodatkowe 10% bieżącego czasu działania, gdy jest widoczny dla przeglądarki. Jeśli na przykład strona index.html została utworzona miesiąc temu, będzie przechowywana w pamięci podręcznej przeglądarki przez kolejne 3 dni.

W przeszłości ta koncepcja miała dobre intencje, ale ze względu na ściśle zintegrowany charakter dzisiejszych witryn takie domyślne zachowanie oznacza, że użytkownik może dojść do stanu, w którym użytkownik ma pliki przeznaczone dla różnych wersji witryny (np. JS z wtorku i kod CSS z piątkowego wydania), a wszystko to dlatego, że pliki te nie były aktualizowane dokładnie w tym samym czasie.

Dobrze oświetlona ścieżka

Nowoczesnym ustawieniem domyślnym buforowania jest rezygnacja z buforowania i korzystanie z sieci CDN, by przekazać treści użytkownikom. Za każdym razem, gdy użytkownik wczytuje witrynę, wchodzi do sieci, aby sprawdzić, czy jest ona aktualna. To żądanie będzie miało krótki czas oczekiwania, ponieważ będzie dostarczane przez CDN geograficznie blisko każdego użytkownika.

Możesz skonfigurować dostawcę hostingu witryn, aby odpowiadał na żądania sieciowe przy użyciu tego nagłówka:

Cache-Control: max-age=0,must-revalidate,public

Oznacza to, że plik jest ważny przez długi czas, a przed ponownym użyciem musisz go zweryfikować w sieci (w przeciwnym razie jest tylko „sugerowany”).

Uwaga: zamiast max-age=0,must-revalidate możesz też określić no-cache: to odpowiednik tego pola. Jednak nazwa no-cache może być myląca, ponieważ może zostać zinterpretowana jako „nigdy nie buforuj tego pliku” – mimo że jest inaczej. Intensywne informacje znajdziesz w sekcji Cache-Control w MDN.

Proces weryfikacji jest stosunkowo niedrogi pod względem liczby przesłanych bajtów – jeśli duży plik obrazu nie uległ zmianie, przeglądarka otrzyma niewielką odpowiedź 304, ale kosztuje czas oczekiwania, ponieważ użytkownik musi i tak połączyć się z siecią, aby to sprawdzić. Jest to główna wada takiego podejścia. Może się doskonale sprawdzić w przypadku osób korzystających z szybkich połączeń w pierwszym świecie i w których wybrana przez Ciebie sieć CDN ma duży zasięg, ale nie będzie dla osób, które mogą korzystać z wolniejszych połączeń komórkowych lub z niską infrastrukturą.

Niezależnie od tego jest to nowoczesne podejście domyślne w popularnej sieci CDN – Netlify, które można skonfigurować w niemal każdej sieci CDN. W przypadku Hostingu Firebase możesz umieścić ten nagłówek w sekcji hostingu pliku firebase.json:

"headers": [
  // Be sure to put this last, to not override other headers
  {
    "source": "**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=0,must-revalidate,public"
    }
  }
]

Choć nadal sugeruję to ustawienie jako rozsądną wartość, to jest to tylko ustawienie domyślne. Czytaj dalej, aby dowiedzieć się, jak przejść do ustawień domyślnych.

Adresy URL z odciskami cyfrowymi

Dodając hasz zawartości pliku do nazw zasobów, obrazów itd. wyświetlanych w Twojej witrynie, zapewniasz, że te pliki zawsze będą zawierać unikalne treści – na przykład powstaną pliki o nazwie sitecode.af12de.js. Gdy serwer odpowiada na żądania dotyczące tych plików, możesz bezpiecznie skonfigurować przeglądarki użytkownika w pamięci podręcznej przez dłuższy czas, konfigurując je za pomocą tego nagłówka:

Cache-Control: max-age=31536000,immutable

Ta wartość to rok w sekundach. Według specyfikacji to w rzeczywistości to tyle samo co „zawsze”.

Co ważne, nie generujej tych haszów ręcznie – to zbyt wiele pracy! Możesz w tym celu użyć takich narzędzi jak Webpack, Rollup itp. Więcej informacji na ten temat znajdziesz w raporcie na temat narzędzi.

Pamiętaj, że korzystanie z adresów URL z odciskami cyfrowymi nie tylko w przypadku JavaScriptu. W ten sposób można również nazwać zasoby takie jak ikony, CSS i inne pliki stałych danych. (Obejrzyj powyższy film, aby dowiedzieć się więcej o dzieleniu kodu, dzięki któremu możesz wysyłać mniej kodu przy każdej zmianie w witrynie).

Uwaga: w powyższej rekomendacji (Cache-Control) uwzględniamy słowo kluczowe immutable. Bez tego słowa kluczowego długi Cache-Control jest uważany tylko za sugestię, a niektóre przeglądarki nadal je zignorują i przekierują ruch na serwer. W 2017 roku Chrome zmienił sposób działania, dzięki czemu zawsze działa tak, jakby stałe słowo kluczowe i tak było włączone. Obecnie jest ono potrzebne tylko w Safari i Firefoksie.

Niezależnie od tego, jak Twoja witryna traktuje buforowanie, tego rodzaju pliki z odciskami cyfrowymi są niezwykle przydatne dla każdej witryny, którą tworzysz. Większość witryn nie zmienia się po każdej wersji.

Oczywiście nie możemy zmienić nazwy naszych przyjaznych stron dla użytkowników w ten sposób – zmień nazwę pliku index.html na index.abcd12.html – nie jest to możliwe – nie możesz każdorazowo prosić użytkowników, by otwierali nowy URL przy każdym wczytywaniu witryny. Nie można zmienić nazwy tych „przyjaznych” adresów URL ani zapisywać w ten sposób ich kopii w pamięci podręcznej, co prowadzi mnie do rozwiązania problemu.

Środek

Jeśli chodzi o buforowanie, można znaleźć złoty środek. Zostały przedstawione 2 ekstremalne opcje: pamięć podręczna nigdy lub na zawsze. Są też pliki, które warto zapisać w pamięci podręcznej przez jakiś czas, np. „przyjazne” adresy URL wymienione powyżej.

Jeśli chcesz zapisywać te „przyjazne” adresy URL i ich kod HTML, zastanów się, jakie one zależności, jak mogą być przechowywane w pamięci podręcznej, a także jak może to wpływać na Twój czas przechowywania adresów URL w pamięci podręcznej. Spójrzmy na stronę HTML zawierającą taki obraz:

<img src="/images/foo.jpeg" loading="lazy" />

Jeśli zaktualizujesz lub zaktualizujesz witrynę, usuwając lub zmieniając ten leniwy obraz, użytkownicy, którzy wyświetlają wersję Twojego kodu HTML z pamięci podręcznej, mogą zobaczyć nieprawidłowy lub brakujący obraz, ponieważ podczas ponownej wizyty na Twojej stronie nadal zapisuje w pamięci podręcznej oryginalny plik /images/foo.jpeg.

Jeśli zachowasz ostrożność, problem może nie mieć wpływu na Twoje konto. Ogólnie należy jednak pamiętać, że witryna – jeśli jest przechowywana w pamięci podręcznej przez użytkowników – nie istnieje już tylko na Twoich serwerach. Może natomiast znajdować się w częściach w pamięci podręcznej przeglądarek użytkowników.

Zazwyczaj w większości przewodników na temat buforowania opisano takie ustawienie – czy chcesz zapisywać dane w pamięci podręcznej na godzinę, kilka godzin itd. Aby skonfigurować taki rodzaj pamięci podręcznej, użyj nagłówka podobnego do tego (co oznacza 3600 sekund, czyli godzinę):

Cache-Control: max-age=3600,immutable,public

Jeszcze jedna uwaga. Jeśli tworzysz aktualne treści, do których użytkownicy zwykle mają dostęp tylko raz, np. artykuły z wiadomościami, uważam, że nie powinny być one zapisywane w pamięci podręcznej. Zalecamy skorzystanie z naszych rozsądnych ustawień domyślnych. Wydaje mi się, że często zaniżamy wartość buforowania zamiast chęci użytkownika, by zawsze mieć dostęp do najnowszych i najciekawszych treści, takich jak krytyczna aktualizacja reportażu lub bieżącego wydarzenia.

Opcje inne niż HTML

Oprócz kodu HTML dostępne są też inne opcje dotyczące plików:

• Ogólnie rzecz biorąc, szukaj komponentów, które nie mają wpływu na inne

  • Na przykład: unikaj CSS, ponieważ powoduje to zmiany w sposobie renderowania kodu HTML

• Duże obrazy, które są używane w artykułach w odpowiednim momencie.

  • Użytkownicy prawdopodobnie nie będą odwiedzać żadnego artykułu więcej niż kilka razy, więc nie zapisuj zdjęć ani grafik głównych w nieskończoność, aby

• Zasób, który reprezentuje coś przez całe życie

  • Dane JSON o pogodzie mogą być publikowane tylko co godzinę, więc poprzedni wynik możesz zapisać w pamięci podręcznej na godzinę – nie zmienią się w Twoim oknie
  • Kompilacje projektów open source mogą mieć ograniczoną częstotliwość, więc zapisuj w pamięci podręcznej obraz stanu kompilacji do czasu, aż ten stan się zmieni.

Podsumowanie

Gdy użytkownicy wczytają Twoją witrynę po raz drugi, dajesz im pewność, że chcą wrócić do Twojej oferty jeszcze raz, aby zapoznać się z Twoją ofertą. W tym momencie nie chodzi tylko o skrócenie czasu wczytywania – dostępnych jest wiele opcji, dzięki którym przeglądarka może wykonywać tylko te zadania, które są niezbędne, by zapewnić szybką i aktualną wersję.

Zapisywanie w pamięci podręcznej nie jest nową koncepcją w internecie, ale być może wymagałoby rozsądnego zastosowania domyślnego rozwiązania – w razie potrzeby warto rozważyć użycie go i zdecydowanie zaakceptować lepsze strategie buforowania. Dziękujemy za uwagę!

Zobacz też

Ogólne informacje o pamięci podręcznej HTTP znajdziesz w artykule Zapobiegaj niepotrzebnym żądaniam sieciowym dzięki pamięci podręcznej HTTP.