cycle de vie du script
unload et beforeunload
Les gestionnaires de sortie peuvent empêcher la restauration. Vérifiez le motif du navigateur, la mesure d’audience et les formulaires avant de modifier le code.
Vérifier le BFCache d'un site en ligne
Vérifiez si une page est restaurée lors du retour en arrière. Identifiez les restrictions du navigateur qui imposent un rechargement complet.
Causes de blocage
Pourquoi le retour exige un rechargement
Le BFCache a rarement un seul bloqueur universel. Le rapport sépare les en-têtes serveur, les restrictions du navigateur et le code frontend pour que la correction ne devienne pas une devinette.
en-têtes de réponse
Cache-Control: no-store
L’effet de no-store dépend du navigateur et des conditions du test. Consultez le motif de refus enregistré. Ne retirez pas la protection des données privées pour BFCache.
état d'exécution
État JavaScript et connexions
WebSocket, transactions IndexedDB, minuteries et état SPA peuvent bloquer la restauration. Milten vérifie ce qui se passe lorsque l'utilisateur quitte la page et y revient via pageshow.
FAQ
Questions fréquentes sur le Back/Forward Cache
Réponses courtes sur ce qu'est le BFCache, pourquoi il se désactive et comment corriger les bloqueurs en toute sécurité.
Qu'est-ce que le Back/Forward Cache ?
Le BFCache conserve un instantané complet de la page dans la mémoire du navigateur. Lorsque l'utilisateur clique sur Précédent ou Suivant, la page peut apparaître immédiatement sans recharger le HTML, les ressources ni effectuer un nouveau rendu.
Pourquoi une page n'utilise-t-elle pas le BFCache ?
Consultez les raisons enregistrées par le navigateur testé. Les gestionnaires du cycle de vie, les ressources ouvertes et les paramètres de réponse peuvent affecter la restauration. Les règles varient selon le navigateur et son état. Dans Chrome actuel, no-store et beforeunload ne bloquent pas systématiquement BFCache à eux seuls.
Quel est le lien entre le BFCache et les Core Web Vitals ?
Une restauration BFCache semble généralement instantanée car le navigateur affiche l'état prêt de la page. Elle réduit les chargements répétés et améliore l'expérience de navigation en arrière et en avant.
Peut-on supprimer unload sans perdre l'analytique ?
Vérifiez quels événements dépendent d'unload avant de le supprimer. Les changements de visibilité, pagehide ou sendBeacon peuvent convenir à l'usage, mais il faut vérifier la livraison des événements. Testez un chargement normal et une restauration BFCache sans compter deux fois la même visite.
Faut-il vérifier chaque page ?
Commencez par les modèles clés : page d'accueil, catalogue, page produit, article, espace compte ou paiement. Si le bloqueur se trouve dans la mise en page partagée, il apparaîtra sur plusieurs types de pages.
Services associés
Ce qu'il faut vérifier ensuite avec ce service
Vitesse de chargement
Vérifiez le chargement avec les paramètres d’appareil et de réseau choisis. Obtenez des mesures de vitesse, les résultats et les recommandations.
OuvrirVérification JavaScript
Vérifiez les fichiers JavaScript, les erreurs de chargement et le code inutilisé au chargement. Repérez les scripts à examiner davantage.
OuvrirFuites de mémoire
Repérez les données qui restent en mémoire après des navigations répétées. Examinez les fuites possibles et les données qui s’accumulent.
OuvrirRéactivité de la page (INP)
Mesurez la rapidité de réponse de la page à des actions automatisées. Repérez les retards pendant le test.
Ouvrir