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 nie jest wymagana, przeglądarki zwykle traktują Cache-Control: no-store jako sygnał, który pozwala uniknąć umieszczania strony w pamięci podręcznej stanu strony internetowej. 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 takie strony nie korzystają z szybkiego przywracania i muszą całkowicie załadować stronę ponownie, łącznie ze wszystkimi wywołaniami sieciowymi, wykonaniem JavaScriptu i renderowaniem.
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 trwały przy 5% wczytywania 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ż z naszej analizy wynika, że większość nawigacji wstecz lub do przodu nie zawiera danych wrażliwych, więc powinna ona kwalifikować się do pamięci podręcznej stanu strony internetowej, ale w niektórych przypadkach strony nie powinny być umieszczane w pamięci podręcznej stanu strony internetowej. Na przykład po wylogowaniu nie powinno być możliwości odzyskania zalogowanej strony z powrotem lub z powrotem.
Aby tego uniknąć, Chrome usuwa stronę z pamięci podręcznej bfcache po zmianach w plikach cookie lub innych metodach autoryzacji.
Ponadto użycie tych interfejsów API na stronach używających Cache-Control: no-store w dalszym ciągu sprawi, że strony te nie będą się kwalifikować do wykorzystania w 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.
Czas oczekiwania bfcache w przypadku stron Cache-Control: no-store został też skrócony do 3 minut (z 10 minut w przypadku stron, które nie korzystają z Cache-Control: no-store), aby jeszcze bardziej zmniejszyć ryzyko.
Rezygnacja z usług Google Enterprise
Firmy często mają trudności z aktualizacją i współdzielone urządzenia. Aby nadal uniemożliwić korzystanie z pamięci podręcznej stanu strony internetowej na stronach Cache-Control: no-store, można 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 zachodzi jedno z wcześniejszych wyjątków (np. zmiana plików cookie), strona nie będzie mogła 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”.
Na tej stronie testowej bfcache możesz przeprowadzić testy z użyciem tej flagi i bez niej.
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 miarę 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 wczytują jej ponownie. Wielu popularnych dostawców rozwiązań analitycznych nie mierzy operacji przywracania Bfcache jako nowych wyświetleń strony, ponieważ wyzwalają one wyświetlenia tylko przy wstępnym wczytaniu.
W związku z tym strony mogą zauważyć w statystykach spadek liczby ładowań stron, jeśli po raz pierwszy zaczną korzystać z pamięci podręcznej stanu strony internetowej. 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
Witryny mogą teraz zobaczyć użycie pamięci podręcznej stanu strony internetowej, gdy wcześniej jej nie widzieli, oraz wtedy, gdy strona została w pełni ponownie załadowana nowymi danymi, więc deweloperzy mogą rozważyć odświeżenie danych przy przywracaniu pamięci podręcznej stanu strony internetowej.
Aktualizacje mogą być wywoływane w sposób podobny do rejestrowania dodatkowych wyświetleń stron na potrzeby funkcji 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 statystyk, witryny mogą zauważyć spadek liczby wyświetleń reklam, jeśli reklamy wczytują się tylko podczas wczytywania 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żywasz zdarzenia pageshow i sprawdzasz właściwość 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ć funkcję bfcache na wielu stronach, aby poprawić wrażenia użytkowników. Uważnie przeanalizowaliśmy tę zmianę i szukamy sposobu na jej wdrożenie w jak najbezpieczniejszy sposób. Mamy nadzieję, że te informacje pomogą deweloperom zrozumieć tę zmianę i wprowadzić niezbędne zmiany, aby uniknąć problemów.