Cache amélioré

Optimisez vos pages pour des chargements instantanés lorsque vous utilisez les boutons "Précédent" et "Suivant" du navigateur.

Philip Walton
Barry Pollard

Le cache amélioré est une optimisation du navigateur qui permet une navigation instantanée. Elle améliore considérablement l'expérience de navigation pour les utilisateurs, en particulier ceux dont les réseaux ou les appareils sont plus lents.

En tant que développeurs Web, il est essentiel que vous compreniez comment optimiser vos pages pour le cache amélioré sur tous les navigateurs, 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 les ordinateurs et les mobiles.

À partir de la version 86, Chrome a activé le cache amélioré pour la navigation intersites sur Android pour un faible pourcentage d'utilisateurs. Dans les versions suivantes, la prise en charge supplémentaire sera progressivement déployée. Depuis la version 96, le cache amélioré est activé pour tous les utilisateurs de Chrome sur ordinateur et 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. Avec la page entière en mémoire, le navigateur peut la restaurer rapidement et facilement 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:

Sans cache amélioré Une nouvelle requête est lancée pour charger la page précédente. Selon l' optimisation de la page pour les visites répétées, le navigateur devra peut-être télécharger, analyser et réexécuter tout ou partie des ressources qu'il vient de télécharger.
Avec le cache amélioré Le chargement de la page précédente est essentiellement instantané, car la page entière peut être restaurée à partir de la mémoire, sans avoir à accéder au réseau.

Regardez cette vidéo sur le cache amélioré pour comprendre l'accélération des navigations:

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

Non seulement le cache amélioré accélère la navigation, mais il 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 montrent qu'une navigation sur 10 sur ordinateur et une navigation sur cinq sur 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" utilisé par le cache amélioré est différent du cache HTTP (qui est également utile pour accélérer les 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 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 assez rare que toutes les requêtes requises pour charger une page puissent être 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érez-vous 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 l'exécution des minuteurs en attente ou des promesses non résolues (essentiellement toutes les tâches en attente dans les files d'attente de tâches JavaScript) et reprennent les tâches de traitement lorsque la page est restaurée à partir du cache amélioré (ou si cette dernière est restaurée).

Dans certains cas, ce risque est relativement faible (par exemple, expirations de délai ou promesses), mais dans d'autres cas, cela peut entraîner un comportement très déroutant 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 (puisque les mêmes bases de données IndexedDB sont accessibles simultanément depuis plusieurs onglets). Par conséquent, les navigateurs ne tentent généralement pas de mettre en cache les pages au milieu d'une transaction IndexedDB ou d'utiliser des API susceptibles d'affecter d'autres pages.

Pour en savoir plus sur l'impact des différentes utilisations des API sur l'éligibilité au cache amélioré d'une page, consultez Optimiser vos pages pour le cache amélioré ci-dessous.

Le cache amélioré et les applications monopages (SPA)

Le cache amélioré fonctionne avec les navigations gérées par le navigateur. Par conséquent, elle n'est pas compatible avec ce que l'on appelle des "navigations douces" au sein d'une SPA. Toutefois, l'un des principaux arguments de vente d'une SPA est que ces types de navigation doivent de toute façon être rapides. Toutefois, le cache amélioré peut être utile si vous retournez sur une application monopage au lieu 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 de pouvoir optimiser leurs pages en conséquence et ajuster les métriques ou 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 existent depuis que le cache amélioré existe et sont pris en charge par la plupart des navigateurs utilisés aujourd'hui.

Les nouveaux événements Cycle de vie de la page (freeze et resume) sont également déclenchés lorsque les pages entrent ou sortent du cache amélioré, et dans certaines autres situations. (par exemple, lorsqu'un onglet en arrière-plan est figé pour minimiser l'utilisation du processeur). Notez que les événements du cycle de vie de la page ne sont actuellement compatibles qu'avec les navigateurs 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 comporte une propriété persisted qui sera 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 également lorsque les pages sont restaurées à partir du cache amélioré (juste avant l'événement pageshow), bien qu'il se déclenche également 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.

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

L'événement pagehide est l'équivalent de l'événement pageshow. L'événement pageshow se déclenche lorsqu'une page est chargée normalement ou restaurée à partir du cache amélioré. L'événement pagehide se déclenche lorsque la page est déchargée normalement ou lorsque le navigateur tente de la placer dans le cache amélioré.

L'événement pagehide comporte également une propriété persisted. S'il 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 la propriété persisted est définie sur true, cela ne garantit pas qu'une page sera mise en cache. Cela signifie que le navigateur intends de mettre en cache la page, mais que certains facteurs peuvent empêcher sa mise 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 la propriété persisted de l'événement est true), mais là encore, cela signifie que le navigateur intends de mettre en cache la page. Il se peut que vous deviez tout de même le supprimer pour plusieurs raisons expliquées ci-dessous.

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é afin de maximiser leur taux de succès de cache.

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

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 aux navigateurs, car il est antérieur au cache amélioré, et de nombreuses pages sur Internet fonctionnent en partant du principe (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é conçues 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 tente de mettre en cache certaines pages avec un écouteur d'événements unload. Toutefois, pour réduire les risques de dysfonctionnement, il n'exécute pas l'événement unload lorsqu'un utilisateur quitte 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 évite que des tiers ou des extensions ralentissent le site en ajoutant des gestionnaires de déchargement et en le rendant inéligible au cache amélioré.

Ajouter uniquement des écouteurs beforeunload de manière conditionnelle

L'événement beforeunload ne rendra pas vos pages inéligibles au cache amélioré dans les navigateurs récents. C'était auparavant le cas 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.

À éviter
window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});
Le code ci-dessus ajoute un écouteur beforeunload sans condition.
À faire
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);
});
Le code ci-dessus n'ajoute l'écouteur beforeunload que lorsque cela est nécessaire (et le supprime dans le cas contraire).

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. Utilisez-la pour les ressources contenant des informations utilisateur sensibles, par exemple les pages nécessitant une connexion préalable.

Bien que le cache amélioré ne soit pas un cache HTTP, les navigateurs ont toujours choisi de ne pas stocker la page dans le cache amélioré lorsque Cache-Control: no-store est défini sur la ressource de la page elle-même (et non sur toute sous-ressource). 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 souhaitent toujours afficher 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 offrirait sans doute une meilleure expérience utilisateur, mais les restaurations en cache amélioré sont instantanées. Étant donné que 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, que les données doivent être mises à jour ou effacé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 afficher des informations obsolètes si une page obsolète est restaurée à partir du cache amélioré.

Un autre exemple plus important est le cas où un utilisateur se déconnecte d'un site sur un ordinateur public et que l'utilisateur suivant clique sur le bouton Retour. Cela peut exposer des données privées que l'utilisateur a supposées avoir été effacées lors de la 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 avancée. 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 sur laquelle ils avaient l'intention de revenir, 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 à l'aide de window.open() à partir d'un lien avec target=_blank (sans spécifier rel="noopener"), la page d'ouverture fait référence à l'objet de fenêtre de la page ouverte.

En plus de présenter un risque de 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 amélioré, 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" 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'ouvre ne seront éligibles pour le cache amélioré.

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

Comme indiqué ci-dessus, 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'aux API DOM ou à d'autres API isolées uniquement de la page actuelle, mettre en pause ces tâches alors que la page n'est pas visible par l'utilisateur ne pose 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, etc.), 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 n'essaieront pas de mettre une page en cache amélioré dans les cas suivants:

Si votre page utilise l'une de ces API, il est préférable de toujours 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 de manière sécurisée, sans que cela affecte 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 (dans l'événement pageshow ou resume).

L'exemple suivant montre comment vous assurer que vos pages sont éligibles au cache amélioré lorsque vous utilisez IndexedDB 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 is leaving.
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 les empêchent d'être éligibles.

Pour tester une page spécifique, accédez-y dans Chrome, puis dans les outils de développement, accédez à Application > Cache amélioré. Cliquez ensuite sur le bouton Run Test (Exécuter le test). DevTools tentera 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é.

Panneau du cache amélioré dans les outils de développement

Si l'opération réussit, le panneau indique "Restauré à partir du cache amélioré":

Les outils de développement signalent qu'une page a bien été restaurée à partir du cache amélioré

En cas d'échec, le panneau indique que la page n'a pas été restaurée et en indique la raison.

Si vous pouvez résoudre le problème en tant que développeur, cela est également indiqué:

Les outils de développement signalent un échec de restauration d'une page depuis le cache amélioré

Dans la capture d'écran ci-dessus, l'utilisation d'un écouteur d'événements unload empêche la page d'être éligible au cache amélioré. Pour résoudre ce problème, remplacez unload par pagehide:

À éviter
window.addEventListener('unload', ...);
À faire
window.addEventListener('pagehide', ...);

Lighthouse 10.0 a également ajouté un audit de cache amélioré, qui effectue un test semblable à celui des outils de développement. Il indique également les raisons pour lesquelles la page n'est pas éligible en cas d'échec de l'audit. 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 suivez les visites sur votre site à l'aide d'un outil d'analyse, vous constaterez probablement une diminution du nombre total de pages vues, car Chrome continue d'activer le cache amélioré pour davantage d'utilisateurs.

En fait, vous sous-représentez probablement déjà les pages vues par d'autres navigateurs qui implémentent le cache amélioré, car la plupart des bibliothèques d'analyse populaires n'effectuent pas le suivi des restaurations de cache amélioré en tant que nouvelles pages vues.

Si vous ne souhaitez pas que le nombre de pages vues diminue lorsque Chrome active le cache amélioré, vous pouvez signaler les restaurations du cache amélioré en tant que pages vues (recommandé) en écoutant l'événement pageshow et en vérifiant la propriété persisted.

L'exemple suivant montre comment procéder avec Google Analytics. La logique doit être similaire pour d'autres outils d'analyse:

// 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 vérifier 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';
    });
  }
});

En examinant le ratio entre les navigations back_forward et back_forward_cache, il est possible de calculer le ratio de cache amélioré.

Il est important de noter qu'il existe un certain nombre de scénarios, qui ne relèvent pas du contrôle du propriétaire du site, dans lesquels une navigation avant/arrière n'utilise pas le cache amélioré. Par exemple:

  • Lorsque l'utilisateur quitte le navigateur, puis 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 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.

Ainsi, les propriétaires de sites Web ne doivent 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 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 travaille sur une API NotRestoredReasons qui permet d'identifier les raisons pour lesquelles le cache amélioré n'a pas été utilisé. Cela permet aux développeurs de comprendre pourquoi le cache n'a pas été utilisé et de déterminer s'il est possible d'améliorer ce point pour leurs sites.

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 les 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 de cache amélioré aient probablement été l'un des chargements de page les plus rapides de votre ensemble de données. En effet, par définition, les navigations en arrière-plan sont 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 des nouveaux visiteurs (en raison de 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 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. L'une d'elles consiste à annoter toutes les métriques de chargement de page avec leur type de navigation respectif : navigate, reload, back_forward ou prerender. Vous pourrez ainsi continuer à surveiller vos performances dans ces types de navigation, même si la distribution globale est négative. Cette approche est recommandée pour les métriques de chargement de page qui ne sont pas axées sur l'utilisateur, telles que le temps 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 en fonction de plusieurs dimensions (vitesse de chargement, interactivité et stabilité visuelle). Étant donné que les restaurations en cache amélioré sont plus rapides que le chargement de page traditionnel, 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é. Il se soucie simplement que la navigation soit rapide.

Des outils tels que le rapport d'expérience utilisateur Chrome, qui collectent les métriques Core Web Vitals et génèrent des rapports les concernant, traitent les restaurations en cache amélioré comme des visites de pages distinctes dans leur ensemble de données.

Et bien qu'il n'existe pas (encore) d'API de performances Web dédiées pour mesurer ces métriques après la restauration du cache amélioré, leurs valeurs peuvent être approximatives à l'aide des API Web existantes.

  • Pour le Largest Contentful Paint (LCP), vous pouvez utiliser le delta entre l'horodatage de l'événement pageshow et celui du prochain frame peint (étant donné que tous les éléments du frame seront peints en même temps). Notez que dans le cas d'une restauration de cache amélioré, le LCP et le FCP seront identiques.
  • Pour le premier délai d'entrée (FID), vous pouvez ajouter à nouveau les écouteurs d'événements (les mêmes que ceux utilisés par le polyfill FID) dans l'événement pageshow et signaler le FID comme délai de la première entrée après la restauration du cache amélioré.
  • Pour le CLS (Cumulative Layout Shift), vous pouvez continuer à utiliser votre Performance Observer existant. Il vous suffit de réinitialiser 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. Pour obtenir un exemple spécifique de mise en œuvre des versions de cache amélioré de ces métriques dans le code, reportez-vous à l'article Ajouter des versions de cache amélioré à la bibliothèque JS web-Vitals.

Autres ressources