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.

Cette page explique comment optimiser vos pages pour le cache amélioré sur tous les navigateurs.

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 lorsque l'utilisateur la quitte. Avec la page entière en mémoire, le navigateur peut la restaurer rapidement si l'utilisateur décide de revenir, au lieu de devoir répéter toutes les requêtes réseau nécessaires pour charger la page.

La vidéo suivante montre à quel point le cache amélioré peut accélérer la navigation:

L'utilisation du cache amélioré accélère le chargement des pages lors de la navigation vers l'avant et l'arrière.

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. De ce fait, le cache amélioré peut vous faire économiser beaucoup de temps et de données.

Fonctionnement du "cache"

Le "cache" utilisé par 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 réalisables à 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 sans cache amélioré, même les mieux 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 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 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, 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 pour 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 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é.

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 de la sortie et du retour dans une SPA.

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 toujours 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 mesures des performances en conséquence.

Les événements principaux 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 les 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é pour minimiser l'utilisation du processeur. Ces événements ne sont 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 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 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 (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 la section 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 mettre 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 en cache la page, 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, ce qui signifie que le navigateur intends de mettre en cache la page. 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. Les pages suivantes décrivent ce qui rend vos pages éligibles au cache amélioré, ainsi que les bonnes pratiques à suivre pour optimiser la capacité du navigateur à mettre en cache votre page et obtenir de meilleurs taux de succès de cache (hit).

Utiliser pagehide à la place de unload

Le moyen le plus important d'optimiser le cache amélioré dans tous les navigateurs consiste à ne jamais utiliser les écouteurs d'événements unload. Écoutez plutôt pagehide, car il se déclenche à la fois lorsqu'une page entre dans le cache amélioré et à chaque fois que unload se déclenche.

unload est une ancienne fonctionnalité, conçue à l'origine pour se déclencher chaque fois qu'un utilisateur quitte une page. Ce n'est plus le cas, mais de nombreuses pages Web partent du principe que les navigateurs utilisent unload de cette manière et qu'après le déclenchement de unload, la page non chargée cesse d'exister. Cela peut interrompre le cache amélioré si le navigateur tente de mettre en cache une page non chargée.

Sur les ordinateurs, Chrome et Firefox rendent les pages avec des écouteurs unload inéligibles au cache amélioré, ce qui réduit les risques, mais empêche également la mise en cache d'un grand nombre de pages et donc s'actualisent beaucoup plus lentement. Safari tente bien de mettre en cache certaines pages avec des écouteurs d'événements unload, mais pour réduire les risques de dysfonctionnement, il n'exécute pas l'événement unload lorsqu'un utilisateur quitte la page, ce qui rend les écouteurs unload peu fiables.

Sur mobile, Chrome et Safari tentent de mettre en cache les pages avec des écouteurs d'événements unload, car le manque de fiabilité de unload sur mobile réduit le risque de dysfonctionnement. Firefox pour mobile considère les pages qui utilisent unload comme étant 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.

Pour déterminer si du code JavaScript sur vos pages utilise unload, nous vous recommandons d'utiliser l'audit no-unload-listeners dans Lighthouse.

Pour en savoir plus sur l'abandon de unload par Chrome, consultez Abandonner l'événement unload.

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

Certains scripts et extensions tiers peuvent ajouter des gestionnaires de déchargement à une page, ce qui ralentit le site en le rendant inéligible au cache amélioré. Pour empêcher cela dans Chrome 115 et versions ultérieures, utilisez une règle d'autorisation.

Permission-Policy: unload()

Ajouter uniquement des écouteurs beforeunload de manière conditionnelle

L'événement beforeunload ne rend pas vos pages inéligibles au cache amélioré. Cependant, elle n'est pas fiable. Nous vous recommandons donc de ne l'utiliser que lorsque cela est absolument nécessaire.

Un exemple de cas d'utilisation de beforeunload consiste à avertir un utilisateur que des modifications non enregistrées seront perdues s'il quitte la page. Dans ce cas, nous vous recommandons d'ajouter des écouteurs beforeunload uniquement lorsqu'un utilisateur a des modifications non enregistrées, puis de les supprimer immédiatement après l'enregistrement des modifications non enregistrées, comme dans le code suivant:

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 serveur Web d'en-tête HTTP défini sur les réponses qui indique 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 protégées par une procédure de connexion.

Bien que le cache amélioré ne soit pas un cache HTTP, les navigateurs en ont toujours exclu les pages lorsque Cache-Control: no-store est défini sur la ressource de la page (mais pas sur une sous-ressource). Chrome s'efforce de modifier ce comportement tout en préservant la confidentialité des utilisateurs, mais par défaut, les pages qui utilisent Cache-Control: no-store ne sont pas éligibles au cache amélioré.

Pour optimiser le cache amélioré, n'utilisez Cache-Control: no-store que sur les pages contenant des informations sensibles qui ne doivent pas être mises en cache.

Pour les pages qui souhaitent toujours diffuser du contenu à jour, mais qui n'incluent pas d'informations sensibles, utilisez Cache-Control: no-cache ou Cache-Control: max-age=0. Celles-ci indiquent au navigateur de revalider le contenu avant de le diffuser. Elles n'affectent pas l'éligibilité d'une page au cache amélioré, car la restauration d'une page à partir du cache amélioré n'implique pas le cache HTTP.

Si votre contenu change minute par minute, récupérez les mises à jour à l'aide de l'événement pageshow pour maintenir votre page à jour, 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 des données d'état de l'utilisateur, en particulier si elles incluent des informations utilisateur sensibles, vous devez les mettre à jour ou les effacer après la restauration d'une page depuis le cache amélioré.

Par exemple, si un utilisateur se déconnecte d'un site sur un ordinateur public et que l'utilisateur suivant clique sur le bouton "Retour", les données obsolètes du cache amélioré peuvent inclure des données privées que le premier utilisateur pensait être effacées lors de sa déconnexion.

Pour éviter de telles situations, mettez toujours à jour la page après un événement pageshow si event.persisted est true:

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

Pour certaines modifications, il se peut que vous souhaitiez forcer une actualisation complète, afin de préserver l'historique de navigation pour les navigations suivantes. Le code suivant vérifie la présence d'un cookie spécifique au site dans l'événement pageshow et se réactualise 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();
  }
});

Restauration des annonces et du cache amélioré

Il peut être tentant d'éviter d'utiliser le cache amélioré pour que votre page puisse diffuser un nouvel ensemble d'annonces à chaque navigation précédente ou suivante. Toutefois, cela nuit aux performances du site et n'augmente pas systématiquement l'engagement avec les annonces. Par exemple, un utilisateur peut avoir l'intention de revenir sur une page pour cliquer sur une annonce, mais si la page est actualisée au lieu d'être restaurée à partir du cache amélioré, une autre annonce peut s'afficher. Nous vous recommandons d'utiliser les tests A/B afin de déterminer la meilleure stratégie pour votre page.

Pour les sites qui souhaitent actualiser les annonces lors de la restauration du cache amélioré, vous pouvez n'actualiser que les annonces lors de l'événement pageshow lorsque event.persisted est défini sur true, sans affecter les performances de la page, comme dans cet exemple de balise Google Publishing. Pour en savoir plus sur les bonnes pratiques à suivre pour votre site, contactez votre fournisseur d'annonces.

Éviter les références window.opener

Dans les navigateurs plus anciens, 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 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é en toute sécurité, car cela pourrait endommager les pages qui tentent d'y accéder.

Pour éviter ces risques, utilisez rel="noopener" afin d'empêcher la création de références window.opener. Il s'agit du comportement par défaut dans tous les navigateurs récents. Si votre site doit ouvrir une fenêtre et la contrôler à l'aide de window.postMessage() ou en référençant directement l'objet window, ni la fenêtre ouverte, ni l'ouverture ne sont é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 en cache amélioré, toutes les tâches JavaScript planifiées sont suspendues, puis réactivées lorsque la page est sortie du cache.

Si ces tâches JavaScript planifiées n'accèdent qu'aux API DOM ou à d'autres API isolées par rapport à la page actuelle, la mise en pause de ces tâches lorsque 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 et WebSockets), leur suspension peut endommager ces pages en empêchant leur exécution.

Par conséquent, certains navigateurs n'essaient pas de mettre une page en cache amélioré si elle présente l'un des éléments suivants:

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 de manière sécurisée, sans risquer d'affecter les autres onglets ouverts. Ensuite, si la page est restaurée à partir du cache amélioré, vous pouvez rouvrir ces API ou vous y reconnecter lors de l'événement pageshow ou resume.

L'exemple suivant montre comment vous assurer 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.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 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é.
Panneau du cache amélioré dans les outils de développement
Panneau Cache amélioré dans les outils de développement

Si le test réussit, le panneau indique "Restauré à partir du cache amélioré". En cas d'échec, le panneau en indique la raison. Pour obtenir la liste complète des raisons, consultez la liste des motifs non restaurés pour Chromium.

Si le problème vient d'un point que vous pouvez aborder en tant que développeur, le panneau la marque comme exploitable.

Les outils de développement signalent un échec de restauration d'une page depuis le cache amélioré
Échec du test de cache amélioré avec un résultat exploitable.

Dans cette image, l'utilisation d'un écouteur d'événements unload rend la page inéligible au cache amélioré. Pour résoudre ce problème, passez de unload à pagehide:

À faire
window.addEventListener('pagehide', ...);
À éviter
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 suivre les visites sur votre site, vous constaterez peut-être une baisse 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à les pages vues par d'autres navigateurs qui implémentent le cache amélioré, car la plupart des bibliothèques d'analyse populaires ne suivent pas les restaurations de cache amélioré en tant que 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é

Pour identifier les pages qui n'utilisent pas encore le cache amélioré, mesurez le type de navigation pour les chargements de page comme suit:

// 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.

Les raisons pour lesquelles une navigation vers l'arrière ou vers l'avant peut ne pas utiliser le cache amélioré incluent les comportements utilisateur suivants:

  • Quittez et redémarrez le navigateur.
  • Duplication d'un onglet.
  • Fermer et restaurer un onglet

Dans certains de ces cas, le navigateur peut conserver le type de navigation d'origine et afficher un type de back_forward, même s'il ne s'agit pas de navigations vers l'avant ou vers l'avant. Même lorsque les types de navigation sont correctement signalés, le cache amélioré est régulièrement supprimé pour économiser de la mémoire.

De ce fait, les propriétaires de sites Web ne peuvent pas s'attendre à un taux d'accès au cache amélioré de 100% pour toutes les navigations dans back_forward. Toutefois, la mesure de leur ratio peut aider à identifier les pages qui empêchent l'utilisation du cache amélioré.

L'équipe Chrome travaille sur une 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é.

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 démarrer un nouveau chargement de page, le nombre total de chargements de page collectés diminue lorsque le cache amélioré est activé. Toutefois, les chargements de page remplacés par le cache amélioré font probablement partie des chargements de page les plus rapides de votre ensemble de données, car les chargements de page répétés, y compris les navigations précédentes et suivantes, sont généralement plus rapides que les premiers chargements de page en raison de la mise en cache HTTP. L'activation du cache amélioré peut donc ralentir le chargement des pages dans vos analyses, malgré l'amélioration des performances du site pour l'utilisateur.

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. Cela vous permet de continuer à surveiller vos performances dans ces types de navigation, même si la distribution globale est négative. Nous recommandons cette approche pour les métriques de chargement de page non axées sur l'utilisateur, telles que le temps de chargement du 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 Core Web Vitals mesurent l'expérience utilisateur sur une page Web en fonction de différentes dimensions (vitesse de chargement, interactivité, stabilité visuelle). Il est important que vos métriques Core Web Vitals reflètent le fait que la restauration du cache amélioré par les utilisateurs soit plus rapide que le chargement de la page par défaut.

Les outils qui collectent les métriques Core Web Vitals et génèrent des rapports les concernant, 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 de performances Web dédiées pour mesurer ces métriques après la 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 CLS 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. Pour obtenir un exemple spécifique d'implémentation des versions de cache amélioré de ces métriques, consultez le PR en les ajoutant à la bibliothèque JS web-vitals.

Autres ressources