Optimiser le cache précédent/suivant (bfcache)
Rendez vos pages éligibles au bfcache pour des navigations Précédent et Suivant quasi instantanées et de meilleurs Core Web Vitals.
Le cache précédent/suivant, ou bfcache, est une optimisation du navigateur qui rend instantanées les navigations vers les pages précédente et suivante. Au lieu de détruire une page quand l’utilisateur la quitte, le navigateur en conserve un instantané complet en mémoire, code JavaScript inclus, puis la restaure telle quelle au retour. Sur ordinateur, une navigation sur dix est de type Précédent ou Suivant ; sur mobile, c’est une sur cinq. L’enjeu est donc considérable pour l’expérience utilisateur, et directement pour le SEO : ces restaurations quasi instantanées améliorent les Core Web Vitals mesurés sur le terrain, et limitent les décalages que l’on cherche à corriger en optimisant le CLS.
Le cache utilisé ici diffère du cache HTTP. Le bfcache est un instantané de la page entière en mémoire, tandis que le cache HTTP ne contient que les réponses des requêtes passées. Une restauration depuis le bfcache est donc toujours plus rapide que la visite répétée la mieux optimisée, puisqu’aucune requête réseau n’est nécessaire.
Le bfcache est un gain quasi gratuit que trop de sites laissent sur la table sans le savoir. Les retours en arrière représentent une vraie part de la navigation, et les rendre instantanés se ressent immédiatement dans l’expérience. En audit, je commence par vérifier ce qui rend une page inéligible, car un seul script mal placé peut suffire à tout désactiver.
Observer l'entrée et la sortie du bfcache
Bien que le bfcache soit automatique, il est utile de savoir quand il agit pour optimiser vos pages et ajuster vos mesures, tout comme on surveille le cache HTTP pour les requêtes passées. Les deux événements clés sont pageshow et pagehide, compatibles avec la plupart des navigateurs. L’événement pageshow se déclenche au chargement et à chaque restauration : sa propriété persisted vaut true si la page vient du bfcache. L’événement pagehide se déclenche au déchargement ou avant une mise en cache potentielle.
<script>
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
console.log('Cette page a ete restauree depuis le bfcache.');
} else {
console.log('Cette page a ete chargee normalement.');
}
});
</script>Rendre vos pages éligibles au bfcache
Toutes les pages ne sont pas stockées dans le bfcache. La règle la plus importante est de ne jamais utiliser l’événement unload, qui rend les pages inéligibles sur de nombreux navigateurs : utilisez pagehide à la place. Évitez aussi l’en-tête Cache-Control: no-store sur la page elle-même, sauf pour des informations sensibles, car il limite l’éligibilité. Enfin, fermez les connexions ouvertes (IndexedDB, WebSocket, requêtes en cours) avant le départ de l’utilisateur ; si votre application met des données en réserve, sachez aussi comment utiliser le cache pour le hors-ligne pour les retrouver hors connexion.
Voici les principaux facteurs qui conditionnent l’éligibilité d’une page au bfcache.
| Facteur | Effet sur le bfcache | Bonne pratique |
|---|---|---|
Événement unload |
Rend la page inéligible sur de nombreux navigateurs |
Le remplacer par pagehide |
Cache-Control: no-store |
Limite l’éligibilité de la page |
Le réserver aux pages réellement sensibles |
Connexions ouvertes (IndexedDB, WebSocket) |
Peuvent empêcher la mise en cache |
Les fermer lors de l’événement pagehide |
Référence window.opener non nulle |
Rend la page inéligible |
Utiliser rel= »noopener » sur les liens |
Écouteur beforeunload inconditionnel |
Peu fiable, à limiter |
L’ajouter seulement en cas de modifications non enregistrées |
Une page restaurée depuis le bfcache l’est depuis la mémoire, sans revalidation : Cache-Control: no-cache n’est alors pas pris en compte. Si votre site conserve un état utilisateur, mettez à jour ou effacez les données sensibles dans l’événement pageshow lorsque persisted vaut true, afin d’éviter d’exposer des informations après une déconnexion.
À faire
- utiliser pagehide à la place de unload
- fermer les connexions ouvertes au départ
- rafraîchir les données sensibles dans pageshow
- tester l’éligibilité dans les outils de développement
À éviter
- ajouter un écouteur unload
- appliquer no-store à des pages non sensibles
- conserver des références window.opener
- ajouter beforeunload de façon inconditionnelle
Points clés à retenir
- Bannir l'événement unload et lui préférer pagehide.
- Réserver Cache-Control: no-store aux seules pages sensibles.
- Fermer les connexions IndexedDB, WebSocket ou en cours avant le départ.
- Rafraîchir l'état utilisateur dans pageshow quand persisted vaut true.
- Vérifier l'éligibilité avec le panneau dédié des outils de développement.
Le bfcache offre des navigations Précédent/Suivant quasi instantanées si vos pages restent éligibles.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Quelle règle est la plus importante pour rendre une page éligible au bfcache ?
- Toujours appliquer Cache-Control: no-store sur la page
- Ne jamais utiliser l'événement unload et préférer pagehide
- Conserver des références window.opener ouvertes
L’événement
unloadrend les pages inéligibles au bfcache sur de nombreux navigateurs. Mieux vaut utiliserpagehide, qui se déclenche dans tous les cas oùunloadse déclencherait. -
Le bfcache remplace-t-il le cache HTTP ?
- Non, le bfcache est un instantané en mémoire alors que le cache HTTP stocke les réponses des requêtes
- Oui, le bfcache rend le cache HTTP inutile
- Oui, ils stockent exactement la même chose
Le bfcache conserve un instantané complet de la page en mémoire, tandis que le cache HTTP stocke les réponses des requêtes réseau. Les deux jouent des rôles complémentaires.
-
Quels événements permettent d'observer l'entrée et la sortie du bfcache ?
- DOMContentLoaded et beforeunload
- load et unload
- pageshow et pagehide
Les deux événements clés pour suivre le bfcache sont
pageshowetpagehide, compatibles avec la plupart des navigateurs.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Des pages inéligibles au bfcache passent à côté de navigations instantanées et de meilleurs Core Web Vitals.