bfcache : accélérer les retours en arrière sans réécrire son site
Le bfcache rend les retours de navigation quasi instantanés. Découvrez les blocages fréquents et les corrections utiles sans refonte.
Le back/forward cache, ou bfcache, accélère le retour en arrière en restaurant une page telle que le navigateur l’avait laissée, avec son DOM, son état JavaScript, le défilement et les champs saisis. Pour en profiter, supprimez les incompatibilités comme unload, puis ne resynchronisez au retour que les données qui ne peuvent pas être réutilisées.
Gérer une page restaurée
Le bfcache ne correspond ni à un préchargement ni au cache HTTP : le navigateur conserve une instance de la page en mémoire au lieu de la détruire. Les scripts sont suspendus pendant la navigation, puis repris lors du retour ; ce n’est pas un rechargement.
Ne comptez donc pas sur load pour réinitialiser l’interface ou mesurer ce retour. Utilisez pageshow : event.persisted vaut true lorsque la page vient du bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Synchroniser uniquement les données devenues obsolètes
}
});
Ne rechargez pas toute la page restaurée, car vous annuleriez le gain et pourriez perdre une saisie utilisateur. Vérifiez plutôt l’état de session avant une action protégée, demandez un nouveau jeton à usage unique si nécessaire et relancez une requête ciblée pour un solde, un stock ou une notification qui doit être à jour.
Les champs de formulaire restaurés doivent en général rester intacts. Évitez aussi les nettoyages destructifs dans pagehide : une page peut être mise en pause puis restaurée, et fermer une connexion ou vider un état indispensable peut alors créer un bug.
Supprimer les blocages
Recherchez d’abord les écouteurs unload, y compris dans les scripts tiers. Cet événement peut empêcher le bfcache dans plusieurs navigateurs et n’est pas fiable sur mobile ; pour une télémétrie légère, préférez pagehide avec navigator.sendBeacon() ou fetch(..., { keepalive: true }).
Des politiques de sécurité ou de cache peuvent aussi exclure une page. Chrome signale notamment Cache-Control: no-store comme motif de non-éligibilité dans certains cas ; ne retirez pas cette directive sans valider le risque métier, car une page sensible ne se traite pas comme une page catalogue.
Dans Chrome DevTools, ouvrez Application, puis Back/forward cache, pour tester une page et consulter les motifs de blocage. Vous pouvez aussi inspecter l’entrée de navigation :
const navigation = performance.getEntriesByType('navigation')[0];
console.log(navigation?.notRestoredReasons);
L’API notRestoredReasons expose les motifs connus d’une non-restauration. Les détails peuvent être limités pour les iframes externes ; un motif lié à un cadre embarqué n’est donc pas toujours corrigeable de votre côté.
Testez les parcours importants, par exemple liste vers fiche puis retour, formulaire vers confirmation puis retour, et connexion puis déconnexion. Vérifiez à la fois DevTools et le comportement produit : une page restaurable peut afficher une donnée qui n’est plus valide.
La documentation de web.dev sur le bfcache détaille les critères d’éligibilité et les stratégies de test selon les navigateurs. Le bfcache ne remplace pas le cache HTTP ni une application réactive, mais il améliore nativement un retour vers une page déjà visitée.