Cache arrière/avant (bfcache)

TL;DR — Le cache arrière/avant (bfcache) est une fonction du navigateur qui gèle une page entière en mémoire lorsque vous la quittez. Ainsi, les boutons Back et Forward peuvent la restaurer instantanément — sans rechargement — tant que le navigateur n’a pas évincé cette page gelée. C’est une fonction du navigateur, pas un facteur de classement Google. Comme une page restaurée se charge presque instantanément, elle améliore discrètement vos chiffres Core Web Vitals sur les navigations Back/Forward effectivement restaurées ; c’est pourquoi un audit de performance peut vous demander de « corriger l’éligibilité au bfcache ».

Qu’est-ce que le bfcache ?

Lorsque vous cliquez sur le bouton Back du navigateur, deux scénarios sont possibles. Le navigateur peut reconstruire la page précédente depuis zéro — retélécharger les fichiers, réexécuter JavaScript et recalculer toute la mise en page — ou restaurer la page instantanément, exactement dans l’état où vous l’aviez laissée. Cette version instantanée est le cache arrière/avant, ou bfcache.

Voici l’astuce : au lieu de supprimer l’ancienne page lorsque vous la quittez, le navigateur gèle la page entière en mémoire — absolument tout, y compris JavaScript en cours d’exécution — et la conserve. Si vous revenez assez vite et que le navigateur dispose encore de cette page gelée, il la dégèle et l’affiche exactement comme avant — sans requête réseau ni attente. La restauration est possible, pas garantie : le navigateur peut évincer une page gelée avant votre retour (mémoire insuffisante, délai d’expiration ou activité particulière) ; vous obtenez alors un rechargement normal.

La description en une ligne de Google l’exprime clairement : le bfcache est “a browser optimization that enables instant back and forward navigation.” (traduction) : « une optimisation du navigateur qui permet une navigation arrière et avant instantanée. »

Pourquoi ce n’est pas « le cache » que vous connaissez déjà

C’est la confusion la plus fréquente. Quand vous entendez « cache », vous pensez probablement au cache du navigateur ou au cache HTTP — les fichiers (images, scripts, feuilles de style) que votre navigateur conserve pour ne pas les télécharger à nouveau. Le bfcache n’est pas cela. Ces caches stockent des fichiers ; le bfcache stocke la page vivante entière, avec son état JavaScript, sous forme d’instantané. La documentation de Chrome le dit explicitement : bfcache “differs from browser cache and HTTP cache.” (traduction) : « diffère du cache du navigateur et du cache HTTP. »

Ce n’est pas non plus l’un des deux autres mécanismes que l’on confond parfois avec lui : le cache de ressources en mémoire du navigateur (scripts compilés et images décodées conservés pendant la session) et le Cache Storage d’un service worker (paires requête/ réponse qu’un site gère explicitement avec caches.open()). Ces deux mécanismes peuvent être actifs sur la même page que le bfcache ; ils restent séparés et ne constituent pas le bfcache.

Ce n’est pas non plus l’ancienne fonction de recherche « page en cache » ou « instantané mis en cache » proposée autrefois par Google et Bing dans les résultats (le petit menu qui affichait la version d’une page conservée par le moteur). C’était une fonction de recherche, désormais retirée. Le bfcache est une fonction vivante du navigateur, sans rapport avec les résultats de recherche.

Le bfcache aide-t-il mon SEO ?

Pas directement. Le bfcache n’est pas un facteur de classement Google : la propre documentation de Google sur le classement Core Web Vitals ne le mentionne jamais. Il rend les navigations Back/Forward presque instantanées pour les visiteurs qui bénéficient réellement d’une restauration, et les navigateurs mesurent alors un excellent « chargement de page ». Si beaucoup de visiteurs utilisent Back et Forward (achats, consultation de résultats, lecture d’articles de page en page), le bfcache peut améliorer les chiffres Core Web Vitals de terrain de votre site — l’un des nombreux éléments que Google indique comme alignés sur ce que ses systèmes de classement valorisent. C’est deux étapes après « le bfcache améliore le classement » et cela ne garantit ni votre taux de restauration, ni votre note Core Web Vitals globale, ni votre classement ; mais l’effet est réel et mesurable.

Vous voulez une vue complète — ce qui bloque exactement le bfcache, comment le tester et la relation précise (sans la survendre) avec Core Web Vitals ? Passez à l’onglet Advanced.

TL;DR — Le bfcache est un instantané de page entière en mémoire (DOM + tas JS + état d’exécution), et non une réponse HTTP récupérable, le cache de ressources en mémoire du navigateur ou le Cache Storage d’un service worker — c’est la distinction conceptuelle n° 1 à retenir. Lorsque vous quittez une page, le navigateur met JavaScript en pause et gèle la page ; avec Back/Forward, si l’instantané gelé est encore disponible, il le dégèle et le réaffiche instantanément, sans aucune requête réseau — mais l’éviction reste possible : considérez donc une restauration comme probable, pas garantie. Ce n’est pas un facteur de classement documenté par Google Search (les documents Core Web Vitals de Search Central ne le mentionnent jamais) ; sa pertinence est indirecte et limitée, via la mesure CWV de terrain (surtout LCP et CLS) pour les navigations effectivement restaurées. Elle ne garantit ni votre taux de restauration, ni votre note CWV globale, ni le classement ou la conversion. Le principal bloqueur d’éligibilité est le gestionnaire unload (environ 18 points de pourcentage du taux de restauration dans Chrome) ; historiquement, le plus important était Cache-Control: no-store (bloquant environ 17 % des navigations historiques mobiles et 7 % des navigations desktop), même si Chrome autorise désormais conditionnellement le bfcache pour de nombreuses pages no-store (éviction si l’authentification ou les cookies changent, et blocage persistant par les mêmes API de connexions ouvertes) depuis son déploiement de 2025. Les connexions ouvertes, minuteries et observateurs doivent être fermés ou mis en pause dans pagehide/freeze, puis recréés dans pageshow/resume ; window.opener, les politiques de permissions et les cadres peuvent aussi le bloquer — consultez la raison par cadre dans DevTools ou notRestoredReasons au lieu de supposer. Testez ponctuellement avec Chrome DevTools ; diagnostiquez sur le terrain avec l’API notRestoredReasons, propre à Chrome (un résultat null ne prouve pas une restauration et le texte des raisons n’est pas stable). Chaque navigateur a ses propres règles d’éligibilité et les navigations douces des SPA ne bénéficient pas du même traitement.

Ce qu’est réellement le bfcache (le socle de précision)

Le point le plus important : le bfcache est un instantané de page entière en mémoire, et non une réponse HTTP mise en cache. Lorsque vous quittez une page, le navigateur met en pause l’exécution de JavaScript et gèle toute la page — le DOM, le tas JS, les minuteries en cours, tout — puis la conserve en mémoire. Si vous appuyez sur Back ou Forward alors que l’instantané est encore disponible, il le dégèle et réaffiche exactement la page quittée, avec zéro requête réseau et zéro nouveau rendu. C’est une restauration possible, pas une garantie : l’instantané peut être évincé avant votre retour (pression mémoire, délai, événement particulier), ou une règle propre au navigateur peut imposer un chargement complet. La formulation canonique de Google est que le bfcache est “a browser optimization that enables instant back and forward navigation.” (traduction) : « une optimisation du navigateur qui permet une navigation arrière et avant instantanée. »

C’est pourquoi le confondre avec le cache HTTP ou du navigateur est l’erreur récurrente des contenus concurrents. Le cache HTTP stocke des réponses aux requêtes précédentes et peut les resservir. Le bfcache stocke la page vivante en cours d’exécution. La documentation de Chrome DevTools fait explicitement la distinction : le bfcache “differs from browser cache and HTTP cache.” (traduction) : « diffère du cache du navigateur et du cache HTTP. » Vous n’activez pas le bfcache avec des en-têtes de cache comme vous configurez le cache HTTP ; les en-têtes n’interviennent ici que parce que Cache-Control: no-store disqualifiait autrefois une page (voir plus bas).

La même distinction vaut pour deux autres caches que l’on confond parfois avec le bfcache : le cache de ressources en mémoire du navigateur (scripts compilés et images décodées conservés pendant la session) et le Cache Storage d’un service worker (paires requête/ réponse explicites qu’un site gère lui-même avec caches.open()). Les deux peuvent être actifs sur la même page en même temps que le bfcache ; aucun n’est le bfcache, qui désigne précisément l’instance de page gelée, et non des ressources en cache ou des réponses interceptées.

Une autre distinction est utile, car la confusion persiste : le bfcache n’a rien à voir avec l’ancienne fonction de recherche « page en cache » que Google (et Bing) proposait autrefois dans ses résultats. Il s’agissait de l’instantané d’une page conservé dans l’index du moteur, et cette fonction a été retirée. Le bfcache est une fonction du moteur de rendu côté client.

Les navigations Back/Forward sont-elles vraiment fréquentes ?

Ce n’est pas un cas marginal. D’après web.dev : “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (traduction) : « une navigation sur dix sur ordinateur et une sur cinq sur mobile est une navigation arrière ou avant ». Sur tout site où les utilisateurs reviennent en arrière (du catalogue au produit puis retour, résultats de recherche, contenu paginé ou lecture d’article en article), cela représente une grande part des navigations réelles que vous pouvez rendre presque instantanées.

Compatibilité des navigateurs

“All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (traduction) : « Tous les navigateurs majeurs incluent un bfcache, notamment Chrome depuis la version 96, Firefox et Safari. » Firefox et Safari disposent de leurs propres implémentations anciennes du bfcache ; tous les navigateurs fondés sur Chromium (Edge, Brave, Opera, Arc) héritent de Chrome. La documentation des politiques Microsoft Edge décrit la même fonction : lorsqu’une page est quittée, son état actuel (arbre du document, script, etc.) peut être conservé dans le cache arrière/avant ; si le navigateur revient à la page, celle-ci peut être restaurée et affichée dans l’état où elle se trouvait avant la mise en cache. La fonction est activée par défaut dans Edge ; le seul interrupteur est une règle d’entreprise contrôlée par l’administrateur informatique, pas par le propriétaire du site.

La réserve importante est la suivante : chaque navigateur applique ses propres règles d’éligibilité au bfcache. Une page qui passe le test « Test back/forward cache » de Chrome DevTools n’est pas garantie d’être éligible dans Firefox ou Safari. Considérez un résultat positif dans Chrome comme nécessaire, mais pas suffisant.

Ce qui bloque l’éligibilité au bfcache

L’événement unload — le principal bloqueur

Si vous ne retenez qu’une chose de cet article : cessez d’utiliser l’événement unload. web.dev insiste rarement autant dans un document Google : “Never use the unload event. Ever!” (traduction) : « N’utilisez jamais l’événement unload. Jamais ! » Dans Chrome, les gestionnaires unload entraînent environ 18 points de pourcentage de baisse du taux de restauration du bfcache, de loin la plus grande disqualification que vous puissiez vous infliger.

Chrome le déprécie activement pour deux raisons. Premièrement, c’est le plus grand bloqueur du bfcache. Deuxièmement, unload est extrêmement peu fiable : sur mobile, il ne se déclenche souvent pas du tout, car les onglets passent en arrière-plan puis sont supprimés et le navigateur privilégie le bfcache plutôt que le déclenchement de unload. L’événement sur lequel vous comptez pour le « nettoyage » ne se produit donc souvent pas et bloque un véritable gain de performance.

Les corrections :

• Remplacez unload par pagehide. L’événement pagehide se déclenche dans tous les cas où unload se déclenche, ainsi que lorsqu’une page entre dans le bfcache : c’est donc une amélioration stricte. Utilisez visibilitychange pour un nettoyage fiable lorsque « l’utilisateur quitte la page ».
• Détectez une restauration du bfcache avec pageshow. Écoutez pageshow et vérifiez event.persisted — si sa valeur est true, la page a été restaurée depuis le bfcache : c’est le signal pour actualiser les données obsolètes ou recompter une page vue.
• Bloquez préventivement les écouteurs unload avec l’en-tête de réponse Permissions-Policy: unload=(), qui empêche tout gestionnaire unload d’être enregistré. Chrome migre progressivement la politique par défaut vers le refus (une Permissions-Policy pour unload a été livrée avec Chrome 115).

Cache-Control: no-store — historiquement le plus important, aujourd’hui nuancé

C’est le point de fraîcheur que la plupart des contenus concurrents présentent mal. Historiquement, Cache-Control: no-store était la principale raison d’exclure les pages du bfcache — les propres chiffres de Chrome l’estiment à environ 17 % des navigations historiques sur mobile et 7 % sur ordinateur. De nombreux sites définissent no-store par prudence pour éviter de servir une page obsolète, mais Google explique que cet argument perd de sa force avec le bfcache : une restauration ne charge pas une réponse en cache obsolète ; elle réaffiche la page vivante exacte, presque comme si l’onglet était resté ouvert.

Chrome a donc modifié son comportement — mais sous conditions, pas universellement. Les expériences ont commencé dans Chrome 116, avec un déploiement final auprès de 100 % des utilisateurs en mars et avril 2025 : Chrome autorise désormais le bfcache pour de nombreuses pages no-store, sous réserve de conditions de sécurité précises plutôt que d’une exception générale. D’après la documentation de Chrome, la page est évincée du bfcache si l’état d’authentification ou les cookies changent pendant qu’elle est gelée (ainsi un visiteur déconnecté ou dont les cookies ont été effacés ne voit pas un instantané d’une session ouverte), et une liste fixe d’API — les API de connexion ouverte détaillées ci-dessous (IndexedDB, WebSocket, WebRTC, entre autres) — exclut encore une page no-store du bfcache comme n’importe quelle autre page. Ce comportement est propre à Chrome et à une plage de versions donnée ; ne supposez pas que d’autres navigateurs ou d’anciennes versions de Chrome le suivent. Consultez le rapport DevTools/notRestoredReasons actuel pour le navigateur et la version testés au lieu de faire confiance à une règle fixe. À retenir : tout guide (y compris les anciennes versions de celui-ci) qui présente no-store comme un bloqueur inconditionnel et permanent du bfcache est obsolète — tout comme l’affirmation selon laquelle le problème serait entièrement résolu. Si la fraîcheur compte réellement, la documentation de Chrome suggère no-cache ou un max-age court (par exemple max-age=60), plutôt que no-store.

Connexions ouvertes, observateurs et autres bloqueurs

Au moment de la navigation, certaines ressources ouvertes peuvent encore bloquer l’éligibilité — lesquelles, et le fait qu’elles bloquent totalement ou puissent être fermées puis reconnectées, dépendent du navigateur et de sa version. Considérez la liste ci-dessous comme des exemples de comportement, pas comme une liste fixe et permanente :

• Requêtes fetch()/XMLHttpRequest en cours.
• Transactions IndexedDB ouvertes.
• Connexions WebSocket/WebRTC, minuteries et observateurs ouverts (MutationObserver, IntersectionObserver et autres). Cette zone évolue activement : les notes de version récentes de Microsoft Edge montrent qu’une connexion WebSocket ouverte est désormais fermée lorsqu’une page entre dans le bfcache (au lieu de bloquer entièrement la mise en cache), et recommandent de la reconnecter via l’événement pageshow et la vérification event.persisted. Cela suit la tendance de Chrome à réduire les bloqueurs plutôt qu’à exclure systématiquement les pages.

Le modèle général à adopter, plutôt que de mémoriser une liste fixe, est le suivant : fermez ou mettez en pause les connexions, minuteries et observateurs ouverts dans votre gestion de pagehide/freeze, puis rétablissez-les dans la gestion de pageshow/resume lorsque event.persisted vaut true. Ce modèle résiste à l’évolution des navigateurs : certaines API peuvent bloquer l’éligibilité tandis que d’autres sont désormais simplement suspendues et peuvent être reconnectées.

window.opener, les politiques de permissions et les cadres. Une référence window.opener, certaines politiques de permissions et des iFrames intégrées (de même origine ou d’origine différente) peuvent aussi affecter l’éligibilité — c’est indiqué dans la checklist que j’ai synthétisée dans le guide CLS d’Ahrefs et dans la documentation de Chrome. Ne déduisez pas la cause réelle d’une checklist générique : le panneau DevTools de Chrome et l’API notRestoredReasons signalent les raisons de blocage par cadre — le cadre supérieur et chaque iFrame séparément — car le cadre responsable n’est pas toujours la page de premier niveau. Récupérez la raison réelle dans le rapport par cadre du navigateur testé au lieu de deviner à partir d’une liste générale.

Bien gérer la séquence des événements et de l’état du cycle de vie

Confondre ce que chaque événement du cycle de vie prouve réellement avec ce qu’il suggère seulement est, après les erreurs d’éligibilité ci-dessus, le deuxième bug de justesse le plus courant ici :

La règle pratique : traitez pagehide.persisted comme une intention, pas comme une preuve — la page peut encore être évincée avant que vous ne voyiez une restauration. Seul pageshow.persisted === true prouve qu’une restauration a eu lieu. Effectuez toujours le nettoyage dans pagehide/freeze (c’est peu coûteux et sûr même lors d’une navigation ordinaire), et ne faites le travail propre à la restauration que dans pageshow/resume, conditionné par event.persisted, afin de ne pas actualiser les données ou compter deux fois une vue analytique lors d’un chargement normal.

Comment tester et diagnostiquer le bfcache

En laboratoire / ponctuellement : Chrome DevTools

Ouvrez DevTools → Application → Background services → Back/forward cache, puis cliquez sur “Test back/forward cache.” Chrome navigue automatiquement vers chrome://terms/ puis revient en arrière et signale soit la réussite, soit la liste précise des raisons de blocage. C’est idéal pour vérifier une URL à la fois.

Sur le terrain / en production : l’API notRestoredReasons

Auparavant, la seule manière de vérifier l’éligibilité était ce test DevTools manuel, URL par URL : il était impossible de voir pourquoi les navigations des vrais utilisateurs étaient bloquées. La propriété notRestoredReasons de PerformanceNavigationTiming (disponible depuis Chrome 123+) comble cette lacune : elle indique à grande échelle les raisons précises de blocage du cadre supérieur et des iFrames de même origine dans les données de terrain.

const nav = performance.getEntriesByType('navigation')[0];
console.log(nav.notRestoredReasons);

Voici quelques points à respecter, directement issus des recommandations de l’API Chrome :

• Chrome uniquement (123+). Firefox et Safari n’exposent pas d’API de terrain équivalente : vous devez donc toujours effectuer des vérifications manuelles dans ces navigateurs pour connaître votre taux de restauration.
• Un résultat null est ambigu, pas un feu vert. Il peut signifier que la page a été restaurée, ou que le navigateur n’a simplement pas collecté de raison — la documentation de Chrome recommande de ne pas traiter null comme la preuve d’une restauration réussie.
• Le texte d’une raison n’est pas un contrat stable. Ne faites pas de correspondance codée en dur sur les chaînes ; regroupez les raisons et suivez leur évolution, car leur formulation peut changer selon les versions de Chrome.

En pratique, relevez notRestoredReasons avec les taux de restauration pageshow.persisted avant et après la mise en production d’un correctif, comparez la tendance plutôt qu’un instantané et complétez par un passage manuel dans DevTools/lab sur Firefox et Safari, que l’API ne peut pas couvrir. C’est l’outil à utiliser pour diagnostiquer le bfcache à grande échelle dans le RUM/la production, plutôt que de vérifier les URL une par une — mais ne le considérez pas comme toute l’histoire.

Bfcache et Core Web Vitals — la relation précise

Voici la nuance que la plupart des contenus concurrents brouillent, et l’angle qu’il vaut la peine d’assumer.

Mesure d’une restauration bfcache. Les navigateurs (et donc les données de terrain CrUX) comptent une navigation restaurée par bfcache comme un « chargement de page » extrêmement rapide — LCP presque instantané et, lorsque la page est correctement implémentée (aucun nouveau calcul de mise en page), zéro CLS supplémentaire en pratique, car il n’y a pas de nouveau rendu. Dans la comparaison réelle de DebugBear, une page restaurée par bfcache a atteint environ 100 ms de LCP contre ~427 ms pour un chargement non mis en cache. C’est précisément pourquoi le bfcache apparaît comme levier pour CLS et LCP dans ma checklist CLS d’Ahrefs, où je le formule ainsi : “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (traduction) : « Vérifiez que vos pages sont éligibles au bfcache. Le cache arrière/avant conserve les pages dans le cache du navigateur et permet de charger instantanément une page déjà chargée ; aucun décalage de mise en page ne se produira. »

Deux réserves de périmètre méritent d’être précisées, car c’est ici que les contenus concurrents exagèrent le plus. Premièrement, cela ne concerne que les navigations que CrUX classe comme arrière/avant (sa dimension navigation-type) : cela ne dit rien de votre première visite ni de vos rechargements, qui constituent la majorité du trafic de la plupart des sites. Deuxièmement, une amélioration de l’expérience mesurée pour les utilisateurs qui bénéficient d’une restauration ne constitue pas une garantie : un utilisateur dont la page a été évincée du bfcache (voir le tableau du cycle de vie) obtient toujours un chargement normal, sans amélioration. Le travail d’éligibilité déplace votre taux de restauration parmi les navigations Back/Forward ; il ne garantit ni une part fixe du trafic total, ni votre note Core Web Vitals de terrain globale, ni votre classement, ni votre taux de conversion. C’est un levier réel et mesurable, au périmètre précis et limité, pas une correction générale de performance ou de SEO.

Le bfcache est-il un facteur de classement ? Non. C’est l’affirmation défendable et différenciante. La documentation de Google sur le classement Core Web Vitals ne mentionne pas du tout le bfcache. La chaîne d’influence honnête est : éligibilité au bfcache → meilleurs chiffres CWV de terrain (surtout LCP/CLS) sur les navigations arrière/ avant → Core Web Vitals est l’un des signaux « expérience de page » parmi ceux que Google dit alignés sur les éléments déjà valorisés par ses systèmes de classement. C’est une affirmation beaucoup plus faible et précise que « le bfcache améliore le classement » — et c’est celle que les contenus concurrents devraient formuler avec plus de soin. Le bfcache est aussi, correctement, une fonction du moteur de rendu, pas du robot : il n’a rien à voir avec l’exploration de vos pages par Googlebot ou Bingbot ; il n’existe donc pas de « point de vue de Bing sur le bfcache pour le SEO » comparable aux informations sur robots.txt ou les sitemaps.

SPA et navigations douces. Le bfcache fonctionne avec les véritables navigations et événements d’historique du navigateur. Le changement d’itinéraire « doux » côté client d’une application monopage (un échange de vue piloté par JS qui ne déclenche pas une vraie navigation du navigateur) n’est pas un événement bfcache et ne reçoit pas le même traitement. Les tentatives de certains outils RUM pour attribuer les Core Web Vitals aux navigations douces peuvent créer des écarts de mesure entre CrUX et RUM — un point à signaler lors de l’audit d’un site construit avec un framework JS.

Quelle est la fréquence des bloqueurs bfcache dans le monde réel ?

Le Web Almanac de HTTP Archive suit ce sujet, qui évolue encore : ce ne sont pas de vieilles nouvelles définitives. Dans l’édition 2022, au moins ~22 % des pages mobiles étaient inéligibles au bfcache selon les seuls critères unload et no-store. Depuis, l’utilisation des gestionnaires unload diminue dans les différentes catégories de sites et d’appareils ; en revanche, celle de Cache-Control: no-store a augmenté (le chapitre 2025 l’estime à environ 23 % des sites, contre ~21 % en 2024, en partie à cause des expériences authentifiées/ personnalisées plus nombreuses et d’exigences de conformité plus strictes).

Le constat contre-intuitif mérite d’être cité : les sites plus grands et à fort trafic bloquent proportionnellement davantage leur propre bfcache. Parmi les 1 000 premiers sites, environ 28 % des pages desktop et 20 % des pages mobiles utilisent encore des gestionnaires unload, contre seulement ~11 % sur desktop et ~10 % sur mobile pour tous les sites — souvent parce que les grands sites portent davantage de code analytique ancien et dépendant de unload. Les sites qui ont le plus de trafic Back/Forward à perdre sont souvent ceux qui se mettent encore eux-mêmes en difficulté.

Où cela s’insère

Le bfcache est l’un des leviers de performance de ce cluster. Son bénéfice apparaît dans les données de terrain Core Web Vitals, plus précisément dans Cumulative Layout Shift et Largest Contentful Paint, puisqu’une page restaurée se réaffiche instantanément sans nouveau calcul de mise en page. Il se distingue du cache, qui stocke des fichiers plutôt qu’un instantané de page vivante, même si les deux utilisent l’en-tête Cache-Control. Il n’existe pas de lien direct avec Interaction to Next Paint, et je ne vais pas en forcer un.

Résumé par IA

Une synthèse de la version avancée :

• Bfcache = un instantané de page entière en mémoire (DOM + tas JS + état d’exécution), et non une réponse HTTP récupérable, le cache de ressources en mémoire du navigateur ou le Cache Storage d’un service worker. En quittant la page, le navigateur met JS en pause et la gèle ; avec Back/Forward, si l’instantané est encore disponible, il le dégèle et le réaffiche instantanément, sans requête réseau — l’éviction reste possible, donc une restauration est probable mais pas garantie. La documentation de Chrome dit qu’il “differs from browser cache and HTTP cache.” (traduction) : « diffère du cache du navigateur et du cache HTTP ». Ce n’est pas non plus l’ancienne fonction de recherche « page en cache », désormais retirée.
• Ce n’est pas un facteur de classement, et le périmètre est limité. Les documents de classement Core Web Vitals de Google ne mentionnent jamais le bfcache. La chaîne réelle est indirecte : éligibilité au bfcache → meilleurs chiffres CWV de terrain (surtout LCP et CLS) sur les navigations Back/Forward restaurées → CWV est l’un des signaux d’expérience de page que Google dit alignés sur ses systèmes de classement. Cela ne garantit ni le taux de restauration, ni la CWV globale, ni le classement, ni la conversion ; cela ne concerne que les navigations que CrUX classe arrière/avant.
• Échelle : « une navigation sur dix sur ordinateur et une sur cinq sur mobile est arrière ou avant ». Prise en charge par Chrome depuis la version 96, ainsi que Firefox et Safari — mais chaque navigateur a ses propres règles d’éligibilité.
• Principal bloqueur : l’événement unload (« N’utilisez jamais l’événement unload. Jamais ! ») — environ 18 points de pourcentage du taux de restauration dans Chrome. Remplacez-le par pagehide + visibilitychange ; détectez les restaurations avec pageshow/event.persisted ; bloquez unload avec Permissions-Policy: unload=().
• Cache-Control: no-store était historiquement le plus grand bloqueur (environ 17 % des navigations historiques mobiles et 7 % desktop). Chrome autorise désormais conditionnellement le bfcache pour de nombreuses pages no-store après son déploiement de mars-avril 2025 : éviction si l’authentification ou les cookies changent, blocage persistant par les mêmes API de connexion ouverte, et comportement limité à Chrome. Les anciens guides qui le présentent comme un bloqueur absolu sont obsolètes, tout comme l’affirmation que le problème est entièrement résolu.
• Autres bloqueurs : fetch/XHR en cours, minuteries, observateurs, IndexedDB ouvert, WebSocket/WebRTC (fermer ou mettre en pause dans pagehide/freeze, reconnecter dans pageshow/resume), window.opener, politiques de permissions et cadres — consultez la raison par cadre dans DevTools/notRestoredReasons plutôt que de supposer.
• Exactitude du cycle de vie : pagehide.persisted exprime une intention, pas une preuve ; seul pageshow.persisted === true confirme une restauration. Nettoyez sans condition dans pagehide/freeze ; ne faites le travail propre à la restauration (actualiser les données sensibles, reconnecter, compter une vue analytique) que dans pageshow/resume.
• Tests : « Test back/forward cache » dans Chrome DevTools pour le laboratoire ; l’API notRestoredReasons, propre à Chrome (Chrome 123+), pour les données de terrain. null ne prouve pas une restauration, le texte des raisons n’est pas stable et Firefox ou Safari exigent des contrôles manuels. Comparez les taux notRestoredReasons et pageshow.persisted avant et après un correctif.
• SPA : les navigations douces côté client ne sont pas des événements bfcache et ne bénéficient pas du même traitement, ce qui peut créer un écart CrUX/RUM.
• Adoption (Web Almanac) : l’usage de no-store augmente (environ 21 % → 23 %) et celui de unload est plus élevé sur les très grands sites (environ 28 % desktop parmi les 1 000 premiers) — les grands sites bloquent souvent leur propre bfcache.

Documentation officielle

Documentation issue de sources primaires sur le bfcache. Remarquez la séparation : le bfcache est documenté dans les pages Chrome / moteur de rendu (la voix institutionnelle de Google à ce sujet), et non dans Google Search Central — cette séparation est précisément le point à retenir.

Google / Chrome

• Cache arrière/avant — document de référence : définition, mécanisme, statistique une navigation sur dix / une sur cinq et recommandations sur unload.
• Tester le cache arrière/avant — étapes de test DevTools, principaux bloqueurs et phrase explicite « diffère du cache du navigateur et du cache HTTP ».
• Activer le bfcache pour Cache-Control: no-store — changement de politique de 2025, chiffres 17 % / 7 % et calendrier de déploiement.
• Déprécier l’événement unload — raisons de son retrait progressif et migration vers Permissions-Policy.
• API notRestoredReasons du cache arrière/avant — diagnostic de terrain sur PerformanceNavigationTiming (Chrome 123+).
• Comprendre Core Web Vitals et les résultats Google Search — document de classement de Google Search Central, cité ici parce qu’il ne mentionne jamais le bfcache.

Microsoft / Edge

• Politique Microsoft Edge : BackForwardCacheEnabled — définition d’Edge, même réserve sur unload et interrupteur de politique d’entreprise.

MDN / normes du Web

• bfcache — glossaire MDN — définition générale pour le développement Web et distinction avec le cache HTTP.
• Surveiller les raisons de blocage du bfcache — MDN — utilisation pratique de notRestoredReasons.

Citations de la source

Déclarations attribuées aux documents sources. Chaque lien est un lien profond qui ouvre directement le passage cité sur la page source.

Google / Chrome — ce qu’est le bfcache et pourquoi il compte

• “Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.” (traduction) : « Le cache arrière/avant, ou bfcache, est une optimisation du navigateur qui permet une navigation arrière et avant instantanée. » — web.dev. Voir la citation
• “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!” (traduction) : « Une navigation sur dix sur ordinateur et une sur cinq sur mobile est arrière ou avant. Avec le bfcache, les navigateurs pourraient supprimer le transfert de données et le temps de chargement de milliards de pages chaque jour ! » Voir la citation
• “All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (traduction) : « Tous les navigateurs majeurs incluent un bfcache, notamment Chrome depuis la version 96, Firefox et Safari. » Voir la citation

Google / Chrome — la règle d’optimisation n° 1

• “Never use the unload event. Ever!” (traduction) : « N’utilisez jamais l’événement unload. Jamais ! » — web.dev. Voir la citation

Chrome DevTools — le bfcache n’est pas le cache HTTP

• “Back/forward cache differs from browser cache and HTTP cache.” (traduction) : « Le cache arrière/avant diffère du cache du navigateur et du cache HTTP. » — documentation Chrome DevTools. Voir la citation

Microsoft Edge — même fonction, même réserve

• “When navigating away from a page, its current state (document tree, script, and so on) may be preserved in the back-forward cache. If the browser navigates back to the page, the page may be restored from the back-forward cache and displayed in the state it was in before being cached.” (traduction) : « Lorsque vous quittez une page, son état actuel (arbre du document, script, etc.) peut être conservé dans le cache arrière/avant. Si le navigateur revient à cette page, elle peut être restaurée et affichée dans l’état où elle se trouvait avant sa mise en cache. » — documentation de la politique Microsoft Edge. Voir la citation

Patrick Stox (moi) — le bfcache comme levier de CLS

• “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (traduction) : « Assurez l’éligibilité de vos pages au bfcache : ce cache garde les pages déjà chargées dans le navigateur et empêche les décalages de mise en page lors d’un chargement instantané. » — mon guide CLS chez Ahrefs. Lire le guide

Checklist d’éligibilité au bfcache

Un passage pour vérifier que vos pages peuvent entrer dans le cache arrière/avant :

• Aucun écouteur d’événement unload n’est présent sur la page (votre code ou des scripts tiers). C’est le principal bloqueur.
• Le code de nettoyage et d’analytique est déplacé de unload vers pagehide et visibilitychange.
• Un écouteur pageshow vérifie event.persisted pour actualiser les données obsolètes et recompter correctement les pages vues après une restauration bfcache.
• Envisagez l’en-tête de réponse Permissions-Policy: unload=() pour empêcher l’enregistrement d’écouteurs unload.
• Examinez Cache-Control: no-store — si vous le définissez par prudence, confirmez qu’il est toujours nécessaire (Chrome 2025+ autorise conditionnellement le bfcache pour de nombreuses pages no-store : éviction si l’authentification ou les cookies changent, blocage persistant par les mêmes API de connexion ouverte ; ne supposez pas que les autres navigateurs ou versions se comportent pareil). Si la fraîcheur compte, préférez no-cache ou un max-age court.
• Aucune connexion ouverte, minuterie ou observateur ne reste actif au moment de la navigation — fetch/XHR en cours, transactions IndexedDB, WebSocket/WebRTC, MutationObserver/IntersectionObserver (fermez ou mettez en pause dans pagehide/freeze, rétablissez dans pageshow/resume lorsque event.persisted vaut true).
• Aucune référence window.opener, politique de permissions restrictive ou cadre bloqué ne maintient la page inéligible — consultez la raison par cadre dans DevTools/notRestoredReasons au lieu de deviner.
• Testez en laboratoire la page dans Chrome DevTools → Application → Back/forward cache → “Test back/forward cache.”
• Diagnostiquez sur le terrain à grande échelle avec notRestoredReasons dans votre RUM (uniquement Chrome ; un résultat null ne prouve pas une restauration et le texte des raisons n’est pas un contrat stable : suivez les raisons, ne codez pas leurs chaînes en dur).
• Ne supposez pas qu’un résultat positif dans Chrome signifie une éligibilité partout — contrôlez Firefox et Safari, qui appliquent leurs propres règles.

Fiche pratique du bfcache

Ce qui le bloque — et le correctif

Événements à connaître

Le tester

Faits rapides

• Le bfcache = page vivante entière en mémoire, pas des fichiers, pas le cache de ressources, pas le Cache Storage d’un service worker. Chrome dit qu’il “differs from browser cache and HTTP cache.” (traduction) : « diffère du cache du navigateur et du cache HTTP ».
• Ce n’est pas un facteur de classement Google — les documents CWV de Search Central ne le mentionnent jamais. Une restauration améliore le LCP/CLS mesuré pour les utilisateurs qui en bénéficient ; elle ne garantit ni le taux de restauration, ni la CWV globale, ni le classement, ni la conversion.
• Compatibilité : Chrome 96+, Firefox et Safari — chacun avec ses propres règles.
• Une navigation sur dix sur ordinateur / une sur cinq sur mobile est arrière/avant.

Anti-patterns du bfcache (et mythes associés)

« Le bfcache n’est que mon cache HTTP ou navigateur — je le configure avec Cache-Control. » Non. Le bfcache est un instantané distinct de page entière en mémoire ; la documentation de Chrome affirme qu’il “differs from browser cache and HTTP cache.” (traduction) : « diffère du cache du navigateur et du cache HTTP ». Les en-têtes de cache n’importent que dans la mesure où no-store disqualifiait autrefois une page. On n’active pas le bfcache avec des en-têtes de cache.

« Le bfcache est un facteur de classement Google, donc le corriger améliore le classement. » Aucune source officielle de Google Search ne l’établit. Le document de classement Core Web Vitals ne mentionne pas le bfcache. La relation réelle est indirecte (meilleur LCP/CLS de terrain sur les navigations arrière/avant), ce qui constitue une affirmation plus faible et plus précise.

« Cache-Control: no-store bloque toujours le bfcache, de manière permanente. » C’était vrai historiquement — et cela reste la plus grande cause historique — mais ce n’est plus catégoriquement vrai après le déploiement complet par Chrome en 2025 d’un bfcache compatible avec no-store. Les guides antérieurs au changement sont obsolètes sur ce point précis ; l’affirmer entièrement résolu l’est aussi : l’exception de Chrome est conditionnelle (éviction si l’authentification ou les cookies changent, blocage par les mêmes API de connexion ouverte) et propre à Chrome, pas un feu vert universel.

« Une page qui déclenche pagehide avec persisted: true a forcément été mise en cache. » Non — c’est une intention, pas une preuve. Le navigateur peut encore évincer la page avant que vous ne voyiez une restauration. Seul pageshow.persisted === true confirme qu’une restauration a réellement eu lieu.

« Si le test bfcache de Chrome DevTools réussit, la page est éligible partout. » Faux. Chrome, Firefox et Safari appliquent chacun leurs propres restrictions ; un résultat positif dans l’un ne garantit pas l’éligibilité dans un autre.

« unload est une bonne façon d’exécuter le code de sortie ou de nettoyage, je le garde. » Non : Chrome le juge extrêmement peu fiable (il ne se déclenche souvent pas du tout sur mobile) et le déprécie activement via une Permissions-Policy, précisément parce qu’il est le principal bloqueur du bfcache. Utilisez pagehide + visibilitychange.

« Le bfcache aide mon SPA comme il aide un site multipage. » Pas sans réserve. Le bfcache est lié aux navigations réelles du navigateur ; un changement d’itinéraire « doux » côté client n’est pas le même événement et ne bénéficie pas du même traitement, ce qui provoque aussi des écarts CrUX/RUM sur les sites très dépendants des SPA.

« Le bfcache est réglé / appartient au passé, inutile de l’auditer. » Les données du Web Almanac contredisent cette idée : l’usage de no-store augmente et celui de unload reste nettement plus élevé sur les sites les plus grands et les plus fréquentés — ceux qui ont le plus de trafic Back/Forward à perdre.

Outils pour tester et diagnostiquer le bfcache

• Chrome DevTools — panneau Cache arrière/avant. Application → Background services → Back/forward cache → “Test back/forward cache.” Navigation automatique vers chrome://terms/ puis retour, avec indication de réussite ou des raisons exactes de blocage. Idéal pour un contrôle ponctuel sur une seule URL.
• L’API notRestoredReasons (Chrome 123+). Lisez performance.getEntriesByType('navigation')[0].notRestoredReasons dans votre RUM pour voir à grande échelle les raisons de blocage des vrais utilisateurs, y compris celles des iFrames de même origine, et pas seulement dans un test de laboratoire manuel.
• PageSpeed Insights / Lighthouse / CrUX. C’est souvent là qu’une recommandation ou un signal « cache arrière/avant » apparaît en premier dans un audit, et là que se voit le bénéfice CWV de terrain d’un site éligible au bfcache.
• En-tête Permissions-Policy: unload=(). Ce n’est pas un outil de test, mais le levier d’application : définissez-le pour empêcher activement l’enregistrement de tout écouteur unload, y compris ceux des scripts tiers.
• Chapitre Performance du Web Almanac (HTTP Archive). Pour mesurer la fréquence des bloqueurs bfcache sur le Web selon l’appareil et le rang du site.

DevTools indique qu’un gestionnaire unload a bloqué la restauration

Symptôme : le test du cache arrière/avant cite unload. Cause probable : du code interne ou tiers a enregistré un écouteur unload. Correctif : remplacez le nettoyage par pagehide/visibilitychange, ajoutez Permissions-Policy: unload=() lorsque c’est approprié et relancez le test après chaque modification d’un script concerné.

Une page restaurée affiche des données utilisateur obsolètes

Symptôme : Back revient instantanément, mais l’état du compte, l’inventaire ou une autre valeur dynamique est obsolète. Cause probable : la page a repris son état gelé sans actualiser les données sensibles au temps. Correctif : écoutez pageshow, vérifiez event.persisted et actualisez uniquement les données nécessaires. Confirmez que les chargements ordinaires comme les restaurations se comportent correctement.

Les vues Back/Forward manquent ou sont comptées deux fois dans les statistiques

Symptôme : le nombre de pages vues diffère des navigations d’historique réelles. Cause probable : l’analytique ne s’exécute qu’au chargement initial ou s’exécute deux fois sans distinguer une restauration. Correctif : traitez explicitement pageshow et utilisez event.persisted pour compter une seule fois la navigation restaurée.

Le laboratoire réussit, mais la restauration sur le terrain reste faible

Symptôme : une URL échantillonnée passe dans DevTools, tandis que le RUM signale de nombreuses non-restaurations. Cause probable : d’autres modèles, navigateurs, états utilisateur ou connexions ouvertes intermittentes ajoutent des bloqueurs. Correctif : collectez notRestoredReasons, regroupez les raisons par modèle et par template et reproduisez le cas dominant sur le terrain au lieu d’extrapoler un seul résultat.

Prouver qu’un correctif bfcache est bien déployé

Test d’éligibilité

Test à exécuter : DevTools → Application → Back/forward cache → Test back/forward cache. Résultat attendu : la page est restaurée sans erreur et sans raison de blocage. Interprétation d’un échec : au moins un bloqueur d’éligibilité subsiste. Fenêtre de surveillance : immédiate dans Chrome pour l’état testé. Déclencheur de retour arrière : le correctif casse le nettoyage, la sécurité ou un comportement applicatif nécessaire.

Test du comportement après restauration

Test à exécuter : quittez la page puis revenez avec Back ; vérifiez que pageshow reçoit event.persisted === true et que les données sensibles au temps sont actualisées. Résultat attendu : une restauration instantanée, des données correctes et une seule vue analytique. Interprétation d’un échec : la page n’a pas été mise en cache ou la gestion de la restauration est incomplète. Fenêtre de surveillance : immédiate sur des états représentatifs avec et sans connexion. Déclencheur de retour arrière : données sensibles obsolètes ou actions dupliquées après la restauration.

Test des raisons observées sur le terrain

Test à exécuter : surveillez PerformanceNavigationTiming.notRestoredReasons dans le RUM. Résultat attendu : le bloqueur ciblé diminue pour les templates concernés sans qu’un nouveau bloqueur dominant le remplace. Interprétation d’un échec : l’échantillon de laboratoire ne représentait pas la production ou une autre dépendance porte le problème. Fenêtre de surveillance : suffisamment de trafic Back/Forward réel pour comparer le même mélange de templates. Déclencheur de retour arrière : régression matérielle de l’application ou de l’intégrité des données liée au changement.

Mesures bfcache à conserver

Taux de restauration

Mesure : navigations Back/Forward éligibles restaurées depuis le bfcache. Ce qu’elle indique : la fréquence à laquelle les utilisateurs bénéficient de la navigation instantanée. Comment la collecter : entrées de navigation RUM et pageshow.persisted, segmentées par navigateur et par template. Référence / plage réaliste : établissez votre propre base, car les règles du navigateur, l’état de la page et le mélange de navigations diffèrent. Périodicité : chaque semaine et après les changements du cycle de vie.

Raisons des non-restaurations

Mesure : navigations d’historique regroupées par notRestoredReasons. Ce qu’elle indique : les bloqueurs qui coûtent le plus de restaurations réelles. Comment la collecter : API PerformanceNavigationTiming dans les navigateurs compatibles. Référence / plage réaliste : visez zéro bloqueur contrôlé par votre propre code, en étiquetant la couverture du navigateur et de l’API. Périodicité : triage hebdomadaire.

Exactitude des navigations restaurées

Mesure : erreurs, incidents de données obsolètes et actions ou événements analytiques dupliqués après une restauration. Ce qu’elle indique : si une meilleure éligibilité préserve l’exactitude de l’application. Comment la collecter : événements d’erreur RUM, surveillance applicative et contrôle analytique indexé sur pageshow.persisted. Référence / plage réaliste : zéro erreur connue d’exactitude ou de confidentialité. Périodicité : alertes continues et contrôle à chaque mise en production.

Ressources qui valent le détour

Mes articles connexes

• Qu’est-ce que le Cumulative Layout Shift (CLS) et comment l’améliorer ? — j’y présente l’éligibilité bfcache comme levier d’amélioration du CLS, avec une courte checklist des bloqueurs.
• Que sont les Core Web Vitals (CWV) et comment les améliorer ? — les métriques parentes, avec le bfcache comme l’un des leviers du CLS.
• Guide du SEO technique pour débutants — la place de la performance Web dans la vue d’ensemble.

Mes interventions

• Comment fonctionne la recherche (SlideShare) — ma présentation de l’exploration, du rendu, de l’indexation et du classement, pour comprendre pourquoi une fonction du moteur de rendu comme le bfcache est extérieure aux signaux de classement de Search. (Ma clause habituelle s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) : « Voici ma compréhension des systèmes… elle ne sera pas complète ou exacte à 100 %. »)

Officiel

• Cache arrière/avant (web.dev) — le document de référence.
• Activer le bfcache pour Cache-Control: no-store et Déprécier l’événement unload (Chrome for Developers) — les deux changements qui rendent les anciens guides obsolètes.
• Comprendre Core Web Vitals et les résultats Google Search (Google Search Central) — le document de classement qui, de façon révélatrice, ne mentionne jamais le bfcache.

Dans le secteur

• bfcache — glossaire MDN — définition exacte et indépendante du moteur, avec la distinction du cache HTTP.
• Que signifie le cache arrière/avant pour la vitesse d’un site ? (DebugBear) — l’article le plus fondé sur les données dans ce domaine, avec des journaux réels et une comparaison LCP concrète (~100ms en cache contre ~427ms sans cache).
• Explication du cache arrière/avant (SpeedVitals) — mécanisme, éligibilité, tests et effet sur CWV.
• Cache arrière/avant : définition et mise en œuvre (NitroPack) — approche centrée sur la mise en œuvre, pour les équipes CMS et hébergement.
• Le cache arrière/avant, un changement majeur pour la performance (Smashing Magazine) — analyse technique solide, mais antérieure au changement no-store de 2025.
• Web Almanac — chapitre Performance (2025) (HTTP Archive) — données réelles d’adoption de unload et no-store par appareil et rang du site.

Statistiques à citer

• Les navigations Back/Forward sont fréquentes : “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward” (traduction) : « une navigation sur dix sur ordinateur et une sur cinq sur mobile est arrière ou avant » — l’échelle de l’occasion, pas un cas marginal. Source
• unload coûte environ 18 points de pourcentage du taux de restauration bfcache dans Chrome — raison pour laquelle il est le bloqueur n° 1 et est déprécié. Source
• Cache-Control: no-store était le plus grand bloqueur historique — environ 17 % des navigations historiques sur mobile et 7 % sur ordinateur — avant le déploiement de mars-avril 2025 qui a permis le bfcache pour de nombreuses pages no-store. Source
• Une restauration bfcache est presque instantanée : DebugBear a mesuré environ 100ms de LCP pour une page restaurée, contre ~427ms pour un chargement sans cache. Source
• Les grands sites se bloquent le plus : parmi les 1 000 premiers sites, environ 28 % des pages desktop et 20 % des pages mobiles utilisent encore des gestionnaires unload, contre environ 11 % / 10 % sur l’ensemble des sites — et l’usage de no-store augmente (environ 21 % → 23 %). Source

Testez vos connaissances : Back/Forward Cache (bfcache)

Cinq questions rapides sur le bfcache, les éléments qui le bloquent et sa relation avec le SEO. Choisissez une réponse pour chaque question, puis vérifiez.

Journal des modifications