Cache amélioré

Philip Walton

Barry Pollard

Le cache amélioré (ou bfcache) est une optimisation du navigateur qui permet navigation vers l'avant et l'arrière. Cela améliore considérablement l'expérience de navigation, en particulier pour les utilisateurs dont les réseaux ou les appareils sont plus lents.

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

Compatibilité du navigateur

Le cache amélioré est compatible avec Firefox et Safari depuis de nombreuses années, sur ordinateur et sur mobile.

À partir de la version 86, Chrome a activé le cache amélioré pour les navigations intersites sur Android pour un petit pourcentage d'utilisateurs. Dans les versions suivantes, la prise en charge supplémentaire a été déployée progressivement. Depuis la version 96, le cache amélioré est activé pour tous les utilisateurs de Chrome sur ordinateur et mobile.

Principes de base de bfcache

Le cache amélioré est un cache en mémoire qui stocke un instantané complet d'une page (y compris le tas de mémoire JavaScript) lorsque l'utilisateur quitte la page. Une fois la page entière en mémoire, le navigateur peut rapidement la restaurer si l'utilisateur décide de revenir.

Combien de fois avez-vous visité un site Web et cliqué sur un lien pour accéder à une autre page, pour vous rendre compte ensuite que ce n'est pas ce que vous vouliez, et 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 de démonstration du cache amélioré pour comprendre l'accélération de la navigation:

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

Le cache amélioré accélère la navigation, mais réduit également la consommation des données, car les ressources n'ont pas besoin d'être téléchargées à nouveau.

Les données d'utilisation de Chrome indiquent qu'une navigation sur dix sur ordinateur et une navigation sur cinq sur mobile s'effectuent vers l'arrière ou vers l'avant. Avec le cache amélioré activé, les navigateurs pouvaient éliminer le transfert de données et le temps de chargement de milliards de pages Web chaque jour.

Comment le "cache" fonctionne

Le "cache" utilisé par le cache amélioré est différent du cache HTTP, qui joue son propre rôle pour accélérer les navigations répétées. bfcache est un instantané de la page entière en mémoire, y compris le tas de mémoire JavaScript, tandis que le cache HTTP ne contient que les réponses des requêtes effectuées précédemment. Étant donné qu'il est très rare que toutes les requêtes requises pour charger une page soient traitées à partir du cache HTTP, les visites répétées à l'aide de restaurations bfcache sont toujours plus rapides que les navigations non bfcache les plus optimisées.

Toutefois, la création d'un instantané de page en mémoire implique une certaine complexité quant à la meilleure façon de conserver le code en cours. Par exemple, comment gérer les appels setTimeout() pour lesquels le délai avant expiration est atteint alors que la page est en cache amélioré ?

La réponse est simple : les navigateurs suspendent les minuteurs en attente ou les promesses non résolues pour les pages en cache amélioré, y compris presque toutes les tâches en attente dans les files d'attente de tâches JavaScript, et reprennent les tâches de traitement si la page est restaurée à partir du cache amélioré.

Dans certains cas, par exemple pour les délais d'inactivité et les promesses, le risque est relativement faible, mais dans d'autres cas, cela peut entraîner un comportement déroutant ou inattendu. Par exemple, si le navigateur met en veille une tâche requise dans le cadre d'une requête IndexedDB transaction, cela peut affecter d'autres onglets ouverts dans la même origine, car les mêmes bases de données IndexedDB sont accessibles par plusieurs onglets simultanément. Par conséquent, les navigateurs n'essaient généralement pas de mettre en cache des pages au milieu d'une transaction IndexedDB ou lorsqu'ils utilisent des API susceptibles d'affecter d'autres pages.

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

bfcache et iFrames

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

Il est également possible d'empêcher le frame principal d'utiliser le cache amélioré si un iFrame intégré utilise des API qui le bloquent. Pour éviter cela, vous pouvez utiliser la Règle d'autorisation définie sur le frame principal ou l'utilisation d'attributs sandbox.

bfcache et applications monopages (SPA)

Étant donné que le cache amélioré fonctionne avec les navigations gérées par le navigateur, il ne fonctionne pas pour les "navigations logicielles" au sein d'une application monopage (SPA). Toutefois, le cache amélioré peut être utile lorsque vous revenez à une application monopage, plutôt que de procéder à une nouvelle initialisation complète de l'application depuis le début.

API pour observer le cache amélioré

Bien que le cache amélioré soit une optimisation effectuée automatiquement par les navigateurs, il est important que les développeurs sachent quand cela se produit afin qu'ils puissent optimiser leurs pages pour ce cache 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 nouveaux événements de cycle de vie de la page (freeze et resume) sont également déclenchés lorsque les pages entrent ou quittent le cache amélioré, ainsi que dans d'autres situations, par exemple lorsqu'un onglet en arrière-plan est figé pour réduire 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 du cache amélioré

L'événement pageshow se déclenche juste après l'événement load lors du chargement initial de la page et chaque fois qu'elle est restaurée à partir du cache amélioré. L'événement pageshow a une propriété persisted, qui est true si la page a été restaurée à partir du cache amélioré et false dans le cas contraire. Vous pouvez utiliser la propriété persisted pour distinguer les chargements de page réguliers des restaurations de 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 dans un onglet en arrière-plan figé. Si vous souhaitez mettre à jour l'état d'une page après qu'elle est figée (y compris les pages en cache amélioré), vous pouvez utiliser l'événement resume. Toutefois, si vous souhaitez mesurer le taux de succès de 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 cache amélioré, consultez Impact du cache amélioré sur les données analytiques et la mesure des performances.

Observer quand une page entre en cache amélioré

L'événement pagehide se déclenche lorsqu'une page se décharge ou que le navigateur tente de la mettre en 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 ne sera pas sur le point d'entrer dans le cache amélioré. Toutefois, si persisted est défini sur true, cela ne garantit pas qu'une page sera mise en cache. Cela signifie que le navigateur a l'intention de mettre la page en cache, mais que d'autres facteurs peuvent la rendre impossible à mettre en cache.

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 a la valeur true, mais cela signifie simplement que le navigateur a l'intention de mettre en cache la page. Il devra peut-être encore le supprimer pour un certain nombre de 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 (et inéligibles) au cache amélioré pour maximiser leurs taux de succès de cache (hits).

Les sections suivantes décrivent les bonnes pratiques à appliquer pour que le navigateur ait le plus de chances de mettre vos pages en cache.

Ne jamais utiliser l'événement unload

Le moyen le plus important d'optimiser le cache amélioré dans tous les navigateurs consiste à ne jamais utiliser l'événement unload. Jamais !

L'événement unload pose problème pour les navigateurs, car il est antérieur au cache amélioré, et de nombreuses pages sur Internet fonctionnent avec l'hypothèse (raisonnable) qu'une page ne continuera pas d'exister après le déclenchement de l'événement unload. Cela représente un défi, car bon nombre de ces pages ont également été conçues en partant du principe que l'événement unload se déclencherait chaque fois qu'un utilisateur quitterait la page, ce qui n'est plus vrai depuis bien longtemps.

Les navigateurs sont donc confrontés à un dilemme : ils doivent choisir un élément susceptible d'améliorer l'expérience utilisateur, sans pour autant endommager la page.

Sur ordinateur, Chrome et Firefox ont choisi de rendre les pages inéligibles au cache amélioré si elles ajoutent un écouteur unload. Cette approche est moins risquée, mais disqualifie de nombreuses pages. Safari tentera de mettre en cache certaines pages avec un écouteur d'événements unload, mais pour limiter les éventuels problèmes, il n'exécutera pas l'événement unload lorsqu'un utilisateur quitte la page, ce qui le rend très peu fiable.

Sur mobile, Chrome et Safari tenteront de mettre en cache les pages avec un écouteur d'événements unload, car le risque de défaillance est plus faible, car 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 cache amélioré, sauf sur iOS, où tous les navigateurs doivent utiliser le moteur de rendu WebKit. Ce cache se comporte donc comme dans Safari.

Au lieu d'utiliser l'événement unload, utilisez l'événement pagehide. L'événement pagehide se déclenche chaque fois que l'événement unload se déclenche, et également lorsqu'une page est mise en cache amélioré.

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

En raison de son manque de fiabilité et de l'impact sur les performances du cache amélioré, Chrome cherche à abandonner l'événement unload.

Utiliser une 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 à l'aide de règles d'autorisation.

Permission-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 amélioré.

Ajouter uniquement des écouteurs beforeunload de manière conditionnelle

L'événement beforeunload ne rend pas vos pages inéligibles au cache amélioré dans les navigateurs modernes. Ce n'était toutefois pas le cas auparavant et il n'est toujours pas fiable. Nous vous déconseillons donc de l'utiliser, sauf en cas d'absolue nécessité.

Toutefois, contrairement à l'événement unload, il existe des utilisations légitimes beforeunload Par exemple, lorsque vous souhaitez avertir l'utilisateur qu'il a les modifications non enregistrées qu'ils perdront s'ils quittent la page. Dans ce cas, il s'agit recommandé de n'ajouter des écouteurs beforeunload que lorsqu'un utilisateur n'a pas enregistré modifications, puis les supprimer immédiatement après avoir enregistré les modifications non enregistrées.

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);
});

Réduire au maximum 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 nécessitant une connexion préalable.

Bien que le cache amélioré ne soit pas un cache HTTP, par le passé, lorsque Cache-Control: no-store est défini sur la ressource de page elle-même (et non sur une sous-ressource), les navigateurs ont choisi de ne pas stocker la page en cache amélioré. Nous travaillons actuellement pour modifier ce comportement pour Chrome afin de protéger la confidentialité. Toutefois, pour le moment, les pages qui utilisent Cache-Control: no-store ne peuvent pas bénéficier du cache amélioré.

É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 de quelque type que ce soit n'est jamais appropriée.

Pour les pages dont le contenu doit toujours être à jour, et qui ne contiennent pas d'informations sensibles, utilisez Cache-Control: no-cache ou Cache-Control: max-age=0. Ces instructions demandent au navigateur de revalider le contenu avant de le diffuser. Elles n'affectent pas l'éligibilité au cache amélioré d'une page.

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

L'expérience utilisateur reste probablement meilleure, mais les restaurations bfcache sont instantanées et, comme les pages ne restent pas longtemps dans le cache amélioré, il est peu probable que le contenu soit obsolète. Toutefois, si votre contenu change minute par minute, vous pouvez récupérer toutes les mises à jour à l'aide de l'événement pageshow, comme décrit dans la section suivante.

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

Si votre site conserve l'état des utilisateurs, en particulier les informations sensibles des utilisateurs, ces données doivent être mises à jour ou effacées après la restauration d'une page depuis le cache amélioré.

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

Autre exemple plus critique : lorsqu'un utilisateur se déconnecte d'un site sur un ordinateur public et que l'utilisateur suivant clique sur le bouton Retour. Cela peut potentiellement exposer des données privées qui, selon l'utilisateur, ont été effacées lorsqu'il s'est déconnecté.

Pour éviter de telles situations, il est recommandé de toujours mettre à jour 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
  }
});

Bien que l'idéal soit de mettre à jour le contenu sur place, vous pouvez forcer un rechargement complet pour certaines modifications. Le code suivant vérifie la présence d'un cookie spécifique au site dans l'événement pageshow et est actualisé si le cookie est introuvable:

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

Une actualisation présente l'avantage de conserver l'historique (pour permettre les navigations avancées), mais une redirection peut être plus appropriée dans certains cas.

Restauration des annonces et du cache amélioré

Il peut être tentant d'éviter d'utiliser le cache amélioré pour diffuser un nouvel ensemble d'annonces lors de chaque navigation précédente. Cependant, en plus d'avoir un impact sur les performances, il n'est pas sûr que ce comportement améliore l'engagement avec les annonces. Les utilisateurs ont peut-être remarqué qu'ils avaient l'intention de cliquer sur une annonce, mais en actualisant leur contenu au lieu de le restaurer à partir du cache amélioré. Il est important de tester ce scénario, idéalement avec un test A/B, avant de faire des hypothèses.

Pour les sites qui souhaitent actualiser les annonces lors de la restauration du cache amélioré, actualiser uniquement les annonces lors de l'événement pageshow lorsque event.persisted est défini sur true permet d'effectuer cette opération sans affecter les performances de la page. Contactez votre fournisseur d'annonces. Toutefois, voici un exemple illustrant la façon de procéder avec la balise Google Publishing.

É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 contiendrait une référence à l'objet window de la page ouverte.

Outre ce risque de sécurité, une page contenant une référence window.opener non nulle ne peut pas être mise en cache amélioré en toute sécurité, car cela pourrait empêcher toute page tentant d'y accéder.

Par conséquent, il est préférable d'éviter de créer des références window.opener. Pour ce faire, utilisez rel="noopener" dans la mesure du possible (notez qu'il s'agit désormais de l'option par défaut dans tous les navigateurs récents). Si votre site nécessite d'ouvrir une fenêtre et de la contrôler via window.postMessage() ou de référencer directement l'objet window, ni la fenêtre ouverte, ni l'ouverture ne seront éligibles au cache amélioré.

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

Comme indiqué précédemment, lorsqu'une page est mise dans le cache amélioré, toutes les tâches JavaScript planifiées sont mises en veille, puis elles sont réactivées lorsqu'elles sont retirées du cache.

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

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

Par conséquent, certains navigateurs ne tentent pas de mettre une page en cache amélioré dans les cas suivants:

• Pages avec une connexion IndexedDB ouverte
• Pages avec 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 déconnecter les observateurs lors de l'événement pagehide ou freeze. Cela permet au navigateur de mettre la page en cache en toute sécurité sans risquer d'affecter les autres onglets ouverts.

Ensuite, si la page est restaurée à partir du cache amélioré, vous pouvez la 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 pour 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 peuvent vous aider à tester vos pages afin de vous assurer qu'elles sont optimisées pour le cache amélioré et à identifier les problèmes qui pourraient les empêcher d'être éligibles.

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 Run Test (Exécuter le test). Les outils de développement essaient ensuite de quitter la page, puis de revenir en arrière. pour déterminer si la page peut être restaurée à partir du cache amélioré.

Si le test réussit, le panneau indique "Restauration depuis le cache amélioré".

En cas d'échec, le panneau en indique la raison. Si le motif est un point que vous pouvez corriger en tant que développeur, le panneau la marque comme Actionable (Actionable).

Dans cet exemple, l'utilisation d'un écouteur d'événements unload rend la page inéligible au cache amélioré. Vous pouvez résoudre ce problème en passant 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 cache amélioré 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é, car Chrome active le cache amélioré pour davantage d'utilisateurs.

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

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

L'exemple suivant montre comment procéder 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 le taux d'accès au cache amélioré

Vous pouvez également déterminer si le cache amélioré a été utilisé afin d'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 le taux d'accès au cache amélioré à l'aide du nombre de navigations back_forward et back_forward_cache.

Il est important de noter qu'une navigation vers l'avant n'utilise pas le cache amélioré dans un certain nombre de cas, indépendamment du contrôle des propriétaires de sites:

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

Dans certains cas, le type de navigation d'origine peut être conservé par certains navigateurs. Il peut donc afficher un type de back_forward, même s'il ne s'agit pas d'une navigation avant/arrière.

Même sans ces exclusions, le cache amélioré sera supprimé après un certain temps afin d'économiser de la mémoire.

Les propriétaires de sites Web ne doivent donc pas s'attendre à un taux d'accès au cache amélioré de 100% pour toutes les navigations back_forward. Toutefois, mesurer leur ratio peut être utile pour identifier les pages dont la page elle-même empêche l'utilisation du cache amélioré lors d'une grande partie des navigations vers l'avant et vers l'avant.

L'équipe Chrome a ajouté l'API NotRestoredReasons pour vous aider à identifier les raisons pour lesquelles les pages n'utilisent pas le cache amélioré, afin que les développeurs puissent améliorer leurs taux de succès de cache amélioré. L'équipe Chrome a également ajouté des types de navigation à l'expérience utilisateur CrUX, ce qui permet de voir le nombre de navigations en cache amélioré, même sans le mesurer vous-même.

Mesure des performances

Le cache amélioré 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 en cache amélioré restaurent une page existante plutôt que de lancer un nouveau chargement de page, le nombre total de chargements de pages collectés diminue lorsque le cache amélioré est activé. Ce qui est essentiel, c'est que les chargements de page remplacés par des restaurations bfcache auraient probablement été parmi les chargements de page les plus rapides de votre ensemble de données. En effet, les navigations vers l'avant et l'avant sont, par définition, des visites répétées, et les chargements de page répétés sont généralement plus rapides que ceux effectués par les nouveaux visiteurs (grâce à la mise en cache HTTP, comme indiqué précédemment).

Résultat : les pages se chargent moins rapidement dans votre ensemble de données, ce qui risque de fausser la distribution plus lentement, malgré l'amélioration des performances enregistrées par l'utilisateur.

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. Vous pouvez ainsi continuer à surveiller vos performances dans ces types de navigation, même si la distribution globale est faussée. Nous recommandons cette approche pour les métriques de chargement de page non axées sur l'utilisateur, telles que le délai avant le premier octet (TTFB).

Pour les métriques axées sur l'utilisateur telles que 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 métriques Core Web Vitals mesurent l'expérience utilisateur sur une page Web selon différentes dimensions (vitesse de chargement, interactivité, stabilité visuelle). Étant donné que le cache amélioré est utilisé pour restaurer la navigation plus rapidement que le chargement d'une page complète, il est important que les métriques Core Web Vitals en tiennent compte. Après tout, un utilisateur ne se soucie pas de savoir si le cache amélioré a été activé ou non, mais il se soucie 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 du cache amélioré comme des visites de page distinctes dans leur ensemble de données. Bien qu'il n'existe pas d'API dédiées aux performances Web pour mesurer ces métriques après les restaurations du cache amélioré, vous pouvez estimer leurs valeurs à l'aide d'API Web existantes:

• Pour Largest Contentful Paint (LCP), utilisez le delta entre l'horodatage de l'événement pageshow et celui du prochain cadre peint, car tous les éléments du cadre seront peints en même temps. Dans le cas d'une restauration du cache amélioré, le LCP et le FCP sont identiques.
• Pour Interaction to Next Paint (INP), continuez à utiliser l'outil Performance Observer existant, mais réinitialisez la valeur INP actuelle sur 0.
• Pour le paramètre Cumulative Layout Shift (CLS), continuez à utiliser l'observateur de performances existant, mais réinitialisez la valeur CLS actuelle sur 0.

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

La bibliothèque JavaScript web-vitals accepte les restaurations bfcache dans les métriques qu'elle signale.

Autres ressources

• Mise en cache dans Firefox (bfcache dans Firefox)
• Cache de page (bfcache dans Safari)
• Cache amélioré: comportement exposé sur le Web (différences du cache amélioré selon les navigateurs)
• Testeur de cache amélioré (Testez l'impact de différents événements et API sur le cache amélioré dans les navigateurs)
• Performance : Changeur de jeu : cache amélioré dans le navigateur (étude de cas de Smashing Magazine montrant les améliorations spectaculaires des Core Web Vitals grâce à l'activation du cache amélioré)