Cache amélioré

Philip Walton

Barry Pollard

Le cache amélioré (ou bfcache) est une optimisation de navigateur qui permet de naviguer instantanément vers les pages précédentes et suivantes. Il améliore considérablement l'expérience de navigation, en particulier pour les utilisateurs dont la connexion réseau ou les appareils sont plus lents.

En tant que développeur Web, il est essentiel de comprendre comment optimiser vos pages pour la bfcache afin que vos utilisateurs puissent en profiter.

Compatibilité du navigateur

Tous les principaux navigateurs incluent un cache bfcache, y compris Chrome depuis la version 96, Firefox et Safari.

Principes de base du bfcache

Avec le cache Précédent/Suivant (bfcache), au lieu de détruire une page lorsque l'utilisateur quitte celle-ci, nous reportons la destruction et suspendons l'exécution de JavaScript. Si l'utilisateur revient rapidement en arrière, nous rendons la page de nouveau visible et nous réactivons l'exécution du code JavaScript. L'utilisateur peut ainsi naviguer d'une page à l'autre presque instantanément.

Combien de fois avez-vous visité un site Web et cliqué sur un lien pour accéder à une autre page, avant de vous rendre compte que ce n'était pas ce que vous vouliez et de cliquer sur le bouton "Retour" ? À ce moment-là, le cache amélioré peut faire une grande différence dans la vitesse de chargement de la page précédente :

Regardez cette vidéo pour voir la mise en cache BFC en action et comprendre comment elle peut accélérer la navigation :

Dans la vidéo, l'exemple avec bfcache est beaucoup plus rapide que celui sans.

La bfcache accélère non seulement la navigation, mais réduit également l'utilisation des données, car les ressources n'ont pas besoin d'être téléchargées à nouveau.

Les données d'utilisation de Chrome montrent qu'une navigation sur 10 sur ordinateur et une sur 5 sur mobile est une navigation "Précédent" ou "Suivant". Avec le cache amélioré activé, les navigateurs pourraient éliminer le transfert de données et le temps de chargement pour des milliards de pages Web chaque jour !

Fonctionnement du "cache"

Le "cache" utilisé par le cache amélioré est différent du cache HTTP, qui joue son propre rôle dans l'accélération des navigations répétées. Le cache amélioré est un instantané de l'ensemble de la page en mémoire, y compris le tas JavaScript, tandis que le cache HTTP ne contient que les réponses aux requêtes précédemment effectuées. Comme il est très rare que toutes les requêtes nécessaires au chargement d'une page soient satisfaites à partir du cache HTTP, les visites répétées utilisant des restaurations bfcache sont toujours plus rapides que même les navigations sans bfcache les mieux optimisées.

Le gel d'une page pour la réactiver potentiellement plus tard implique une certaine complexité en termes de meilleure façon de préserver le code en cours. Par exemple, comment gérez-vous les appels setTimeout() lorsque le délai d'attente est atteint alors que la page se trouve dans le cache amélioré ?

La réponse est que les navigateurs mettent en pause tous les minuteurs en attente ou les promesses non résolues pour les pages dans le cache amélioré, y compris la quasi-totalité des tâches en attente dans les files d'attente des tâches JavaScript, et reprennent le traitement des tâches si la page est restaurée à partir du cache amélioré.

Dans certains cas, comme pour les délais d'attente et les promesses, le risque est assez faible, mais dans d'autres cas, cela peut entraîner un comportement déroutant ou inattendu. Par exemple, si le navigateur met en pause une tâche requise dans le cadre d'une transaction IndexedDB, cela peut affecter d'autres onglets ouverts dans la même origine, car plusieurs onglets peuvent accéder simultanément aux mêmes bases de données IndexedDB. Par conséquent, les navigateurs ne tentent généralement pas de mettre en cache les pages au milieu d'une transaction IndexedDB ni lorsqu'ils utilisent des API susceptibles d'affecter d'autres pages.

Pour en savoir plus sur l'impact de l'utilisation de différentes API sur l'éligibilité d'une page au bfcache, consultez Optimiser vos pages pour le bfcache.

bfcache et iFrames

Si une page contient des iFrames intégrés, les iFrames eux-mêmes ne sont pas éligibles au cache amélioré. Par exemple, si vous accédez à une autre URL dans un iFrame, le contenu précédent n'entre pas dans le bfcache. Si vous revenez en arrière, le navigateur reviendra en arrière dans l'iFrame plutôt que dans le frame principal, mais la navigation en arrière dans l'iFrame n'utilisera pas le bfcache.

Toutefois, lorsque le frame principal est restauré à partir du cache amélioré, les iframes intégrés sont restaurés tels qu'ils étaient lorsque la page est entrée dans le cache amélioré.

Le frame principal peut également être empêché d'utiliser le bfcache si un iframe intégré utilise des API qui le bloquent. Pour éviter cela, vous pouvez définir la Permissions Policy sur le frame principal ou utiliser les attributs sandbox.

Cache amélioré et applications monopages (SPA)

Comme la bfcache fonctionne avec les navigations gérées par le navigateur, elle ne fonctionne pas pour les "navigations douces" dans une application monopage (SPA). Toutefois, le bfcache peut toujours être utile lorsque vous revenez à une SPA au lieu de réinitialiser complètement cette application depuis le début.

API pour observer le bfcache

Bien que le bfcache soit une optimisation que les navigateurs effectuent automatiquement, il est important que les développeurs sachent quand il se produit afin de pouvoir optimiser leurs pages pour celui-ci et ajuster les métriques ou les mesures de performances en conséquence.

Les principaux événements utilisés pour observer le cache amélioré sont les événements de transition de page pageshow et pagehide, qui sont compatibles avec la plupart des navigateurs.

Les événements Page Lifecycle plus récents (freeze et resume) sont également déclenchés lorsque les pages entrent dans le cache amélioré ou en sortent, ainsi que dans d'autres situations, par exemple lorsqu'un onglet en arrière-plan est figé pour minimiser l'utilisation du processeur. Ces événements ne sont compatibles qu'avec les navigateurs basés sur Chromium.

Observer quand une page est restaurée à partir de bfcache

L'événement pageshow se déclenche immédiatement après l'événement load, lors du chargement initial de la page et chaque fois que celle-ci est restaurée à partir du cache amélioré. L'événement pageshow comporte une propriété persisted, dont la valeur est true si la page a été restaurée à partir du cache amélioré, et false dans le cas contraire. La propriété persisted permet de distinguer les chargements de page des restaurations depuis le cache amélioré. Exemple :

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

Dans les navigateurs compatibles avec l'API Page Lifecycle, l'événement resume se déclenche lorsque les pages sont restaurées à partir du cache amélioré (immédiatement avant l'événement pageshow) et lorsqu'un utilisateur revient sur un onglet en arrière-plan figé. Si vous souhaitez mettre à jour l'état d'une page après qu'elle a été figée (y compris les pages dans le cache amélioré), vous pouvez utiliser l'événement resume. Toutefois, si vous souhaitez mesurer le taux de réussite du cache amélioré de votre site, vous devez utiliser l'événement pageshow. Dans certains cas, vous devrez peut-être utiliser les deux.

Pour en savoir plus sur les bonnes pratiques de mesure du bfcache, consultez Impact du bfcache sur les mesures des performances et des données analytiques.

Observer quand une page entre dans le cache amélioré

L'événement pagehide se déclenche lorsqu'une page est déchargée ou lorsque le navigateur tente de la placer dans le cache amélioré.

L'événement pagehide comporte également une propriété persisted. Si la valeur est false, vous pouvez être sûr que la page n'est pas sur le point d'entrer dans le cache amélioré. Toutefois, le fait que persisted soit défini sur true ne garantit pas qu'une page sera mise en cache. Cela signifie que le navigateur a l'intention de mettre en cache la page, mais que d'autres facteurs peuvent rendre la mise en cache impossible.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

De même, l'événement freeze se déclenche immédiatement après l'événement pagehide si persisted est défini sur true, mais cela signifie uniquement que le navigateur a l'intention de mettre la page en cache. Il devra peut-être quand même la supprimer pour plusieurs raisons expliquées plus loin.

Optimiser vos pages pour le cache amélioré

Toutes les pages ne sont pas stockées dans le cache amélioré, et même lorsqu'une page y est stockée, elle n'y reste pas indéfiniment. Il est essentiel que les développeurs comprennent ce qui rend les pages éligibles (ou non) à bfcache pour maximiser leurs taux de réussite du cache.

Les sections suivantes décrivent les bonnes pratiques à suivre pour que le navigateur puisse mettre en cache vos pages.

Ne jamais utiliser l'événement unload

Pour optimiser le cache amélioré dans tous les navigateurs, il est essentiel de ne jamais utiliser l'événement unload. De rien !

L'événement unload pose problème aux navigateurs, car il est antérieur au cache amélioré. De nombreuses pages sur Internet partent du principe (raisonnable) qu'une page n'existera plus après le déclenchement de l'événement unload. Cela pose problème, car de nombreuses pages ont également été conçues en partant du principe que l'événement unload se déclencherait chaque fois qu'un utilisateur quitte la page, ce qui n'est plus le cas (et ne l'est plus depuis longtemps).

Les navigateurs sont donc confrontés à un dilemme : ils doivent choisir entre quelque chose qui peut améliorer l'expérience utilisateur, mais qui risque également de casser la page.

Sur ordinateur, Chrome et Firefox ont choisi de rendre les pages inéligibles au bfcache si elles ajoutent un écouteur unload, ce qui est moins risqué, mais disqualifie également beaucoup de pages. Safari tente de mettre en cache certaines pages avec un écouteur d'événements unload, mais pour réduire les risques de dysfonctionnement, il n'exécute pas l'événement unload lorsqu'un utilisateur quitte une page, ce qui rend l'événement très peu fiable.

Sur mobile, Chrome et Safari tentent de mettre en cache les pages avec un écouteur d'événement unload, car le risque de dysfonctionnement est plus faible étant donné que l'événement unload a toujours été extrêmement peu fiable sur mobile. Firefox considère que les pages qui utilisent unload ne sont pas éligibles au bfcache, sauf sur iOS, qui exige que tous les navigateurs utilisent le moteur de rendu WebKit et se comportent donc comme Safari.

Au lieu d'utiliser l'événement unload, utilisez l'événement pagehide. L'événement pagehide se déclenche dans tous les cas où l'événement unload se déclenche, et il se déclenche également lorsqu'une page est mise en cache amélioré.

En fait, Lighthouse dispose d'un audit no-unload-listeners qui avertit les développeurs si du code JavaScript sur leurs pages (y compris celui des bibliothèques tierces) ajoute un écouteur d'événements unload.

En raison de son manque de fiabilité et de son impact sur les performances du cache bfcache, Chrome prévoit d'abandonner l'événement unload.

Utiliser la règle d'autorisation pour empêcher l'utilisation de gestionnaires de déchargement sur une page

Les sites qui n'utilisent pas de gestionnaires d'événements unload peuvent s'assurer qu'ils ne sont pas ajoutés en utilisant une règle d'autorisation.

Permissions-Policy: unload=()

Cela empêche également les tiers ou les extensions de ralentir le site en ajoutant des gestionnaires de déchargement et en rendant le site inéligible au cache arrière/avant.

Ajouter uniquement beforeunload écouteurs de manière conditionnelle

L'événement beforeunload ne rendra pas vos pages inéligibles au cache amélioré dans le cache amélioré des navigateurs modernes, mais c'était le cas auparavant. Il n'est toujours pas fiable, alors évitez de l'utiliser, sauf en cas d'absolue nécessité.

Cependant, contrairement à l'événement unload, il existe des utilisations légitimes pour beforeunload. Par exemple, lorsque vous souhaitez avertir l'utilisateur qu'il a des modifications non enregistrées qu'il perdra s'il quitte la page. Dans ce cas, il est recommandé d'ajouter des écouteurs beforeunload uniquement lorsqu'un utilisateur a des modifications non enregistrées, puis de les supprimer immédiatement après l'enregistrement des modifications.

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

Minimiser l'utilisation de Cache-Control: no-store

Cache-Control: no-store est un en-tête HTTP que les serveurs Web peuvent définir sur les réponses pour indiquer au navigateur de ne pas stocker la réponse dans un cache HTTP. Il est utilisé pour les ressources contenant des informations utilisateur sensibles, telles que les pages derrière un identifiant.

Bien que le bfcache ne soit pas un cache HTTP, historiquement, lorsque Cache-Control: no-store est défini sur la ressource de page elle-même (par opposition à une sous-ressource), les navigateurs ont choisi de ne pas stocker la page dans le bfcache. Par conséquent, les pages utilisant Cache-Control: no-store peuvent ne pas être éligibles au bfcache. Nous travaillons à modifier ce comportement pour Chrome de manière à préserver la confidentialité.

Étant donné que Cache-Control: no-store limite l'éligibilité d'une page au cache amélioré, il ne doit être défini que sur les pages contenant des informations sensibles pour lesquelles la mise en cache d'un type quelconque n'est jamais appropriée.

Pour les pages qui doivent toujours diffuser du contenu à jour et qui ne contiennent pas d'informations sensibles, utilisez Cache-Control: no-cache ou Cache-Control: max-age=0. Ces directives indiquent au navigateur de revalider le contenu avant de le diffuser. Elles n'affectent pas l'éligibilité d'une page au bfcache.

Notez que lorsqu'une page est restaurée à partir du cache amélioré, elle est restaurée à partir de la mémoire, et non à partir du cache HTTP. Par conséquent, les directives telles que Cache-Control: no-cache ou Cache-Control: max-age=0 ne sont pas prises en compte, et aucune revalidation n'a lieu avant que le contenu ne soit affiché à l'utilisateur.

Toutefois, l'expérience utilisateur est probablement meilleure, car les restaurations à partir du cache arrière/avant sont instantanées et, comme les pages ne restent pas très longtemps dans le cache arrière/avant, il est peu probable que le contenu soit obsolète. Toutefois, si votre contenu change de minute en minute, vous pouvez récupérer les mises à jour à l'aide de l'événement pageshow, comme indiqué dans la section suivante.

Mettre à jour les données obsolètes ou sensibles après la restauration du bfcache

Si votre site conserve l'état de l'utilisateur, en particulier des informations utilisateur sensibles, ces données doivent être mises à jour ou effacées après la restauration d'une page à partir du cache bfcache.

Par exemple, si un utilisateur accède à une page de paiement, puis met à jour son panier, une navigation à l'arrière peut potentiellement afficher des informations obsolètes si une page périmée est restaurée à partir du cache bfcache.

Un autre exemple plus critique se produit lorsqu'un utilisateur se déconnecte d'un site sur un ordinateur public et que l'utilisateur suivant clique sur le bouton "Retour". Cela pourrait potentiellement exposer des données privées que l'utilisateur pensait avoir effacées lorsqu'il s'est déconnecté.

Pour éviter ce genre de situation, il est recommandé de toujours actualiser la page après un événement pageshow si event.persisted est défini sur true :

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

Dans l'idéal, vous devriez mettre à jour le contenu sur place, mais pour certaines modifications, vous pouvez forcer un rechargement complet. Le code suivant vérifie la présence d'un cookie spécifique au site dans l'événement pageshow et recharge la page si le cookie n'est pas trouvé :

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

L'avantage d'une actualisation est qu'elle préserve l'historique (pour permettre la navigation vers l'avant), mais une redirection peut être plus appropriée dans certains cas.

Annonces et restauration du cache amélioré

Il peut être tentant d'essayer d'éviter l'utilisation du cache amélioré pour diffuser un nouvel ensemble d'annonces à chaque navigation vers l'arrière ou vers l'avant. Toutefois, en plus d'avoir un impact sur les performances, il est discutable de savoir si un tel comportement conduit à un meilleur engagement avec les annonces. Il est possible que les utilisateurs aient vu une annonce sur laquelle ils souhaitaient cliquer à nouveau, mais qu'ils n'aient pas pu le faire en rechargeant la page au lieu de la restaurer à partir du cache bf. Il est important de tester ce scénario, idéalement avec un test A/B, avant de tirer des conclusions.

Pour les sites qui souhaitent actualiser les annonces lors de la restauration à partir du cache bfcache, il suffit d'actualiser les annonces lors de l'événement pageshow lorsque event.persisted est défini sur true. Cela permet d'éviter d'impacter les performances de la page. Renseignez-vous auprès de votre fournisseur d'annonces, mais voici un exemple de procédure à suivre avec Google Publishing Tag.

Éviter les références window.opener

Dans les anciens navigateurs, si une page était ouverte à l'aide de window.open() à partir d'un lien avec target=_blank, sans spécifier rel="noopener", la page d'ouverture aurait une référence à l'objet de fenêtre de la page ouverte.

En plus de présenter un risque pour la sécurité, une page avec une référence window.opener non nulle ne peut pas être placée en toute sécurité dans le cache bfcache, car cela pourrait endommager les pages qui tentent d'y accéder.

Il est donc préférable d'éviter de créer des références window.opener. Pour ce faire, utilisez rel="noopener" autant que possible (notez que c'est désormais la valeur par défaut dans tous les navigateurs modernes). Si votre site nécessite l'ouverture d'une fenêtre et son contrôle via window.postMessage() ou en référençant directement l'objet de la fenêtre, ni la fenêtre ouverte ni l'ouvreur ne seront éligibles au bfcache.

Fermer les connexions ouvertes avant que l'utilisateur ne quitte la page

Comme indiqué précédemment, lorsqu'une page est conservée dans le cache amélioré, toutes les tâches JavaScript planifiées sont mises en pause et reprennent lorsque la page est retirée du cache.

Si ces tâches JavaScript planifiées n'accèdent qu'aux API DOM (ou à d'autres API isolées à la page actuelle), la mise en pause de ces tâches lorsque la page n'est pas visible par l'utilisateur ne posera aucun problème.

Toutefois, si ces tâches sont associées à des API également accessibles depuis d'autres pages de la même origine (par exemple, IndexedDB, Web Locks, WebSockets), cela peut poser problème, car la mise en pause de ces tâches peut empêcher l'exécution du code dans d'autres onglets.

Par conséquent, certains navigateurs ne tenteront pas de placer une page dans le cache amélioré dans les scénarios suivants :

• Pages avec une connexion IndexedDB ouverte
• Pages avec des requêtes fetch() ou XMLHttpRequest en cours
• Pages avec une connexion WebSocket ou WebRTC ouverte

Si votre page utilise l'une de ces API, nous vous recommandons vivement de fermer les connexions et de supprimer ou de déconnecter les observateurs lors de l'événement pagehide ou freeze. Cela permet au navigateur de mettre en cache la page de manière sécurisée, sans risquer d'affecter les autres onglets ouverts.

Ensuite, si la page est restaurée à partir du cache amélioré, vous pouvez rouvrir ou vous reconnecter à ces API lors de l'événement pageshow ou resume.

L'exemple suivant montre comment s'assurer que les pages utilisant IndexedDB sont éligibles au bfcache en fermant une connexion ouverte dans l'écouteur d'événements pagehide :

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

Tester la mise en cache de vos pages

Les outils pour les développeurs Chrome permettent de tester vos pages afin de vérifier qu'elles sont optimisées pour bfcache, et d'identifier les problèmes susceptibles de les rendre incompatibles.

Pour tester une page :

1. Accédez à la page dans Chrome.
2. Dans les outils de développement, accédez à Application > Cache amélioré.
3. Cliquez sur le bouton Exécuter le test. Les outils pour les développeurs tentent ensuite de quitter la page, puis d'y revenir pour déterminer si elle peut être restaurée à partir du cache amélioré.

Si le test réussit, le panneau indique "Restaurée à partir du cache amélioré".

Si l'opération échoue, le panneau indique pourquoi. Si le problème peut être résolu par un développeur, le panneau le marque comme Actionnable.

Dans cet exemple, l'utilisation d'un écouteur d'événements unload rend la page inéligible au bfcache. Pour résoudre ce problème, passez de unload à pagehide :

window.addEventListener('pagehide', ...);

window.addEventListener('unload', ...);

Lighthouse 10.0 a également ajouté un audit bfcache, qui effectue un test similaire. Pour en savoir plus, consultez la documentation sur l'audit bfcache.

Impact du bfcache sur les données analytiques et la mesure des performances

Si vous utilisez un outil d'analyse pour mesurer les visites sur votre site, vous remarquerez peut-être une diminution du nombre total de pages vues signalées à mesure que Chrome active la bfcache pour davantage d'utilisateurs.

En fait, vous sous-déclarez probablement déjà les pages vues provenant d'autres navigateurs qui implémentent le bfcache, car de nombreuses bibliothèques d'analyse populaires ne mesurent pas les restaurations du bfcache comme de nouvelles pages vues.

Pour inclure les restaurations à partir du cache amélioré dans votre nombre de vues de page, définissez des écouteurs pour l'événement pageshow et vérifiez la propriété persisted.

L'exemple suivant montre comment effectuer cette opération avec Google Analytics. D'autres outils d'analyse utilisent probablement une logique similaire :

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

Mesurer votre taux d'accès au cache bfcache

Vous pouvez également mesurer si le bfcache a été utilisé pour identifier les pages qui ne l'utilisent pas. Pour ce faire, mesurez le type de navigation pour les chargements de page :

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

Calculez votre taux de réussite du bfcache à l'aide des nombres de navigations back_forward et back_forward_cache.

Il est important de noter qu'il existe un certain nombre de scénarios indépendants de la volonté des propriétaires de sites dans lesquels la navigation Précédent/Suivant n'utilise pas le bfcache. Par exemple :

• lorsque l'utilisateur quitte le navigateur et le redémarre ;
• Lorsque l'utilisateur duplique un onglet
• Lorsque l'utilisateur ferme un onglet et le rouvre

Dans certains de ces cas, le type de navigation d'origine peut être conservé par certains navigateurs et afficher un type back_forward, même s'il ne s'agit pas de navigations "Précédent"/"Suivant".

Même sans ces exclusions, le bfcache sera supprimé au bout d'un certain temps pour économiser de la mémoire.

Par conséquent, les propriétaires de sites Web ne doivent pas s'attendre à un taux de réussite de 100 % pour le cache arrière/avant pour toutes les navigations back_forward. Toutefois, mesurer leur ratio peut être utile pour identifier les pages où la page elle-même empêche l'utilisation du cache bf pour une grande partie des navigations en arrière et en avant.

L'équipe Chrome a ajouté l'API NotRestoredReasons pour aider à identifier les raisons pour lesquelles les pages n'utilisent pas bfcache. Les développeurs peuvent ainsi améliorer leurs taux de réussite bfcache. L'équipe Chrome a également ajouté des types de navigation à CrUX, ce qui permet de voir le nombre de navigations bfcache même sans les mesurer vous-même.

Mesure des performances

Le bfcache peut également avoir un impact négatif sur les métriques de performances collectées sur le terrain, en particulier celles qui mesurent les temps de chargement des pages.

Étant donné que les navigations bfcache restaurent une page existante au lieu de lancer le chargement d'une nouvelle page, le nombre total de chargements de page collectés diminuera lorsque le bfcache sera activé. Toutefois, il est essentiel de noter que les chargements de page remplacés par les restaurations du cache amélioré auraient probablement été parmi les plus rapides de votre ensemble de données. En effet, les navigations en arrière et en avant sont, par définition, des visites répétées. Or, les chargements de page répétés sont généralement plus rapides que ceux des nouveaux visiteurs (en raison de la mise en cache HTTP, comme mentionné précédemment).

Le résultat est un nombre moins élevé de chargements de pages rapides dans votre ensemble de données, ce qui faussera probablement la distribution vers des temps de chargement plus lents, même si les performances constatées par l'utilisateur se sont probablement améliorées.

Il existe plusieurs façons de résoudre ce problème. La première consiste à annoter toutes les métriques de chargement de page avec leur type de navigation respectif : navigate, reload, back_forward ou prerender. Cela vous permet de continuer à surveiller vos performances dans ces types de navigation, même si la distribution globale est négative. Nous recommandons cette approche pour les métriques de chargement de page non centrées sur l'utilisateur, comme le temps de latence du premier octet (TTFB).

Pour les métriques axées sur l'utilisateur, comme les Core Web Vitals, il est préférable de signaler une valeur qui représente plus précisément l'expérience utilisateur.

Impact sur les métriques Core Web Vitals

Les Core Web Vitals mesurent l'expérience utilisateur d'une page Web selon différentes dimensions (vitesse de chargement, interactivité, stabilité visuelle). Étant donné que les utilisateurs perçoivent les restaurations à partir du cache bfcache comme des navigations plus rapides que les chargements de page complets, il est important que les métriques Core Web Vitals reflètent cela. Après tout, un utilisateur ne se soucie pas de savoir si le bfcache était activé ou non. Il veut simplement que la navigation soit rapide.

Les outils qui collectent et génèrent des rapports sur les métriques Core Web Vitals, comme le rapport sur l'expérience utilisateur Chrome, traitent les restaurations à partir du cache arrière-avant comme des visites de pages distinctes dans leur ensemble de données. Bien qu'il n'existe pas d'API de performances Web dédiées pour mesurer ces métriques après la restauration du cache bfcache, vous pouvez approximer leurs valeurs à l'aide des API Web existantes :

• Pour le Largest Contentful Paint (LCP), utilisez le delta entre le code temporel de l'événement pageshow et celui du prochain frame peint, car tous les éléments du frame seront peints en même temps. En cas de restauration à partir du cache amélioré, les valeurs LCP et FCP sont identiques.
• Pour Interaction to Next Paint (INP), continuez à utiliser votre Performance Observer existant, mais réinitialisez la valeur INP actuelle à 0.
• Pour la métrique Cumulative Layout Shift (CLS), continuez à utiliser votre Performance Observer existant, mais réinitialisez la valeur CLS actuelle à 0.

Pour en savoir plus sur l'impact du bfcache sur chaque métrique, consultez les pages des guides sur les métriques Core Web Vitals. Pour obtenir un exemple spécifique d'implémentation des versions bfcache de ces métriques, consultez la demande d'extraction qui les ajoute à la bibliothèque JS web-vitals.

La bibliothèque JavaScript web-vitals prend en charge les restaurations bfcache dans les métriques qu'elle génère.

Autres ressources

• Mise en cache de Firefox (bfcache dans Firefox)
• Cache de page (bfcache dans Safari)
• Cache amélioré : comportement exposé sur le Web (différences du cache amélioré entre les navigateurs)
• Testeur bfcache (testez l'impact de différentes API et événements sur le bfcache dans les navigateurs)
• Le cache amélioré : un atout pour les performances des navigateurs (étude de cas de Smashing Magazine montrant une amélioration spectaculaire des Core Web Vitals grâce à l'activation du cache amélioré)