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, nous rendons la page visible à nouveau et réactivons l'exécution du code JavaScript. 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 actualisé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 avait été laissée ouverte tout du long.
Comment Chrome modifie-t-il 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 l'avons porté à 10% des chargements de pages le 2 octobre, et nous prévoyons de l'augmenter à 20% en novembre, puis à 50% début l'année prochaine. Nous le déploierons complètement peu de temps après, et certaines options de désactivation seront abordées ci-dessous.
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 bfcache pour tester avec et sans cet indicateur.
Ce que les développeurs doivent savoir
Bien que les développeurs n'aient pas besoin d'apporter de modifications pour que leurs utilisateurs profitent de cette utilisation accrue de bfcache, ils devront peut-être prendre certaines choses en compte. 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 peuvent constater une amélioration de leurs Core Web Vitals à mesure que cette fonctionnalité sera déployée. Ils peuvent également mesurer l'utilisation de bfcache dans 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.
Il est donc possible que les sites constatent une diminution des chargements de page dans leurs données analytiques lorsqu'ils commencent à utiliser le bfcache 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 l'enregistrement 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 par programmation 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
Nous sommes impatients de recevoir vos commentaires sur ce changement, que vous pouvez nous envoyer dans le 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 les problèmes qui pourraient en découler.