Chrome apporte un changement pour autoriser l'utilisation du cache avant/arrière (bfcache) pour les pages utilisant Cache-Control: no-store lorsque cela est possible. Découvrez ce que cela signifie pour les développeurs.
Contexte
Définir Cache-Control: no-store comme en-tête HTTP indique que la page ne doit pas être stockée dans le cache HTTP. Cette directive doit être utilisée pour les pages contenant des données sensibles (par exemple, les pages d'un utilisateur connecté), mais la directive no-store est souvent utilisée sur les pages sans données sensibles.
Avec bfcache, au lieu de détruire une page lorsque l'utilisateur quitte la page, nous retardons la destruction et mettons en pause l'exécution du code JavaScript. Si l'utilisateur revient rapidement en arrière, la page sera de nouveau visible et nous réactiverons l'exécution JS. Cela permet une navigation presque instantanée sur les pages pour l'utilisateur.
Bien que cela ne soit pas obligatoire dans les spécifications HTML, les navigateurs considèrent généralement Cache-Control: no-store comme un signal pour éviter de placer la page dans bfcache. C'est la principale raison pour laquelle le bfcache n'est pas utilisé, pour environ 17 % des navigations dans l'historique sur mobile et 7 % sur ordinateur. Cela signifie que ces pages ne bénéficient pas des restaurations rapides et doivent être entièrement rechargées, y compris les appels réseau, l'exécution JavaScript et le rendu.
Cache-Control: no-store est souvent défini pour éviter les problèmes de mise en cache lorsque le site change, mais cette raison est moins pertinente lorsque le bfcache est utilisé, car la page complète est restaurée presque comme si elle était restée ouverte tout du long.
Comment Chrome modifie ce comportement
Chrome a annoncé son intention de modifier ce comportement, mais adopte une approche prudente. Nous effectuons des tests depuis Chrome 116. Jusqu'à récemment, ils étaient exécutés sur 5 % des chargements de pages.
Nous avons augmenté ce pourcentage pour atteindre 10% des chargements de pages le 2 octobre et nous prévoyons de le faire passer à 20% des chargements de pages en novembre (50% au début de l'année prochaine). Nous lancerons cette fonctionnalité complètement peu de temps après, et nous parlerons ensuite de certaines options de désactivation.
données sensibles
Bien que notre analyse montre que la majorité des navigations "Retour" ou "Avant" n'incluent pas de données sensibles et devraient donc être éligibles au bfcache, il existe des cas où les pages ne doivent pas être placées dans le bfcache. Par exemple, lorsque vous vous déconnectez, vous ne devriez pas pouvoir récupérer une page de connexion en naviguant en arrière ou en avant.
Pour éviter cela, Chrome supprime une page du bfcache en cas de modification des cookies ou d'autres méthodes d'autorisation.
De plus, l'utilisation des API suivantes pour les pages qui utilisent Cache-Control: no-store continuera de les rendre non éligibles au cache amélioré :
Notez qu'il ne s'agit pas d'une liste exhaustive des API qui empêchent l'utilisation de bfcache, mais des API qui bloquent bfcache sur les pages Cache-Control: no-store, même si elles ne sont pas utilisées au moment de quitter la page.
Le délai avant expiration du cache amélioré pour les pages Cache-Control: no-store est également réduit à trois minutes (au lieu de 10 minutes pour les pages qui n'utilisent pas Cache-Control: no-store) afin de réduire davantage les risques.
Désactivations d'entreprise
Les entreprises disposent souvent de logiciels et d'appareils partagés difficiles à mettre à jour. La règle AllowBackForwardCacheForCacheControlNoStorePageEnabled peut être désactivée pour continuer à empêcher l'utilisation du cache amélioré pour les pages Cache-Control: no-store.
Tester le changement
Les développeurs peuvent tester cette modification avec l'indicateur suivant :
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Si l'une des exceptions précédentes s'applique (par exemple, la modification des cookies), la page ne pourra pas utiliser le bfcache. Le message "Les pages dont la ressource principale est Cache-Control: no-store ne peuvent pas accéder au cache avant/arrière" s'affichera dans le testeur du bfcache Chrome DevTools.
Vous pouvez utiliser cette page de test du cache amélioré pour effectuer des tests avec et sans cet indicateur.
Ce que les développeurs doivent savoir
Les développeurs n'auront pas besoin d'apporter de modifications pour que leurs utilisateurs puissent bénéficier de cette utilisation accrue du cache amélioré, mais ils devront peut-être prendre en compte certains éléments. D'autres sites ont peut-être rencontré des problèmes similaires lors du lancement initial de bfcache en décembre 2021.
Impact sur les performances
Nous apportons ce changement pour améliorer l'expérience sur les pages pour les utilisateurs sur le Web. Lorsque nous avons lancé bfcache pour la première fois, nous avons constaté des améliorations notables des métriques Core Web Vitals. Nous souhaitons maintenant étendre ces améliorations à davantage de sites.
Les propriétaires de sites pourront constater une amélioration de leurs Core Web Vitals lors du déploiement et peuvent mesurer l'utilisation du cache amélioré dans l'expérience utilisateur Chrome (CrUX), y compris dans le tableau de bord CrUX.
Analyse de l'impact
Les pages restaurées à partir du bfcache "restaurent" l'ancienne page (y compris la pile JavaScript) plutôt que de la recharger. De nombreux fournisseurs d'analyse populaires ne mesurent pas les restaurations du cache amélioré comme de nouvelles pages vues, car elles ne déclenchent des pages vues que lors du chargement initial.
Par conséquent, les sites peuvent constater une réduction des chargements de page dans leurs analyses lorsqu'ils commencent à utiliser le cache amélioré pour la première fois. Nous vous recommandons de les considérer comme des pages vues en définissant des écouteurs pour l'événement pageshow et en vérifiant la propriété 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');
}
});
Gérer les mises à jour lors de la restauration de la page
Comme les sites peuvent désormais voir l'utilisation de bfcache alors qu'ils ne le voyaient pas auparavant et que la page était entièrement actualisée avec des données fraîches, les développeurs peuvent envisager d'actualiser les données lors d'une restauration de bfcache.
Les mises à jour peuvent être déclenchées de la même manière que la journalisation d'autres pages vues pour l'analyse à l'aide de l'événement pageshow et de la vérification de la propriété persisted.
Notez que tous les contenus ne doivent pas être mis à jour et que les utilisateurs peuvent préférer revenir au contenu qu'ils ont vu précédemment. Par exemple, l'actualisation d'une liste d'articles peut entraîner la disparition d'un article que l'utilisateur était en train de consulter.
Impact sur les annonces
Comme pour l'impact sur les données analytiques, le nombre d'impressions d'annonces peut diminuer si les annonces ne se chargent qu'au chargement de la page. Les annonces peuvent être actualisées de manière programmatique lors de la restauration du cache amélioré pour assurer la parité avec les chargements de page complets. Pour ce faire, utilisez à nouveau l'événement pageshow et vérifiez la propriété persisted. Toutefois, cette approche n'est pas toujours la meilleure. Consultez la documentation de votre fournisseur d'annonces pour savoir comment déclencher le rechargement des annonces.
En savoir plus sur bfcache
Pour en savoir plus sur bfcache, consultez notre guide technique complet sur bfcache.
Commentaires
N'hésitez pas à nous faire part de vos commentaires sur ce changement. Pour ce faire, accédez à l'outil de suivi des problèmes de Chrome à l'aide du composant bfcache.
Conclusion
Nous sommes ravis de pouvoir proposer les avantages de bfcache à un plus grand nombre de pages afin d'améliorer l'expérience utilisateur. Nous avons soigneusement réfléchi à ce changement, et notre approche vise à le déployer de la manière la plus sûre possible. Nous espérons que les informations fournies ici aideront les développeurs à comprendre ce changement et à apporter les modifications nécessaires pour éviter tout problème lorsque cela se produit.