Chrome brengt een wijziging aan om het gebruik van back/forward cache (bfcache) toe te staan voor pagina's die Cache-Control: no-store gebruiken wanneer dit veilig is om te doen. Ontdek wat dat betekent voor ontwikkelaars.
Achtergrond
Cache-Control: no-store als HTTP-header is een signaal dat de pagina niet in de HTTP-cache mag worden opgeslagen. Dit zou moeten worden gebruikt voor pagina's die gevoelige gegevens bevatten, bijvoorbeeld voor pagina's waarop een gebruiker is ingelogd, maar de no-store -instructie wordt vaak gebruikt op pagina's zonder gevoelige gegevens.
Met bfcache stellen we de vernietiging uit en pauzeren we de JS-uitvoering in plaats van een pagina te vernietigen wanneer de gebruiker wegnavigeert. Als de gebruiker snel terug navigeert, maken we de pagina weer zichtbaar en hervatten we de JS-uitvoering. Dit resulteert in een vrijwel onmiddellijke paginanavigatie voor de gebruiker.
Hoewel dit niet vereist is door de HTML-specificatie, gebruiken browsers doorgaans Cache-Control: no-store als signaal om te voorkomen dat de pagina in bfcache wordt geplaatst. Dit is de grootste reden waarom de bfcache niet wordt gebruikt , voor ongeveer 17% van de geschiedenisnavigaties op mobiel en 7% van de geschiedenisnavigaties op desktop. Dit betekent dat deze pagina's niet profiteren van het snelle herstel en de pagina volledig opnieuw moeten laden, inclusief eventuele netwerkaanroepen, JavaScript-uitvoering en weergave.
Vaak Cache-Control: no-store is ingesteld om caching-problemen te voorkomen wanneer de site verandert, maar deze reden is minder relevant wanneer de bfcache wordt gebruikt, omdat de volledige pagina wordt hersteld alsof deze de hele tijd open heeft gestaan.
Hoe Chrome dit gedrag verandert
Chrome heeft aangekondigd dit gedrag te willen veranderen , maar gaat voorzichtig om met deze verandering. We voeren experimenten uit sinds Chrome 116 en tot voor kort werden deze uitgevoerd bij 5% van de paginaladingen.
We hebben dit op 2 oktober verhoogd naar 10% van het aantal pagina's en zijn van plan dit verder te verhogen naar 20% van het aantal pagina's in november, 50% begin volgend jaar. Dit zullen we kort daarna volledig lanceren, waarbij bepaalde opt-outs hierna worden besproken.
Gevoelige gegevens
Hoewel uit onze analyse blijkt dat de meerderheid van de terug- of vooruitnavigaties geen gevoelige gegevens bevat en dus in aanmerking zou moeten komen voor de bfcache, zijn er gevallen waarin pagina's niet in de bfcache mogen worden geplaatst. Bij het uitloggen zou het bijvoorbeeld niet mogelijk moeten zijn om een ingelogde pagina op te halen door heen of weer te navigeren.
Om dit te voorkomen, zal Chrome een pagina uit de bfcache verwijderen bij wijzigingen in cookies of andere autorisatiemethoden .
Bovendien zal het gebruik van de volgende API's voor pagina's die Cache-Control: no-store gebruiken ervoor zorgen dat die pagina's niet in aanmerking komen voor bfcache:
Merk op dat dit geen uitgebreide lijst is van API's die het gebruik van bfcache voorkomen, maar de API's die bfcache op Cache-Control: no-store zelfs als ze niet worden gebruikt op het moment dat de pagina wordt verlaten.
De bfcache-time-out voor Cache-Control: no-store -pagina's wordt ook teruggebracht tot 3 minuten (was 10 minuten gebruikt voor pagina's die geen Cache-Control: no-store gebruiken) om het risico verder te verminderen.
Enterprise uit kiest
Bedrijven beschikken vaak over moeilijk te updaten software en gedeelde apparaten. Het beleid AllowBackForwardCacheForCacheControlNoStorePageEnabled kan worden uitgeschakeld om het gebruik van bfcache voor Cache-Control: no-store -pagina's te blijven voorkomen.
Het testen van de verandering
Ontwikkelaars kunnen deze wijziging testen met de volgende vlag:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Als een van de voorgaande uitzonderingen van toepassing is (bijvoorbeeld als cookies veranderen), zal dit voorkomen dat de pagina de bfcache gebruikt met als reden "Pagina's waarvan de hoofdbron Cache-Control: no-store kan de back/forward cache niet betreden." weergegeven in de Chrome DevTools bfcache-tester .
U kunt deze bfcache-testpagina gebruiken om te testen met en zonder deze vlag.
Wat ontwikkelaars moeten weten
Hoewel ontwikkelaars geen wijzigingen hoeven aan te brengen zodat hun gebruikers kunnen profiteren van dit grotere bfcache-gebruik, zijn er enkele dingen waarmee ze mogelijk rekening moeten houden als gevolg hiervan. Dit waren soortgelijke overwegingen die andere sites mogelijk hebben ervaren bij de eerste lancering van bfcache in december 2021.
Impact op de prestaties
De reden dat we deze wijziging doorvoeren is om de pagina-ervaring voor gebruikers op internet te verbeteren. We zagen merkbare verbeteringen in Core Web Vitals toen we bfcache voor het eerst lanceerden, en nu willen we diezelfde verbeteringen naar meer sites brengen.
Site-eigenaren zien mogelijk een verbetering in hun Core Web Vitals naarmate dit wordt uitgerold, en kunnen het bfcache-gebruik in Crux meten, inclusief in het Crux Dashboard .
Impactanalyse
Pagina's die vanuit de bfcache zijn hersteld, "herstellen" de oude pagina (inclusief de JavaScript-heap) in plaats van de pagina opnieuw te laden. Veel populaire analyseproviders meten bfcache-herstel niet als nieuwe paginaweergaven, omdat ze alleen paginaweergaven activeren wanneer ze voor het eerst worden geladen.
Sites kunnen daarom in hun analyses een vermindering van het aantal pagina's zien wanneer ze de bfcache voor de eerste keer gaan gebruiken. We raden u aan deze als paginaweergaven te beschouwen, door luisteraars in te stellen voor de pageshow gebeurtenis en de persisted eigenschap te controleren:
// 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');
}
});
Updates verwerken bij paginaherstel
Omdat sites nu bfcache-gebruik kunnen zien terwijl ze dit niet eerder zagen en wanneer de pagina in plaats daarvan volledig opnieuw zou worden geladen met nieuwe gegevens, kunnen ontwikkelaars overwegen om gegevens te vernieuwen bij een bfcache-herstel.
Updates kunnen op dezelfde manier worden geactiveerd als het registreren van extra paginaweergaven voor analyse met behulp van de pageshow gebeurtenis en het controleren van de persisted eigenschap.
Houd er rekening mee dat niet alle inhoud hoeft te worden bijgewerkt en dat gebruikers er mogelijk de voorkeur aan geven "terug" te gaan naar de inhoud die ze eerder hebben gezien. Het vernieuwen van een lijst met artikelen kan bijvoorbeeld betekenen dat de gebruiker het artikel dat hij/zij wilde bekijken, niet meer ziet.
Impact op advertenties
Net als bij de impact van analyses kunnen sites een vermindering van het aantal advertentievertoningen zien als advertenties alleen worden geladen wanneer de pagina wordt geladen. Advertenties kunnen programmatisch worden vernieuwd bij bfcache-herstel om pariteit met het laden van de volledige pagina te garanderen, opnieuw met behulp van de pageshow -gebeurtenis en het controleren van de persisted eigenschap, maar dit is mogelijk niet altijd het juiste om te doen . Raadpleeg de documentatie van uw advertentieaanbieder over hoe u het opnieuw laden van advertenties activeert.
Meer informatie over bfcache
Voor meer informatie over bfcache, zie onze uitgebreide technische gids voor bfcache .
Feedback
We zijn benieuwd naar feedback over deze wijziging. Deze kan worden gegeven in de issue tracker van Chrome met behulp van de bfcache-component .
Conclusie
We zijn verheugd om het voordeel van bfcache naar veel meer pagina's te brengen om de pagina-ervaring voor gebruikers te verbeteren. We hebben deze verandering zorgvuldig overwogen en onze aanpak is erop gericht deze op een zo veilig mogelijke manier uit te rollen. We hopen dat de hier verstrekte informatie ontwikkelaars zal helpen deze wijziging te begrijpen en eventuele wijzigingen aan te brengen die nodig zijn om problemen te voorkomen wanneer dit gebeurt.