Cache amélioré

Philip Walton

Barry Pollard

Le cache amélioré est une optimisation du navigateur qui permet une navigation instantanée. 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éveloppeurs Web, vous devez impérativement comprendre comment optimiser vos pages pour le cache amélioré pour que vos utilisateurs puissent en retirer les avantages.

Compatibilité du navigateur

Le cache amélioré est compatible avec Firefox et Safari depuis de nombreuses années sur les ordinateurs et les mobiles.

Depuis la version 86, Chrome active le cache amélioré pour la navigation 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 sur mobile.

Principes de base du cache amélioré

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 la restaurer rapidement 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 que ce n'était pas ce que vous vouliez et cliquer sur le bouton Retour ? À ce stade, 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 sur le cache amélioré pour comprendre l'accélération de la navigation:

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

En plus d'accélérer la navigation, le cache amélioré réduit également la consommation de 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 10 sur ordinateur et une navigation sur 5 sur un mobile s'effectuent vers l'avant ou vers l'avant. Lorsque le cache amélioré était activé, les navigateurs pouvaient éliminer le transfert de données et le temps passé à charger des milliards de pages Web chaque jour.

Fonctionnement du "cache"

Le cache amélioré est différent du cache HTTP, qui joue son propre rôle dans la rapidité des navigations répétées. Le cache amélioré est un instantané de l'intégralité de la page en mémoire, y compris le tas de mémoire JavaScript, tandis que le cache HTTP ne contient que les réponses aux requêtes effectuées précédemment. Étant donné qu'il est très rare que toutes les requêtes nécessaires au chargement d'une page soient traitées à partir du cache HTTP, les visites répétées à l'aide de restaurations en cache amélioré sont toujours plus rapides que les navigations hors cache amélioré les plus bien optimisées.

Toutefois, la création d'un instantané d'une 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() où le délai avant expiration est atteint lorsque la page se trouve dans le cache amélioré ?

La réponse est la suivante : les navigateurs suspendent tous les minuteurs 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 le traitement des tâches si la page est restaurée depuis le cache amélioré.

Dans certains cas, par exemple pour les délais d'inactivité et les promesses, ce risque est relativement faible. Dans d'autres cas, cela peut entraîner un comportement confus ou inattendu. Par exemple, si le navigateur suspend une tâche requise dans le cadre d'une transaction IndexedDB, cela peut affecter les autres onglets ouverts de la même origine, car les mêmes bases de données IndexedDB sont accessibles simultanément par plusieurs onglets. Par conséquent, les navigateurs n'essaient généralement pas de mettre en cache les 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 des différentes utilisations de l'API sur l'éligibilité au cache amélioré d'une page, consultez Optimiser vos pages pour le cache amélioré.

Le cache amélioré et les cadres iFrame

Si une page contient des iFrames intégrés, ceux-ci ne sont pas éligibles au cache amélioré. Par exemple, si vous accédez à une autre page dans un iFrame, puis revenez en arrière, le navigateur revient "en arrière" dans l'iFrame plutôt que dans le cadre principal, mais la navigation arrière dans l'iFrame n'utilise pas le cache amélioré.

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

Le cache amélioré et les 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 douces" dans une application monopage (SPA). Toutefois, le cache amélioré peut toujours être utile lors du retour à une SPA plutôt que de procéder à une nouvelle réinitialisation complète de l'application dès le départ.

API permettant d'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 en conséquence 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 Cycle de vie de la page (freeze et resume) sont également déclenchés lorsque des pages entrent dans le cache amélioré ou la quittent, ainsi que dans d'autres situations, par exemple lorsqu'un onglet en arrière-plan est figé afin de 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 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 que celle-ci est restaurée à partir du cache amélioré. L'événement pageshow comporte 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 standards des restaurations en 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 des pages sont restaurées depuis le cache amélioré (juste 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 (ce qui inclut les pages dans le cache amélioré), vous pouvez utiliser l'événement resume. Toutefois, si vous souhaitez mesurer le taux d'accès au 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 analyses et la mesure des performances.

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 qu'une page n'est 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 intends de mettre la page en cache, mais que d'autres facteurs empêchent peut-être cette opération.

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 true, mais cela signifie que le navigateur intends de mettre la page en cache. Il se peut que vous deviez encore le supprimer pour diverses 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 inéligibles) au cache amélioré afin de maximiser leurs taux de succès de cache.

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

Ne jamais utiliser l'événement unload

La méthode la plus importante pour 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 aux navigateurs, car il est antérieur au cache amélioré, et de nombreuses pages sur Internet reposent sur l'hypothèse (raisonnable) qu'une page ne continue 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é créées avec l'hypothèse que l'événement unload se déclencherait chaque fois qu'un utilisateur quitte la page, ce qui n'est plus vrai (et ce n'est plus vrai 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 d'endommager la page.

Sur les ordinateurs, Chrome et Firefox ont choisi de rendre les pages inéligibles au cache amélioré si elles ajoutent un écouteur unload, ce qui est moins risqué, mais disqualifie également beaucoup de pages. Safari tentera de mettre en cache certaines pages avec un écouteur d'événements unload. Toutefois, pour réduire les risques de dysfonctionnement, il n'exécutera pas l'événement unload lorsqu'un utilisateur quittera la page, ce qui le rend 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 dysfonctionnement est moins important en raison du fait que l'événement unload a toujours été extrêmement peu fiable sur mobile. Firefox considère les pages qui utilisent unload comme inéligibles au cache amélioré, sauf sur iOS, qui nécessite que tous les navigateurs utilisent le moteur de rendu WebKit. Il se comporte 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 également lorsqu'une page est mise en cache amélioré.

Lighthouse propose en effet 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 des règles 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 que ceux-ci ne sont pas ajoutés en utilisant une règle d'autorisation de Chrome 115.

Permission-Policy: unload()

Cela permet également d'éviter que des tiers ou des extensions ralentissent 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 récents. En revanche, c'était le cas auparavant, et il n'est toujours pas fiable. Évitez donc de l'utiliser, sauf si cela est absolument nécessaire.

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

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 qui indiquent 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, historiquement, lorsque Cache-Control: no-store est défini sur la ressource de la page elle-même (et non sur toute sous-ressource), les navigateurs ont choisi de ne pas stocker la page dans le cache amélioré. Nous travaillons actuellement à modifier ce comportement dans Chrome tout en protégeant la confidentialité, mais les pages qui utilisent Cache-Control: no-store ne sont actuellement pas éligibles au 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 n'est jamais appropriée.

Pour les pages qui doivent toujours diffuser des contenus à jour et qui ne contiennent aucune information sensible, utilisez Cache-Control: no-cache ou Cache-Control: max-age=0. Ces instructions indiquent au navigateur de revalider le contenu avant de le diffuser. Elles n'affectent pas l'éligibilité d'une page au cache amélioré.

Notez que lorsqu'une page est restaurée à partir du cache amélioré, elle l'est à partir de la mémoire, et non 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 nouvelle validation n'est effectuée avant que le contenu soit présenté à l'utilisateur.

Cela offrira probablement une meilleure expérience utilisateur, mais les restaurations en cache amélioré sont instantanées et, comme les pages ne restent pas très 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 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 cache amélioré

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

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

Autre exemple, plus important, 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 permettre de divulguer des données privées que l'utilisateur a supposées avoir effacées lors de sa déconnexion.

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

Même s'il est conseillé de mettre à jour le contenu dans l'idéal, vous devrez peut-être forcer l'actualisation complète pour certaines modifications. Le code suivant vérifie la présence d'un cookie spécifique au site dans l'événement pageshow et se réactualise dans le cas contraire:

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 la navigation vers l'avant), 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 l'utilisation du cache amélioré pour diffuser un nouvel ensemble d'annonces à chaque navigation antérieure/avant. Toutefois, en plus d'avoir un impact sur les performances, il n'est pas question de savoir si ce type de comportement permet d'améliorer l'engagement avec les annonces. Les utilisateurs ont peut-être remarqué une annonce qu'ils avaient l'intention de revenir sur laquelle ils avaient l'intention de cliquer, mais en les rechargeant au lieu de les 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 suppositions.

Pour les sites qui souhaitent actualiser les annonces lors de la restauration du cache amélioré, puis actualiser uniquement les annonces pour l'événement pageshow lorsque event.persisted est défini sur true, cela n'aura aucune incidence sur les performances de la page. Vérifiez auprès de votre fournisseur d'annonces. Voici un exemple montrant comment procéder avec Google Publishing Tag.

Éviter les références window.opener

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

En plus de représenter un risque de sécurité, une page contenant une référence window.opener non nulle ne peut pas être mise en cache amélioré de manière sécurisée, car cela pourrait endommager les pages qui tentent 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" autant que 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 pour le cache amélioré.

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

Comme indiqué précédemment, lorsqu'une page est placée dans le cache amélioré, toutes les tâches JavaScript planifiées sont suspendues, puis réactivées lorsque la page est extraite du cache.

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

Toutefois, si ces tâches sont connectées à des API qui sont également accessibles à partir d'autres pages de 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 des autres onglets.

Par conséquent, certains navigateurs n'essaient 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 de déconnecter les observateurs pendant l'événement pagehide ou freeze. Le navigateur peut ainsi 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 rouvrir ces API ou vous y reconnecter lors de l'événement pageshow ou resume.

L'exemple suivant montre comment vérifier que les pages qui utilisent IndexedDB sont éligibles au cache amélioré 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. => req.result.createObjectStore('keyval');
      req. => reject(req.error);
      req. => 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 pour vous assurer que vos pages peuvent être mises en cache

Les outils pour les développeurs Chrome peuvent vous aider à tester vos pages pour 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 le cache, 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 "Restauré à partir du cache amélioré".

En cas d'échec, le panneau en indique la raison. Si le problème concerne un point que vous pouvez aborder en tant que développeur, le panneau le marque comme exploitable.

Dans cet exemple, l'utilisation d'un écouteur d'événements unload rend la page inéligible au cache amélioré. Pour résoudre ce problème, remplacez unload par pagehide:

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

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

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

Impact du cache amélioré sur les analyses et la mesure des performances

Si vous utilisez un outil d'analyse pour mesurer les visites sur votre site, vous constaterez peut-être une diminution du nombre total de pages vues, car Chrome active le cache amélioré pour un plus grand nombre d'utilisateurs.

En fait, vous sous-estimez probablement déjà le nombre de pages vues par 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 de 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 mesurer si le cache amélioré a été utilisé afin d'identifier les pages qui n'utilisent pas le cache amélioré. 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 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'il existe un certain nombre de scénarios, hors du contrôle du propriétaire du site, dans lesquels une navigation avant/arrière n'utilise pas le cache amélioré, notamment:

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

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

Même sans ces exclusions, le cache amélioré est supprimé après un certain temps pour é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 dans back_forward. Toutefois, mesurer leur ratio peut être utile pour identifier les pages pour lesquelles la page elle-même empêche l'utilisation du cache amélioré pour une proportion élevée de navigations vers l'avant et 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 à CrUX. Vous pouvez ainsi connaître le nombre de navigations en cache amélioré, même si vous ne le mesurez pas 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 dans le champ, en particulier celles qui mesurent le temps de chargement des pages.

Étant donné que les navigations en cache amélioré restaurent une page existante au lieu de lancer un nouveau chargement de page, le nombre total de chargements de page collectés diminue lorsque le cache amélioré est activé. Toutefois, le plus important est que les chargements de page remplacés par les restaurations en cache amélioré aient probablement été parmi les plus rapides de votre ensemble de données. En effet, par définition, les navigations vers l'avant et l'avant correspondent à des visites répétées, et les chargements de page répétés sont généralement plus rapides que les chargements de page effectués par les nouveaux visiteurs (en raison de la mise en cache HTTP, comme indiqué précédemment).

Par conséquent, les pages se chargent moins rapidement dans votre ensemble de données, ce qui risque de ralentir la distribution, même si les performances observées par l'utilisateur se sont probablement améliorées.

Il y a plusieurs façons de traiter 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 répartition globale est négative. Nous recommandons cette approche pour les métriques de chargement de page qui ne sont pas axées sur l'utilisateur, telles que le temps nécessaire au 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 en fonction de différentes dimensions (vitesse de chargement, interactivité et stabilité visuelle). Étant donné que les restaurations en cache amélioré sont plus rapides que les chargements de pages complètes, les métriques Core Web Vitals doivent en tenir compte. Après tout, l'utilisateur ne se soucie pas de l'activation ou non du cache amélioré, mais de la rapidité de la navigation.

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

• Pour le Largest Contentful Paint (LCP), utilisez le delta entre l'horodatage de l'événement pageshow et celui du prochain frame peint, car tous les éléments du frame seront peints en même temps. Dans le cas d'une restauration de cache amélioré, le LCP et le FCP sont identiques.
• Pour Interaction to Next Paint (INP), continuez à utiliser votre Performance Observer existant, mais réinitialisez la valeur INP actuelle sur 0.
• Pour le Cumulative Layout Shift (CLS), continuez à utiliser votre Performance Observer 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 des guides sur les métriques Core Web Vitals individuelles. Pour obtenir un exemple spécifique d'implémentation des versions bfcache de ces métriques, consultez l'article Ajouter des versions de cache amélioré à la bibliothèque JS web-Vitals.

La bibliothèque JavaScript web-vitals accepte les restaurations en cache amélioré dans les métriques qu'elle génère.

Autres ressources

• Mise en cache Firefox (bfcache dans Firefox)
• Cache de la page (cache amélioré dans Safari)
• Cache amélioré: comportement exposé sur le Web (différences de cache amélioré entre les navigateurs)
• Testeur de cache amélioré (teste l'impact de différents événements et API sur le cache amélioré dans les navigateurs)
• Performance Game Changer: cache amélioré dans le navigateur (étude de cas du magazine Smashing qui montre des améliorations spectaculaires des Core Web Vitals grâce à l'activation du cache amélioré)