BFCache : accélérer les retours sans brouiller vos KPI SEO

Le Back/Forward Cache, généralement abrégé en BFCache, est un mécanisme de navigateur qui permet de restaurer instantanément une page lorsqu’un internaute utilise les boutons « précédent » ou « suivant ». Au lieu de recharger le document, de solliciter le serveur et de réexécuter l’ensemble des ressources, le navigateur remet en activité une version de la page conservée en mémoire.

Pour un site e-commerce, média ou SaaS, cet usage est loin d’être marginal : revenir à une liste de produits après avoir consulté une fiche, retourner à un article depuis une page liée ou naviguer entre des écrans d’une application sont des parcours fréquents. Le BFCache peut alors réduire très fortement la latence perçue.

Il faut toutefois cadrer son rôle SEO. Le BFCache n’améliore pas directement le crawl de Googlebot, l’indexation ni le positionnement. Il ne constitue pas non plus un remède aux lenteurs d’un chargement initial. C’est un levier de qualité d’expérience pour les visiteurs déjà engagés dans la navigation. Son intérêt se mesure donc avec des données de terrain, en distinguant les restaurations d’historique des pages réellement chargées depuis le serveur.

BFCache : ce qui change réellement pour l’expérience et les métriques terrain

Lorsqu’une page est admissible au BFCache, le navigateur peut la placer dans un état suspendu au moment où l’utilisateur la quitte. Le document, le DOM, l’état JavaScript et, selon le navigateur, une partie de l’état de l’interface sont préservés. Au retour, la page reprend son exécution au lieu de repartir de zéro.

Ce fonctionnement diffère du cache HTTP. Un cache HTTP stocke des réponses et des ressources afin de pouvoir les réutiliser lors d’un prochain chargement. Le BFCache, lui, conserve une instance vivante de la page. Une restauration BFCache n’est donc pas une navigation classique : elle ne doit généralement pas produire une nouvelle requête HTML ni un nouveau cycle complet de rendu.

Les bénéfices sont surtout visibles sur :

le délai entre le clic sur « précédent » et le retour à une interface utilisable ;
la conservation de la position de défilement ;
la conservation d’un état d’interface, par exemple des filtres ou un formulaire non soumis ;
la réduction des sollicitations inutiles vers l’origine pour les navigations d’historique.

Le BFCache ne remplace pas les fondamentaux de performance. Une page lente au premier accès reste lente au premier accès. Les optimisations du temps de chargement, du TTFB, du JavaScript et des ressources critiques restent nécessaires. De même, une page mal rendue pour les robots ou difficile à indexer ne devient pas SEO-friendly parce qu’elle est restaurée depuis le cache d’historique d’un navigateur utilisateur.

Le BFCache améliore principalement le retour sur une page déjà visitée. Il faut le traiter comme un levier de performance perçue et de fluidité de parcours, pas comme un signal de classement.

Les modalités exactes du BFCache varient selon les navigateurs. Chrome, Firefox et Safari ont chacun leurs règles, et ces règles évoluent. Une décision de correction doit donc commencer par des observations réelles sur les navigateurs utilisés par votre audience, plutôt que par l’application mécanique d’une liste de blocages trouvée dans une documentation ancienne.

Comprendre le cycle de vie d’une page restaurée

Pour instrumenter correctement ce sujet, il est utile de distinguer la première visite, le rechargement, une navigation d’historique avec rechargement et une restauration BFCache.

Lors d’un chargement standard, le navigateur demande ou réutilise le HTML, parse le document, télécharge les sous-ressources nécessaires, exécute les scripts et affiche la page. Lors d’une restauration BFCache, le navigateur ne recrée pas le document de la même manière. La page est réactivée et l’événement pageshow est déclenché.

Le signal JavaScript le plus fiable côté page est la propriété persisted de cet événement :

window.addEventListener('pageshow', function (event) {
  if (event.persisted) {
    // La page a été restaurée depuis le BFCache.
  }
});

À l’inverse, l’événement pagehide permet d’identifier le moment où une page quitte le premier plan. Il ne faut pas supposer qu’un pagehide implique nécessairement une future restauration : l’admissibilité finale dépend du navigateur et peut être remise en cause par l’état de la page ou du système.

La documentation MDN sur PageTransitionEvent.persisted décrit ce signal utile à l’instrumentation. Il est préférable à une simple déduction basée sur le bouton « précédent », car les utilisateurs peuvent revenir dans l’historique sans que la page soit effectivement servie par le BFCache.

L’API Navigation Timing apporte aussi des indices. Une entrée PerformanceNavigationTiming peut indiquer un type de navigation back_forward. Cela identifie une navigation via l’historique, mais pas à elle seule une réussite BFCache. Une telle navigation peut conduire à une restauration ou à un rechargement selon le contexte. Pour votre RUM, associez donc le type de navigation au booléen event.persisted.

Identifier les pages exclues avec Chrome DevTools

Chrome DevTools fournit un diagnostic pratique dans son panneau Application. Après avoir ouvert une page dans Chrome, accédez à Application, puis à la section Back-forward Cache. L’outil permet de tester l’admissibilité de la page et affiche les raisons qui peuvent empêcher sa mise en cache lors d’une navigation arrière ou avant.

La démarche de test doit reproduire un parcours réel :

ouvrez une page importante, par exemple une catégorie ou une fiche produit ;
naviguez vers une seconde page du même site ;
utilisez le bouton précédent du navigateur ;
observez si la page est restaurée et consultez les raisons de non-éligibilité signalées par DevTools.

Ne limitez pas l’audit à la page d’accueil. Les gabarits qui comptent sont ceux utilisés dans les parcours : listings paginés, résultats de recherche interne, fiches, panier, tunnel de connexion, articles et pages de compte. Une cause d’exclusion peut être présente sur un seul gabarit, dans un module tiers ou dans une condition spécifique d’authentification.

Les résultats de DevTools doivent être lus comme des diagnostics techniques, pas comme une liste de corrections à appliquer aveuglément. Certaines exclusions sont nécessaires. Par exemple, une page bancaire, une interface avec des données sensibles ou un écran qui exige une fraîcheur immédiate des données peut justifier un comportement moins favorable au BFCache. Le bon objectif est de supprimer les exclusions accidentelles, sans fragiliser la sécurité, la cohérence des données ou les règles métier.

Un audit utile inclut aussi les navigateurs réellement représentés dans vos statistiques d’audience. Chrome DevTools est précieux pour investiguer Chrome, mais un taux observé sur Chrome ne se transpose pas automatiquement à Safari ou Firefox.

Les blocages fréquents : unload, Cache-Control, WebSockets et scripts tiers

Le premier point à vérifier est l’usage de l’événement unload. Historiquement, cet événement a été employé pour envoyer des données d’analytics ou effectuer un nettoyage avant la sortie d’une page. Il est problématique pour l’expérience moderne et peut empêcher l’utilisation du BFCache selon le navigateur et le contexte.

Avant de supprimer un gestionnaire, identifiez son rôle. Pour les envois de mesure à la fermeture, navigator.sendBeacon() ou fetch() avec l’option keepalive sont souvent des mécanismes plus adaptés, sous réserve des limites documentées par les navigateurs. Pour réagir à une transition de visibilité, visibilitychange et pagehide sont généralement des événements plus appropriés que unload. La documentation de navigator.sendBeacon() constitue un bon point de départ.

Le second sujet est l’en-tête HTTP Cache-Control, en particulier la directive no-store. Cette directive concerne d’abord le stockage des réponses HTTP, mais elle peut également avoir des conséquences sur l’éligibilité BFCache selon le navigateur et ses politiques. Chrome a fait évoluer son comportement autour de no-store, tandis que d’autres navigateurs peuvent appliquer des règles différentes. Ne retirez jamais no-store sur une page sensible uniquement pour gagner un taux BFCache : cet en-tête peut répondre à une exigence de confidentialité ou de sécurité.

La méthode saine consiste à inventorier les réponses concernées, à comprendre pourquoi l’en-tête est envoyé, puis à séparer les contenus publics des contenus personnels ou sensibles. Un CDN, un framework, un reverse proxy ou une règle globale peut parfois appliquer une politique trop restrictive à des pages publiques. Le sujet se rapproche alors de la gouvernance de cache décrite dans un audit de CDN et de cache HTML, même si cache HTTP et BFCache restent deux mécanismes distincts.

Les connexions persistantes, telles que les WebSockets, peuvent aussi influencer l’admissibilité. Une application temps réel doit prévoir ce qui se passe lorsqu’elle est suspendue puis restaurée : abonnement à des flux, état de présence, synchronisation de messages ou données devenues obsolètes. La correction n’est pas nécessairement de supprimer le WebSocket. Il peut s’agir de gérer proprement la suspension, la reconnexion et le rafraîchissement des données après une restauration.

Enfin, les scripts tiers sont une source fréquente de surprises. Outils publicitaires, chat, A/B testing, tag managers, lecteurs vidéo, widgets de consentement ou scripts de mesure peuvent enregistrer des événements incompatibles, maintenir des ressources actives ou modifier le cycle de vie de la page. Dans DevTools, remontez chaque raison d’exclusion à son script ou à sa bibliothèque. Travaillez ensuite avec le propriétaire métier ou le fournisseur concerné.

Un audit par suppression temporaire est particulièrement efficace : désactivez un groupe de tags dans un environnement de préproduction, rejouez le parcours dans DevTools et vérifiez l’évolution des raisons affichées. Réintroduisez les scripts un à un si nécessaire. Cette approche évite d’attribuer trop vite un blocage au code applicatif alors qu’il provient d’un conteneur tiers.

Construire une mesure RUM spécifique au BFCache

Un outil RUM, qu’il soit interne ou fourni par un service comme Datadog, New Relic, Dynatrace ou SpeedCurve, peut compléter les tests de laboratoire. L’enjeu est d’envoyer un événement explicite à chaque restauration BFCache, avec un schéma stable.

Au minimum, collectez les dimensions suivantes :

l’URL ou, idéalement, un identifiant de gabarit limité en cardinalité ;
le navigateur et sa version majeure lorsque votre outil le permet ;
le type de navigation issu de Navigation Timing ;
un indicateur bfcache_restore basé sur pageshow.persisted ;
l’état connecté ou non connecté, si cela influence les scripts et les en-têtes ;
le consentement et les familles de tags actives, lorsqu’elles modifient réellement le comportement ;
un horodatage et un identifiant de session pseudonymisé selon votre cadre de conformité.

Voici un exemple volontairement simple d’instrumentation. La fonction sendRumEvent représente votre mécanisme existant de collecte :

window.addEventListener('pageshow', function (event) {
  const navigation = performance.getEntriesByType('navigation')[0];

  sendRumEvent({
    event_name: 'page_show',
    bfcache_restore: event.persisted,
    navigation_type: navigation ? navigation.type : null,
    path: location.pathname
  });
});

Pour calculer un taux, utilisez un dénominateur cohérent. Par exemple :

Taux de restauration BFCache = nombre de pageshow avec persisted=true / nombre de navigations d’historique observées.

Ce taux doit être segmenté. Un résultat global masque souvent des écarts importants entre les pages publiques et les pages connectées, entre le desktop et le mobile, ou entre un listing léger et une fiche chargée de tags. Il est également recommandé de suivre le volume absolu de restaurations : un taux élevé sur un flux peu utilisé peut avoir moins d’effet qu’une amélioration plus modeste sur les parcours les plus fréquents.

Mesurer les gains sans confondre restauration, trafic SEO et Core Web Vitals

Le piège principal consiste à considérer une restauration BFCache comme une page vue équivalente à un nouveau chargement. Selon votre implémentation analytics, le retour peut générer une nouvelle page vue, ne rien envoyer, ou déclencher des événements incomplets. Cette différence affecte les sessions, les pages vues, le temps passé et les métriques d’engagement.

Dans Google Analytics 4, comme dans tout outil d’analytics, vérifiez ce qui est envoyé au retour d’historique. Un mécanisme fondé uniquement sur le chargement initial du document peut ne pas réagir à la restauration. À l’inverse, un code qui envoie une page vue à chaque pageshow peut comptabiliser les retours, ce qui est parfois souhaitable mais doit être interprété comme tel.

La solution n’est pas de choisir arbitrairement entre « compter » ou « ne pas compter ». Elle consiste à définir votre convention analytique :

compter les retours comme des consultations d’écran lorsque l’utilisateur retrouve effectivement un contenu ;
les identifier avec une dimension dédiée afin de les distinguer des chargements initiaux ;
éviter de les attribuer à tort à une nouvelle acquisition organique, payante ou sociale ;
préserver les règles de déduplication de vos conversions et de vos événements métier.

Le BFCache ne crée pas de session SEO supplémentaire et ne déclenche pas une nouvelle arrivée depuis Google. Un utilisateur peut être revenu initialement via la recherche organique, puis consulter plusieurs pages et utiliser « précédent » à plusieurs reprises. Les restaurations appartiennent au parcours de cette session ; elles ne représentent pas un trafic organique additionnel.

La même prudence s’applique aux Core Web Vitals. Une restauration très rapide peut améliorer la perception du retour, mais elle ne signifie pas automatiquement que le LCP, l’INP ou le CLS du chargement initial se sont améliorés. Ces métriques répondent à des définitions et à des fenêtres de mesure précises. Votre outil RUM peut également les rapporter différemment selon qu’il considère une restauration comme une nouvelle vue ou comme la poursuite du cycle de vie du document.

Avant et après une correction BFCache, suivez séparément :

le taux de restauration confirmé par pageshow.persisted ;
le délai perçu sur les retours, avec une mesure définie dans votre RUM ;
les Core Web Vitals des chargements initiaux ;
les erreurs JavaScript, erreurs métier et incohérences de données après restauration ;
les indicateurs de parcours, comme le retour vers une liste, l’ajout au panier ou la conversion.

Pour interpréter les données de terrain agrégées de Chrome, Chrome UX Report et PageSpeed Insights restent utiles, mais ils ne remplacent pas une instrumentation BFCache dédiée. Ils ne vous diront pas, à eux seuls, si une amélioration provient d’une restauration d’historique, d’un changement de serveur, d’une variation de trafic ou d’une modification de vos scripts.

Prévenir les régressions fonctionnelles après une restauration

Rendre une page éligible ne suffit pas. Une restauration doit aussi être fonctionnellement correcte. Lorsqu’une page reprend vie, l’utilisateur peut voir un panier dont le contenu a changé dans un autre onglet, une disponibilité produit devenue obsolète, un statut de connexion expiré ou une interface de chat qui doit se reconnecter.

Utilisez l’événement pageshow pour déclencher les synchronisations indispensables, uniquement lorsque cela est justifié. Une fiche produit peut, par exemple, rafraîchir une information volatile. Un espace authentifié peut vérifier si la session est toujours valide. Il faut cependant éviter de transformer chaque retour BFCache en rechargement complet : cela annulerait une partie du bénéfice recherché.

Les tests doivent couvrir des scénarios concrets :

retour après ajout au panier ;
retour après application de filtres ou tri sur une liste ;
retour après ouverture d’une modal ou d’un lecteur vidéo ;
retour sur une page connectée après expiration de session ;
retour après une action réalisée dans un autre onglet.

Ajoutez ces parcours à vos recettes de non-régression. Si vous utilisez des tests automatisés avec Playwright ou Cypress, validez au minimum le comportement fonctionnel de la navigation arrière dans les navigateurs ciblés. Les raisons d’éligibilité détectées dans DevTools complètent ces tests, mais ne remplacent pas la vérification métier.

Une feuille de route pragmatique pour améliorer le BFCache

La priorisation doit être pilotée par les données, pas par un objectif abstrait de taux BFCache maximal. Commencez par les pages où les retours sont fréquents et où l’impact sur le parcours est mesurable.

Cartographiez les parcours de retour : catégories vers fiches, résultats vers contenus, tunnel vers panier, navigation dans l’espace client.
Testez les principaux gabarits dans Chrome DevTools et conservez les raisons exactes de non-éligibilité.
Instrumentez pageshow.persisted dans votre RUM afin de distinguer les faits observés en production des résultats de laboratoire.
Traitez d’abord les exclusions évitables, notamment les gestionnaires unload hérités et les scripts tiers non indispensables.
Évaluez les en-têtes Cache-Control avec les équipes sécurité avant toute modification sur des pages sensibles.
Contrôlez la cohérence métier après restauration et surveillez les erreurs, les régressions de session et les écarts analytics.
Comparez les résultats par gabarit et navigateur, sans mélanger les restaurations avec les performances de chargement initial.

Cette démarche complète les audits de Core Web Vitals et de performance serveur, mais elle répond à une question distincte : que vit réellement l’utilisateur quand il revient sur une page qu’il vient de quitter ?

Conclusion : faire du BFCache un indicateur de fluidité, pas un raccourci SEO

Le BFCache peut rendre les retours arrière et avant sensiblement plus fluides en restaurant une page déjà disponible en mémoire. Pour en tirer un bénéfice durable, il faut identifier les exclusions dans DevTools, instrumenter les restaurations avec pageshow.persisted, traiter les blocages réellement évitables et tester les effets fonctionnels.

Son suivi doit rester séparé du crawl, de l’indexation et de l’acquisition organique. En distinguant les navigations restaurées des chargements initiaux dans vos données RUM et analytics, vous évitez d’améliorer un KPI apparent tout en brouillant son interprétation. Commencez par un gabarit à fort volume de retours, mesurez avant toute correction, puis déployez progressivement les changements qui améliorent réellement la fluidité du parcours.