API notRestoredReasons pour le cache amélioré

Identifiez les navigations qui n'ont pas pu utiliser le cache amélioré, et pourquoi.

Chris Mills

La propriété notRestoredReasons, ajoutée à la classe PerformanceNavigationTiming, indique si les frames présents dans le document ont empêché l'utilisation du cache amélioré lors de la navigation, et pourquoi. Les développeurs peuvent utiliser ces informations pour identifier les pages qui doivent être mises à jour pour les rendre compatibles avec le cache amélioré, améliorant ainsi les performances du site.

État actuel

Step État
1. Créer une vidéo explicative Fin
2. Créer un brouillon initial de la spécification Non démarrée
3. Recueillir des commentaires et itérer sur la conception En cours
4. Phase d'évaluation Démarré
5. lancement Non démarrée

Essayer l'API notRestoredReasons de mise en cache amélioré

À partir de la version 109, l'API bfcache notRestoredReasons est disponible en tant que phase d'évaluation dans Chromium. Pour obtenir des informations à jour sur le calendrier de publication de cette fonctionnalité, consultez la page correspondante du site ChromeStatus.com (consultez la feuille de route de Chrome pour connaître les dates de sortie des versions).

Pour tester l'API notRestoredReasons bfcache, inscrivez-vous à la phase d'évaluation et utilisez-la dans vos tests. Consultez Participer à une phase d'évaluation pour savoir comment utiliser votre jeton une fois que vous êtes enregistré.

Concepts et utilisation

Les navigateurs récents offrent une fonctionnalité d'optimisation de la navigation dans l'historique appelée cache amélioré. Cela permet un chargement instantané lorsque les utilisateurs reviennent à une page qu'ils ont déjà consultée. Des pages peuvent être bloquées et supprimées du cache amélioré pour différentes raisons. Certaines sont requises par une spécification ou spécifiques à une implémentation de navigateur.

Auparavant, les développeurs n'avaient aucun moyen de savoir pourquoi l'utilisation du cache amélioré sur le terrain était bloquée. Toutefois, un test dans les outils de développement Chrome était disponible. Pour permettre la surveillance dans le champ, la classe PerformanceNavigationTiming a été étendue pour inclure une propriété notRestoredReasons. Cette opération renvoie un objet contenant des informations associées sur tous les frames présents dans le document:

  • Des détails tels que le cadre id et name, pour faciliter leur identification dans le code HTML
  • Indique si le cache amélioré a été bloqué.

  • Raisons pour lesquelles l'utilisation du cache amélioré a empêché l'utilisateur.

    Les développeurs peuvent ainsi prendre des mesures pour rendre ces pages compatibles avec le cache amélioré, améliorant ainsi les performances du site.

Exemples

Vous pouvez obtenir une instance PerformanceNavigationTiming à partir de fonctionnalités telles que Performance.getEntriesByType() et PerformanceObserver.

Par exemple, vous pouvez appeler la fonction suivante pour renvoyer tous les objets PerformanceNavigationTiming actuellement présents dans la timeline des performances et consigner leurs notRestoredReasons:

function returnNRR() {
  const navEntries = performance.getEntriesByType("navigation");
  for (let i = 0; i < navEntries.length; i++) {
    console.log(`Navigation entry ${i}`);
    let navEntry = navEntries[i];
    console.log(navEntry.notRestoredReasons);
  }
}

Pour les navigations à partir de l'historique, la propriété PerformanceNavigationTiming.notRestoredReasons renvoie un objet ayant la structure suivante, qui représente l'état bloqué du cadre de premier niveau:

{
  blocked: true,
  children: [],
  id: "",
  name: "",
  reasons: [ "Internal Error", "Unload handler" ],
  src: "",
  url: "a.com"
}

Les propriétés sont les suivantes:

blocked
Valeur booléenne indiquant si la page parcourue ne peut pas utiliser le cache amélioré (true) ou non (false).
children
Tableau d'objets représentant l'état bloqué de tous les frames intégrés dans le frame de premier niveau. Chaque objet possède la même structure que l'objet parent. Ainsi, n'importe quel nombre de niveaux de frames intégrés peut être représenté à l'intérieur de l'objet de manière récursive. Si le cadre n'a pas d'enfants, le tableau sera vide.
id
Chaîne représentant la valeur de l'attribut id du cadre (par exemple, <iframe id="foo" src="...">). Si le cadre n'a pas de id, la valeur sera une chaîne vide.
name
Chaîne représentant la valeur de l'attribut name du cadre (par exemple, <iframe name="bar" src="...">). Si le cadre n'a pas de name, la valeur sera une chaîne vide.
reasons
Tableau de chaînes représentant chacune la raison pour laquelle la page parcourue a été bloquée et ne peut plus utiliser le cache amélioré. Un blocage peut se produire pour de nombreuses raisons. Pour en savoir plus, consultez la section Motifs de blocage ci-dessous.
src
Chaîne représentant le chemin d'accès à la source du frame (par exemple, <iframe src="b.html">). Si le frame n'a pas de src, la valeur sera une chaîne vide.
url
Chaîne représentant l'URL de la page consultée.

Pour les objets PerformanceNavigationTiming qui ne représentent pas des navigations à partir de l'historique, la propriété notRestoredReasons renvoie null. Cela permet de déterminer si le cache amélioré n'est pas pertinent pour une navigation particulière, par opposition au fait que notRestoredReasons n'est pas pris en charge, auquel cas il renverrait undefined.

Signaler le blocage du cache amélioré dans les frames de même origine

Lorsqu'une page contient des frames de même origine intégrés, la valeur notRestoredReasons renvoyée contient un objet dans la propriété children représentant l'état bloqué de chaque frame intégré.

Exemple :

{
  blocked: false,
  children: [
    { url: "a.com", src: "b.a.com", id: "b", name: "b", blocked: false, reasons: [], children: [] },
    { url: "a.com", src: "c.a.com", id: "c", name: "c", blocked: true, reasons: [ "BroadcastChannel" ], children: [] },
    { url: "a.com", src: "d.a.com", id: "d", name: "d", blocked: false, reasons: [], children: [] }
  ],
  id: "",
  name: "",
  reasons: [],
  src: "",
  url:"a.com"
}

Signaler le blocage du cache amélioré dans les frames multi-origines

Lorsqu'une page contient des frames multi-origines intégrés, nous limitons la quantité d'informations partagées à leur sujet pour éviter les fuites d'informations multi-origines. Nous n'incluons que les informations déjà connues sur la page externe, et si la sous-arborescence multi-origine a bloqué le cache amélioré ou non. Nous n'incluons pas de motifs de blocage ni d'informations sur les niveaux inférieurs de la sous-arborescence (même si certains sous-niveaux ont la même origine).

Exemple :

{
  blocked: false,
  children: [
    { url: "a.com", src: "c.a.com", id: "c", name: "c", blocked: true, reasons: [ "ScreenReader" ], children: [] },
    /* cross-origin frame */
    { url: "", src: "b.com", id: "d", name: "d", blocked: true, reasons: [], children: [] }
  ],
  id: "",
  name: "",
  reasons: [],
  src: "",
  url:"a.com"
}

Si plusieurs frames multi-origines ont des raisons de blocage, nous sélectionnons au hasard un iFrame multi-origine et indiquons s'il bloque ou non le cache amélioré. Pour les autres frames, nous indiquons null pour la valeur blocked. L'objectif est d'empêcher les acteurs malintentionnés de déduire des informations sur l'état des utilisateurs sur les sites qu'ils ne contrôlent pas en intégrant plusieurs cadres tiers dans une page, puis en comparant les informations de blocage de chacun.

{
  blocked: false,
  children: [
    /* cross-origin frames */
    {url: "", src: "b.com", id: "b", name: "b", blocked: null, reasons: [], children: []},
    {url: "", src: "c.com", id: "c", name: "c", blocked: true, reasons: [], children: []},
    {url: "", src: "d.com", id: "d", name: "d", blocked: null, reasons: [], children: []}
  ]
  id: "",
  name: "",
  reasons: [],
  src: "",
  url:"a.com"
}

Pour en savoir plus sur les considérations liées à la sécurité et à la confidentialité, consultez la section Sécurité et confidentialité dans la vidéo d'explication.

Motifs de blocage

Comme nous l'avons vu précédemment, un blocage peut avoir lieu pour de nombreuses raisons. Nous avons compilé une feuille de calcul pratique montrant toutes les chaînes de raison et expliquant leur signification.

Il existe quelques grandes catégories de raisons qui méritent d'être soulignées:

  • Circumstantial: motifs de blocage qui ne sont pas directement liés au code de la page du développeur. Par exemple, un composant associé a planté, un problème est survenu lors du chargement, la page est dans un état temporaire qui ne peut pas être mis en cache, le cache amélioré est désactivé en raison d'une mémoire insuffisante ou un service worker a effectué une action qui empêche sa mise en cache.
  • Extensions: il existe plusieurs messages de raison différents liés aux extensions. En général, nous combinons plusieurs raisons différentes dans le motif "Extensions". Nous sommes délibérément vagues sur les motifs de blocage liés aux extensions, car nous ne voulons pas divulguer trop d'informations sur les extensions que l'utilisateur a installées, celles qui sont actives sur la page, ce qu'il fait, etc.
  • PageSupportNeeded: le code du développeur utilise une fonctionnalité de la plate-forme Web qui n'est pas bloquée par le cache amélioré. Or, son état actuel indique qu'il bloque le cache amélioré. Par exemple, la page dispose actuellement d'un BroadcastChannel avec des écouteurs enregistrés ou d'une connexion IndexedDB ouverte. Il se peut également que la page ait enregistré un gestionnaire unload, ce qui empêche actuellement l'utilisation du cache amélioré dans certains navigateurs.
  • SupportPending: le code du développeur utilise une fonctionnalité de plate-forme Web qui disqualifie la page du cache amélioré. Il peut s'agir, par exemple, de l'API Web Serial, de l'API Web Authentication, de l'API File System Access ou de l'API Media Session. Il se peut également que la page utilise Cache-Control: no-store, ce qui empêche actuellement l'utilisation du cache amélioré dans certains navigateurs. Cette catégorie permet également de signaler la présence d'un outil situé en dehors de la page et qui bloque le cache amélioré, comme un lecteur d'écran ou le gestionnaire de mots de passe de Chrome.

Commentaires

L'équipe Chromium souhaite connaître votre avis sur votre expérience avec l'API notRestoredReasons de mise en cache amélioré.

Décrivez-nous la conception de l'API.

Y a-t-il quelque chose dans l'API qui ne fonctionne pas comme prévu ? Ou manque-t-il des méthodes ou des propriétés dont vous avez besoin pour mettre en œuvre votre idée ? Vous avez une question ou un commentaire sur le modèle de sécurité ? Signalez un problème de spécification dans le [dépôt GitHub][commentaires] correspondant ou faites part de vos commentaires à un problème existant.

Signaler un problème d'implémentation

Avez-vous détecté un bug dans l'implémentation de Chromium ? Ou l'implémentation est-elle différente des spécifications ? Signalez un bug à l'adresse new.crbug.com. Veillez à inclure autant de détails que possible, ainsi que des instructions simples pour reproduire le problème, puis spécifiez le composant en tant que UI > Browser > Navigation > bfcache. Glitch est idéal pour partager des reproductions simples et rapides.

Afficher la compatibilité avec l'API

Comptez-vous utiliser l'API notRestoredReasons de mise en cache amélioré ? Votre assistance publique aide l'équipe Chromium à hiérarchiser les fonctionnalités et montre aux autres fournisseurs de navigateurs à quel point il est essentiel de les prendre en charge.

Envoyez un tweet à @ChromiumDev avec le hashtag #NotRestoredReasons, et indiquez-nous où et comment vous l'utilisez.

Liens utiles