Prérendu des pages dans Chrome pour la navigation instantanée sur les pages

Barry Pollard

Navigateurs pris en charge

• 109
• 109
• x
• x

L'équipe Chrome travaille actuellement sur des options permettant de rétablir le préchargement complet des futures pages auxquelles les utilisateurs sont susceptibles d'accéder.

Bref historique du prérendu

Auparavant, Chrome prenait en charge l'indice de ressource <link rel="prerender" href="/next-page">, mais il n'était pas largement pris en charge au-delà de Chrome et ce n'était pas une API très expressive.

Cet ancien prérendu utilisant l'optimisation rel=prerender du lien a été abandonné au profit de NoState Prefetch, qui récupérait les ressources nécessaires à la prochaine page, mais ne prérenduisait pas complètement la page ni n'exécutait JavaScript. NoState Prefetch améliore les performances des pages en améliorant le chargement des ressources, mais il n'effectue pas un chargement instantané de la page comme le ferait un prérendu complet.

L'équipe Chrome a maintenant réintroduit le prérendu complet dans Chrome. Pour éviter les complications liées à l'utilisation existante et pour permettre l'élargissement futur du prérendu, ce nouveau mécanisme de prérendu n'utilise pas la syntaxe <link rel="prerender"...>, qui reste en place pour le préchargement NoState Prefetch, avec la possibilité de supprimer cette syntaxe par la suite.

Comment une page est-elle préchargée ?

Une page peut être préchargée de l'une des quatre manières suivantes, qui visent toutes à accélérer la navigation:

1. Lorsque vous saisissez une URL dans la barre d'adresse de Chrome (également appelée "champ polyvalent"), Chrome peut précharger automatiquement la page pour vous si l'utilisateur a la certitude que vous allez la consulter.
2. Lorsque vous saisissez un terme de recherche dans la barre d'adresse de Chrome, la page des résultats de recherche peut être préchargée automatiquement, lorsque le moteur de recherche vous le demande.
3. Les sites peuvent utiliser l'API Speculation Rules pour indiquer de manière programmatique à Chrome les pages à précharger. Cela remplace <link rel="prerender"...> et permet aux sites de précharger de manière proactive une page en fonction de règles de spéculation sur la page. Ceux-ci peuvent exister de manière statique sur les pages ou être injectés de manière dynamique par JavaScript à la place du propriétaire de la page.

Dans chacun de ces cas, un prérendu se comporte comme si la page avait été ouverte dans un onglet en arrière-plan invisible, puis était "activé" en remplaçant l'onglet de premier plan par cette page prérendue. Si une page est activée avant qu'elle ne soit complètement prérendue, son état actuel apparaît au premier plan et continue de se charger. Vous pouvez donc prendre une bonne longueur d'avance.

Lorsque la page prérendue est ouverte dans un état masqué, un certain nombre d'API entraînant des comportements intrusifs (par exemple, des invites) ne sont pas activées dans cet état. Au lieu de cela, elles sont retardées jusqu'à ce que la page soit activée. Dans les quelques cas où cela n'est pas encore possible, le prérendu est annulé. L'équipe Chrome s'efforce d'exposer les motifs d'annulation du prérendu sous forme d'API. Elle améliore également les fonctionnalités des outils de développement afin de faciliter l'identification de ces cas particuliers.

Remarque:Les pages prérendues doivent être traitées comme une indication et une amélioration progressive. Contrairement à preload, le prérendu est un indice spéculatif, que le navigateur peut choisir de ne pas prendre en compte en fonction des paramètres de l'utilisateur, de l'utilisation de la mémoire actuelle ou d'autres heuristiques.

Impact du prérendu

Le prérendu permet un chargement quasi instantané des pages, comme illustré dans la vidéo suivante:

Exemple d'impact du prérendu.

L'exemple de site est déjà rapide, mais vous pouvez constater à quel point le prérendu améliore l'expérience utilisateur. Cela peut donc aussi avoir un impact direct sur les Core Web Vitals d'un site, avec un LCP quasiment nul, un CLS réduit (tout CLS de charge ayant lieu avant l'affichage initial) et un INP amélioré (puisque la charge doit être terminée avant que l'utilisateur n'interagisse).

Même lorsqu'une page s'active avant qu'elle ne soit complètement chargée, avoir une longueur d'avance dans le chargement de la page devrait améliorer l'expérience de chargement. Lorsqu'un lien est activé alors que le prérendu est toujours en cours, la page en prérendu passe au cadre principal et poursuit le chargement.

Toutefois, le prérendu utilise davantage de mémoire et de bande passante réseau. Veillez à ne pas trop effectuer un prérendu, au prix des ressources utilisateur. Le prérendu uniquement s'il est fort probable que la page soit consultée.

Consultez la section Mesurer les performances pour savoir comment mesurer l'impact réel sur les performances dans vos données analytiques.

Afficher les prédictions de la barre d'adresse de Chrome

Dans le premier cas d'utilisation, vous pouvez afficher les prédictions de Chrome pour les URL sur la page chrome://predictors:

Page des prédicteurs Chrome

Les lignes vertes indiquent un niveau de confiance suffisant pour déclencher le prérendu. Dans cet exemple, saisir "s" donne un niveau de confiance raisonnable (orange), mais une fois que vous saisissez "sh", Chrome est suffisamment sûr que vous accédez presque toujours à https://sheets.google.com.

Cette capture d'écran a été effectuée lors d'une installation de Chrome relativement récente, et les prédictions nulles ont été filtrées. Toutefois, si vous affichez vos propres prédicteurs, vous verrez probablement beaucoup plus d'entrées et potentiellement plus de caractères pour atteindre un niveau de confiance suffisamment élevé.

Ces prédicteurs sont également à l'origine des suggestions de la barre d'adresse que vous avez peut-être remarquées:

Fonctionnalité de saisie semi-automatique de la barre d'adresse.

Chrome met continuellement à jour ses prédictions en fonction de votre saisie et de vos sélections.

• Pour un niveau de confiance supérieur à 50 % (indiqué en orange), Chrome se connecte au domaine de manière proactive, mais ne précharge pas la page.
• Si le niveau de confiance est supérieur à 80 % (en vert), Chrome précharge l'URL.

API Speculation Rules

Avec la troisième option de prérendu, les développeurs Web peuvent insérer des instructions JSON dans leurs pages pour indiquer au navigateur les URL à précharger:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Ou par règles de document (disponible à partir de Chrome 121), qui précharge les liens trouvés dans le document en fonction de href ou des sélecteurs CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

Remarque :L'API Speculation Rules incluait une clé source définie sur list pour les URL de liste ou document pour les URL de document. Toutefois, comme cela peut être implicite en raison de la présence d'une clé urls ou where (qui s'excluent mutuellement), cette exigence a été supprimée de Chrome 121. Il est possible que cette clé source soit toujours utilisée sur certains sites ou que dans des exemples de code.

Impatient

Navigateurs pris en charge

• 121
• 121
• x
• x

Le paramètre eagerness permet d'indiquer à quel moment les spéculations doivent se déclencher, ce qui est particulièrement utile pour les règles de document:

• immediate:permet de spéculer dès que possible, c'est-à-dire dès que les règles de spéculation sont observées.
• eager:ce comportement se comporte de la même manière que le paramètre immediate, mais nous prévoyons de le placer à l'avenir entre immediate et moderate.
• moderate:des spéculations sont effectuées lorsque vous pointez sur un lien pendant 200 millisecondes (ou sur l'événement pointerdown s'il est antérieur, et sur un appareil mobile où il n'y a pas d'événement hover).
• conservative:spécule sur le pointeur ou l'atterrissage.

La valeur eagerness par défaut pour les règles list est immediate. Les options moderate et conservative permettent de limiter les règles list aux URL avec lesquelles un utilisateur interagit avec une liste spécifique. Toutefois, dans de nombreux cas, les règles document avec une condition where appropriée peuvent être plus appropriées.

La valeur eagerness par défaut pour les règles document est conservative. Étant donné qu'un document peut comporter de nombreuses URL, il convient d'utiliser immediate ou eager pour les règles document avec précaution (voir également la section Limites de Chrome ci-dessous).

Le paramètre eagerness à utiliser dépend de votre site. Pour un site statique et léger, une spéculation plus agressive peut s'avérer peu coûteuse et présenter un intérêt pour les utilisateurs. Les sites dotés d'architectures plus complexes et de charges utiles de page plus lourdes peuvent préférer réduire le gaspillage en spéculant moins souvent jusqu'à ce que vous obteniez un signal d'intention plus positif de la part des utilisateurs afin de limiter le gaspillage.

Attention :La surspéculation entraîne un coût évident pour les utilisateurs en termes de bande passante, de mémoire et de processeur, mais aussi pour les sites eux-mêmes. Tenez compte de l'impact que vous avez sur vos utilisateurs lorsque vous mettez en œuvre des spéculations. Les paramètres eagerness vous permettent de réduire le risque de spéculations inutiles. Chrome limite également les spéculations afin de réduire l'impact d'une utilisation excessive.

L'option moderate est un terrain d'entente. De nombreux sites pourraient bénéficier de la règle de spéculation suivante, qui prérendu tous les liens lorsque l'utilisateur pointe ou pointe sur l'écran en tant qu'implémentation basique, mais efficace, de règles de spéculation:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Préchargement

Les règles de spéculation peuvent également servir uniquement à précharger des pages, sans prérendu complet. Cela constitue souvent le premier pas vers le prérendu:

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Remarque:Contrairement à l'ancien indicateur de ressource <link rel="prefetch"> qui vient d'être préchargé dans le cache HTTP, les documents chargés à l'aide de règles de spéculation sont traités de la même manière que les navigations (mais pas affichées) et sont conservés en mémoire. Ils seront donc disponibles plus rapidement pour le navigateur en cas de besoin. Cela permet également de précharger les documents qui ne peuvent pas être mis en cache dans le cache HTTP. En raison de problèmes liés au préchargement de documents à l'aide de <link rel="prefetch">, nous vous recommandons d'utiliser des règles de spéculation pour ceux-ci à l'avenir, <link rel="prefetch"> n'étant utilisé que pour le préchargement des sous-ressources.

Limites de Chrome

Des limites ont été mises en place dans Chrome pour éviter toute utilisation excessive de l'API Speculation Rules:

impatience	Préchargement	Prérendu
immediate/eager	50	10
moderate/conservative	2 (FIFO)	2 (FIFO)

Limites de spéculation dans Chrome.

Les paramètres moderate et conservative, qui dépendent de l'interaction de l'utilisateur, fonctionnent selon le principe du premier entré, premier sorti (FIFO): une fois la limite atteinte, une nouvelle spéculation entraîne l'annulation de la spéculation la plus ancienne et son remplacement par la plus récente afin de préserver la mémoire. Une spéculation annulée peut être déclenchée à nouveau (par exemple, en pointant de nouveau sur ce lien), ce qui entraîne une nouvelle spéculation sur l'URL et renvoie la plus ancienne spéculation. Dans ce cas, la spéculation précédente mettra en cache toutes les ressources pouvant être mises en cache dans le cache HTTP pour cette URL. Par conséquent, la spéculation plus longue devrait avoir un coût réduit. C'est pourquoi la limite est définie sur le seuil modeste de 2. Les règles de liste statique ne sont pas déclenchées par une action de l'utilisateur. Elles ont donc une limite plus élevée, car le navigateur ne peut pas savoir quelles règles sont nécessaires ni à quel moment.

Les limites de immediate et eager sont également dynamiques. Par conséquent, la suppression d'un élément de script d'URL list crée de la capacité en annulant ces spéculations supprimées.

Chrome empêche également l'utilisation de spéculations dans certaines conditions, y compris les suivantes:

• Save-Data (Enregistrer les données) :
• Économiseur d'énergie lorsque la fonctionnalité est activée et que la batterie est faible.
• Contraintes de mémoire.
• Lorsque le paramètre "Précharger les pages" est désactivé (il est aussi explicitement désactivé par les extensions Chrome telles que uBlock Origin).
• Pages ouvertes dans des onglets en arrière-plan.

De plus, Chrome n'affiche pas les iFrames multi-origines sur les pages prérendues tant qu'ils ne sont pas activés.

Toutes ces conditions visent à réduire l'impact d'une spéculation excessive lorsqu'elle serait préjudiciable aux utilisateurs.

Inclure des règles de spéculation sur une page

Les règles de spéculation peuvent être incluses de manière statique dans le code HTML de la page ou insérées dynamiquement dans la page par JavaScript:

• Règles de spéculation incluses de manière statique: par exemple, un site de médias d'actualités ou un blog peut précharger le dernier article s'il s'agit souvent de la navigation suivante pour un grand nombre d'utilisateurs. Vous pouvez également utiliser des règles de document avec moderate ou conservative pour émettre des spéculations lorsque les utilisateurs interagissent avec les liens.
• Règles de spéculation insérées dynamiquement: elles peuvent être basées sur une logique d'application, personnalisées en fonction de l'utilisateur ou sur d'autres heuristiques.

Nous recommandons aux utilisateurs qui favorisent l'insertion dynamique d'après des actions telles que passer la souris ou cliquer sur un lien (comme de nombreuses bibliothèques l'ont déjà fait avec <link rel=prefetch>). Nous vous recommandons d'examiner les règles de document, car elles permettent au navigateur de gérer la plupart de vos cas d'utilisation.

Les règles de spéculation peuvent être ajoutées dans le <head> ou le <body> du frame principal. Les règles de spéculation dans les sous-frames ne sont pas appliquées, et les règles de spéculation dans les pages prérendues ne sont appliquées qu'une fois la page activée.

En-tête HTTP Speculation-Rules

Navigateurs pris en charge

• 121
• 121
• x
• x

Source

Les règles de spéculation peuvent également être transmises à l'aide d'un en-tête HTTP Speculation-Rules, au lieu de les inclure directement dans le code HTML du document. Cela facilite le déploiement par les CDN sans qu'il soit nécessaire de modifier le contenu des documents eux-mêmes.

L'en-tête HTTP Speculation-Rules est renvoyé avec le document et pointe vers l'emplacement d'un fichier JSON contenant les règles de spéculation:

Speculation-Rules: "/speculationrules.json"

Avertissement :Comme il s'agit d'un en-tête structuré, les guillemets sont importants et doivent être inclus dans la valeur de l'en-tête.

Cette ressource doit utiliser le type MIME approprié et, s'il s'agit d'une ressource multi-origine, réussir une vérification CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Si vous souhaitez utiliser des URL relatives, vous pouvez inclure la clé "relative_to": "document" dans vos règles de spéculation. Dans le cas contraire, les URL relatives seront relatives à l'URL du fichier JSON de règles de spéculation. Cela peut être particulièrement utile si vous devez sélectionner tous vos liens de même origine ou seulement certains d'entre eux.

Règles de spéculation et SPA

Les règles de spéculation ne sont compatibles qu'avec les navigations en pleine page gérées par le navigateur, et non avec les applications monopages (SPA) ni les pages shell d'application. Cette architecture n'utilise pas l'extraction de documents, mais plutôt l'API ou des récupérations partielles de données ou de pages, qui sont ensuite traitées et présentées sur la page actuelle. Les données nécessaires à ces "navigations douces" peuvent être préchargées par l'application en dehors des règles de spéculation, mais elles ne peuvent pas être prérendues.

Les règles de spéculation peuvent être utilisées pour précharger l'application elle-même à partir d'une page précédente. Cela permet de compenser une partie des coûts supplémentaires de chargement initial pratiqués par certaines SPA. Toutefois, les modifications de routage dans l'application ne peuvent pas être prérendues.

Déboguer les règles de spéculation

Consultez le post consacré au débogage des règles de spéculation pour en savoir plus sur les nouvelles fonctionnalités des outils pour les développeurs Chrome qui vous aideront à afficher et déboguer cette nouvelle API.

Règles de spéculation multiples

Plusieurs règles de spéculation peuvent également être ajoutées sur la même page et ajoutées aux règles existantes. Par conséquent, les différentes méthodes suivantes entraînent toutes deux un prérendu one.html et two.html:

Liste des URL:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

Plusieurs speculationrules:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Plusieurs listes dans un même ensemble de speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Assistance No-Vary-Search

Navigateurs pris en charge

• 121
• 121
• x
• x

Source

Lors du préchargement ou du préchargement d'une page, certains paramètres d'URL (techniquement appelés paramètres de recherche) peuvent être sans importance pour la page effectivement diffusée par le serveur. En outre, ils ne sont utilisés que par le code JavaScript côté client.

Par exemple, les paramètres UTM sont utilisés par Google Analytics pour mesurer les campagnes, mais ils n'entraînent généralement pas la diffusion de différentes pages depuis le serveur. Cela signifie que page1.html?utm_content=123 et page1.html?utm_content=456 vont diffuser la même page à partir du serveur, de sorte que la même page pourra être réutilisée à partir du cache.

De même, les applications peuvent utiliser d'autres paramètres d'URL qui ne sont gérés que côté client.

La proposition No-Vary-Search permet à un serveur de spécifier des paramètres qui n'entraînent pas de différence par rapport à la ressource fournie, et permet donc à un navigateur de réutiliser des versions précédemment mises en cache d'un document qui ne diffèrent que par ces paramètres. Cette option n'est disponible dans Chrome (et dans les navigateurs basés sur Chromium) que pour les spéculations de navigation en préchargement.

Les règles de spéculation prennent en charge l'utilisation de expects_no_vary_search pour indiquer où un en-tête HTTP No-Vary-Search doit être renvoyé. Vous éviterez ainsi davantage de téléchargements inutiles.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

Dans cet exemple, le code HTML de la page initiale de /products est identique pour les ID produit 123 et 124. Toutefois, le contenu de la page diffère finalement en fonction de l'affichage côté client, qui utilise JavaScript pour récupérer les données produit à l'aide du paramètre de recherche id. Nous préchargeons donc hâtivement cette URL, et elle devrait renvoyer un en-tête HTTP No-Vary-Search indiquant que la page peut être utilisée pour n'importe quel paramètre de recherche id.

Toutefois, si l'utilisateur clique sur l'un des liens avant la fin du préchargement, il est possible que le navigateur n'ait pas reçu la page /products. Dans ce cas, le navigateur ne sait pas s'il contiendra l'en-tête HTTP No-Vary-Search. Le navigateur peut ensuite choisir de récupérer à nouveau le lien ou d'attendre la fin du préchargement pour voir s'il contient un en-tête HTTP No-Vary-Search. Le paramètre expects_no_vary_search permet au navigateur de savoir que la réponse de la page doit contenir un en-tête HTTP No-Vary-Search et d'attendre la fin du préchargement.

Restrictions liées aux règles de spéculation et futures améliorations

Les règles de spéculation sont limitées aux pages ouvertes dans le même onglet, mais nous nous efforçons de réduire ces restrictions. Par défaut, le prérendu est limité aux pages de même origine.

Le prérendu de pages multi-origines sur le même site (par exemple, https://a.example.com pourrait précharger une page sur https://b.example.com). Pour l'utiliser, la page prérendue (https://b.example.com dans cet exemple) doit être activée en incluant un en-tête HTTP Supports-Loading-Mode: credentialed-prerender, sinon Chrome annulera le prérendu.

Les futures versions pourront également autoriser le prérendu pour les pages multi-origines (où le site active cette fonctionnalité avec un en-tête HTTP Supports-Loading-Mode: uncredentialed-prerender similaire) et activer le prérendu dans les nouveaux onglets.

Détecter la compatibilité avec l'API Speculation Rules

Vous pouvez activer la prise en charge de la détection de l'API Speculation Rules avec des vérifications HTML standards:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Ajouter des règles de spéculation de manière dynamique via JavaScript

Voici un exemple d'ajout d'une règle de spéculation prerender avec JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Vous pouvez regarder une démonstration du prérendu de l'API Speculation Rules à l'aide de l'insertion JavaScript sur cette page de démonstration du prérendu.

Annuler les règles de spéculation

La suppression des règles de spéculation entraînera l'annulation du prérendu, mais avant, les ressources auront probablement déjà été utilisées pour lancer le prérendu. Nous vous recommandons donc de ne pas effectuer de prérendu s'il est probable que vous deviez annuler le prérendu.

Règles de spéculation et Content Security Policy

Comme les règles de spéculation utilisent un élément <script>, même si elles ne contiennent que du JSON, elles doivent être incluses dans script-src Content-Security-Policy si le site l'utilise (à l'aide d'un hachage ou d'un nonce).

Un nouveau inline-speculation-rules peut être ajouté à script-src, ce qui permet de prendre en charge les éléments <script type="speculationrules"> injectés à partir de scripts de hachage ou de nonce. Cela n'est pas compatible avec les règles incluses dans le code HTML initial. Elles doivent donc être injectées par JavaScript pour les sites qui utilisent une CSP stricte.

Détecter et désactiver le prérendu

Le prérendu est généralement une expérience positive pour les utilisateurs, car il permet un rendu des pages rapide, souvent instantané. Cela profite à la fois à l'utilisateur et au propriétaire du site, car les pages prérendues offrent une meilleure expérience utilisateur qui pourrait être difficile à obtenir autrement.

Toutefois, il peut arriver que vous ne souhaitiez pas que certaines pages soient préchargées, par exemple lorsque leur état change (en fonction de la requête initiale ou de l'exécution du code JavaScript sur la page).

Activer et désactiver le prérendu dans Chrome

Le prérendu n'est activé que pour les utilisateurs de Chrome dont le paramètre "Précharger les pages" est défini dans chrome://settings/performance/. De plus, le prérendu est également désactivé sur les appareils à faible mémoire, ou si le système d'exploitation est en mode Économies de données ou Économiseur d'énergie. Consultez la section Limites de Chrome.

Détecter et désactiver le prérendu côté serveur

Les pages prérendues seront envoyées avec l'en-tête HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

Pour les pages préchargées à l'aide de l'API Speculation Rules, cet en-tête sera uniquement défini sur prefetch:

Sec-Purpose: prefetch

Les serveurs peuvent répondre en fonction de cet en-tête pour consigner les requêtes de spéculation, renvoyer des contenus différents ou empêcher un prérendu. Si un code de réponse indiquant un échec (c'est-à-dire autre que 200 ou 304) est renvoyé, la page n'est pas prérendue et toute page de préchargement est supprimée.

Si vous ne voulez pas qu'une page spécifique soit préchargée, c'est le meilleur moyen de vous assurer que cela ne se produira pas. Toutefois, pour une expérience optimale, nous vous recommandons d'autoriser plutôt le prérendu, mais de retarder les actions qui ne devraient se produire que lorsque la page est effectivement affichée, à l'aide de JavaScript.

Détecter le prérendu en JavaScript

L'API document.prerendering renvoie true pendant le prérendu de la page. Il permet aux pages d'empêcher ou de retarder certaines activités pendant le prérendu jusqu'à ce que la page soit réellement activée.

Une fois qu'un document prérendu est activé, le activationStart de PerformanceNavigationTiming est également défini sur une durée non nulle représentant le moment entre le début du prérendu et le moment où le document a été réellement activé.

Vous pouvez utiliser une fonction permettant de vérifier la présence de pages prérendues et prérendues comme ceci:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

Le moyen le plus simple de voir si une page a été prérendue est d'ouvrir les outils de développement une fois le prérendu s'est produit, puis de saisir performance.getEntriesByType('navigation')[0].activationStart dans la console. Si une valeur non nulle est renvoyée, vous savez que la page a été prérendue:

Tester le prérendu dans la console

Conseil:D'autres fonctionnalités de débogage des outils pour les développeurs Chrome sont disponibles pour déboguer les pages préchargées et prérendues. Pour en savoir plus, consultez Déboguer les règles de spéculation.

Lorsque la page est activée par l'utilisateur qui la consulte, l'événement prerenderingchange est déclenché au document. Cet événement peut ensuite être utilisé pour activer des activités qui étaient lancées par défaut au moment du chargement de la page, mais que vous souhaitez retarder jusqu'à ce que la page soit réellement vue par l'utilisateur.

Grâce à ces API, le code JavaScript de l'interface peut détecter les pages prérendues et agir en conséquence.

Avertissement:PerformanceNavigationTiming.type n'utilise pas la valeur prerender, qui correspond à l'ancien type de navigation <link rel="prerender"...> d'origine. Cela est susceptible de changer à l'avenir, mais pour l'instant, les clients doivent utiliser l'API document.prerendering pour identifier les pages en prérendu et un champ PerformanceNavigationTiming.activationStart non nul pour identifier les pages prérendues qui ont depuis été activées.

Impact sur les données analytiques

Analytics permet de mesurer l'utilisation du site Web (par exemple, Google Analytics pour mesurer les pages vues et les événements). Vous pouvez également mesurer les métriques de performances des pages à l'aide de Real User Monitoring (RUM).

Les pages ne doivent être préchargées que lorsqu'il est très probable qu'elles soient chargées par l'utilisateur. C'est pourquoi les options de préchargement de la barre d'adresse Chrome ne sont disponibles que lorsqu'il existe une probabilité aussi élevée (dans plus de 80% des cas).

Toutefois, en particulier lors de l'utilisation de l'API Speculation Rules, les pages prérendues peuvent avoir un impact sur les données analytiques, et les propriétaires de sites peuvent avoir besoin d'ajouter du code pour n'activer l'analyse que pour les pages prérendues lors de l'activation. En effet, tous les fournisseurs de solutions d'analyse ne le font pas par défaut.

Remarque:Par défaut, Google Analytics gère le prérendu en retardant l'activation jusqu'à l'activation. De la même manière, Google Publisher Tag (GPT) et Google AdSense retardent l'activation jusqu'à leur activation.

Pour ce faire, vous pouvez utiliser un Promise qui attend l'événement prerenderingchange si un document est en prérendu, ou qui se résout immédiatement s'il est maintenant:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve);
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Évaluer les performances

Pour mesurer les métriques de performances, Analytics doit déterminer s'il est préférable de les mesurer en fonction du temps d'activation plutôt que du temps de chargement de la page qui sera signalé par les API de navigateur.

Les métriques Core Web Vitals, mesurées par Chrome via le rapport d'expérience utilisateur Chrome, visent à mesurer l'expérience utilisateur. Elles sont donc mesurées en fonction du temps d'activation. Par exemple, cela donne souvent un LCP de 0 seconde, ce qui montre qu'il s'agit d'un excellent moyen d'améliorer vos Core Web Vitals.

Depuis la version 3.1.0, la bibliothèque web-vitals a été mise à jour pour gérer les navigations prérendues de la même manière que Chrome mesure les Core Web Vitals. Cette version signale également les navigations prérendues pour ces métriques dans l'attribut Metric.navigationType.

Mesurer les prérendus

Si une page est prérendue peut être vue avec une entrée activationStart non nulle de PerformanceNavigationTiming. Elle peut ensuite être consignée à l'aide d'une dimension personnalisée ou d'une dimension similaire lors de la journalisation des pages vues, par exemple à l'aide de la fonction pagePrerendered décrite précédemment:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

Cela permettra à vos données analytiques de montrer combien de navigations sont prérendues par rapport à d'autres types de navigation, et vous permettra également de corréler les métriques de performance ou d'activité avec ces différents types de navigation. Des pages plus rapides signifient des utilisateurs plus satisfaits, ce qui peut souvent avoir un réel impact sur les mesures commerciales, comme le montrent nos études de cas.

Lorsque vous mesurez l'impact commercial du prérendu des pages pour les navigations instantanées, vous pouvez décider s'il est utile d'investir davantage dans l'utilisation de cette technologie pour permettre le prérendu d'un plus grand nombre de navigations ou pour déterminer pourquoi les pages ne sont pas prérendues.

Mesurer les taux de succès

En plus de mesurer l'impact des pages consultées après un prérendu, il est également important de mesurer les pages qui sont prérendues et pas consultées par la suite. Cela peut signifier que vous effectuez trop de préchargements et que vous utilisez de précieuses ressources de l'utilisateur pour peu d'avantages.

Pour ce faire, vous pouvez déclencher un événement d'analyse lorsque des règles de spéculation sont insérées (après vérification que le navigateur accepte le prérendu à l'aide de HTMLScriptElement.supports('speculationrules')) pour indiquer que le prérendu a été demandé. Notez que même si un prérendu a été demandé, cela n'indique pas qu'un prérendu a commencé ou s'est terminé. En effet, comme indiqué précédemment, le prérendu est une indication au navigateur, qui peut choisir de ne pas précharger les pages en fonction des paramètres utilisateur, de l'utilisation de la mémoire actuelle ou d'autres méthodes heuristiques.

Vous pouvez ensuite comparer le nombre de ces événements au nombre réel de pages vues en prérendu. Vous pouvez également déclencher un autre événement lors de l'activation si cela permet de comparer plus facilement les résultats.

Le "taux de succès de succès" peut être estimé en examinant la différence entre ces deux chiffres. Pour les pages où vous utilisez l'API Speculation Rules pour les précharger, vous pouvez ajuster les règles en conséquence pour vous assurer de conserver un taux d'accès élevé afin de maintenir un équilibre entre l'utilisation des ressources des utilisateurs pour les aider et leur utilisation inutile.

Sachez que certains prérendu peuvent être dus au prérendu de la barre d'adresse et pas seulement à vos règles de spéculation. Vous pouvez vérifier le document.referrer (qui sera vide pour la navigation dans la barre d'adresse, y compris les navigations de la barre d'adresse prérendues) si vous souhaitez les différencier.

N'oubliez pas d'examiner également les pages qui n'ont pas de prérendu, car cela pourrait indiquer qu'elles ne sont pas éligibles au prérendu, même à partir de la barre d'adresse. Cela signifie peut-être que vous ne bénéficiez pas de cette amélioration des performances. L'équipe Chrome souhaite ajouter des outils supplémentaires pour vérifier l'éligibilité au prérendu, peut-être semblables à l'outil de test du cache amélioré. L'équipe Chrome souhaite également ajouter une API pour indiquer pourquoi un prérendu a échoué.

Impact sur les extensions

Consultez l'article dédié sur Chrome Extensions: Extending API to support Instant Navigation (Extensions Google Chrome : étendre l'API pour permettre la navigation instantanée) qui détaille certaines considérations supplémentaires auxquelles les auteurs d'extensions peuvent se poser pour les pages prérendues.

Commentaires

Le prérendu est en cours de développement par l'équipe Chrome, et de nombreux projets prévoit d'étendre le champ d'application de la version 108 de Chrome. N'hésitez pas à nous faire part de vos commentaires sur le dépôt GitHub ou sur notre outil de suivi des problèmes. Nous avons hâte de découvrir et de partager des études de cas sur cette nouvelle API très intéressante.

Liens associés

• Déboguer les règles de spéculation
• Présentation du préchargement NoState
• API Speculation Rules
• Dépôt GitHub de spéculation Navigational
• Extensions Chrome: API étendue pour la navigation instantanée

Remerciements

Vignette de Marc-Olivier Jodoin sur Unsplash