Gepubliceerd: 21 oktober 2024, Laatst bijgewerkt: 9 sep 2025
Chrome voert een wijziging door om back-forward cache (bfcache) -gebruik toe te staan voor pagina's die Cache-Control: no-store gebruiken wanneer dit veilig is. Lees meer over wat dit betekent voor ontwikkelaars.
Achtergrond
Het instellen van Cache-Control: no-store als HTTP-header geeft aan dat de pagina niet in de HTTP-cache mag worden opgeslagen. Dit zou moeten worden gebruikt voor pagina's met gevoelige gegevens, bijvoorbeeld voor pagina's waarop een gebruiker is ingelogd. De no-store -instructie wordt echter vaak gebruikt voor pagina's zonder gevoelige gegevens.
Met bfcache vernietigen we een pagina niet wanneer de gebruiker wegnavigeert, maar stellen we de vernietiging uit en pauzeren we de JS-uitvoering. Als de gebruiker snel weer terug navigeert, maken we de pagina weer zichtbaar en hervatten we de JS-uitvoering. Dit resulteert in vrijwel directe paginanavigatie voor de gebruiker.
Hoewel het niet vereist is door de HTML-specificatie, gebruiken browsers Cache-Control: no-store doorgaans als signaal om te voorkomen dat de pagina in bfcache wordt geplaatst. Dit is de belangrijkste reden waarom bfcache niet wordt gebruikt : voor ongeveer 17% van de navigatiegeschiedenis op mobiele apparaten en 7% van de navigatiegeschiedenis op desktops. Dit betekent dat deze pagina's niet profiteren van de snelle herstelbewerkingen en de pagina volledig opnieuw moeten laden, inclusief netwerkaanroepen, JavaScript-uitvoering en rendering.
Vaak wordt Cache-Control: no-store ingesteld om cacheproblemen te voorkomen als de site verandert. Deze reden is echter minder relevant wanneer bfcache wordt gebruikt, omdat de volledige pagina wordt hersteld alsof deze al die tijd open is gebleven.
Hoe Chrome dit gedrag verandert
Chrome heeft aangekondigd dit gedrag te willen veranderen, maar hanteert hierbij een voorzichtige aanpak. We voeren al sinds Chrome 116 experimenten uit om het percentage geladen pagina's geleidelijk te verhogen en dit zal naar verwachting in maart en april 2025 100% bereiken.
Gevoelige gegevens
Hoewel onze analyse aantoont dat de meeste terug- of vooruitnavigaties geen gevoelige gegevens bevatten en daarom in aanmerking zouden moeten komen voor de bfcache, zijn er gevallen waarin pagina's niet in de bfcache geplaatst zouden moeten worden. Bijvoorbeeld, bij het uitloggen zou het niet mogelijk moeten zijn om een ingelogde pagina op te halen door heen en weer te navigeren.
Om dit te voorkomen, verwijdert Chrome een pagina uit de bfcache bij wijzigingen in cookies of andere autorisatiemethoden .
Bovendien zorgt het gebruik van de volgende API's voor pagina's die Cache-Control: no-store ervoor dat deze pagina's nog steeds niet in aanmerking komen voor bfcache:
Houd er rekening mee dat dit geen volledige lijst is van API's die het gebruik van bfcache voorkomen, maar van de API's die bfcache blokkeren op Cache-Control: no-store pagina's, 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 is ook verlaagd naar 3 minuten (voor pagina's die geen Cache-Control: no-store gebruiken was dit 10 minuten) om het risico verder te verkleinen.
Enterprise kiest voor out-opts
Bedrijven hebben vaak software die moeilijk te updaten is en gedeelde apparaten. Het beleid AllowBackForwardCacheForCacheControlNoStorePageEnabled kan worden uitgeschakeld om bfcache-gebruik voor Cache-Control: no-store pagina's te blijven voorkomen.
De verandering testen
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 wijzigingen in cookies), voorkomt dit dat de pagina de bfcache gebruikt met de reden 'Pagina's waarvan de hoofdbron Cache-Control: no-store heeft, kunnen de back-forward cache niet openen' in de Chrome DevTools bfcache-tester .
U kunt deze bfcache-testpagina gebruiken om met en zonder deze vlag te testen.
Wat ontwikkelaars moeten weten
Hoewel ontwikkelaars geen wijzigingen hoeven aan te brengen om hun gebruikers te laten profiteren van dit grotere bfcache-gebruik, zijn er wel een aantal zaken waar ze rekening mee moeten houden. Dit waren vergelijkbare overwegingen die andere sites mogelijk hebben ervaren bij de eerste lancering van bfcache in december 2021.
Moeten ontwikkelaars er nog steeds naar streven het gebruik van Cache-Control: no-store te verminderen?
Bfcache is ingeschakeld voor Cache-Control: no-store onder de eerder genoemde beperkte omstandigheden en alleen voor Chrome. Andere browsers kunnen het gebruik van bfcache nog steeds blokkeren wanneer Cache-Control: no-store wordt gebruikt.
De beste praktijk blijft om het gebruik van Cache-Control: no-store , maar vertrouw niet op deze heuristiek.
Impact op prestaties
We voeren deze wijziging door om de pagina-ervaring voor webgebruikers 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 doorvoeren.
Website-eigenaren kunnen een verbetering in hun Core Web Vitals verwachten wanneer dit wordt uitgerold en kunnen het bfcache-gebruik in CrUX meten, inclusief in CrUX Vis .
Impactanalyse
Pagina's die vanuit de bfcache worden hersteld, "herstellen" de oude pagina (inclusief de JavaScript-heap) in plaats van de pagina opnieuw te laden. Veel populaire analyseproviders meten bfcache-herstelbewerkingen niet als nieuwe paginaweergaven, omdat ze alleen paginaweergaven activeren wanneer ze voor het eerst worden geladen.
Sites kunnen daarom een vermindering in het aantal paginaweergaven in hun analyses zien wanneer ze de bfcache voor het eerst gebruiken. We raden aan deze als paginaweergaven te beschouwen door listeners 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 dat voorheen niet het geval was en de pagina in plaats daarvan volledig opnieuw wordt geladen met nieuwe gegevens, kunnen ontwikkelaars overwegen om gegevens te vernieuwen bij een bfcache-herstel.
Updates kunnen op een vergelijkbare manier worden geactiveerd als het registreren van extra paginaweergaven voor analyses met behulp van de gebeurtenis pageshow en het controleren van de persisted eigenschap.
Houd er rekening mee dat niet alle content bijgewerkt hoeft te worden en dat gebruikers er mogelijk de voorkeur aan geven om terug te gaan naar de content die ze eerder hebben bekeken. Het vernieuwen van een lijst met artikelen kan er bijvoorbeeld toe leiden dat de gebruiker een artikel dat hij/zij wilde bekijken, niet meer ziet.
Impact op advertenties
Net als bij Analytics kunnen sites een afname in advertentievertoningen zien als advertenties alleen laden bij het laden van de pagina. Advertenties kunnen programmatisch worden vernieuwd bij bfcache-herstel om pariteit te garanderen met volledige paginaladingen. Hierbij wordt opnieuw de pageshow gebeurtenis gebruikt en de persisted eigenschap gecontroleerd, maar dit is niet altijd de juiste aanpak . Raadpleeg de documentatie van uw advertentieprovider voor informatie over het activeren van advertentieherladingen.
Meer informatie over bfcache
Voor meer informatie over bfcache, zie onze uitgebreide technische handleiding voor bfcache .
Feedback
We horen graag uw feedback over deze wijziging. U kunt uw feedback doorgeven via de issue tracker van Chrome met behulp van het bfcache-component .
Conclusie
We zijn verheugd om de voordelen van bfcache naar veel meer pagina's te brengen en zo de pagina-ervaring voor gebruikers te verbeteren. We hebben deze wijziging zorgvuldig overwogen en onze aanpak is erop gericht deze zo veilig mogelijk uit te rollen. We hopen dat de hier verstrekte informatie ontwikkelaars helpt deze wijziging te begrijpen en de nodige aanpassingen door te voeren om problemen te voorkomen wanneer dit gebeurt.