W Chrome wprowadzamy zmianę, która umożliwi użytkowanie pamięci podręcznej wstecz/do przodu (bfcache) na stronach korzystających z Cache-Control: no-store, gdy będzie to bezpieczne. Dowiedz się, co to oznacza dla deweloperów.
Tło
Ustawienie wartości Cache-Control: no-store jako nagłówka HTTP jest sygnałem, że strona nie powinna być przechowywana w pamięci podręcznej HTTP. Należy jej używać na stronach zawierających dane wrażliwe, np. na stronach, na których użytkownik jest zalogowany, ale często na stronach bez danych wrażliwych jest używana dyrektywa no-store.
Dzięki bfcache zamiast usuwać stronę, gdy użytkownik ją opuszcza, odkładamy usuwanie i wstrzymujemy wykonywanie kodu JS. Jeśli użytkownik szybko wróci, ponownie wyświetlimy stronę i wznowimy wykonywanie kodu JS. Dzięki temu użytkownik może niemal natychmiast przejść na inną stronę.
Chociaż specyfikacja HTML tego nie wymaga, przeglądarki zwykle interpretują Cache-Control: no-store jako sygnał, aby nie umieszczać strony w bfcache. To największy powód, dla którego nie jest używana pamięć podręczna bfcache – dotyczy to około 17% przejść do historii na urządzeniach mobilnych i 7% przejść do historii na komputerach. Oznacza to, że te strony nie korzystają z szybkiego przywracania i należy je całkowicie ponownie wczytać, w tym uwzględniając wywołania sieci, wykonanie kodu JavaScript i renderowanie.
Często parametr Cache-Control: no-store jest ustawiany, aby uniknąć problemów z pamięcią podręczną podczas zmiany witryny, ale ten powód jest mniej istotny, gdy używasz pamięci podręcznej stanu strony internetowej, ponieważ pełna strona jest przywracana prawie tak, jakby była otwarta przez cały czas.
Jak Chrome zmienia to zachowanie
Chrome zapowiedziało zamiar zmiany tego zachowania, ale podchodzi do tej zmiany ostrożnie. Eksperymenty prowadzimy od wersji Chrome 116 i do niedawna obejmowały one 5% wczytanych stron.
2 października zwiększyliśmy ten odsetek do 10% wczytanych stron. W listopadzie planujemy zwiększyć go do 20%, a na początku przyszłego roku – do 50%. Krótko potem wprowadzimy tę funkcję na stałe, a w tym czasie będziemy informować o możliwościach rezygnacji z tej funkcji.
Dane wrażliwe
Chociaż nasza analiza pokazuje, że większość stron nawigacji wstecz i do przodu nie zawiera danych poufnych i powinna być dostępna w pamięci podręcznej stanu strony internetowej, są przypadki, w których nie należy umieszczać w niej stron. Na przykład po wylogowaniu się nie powinno być możliwe przejście do strony logowania przez cofnięcie lub przewinięcie.
Aby tego uniknąć, Chrome usuwa stronę z pamięci podręcznej bfcache po zmianach w plikach cookie lub innych metodach autoryzacji.
Ponadto korzystanie z tych interfejsów API na stronach, które używają Cache-Control: no-store, nadal będzie powodować, że te strony nie będą się kwalifikować do korzystania z pamięci podręcznej stanu strony internetowej:
Pamiętaj, że nie jest to pełna lista interfejsów API, które uniemożliwiają korzystanie z bfcache, ale tylko tych, które blokują bfcache na stronach Cache-Control: no-store, nawet jeśli nie są używane w momencie opuszczania strony.
Aby jeszcze bardziej zmniejszyć ryzyko, czas oczekiwania na odpowiedź z pamięci podręcznej stanu strony internetowej w przypadku stron Cache-Control: no-store został skrócony do 3 minut (z 10 minut stosowanych w przypadku stron, które nie korzystają z funkcji Cache-Control: no-store).
Rezygnacja z usług Google Enterprise
Firmy często mają trudności z aktualizacją oprogramowania i współdzielonych urządzeń. Aby nadal uniemożliwić korzystanie z pamięci podręcznej stanu strony internetowej na stronach Cache-Control: no-store, możesz wyłączyć zasadę AllowBackForwardCacheForCacheControlNoStorePageEnabled.
Testowanie zmiany
Deweloperzy mogą przetestować tę zmianę za pomocą tej flagi:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Jeśli ma zastosowanie któreś z wcześniejszych wyjątków (np. zmiana plików cookie), strona nie będzie korzystać z pamięci podręcznej stanu strony internetowej. W testerze pamięci podręcznej stanu strony internetowej w Chrome DevTools wyświetli się komunikat „Strona, której główny zasób ma wartość Cache-Control: no-store, nie może korzystać z pamięci podręcznej stanu strony internetowej”.
Aby przetestować działanie tej opcji, możesz użyć strony testowej bfcache.
Informacje dla deweloperów
Chociaż deweloperzy nie będą musieli wprowadzać żadnych zmian, aby ich użytkownicy mogli korzystać z większego wykorzystania bfcache, mogą być pewne kwestie, które będą musieli wziąć pod uwagę. Inne witryny mogły napotkać podobne problemy podczas wdrożenia bfcache w grudniu 2021 r.
Wpływ na wydajność
Ta zmiana ma na celu poprawę jakości stron internetowych. Po pierwszym uruchomieniu bfcache zauważyliśmy znaczne ulepszenia podstawowych wskaźników internetowych. Teraz chcemy udostępnić te ulepszenia większej liczbie witryn.
Właściciele witryn mogą zauważyć poprawę podstawowych wskaźników internetowych w trakcie wdrażania tej funkcji. Mogą też mierzyć wykorzystanie bfcache w CrUX, m.in. w panelu CrUX.
Analiza wpływu
Strony przywracane z pamięci podręcznej stanu strony internetowej „przywracają” starą stronę (w tym stos JavaScript), a nie ją ponownie wczytują. Wielu popularnych dostawców usług analitycznych nie traktuje przywracania bfcache jako nowych wyświetleń strony, ponieważ wywołuje ono wyświetlenia strony tylko podczas początkowego wczytania.
Dlatego, gdy witryny po raz pierwszy zaczną korzystać z bfcache, mogą zauważyć w statystykach spadek liczby wczytanych stron. Zalecamy traktowanie tych zdarzeń jako wyświetleń strony. Aby to zrobić, ustaw odbiorniki dla zdarzenia pageshow i sprawdź właściwość persisted:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
Obsługa zmian podczas przywracania strony
Ponieważ witryny mogą teraz korzystać z bfcache, gdy wcześniej nie korzystały z tego mechanizmu, a zamiast tego strona była całkowicie przeładowy z nowymi danymi, deweloperzy powinni rozważyć odświeżanie danych przy przywracaniu bfcache.
Aktualizacje mogą być wywoływane w sposób podobny do rejestrowania dodatkowych wyświetleń stron na potrzeby usług analitycznych za pomocą zdarzenia pageshow i sprawdzania właściwości persisted.
Pamiętaj, że nie wszystkie treści muszą być aktualizowane, a użytkownicy mogą chcieć „wrócić” do treści, które widzieli wcześniej. Na przykład odświeżenie listy artykułów może spowodować, że użytkownik nie zobaczy już artykułu, do którego wracał.
Wpływ na reklamy
Podobnie jak w przypadku wpływu na usługi analityczne, witryny mogą odnotować spadek liczby wyświetleń reklam, jeśli reklamy wczytują się dopiero po załadowaniu strony. Reklamy można odświeżać programowo podczas przywracania pamięci podręcznej bfcache, aby zapewnić zgodność z pełnym wczytaniem strony. W tym celu ponownie używa się zdarzenia pageshow i właściwości persisted, ale nie zawsze jest to właściwe rozwiązanie. W dokumentacji dostawcy reklam znajdziesz informacje o tym, jak wywoływać ponowne wczytywanie reklam.
Więcej informacji o pamięci podręcznej stanu strony internetowej
Więcej informacji o bfcache znajdziesz w szczegółowym przewodniku technicznym na temat bfcache.
Prześlij opinię
Chętnie poznamy Twoją opinię na temat tej zmiany. Możesz ją przesłać w śledzeniu problemów w Chrome za pomocą komponentu bfcache.
Podsumowanie
Cieszymy się, że możemy udostępnić korzyści z użycia bfcache na wielu kolejnych stronach, aby poprawić wrażenia użytkowników. Uważnie przeanalizowaliśmy tę zmianę i szukamy sposobu na jej wdrożenie w jak najbardziej bezpieczny sposób. Mamy nadzieję, że te informacje pomogą deweloperom zrozumieć tę zmianę i wprowadzić niezbędne zmiany, aby uniknąć problemów.