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

Barry Pollard

Navigateurs pris en charge

  • Chrome : 109.
  • Edge : 109.
  • Firefox: non compatible.
  • Safari : non compatible.

L'équipe Chrome a rétabli le préchargement complet des futures pages susceptibles d'être consultées par les utilisateurs.

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 compatible avec plus de Chrome et n'était pas une API très expressive.

Ce prérendu obsolète à l'aide de l'indice de lien rel=prerender a été abandonné au profit du préchargement sans état, qui récupère à la place les ressources nécessaires à la future page, mais ne la prérend pas entièrement ni n'exécute JavaScript. Le préchargement NoState permet d'améliorer les performances des pages en améliorant le chargement des ressources, mais ne permet pas de charger les pages instantanément comme le ferait un prérendu complet.

L'équipe Chrome a réintroduit le prérendu complet dans Chrome. Pour éviter les complications liées à l'utilisation existante et permettre une future extension du prérendu, ce nouveau mécanisme de prérendu n'utilisera pas la syntaxe <link rel="prerender"...>, qui reste en place pour le préchargement sans état, avec l'objectif de l'abandonner à terme.

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

Une page peut être pré-rendue de l'une des quatre manières suivantes, toutes visant à accélérer la navigation:

  1. Lorsque vous saisissez une URL dans la barre d'adresse de Chrome (également appelée "omnibox"), Chrome peut précharger automatiquement la page pour vous, s'il est très confiant que vous allez y accéder, en fonction de votre historique de navigation précédent.
  2. Lorsque vous utilisez la barre de favoris, Chrome peut précharger automatiquement la page en maintenant le curseur sur l'un des boutons des favoris.
  3. Lorsque vous saisissez un terme de recherche dans la barre d'adresse de Chrome, Chrome peut pré-afficher automatiquement la page de résultats de recherche, lorsque le moteur de recherche lui demande de le faire.
  4. Les sites peuvent utiliser l'API Speculation Rules pour indiquer à Chrome de manière programmatique les pages à précharger. Cette fonctionnalité remplace ce que <link rel="prerender"...> faisait auparavant et permet aux sites de prérendre de manière proactive une page en fonction des règles de spéculation sur la page. Ils peuvent exister de manière statique sur les pages ou être injectés de manière dynamique par JavaScript selon le bon vouloir 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 d'arrière-plan invisible, puis est "activé" en remplaçant l'onglet de premier plan par cette page prérendu. Si une page est activée avant d'avoir été entièrement prérendue, son état actuel est "au premier plan" et continue de se charger. Vous pouvez donc toujours prendre une bonne longueur d'avance.

Comme la page prérendue est ouverte dans un état masqué, un certain nombre d'API qui provoquent des comportements intrusifs (par exemple, les requêtes) ne sont pas activées dans cet état, mais sont retardées jusqu'à ce que la page soit activée. Dans les rares cas où cela n'est pas encore possible, le prérendu est annulé. L'équipe Chrome travaille à exposer les raisons d'annulation du préchargement en tant qu'API, et à améliorer les fonctionnalités de DevTools pour faciliter l'identification de ces cas particuliers.

Impact du prérendu

Le prérendu permet de charger la page presque instantanément, comme illustré dans la vidéo suivante :

Exemple d'impact du prérendu.

L'exemple de site est déjà rapide, mais vous pouvez voir comment le préchargement améliore l'expérience utilisateur. Cela peut donc également avoir un impact direct sur les Core Web Vitals d'un site, avec un LCP proche de zéro, un CLS réduit (puisque tout CLS de chargement se produit avant l'affichage initial) et un INP amélioré (puisque le chargement doit être terminé avant que l'utilisateur n'interagisse).

Même lorsqu'une page s'active avant d'être entièrement chargée, le fait de bénéficier d'une longueur d'avance sur le chargement de la page devrait améliorer l'expérience de chargement. Lorsqu'un lien est activé pendant le prérendu, la page prérendue est déplacée vers le frame principal et continue de se charger.

Toutefois, le prérendu utilise davantage de mémoire et de bande passante réseau. Veillez à ne pas prérendre trop de données, au détriment des ressources de l'utilisateur. Ne prérendre que lorsque la probabilité d'accès à la page est élevée.

Pour en savoir plus sur la mesure de l'impact réel sur les performances dans vos données analytiques, consultez la section Mesurer les performances.

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

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

Page des prédicteurs Chrome filtrée pour afficher les prédictions faibles (gris), moyennes (ambre) et élevées (vert) en fonction du texte saisi.
Page des prédicteurs Chrome.

Les lignes vertes indiquent un niveau de confiance suffisant pour déclencher le prérendu. Dans cet exemple, taper "s" donne un niveau de confiance raisonnable (ambre), mais une fois que vous avez saisi "sh", Chrome est suffisamment confiant pour que vous accédiez presque toujours à https://sheets.google.com.

Cette capture d'écran a été prise sur une installation relativement récente de Chrome et filtre les prédictions de confiance nulle. Toutefois, si vous consultez vos propres prédicteurs, vous verrez probablement beaucoup plus d'entrées et, potentiellement, plus de caractères requis pour atteindre un niveau de confiance suffisamment élevé.

Ces indicateurs sont également ce qui motivent les options suggérées dans la barre d'adresse que vous avez peut-être remarquées:

Fonctionnalité de prévisualisation de la barre d&#39;adresse de Chrome
Fonctionnalité de prévisualisation de la barre d'adresse.

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

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

API Speculation Rules

Pour l'option de prérendu de l'API Speculation Rules, les développeurs Web peuvent insérer des instructions JSON sur leurs pages afin d'indiquer au navigateur les URL à prérendu:

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

Vous pouvez également utiliser des règles de document (disponibles à partir de Chrome 121), qui prégénèrent les liens trouvés dans le document en fonction de sélecteurs href (basés sur l'API URL Pattern) ou de sélecteurs CSS :

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

L'équipe Chrome a préparé un atelier de programmation sur les règles de spéculation qui vous expliquera comment ajouter des règles de spéculation à un site.

Impatience

Navigateurs pris en charge

  • Chrome : 121.
  • Edge : 121.
  • Firefox : non compatible.
  • Safari : non compatible.

Un paramètre eagerness est utilisé pour indiquer quand les spéculations doivent se déclencher, ce qui est particulièrement utile pour les règles de document:

  • immediate : permet de spéculer le plus tôt possible, c'est-à-dire dès que les règles de spéculation sont observées.
  • eager : comportement identique à celui du paramètre immediate, mais nous allons, à l'avenir, chercher à le placer quelque part entre immediate et moderate.
  • moderate:cette méthode effectue des spéculations si vous maintenez le pointeur sur un lien pendant 200 millisecondes (ou sur l'événement pointerdown s'il est plus tôt et sur les appareils mobiles où il n'y a pas d'événement hover).
  • conservative : spécule en cas d'événement tactile ou avec pointeur.

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 à 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 contenir de nombreuses URL, l'utilisation de immediate ou de eager pour les règles document doit être utilisée avec prudence (voir également la section Limites de Chrome ci-dessous).

Le paramètre eagerness à utiliser dépend de votre site. Pour un site statique léger, la spéculation peut avoir peu de coût et être bénéfique pour les utilisateurs. Les sites avec des architectures plus complexes et des 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 plus positif de la part des utilisateurs pour limiter le gaspillage.

L'option moderate est un compromis. De nombreux sites pourraient bénéficier de la règle de spéculation suivante, qui prérendrait un lien lorsque l'utilisateur maintient le pointeur sur le lien pendant 200 millisecondes ou lors de l'événement pointerdown, comme une implémentation de base, mais puissante, des 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 être utilisées pour précharger uniquement des pages, sans prérendu complet. Il s'agit souvent d'une bonne première étape vers le prérendu :

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

Limites de Chrome

Chrome a mis en place des limites pour éviter une utilisation abusive de l'API Speculation Rules:

empressement 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 de manière FIFO (First In, First Out) : 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 pour économiser de la mémoire. Une spéculation annulée peut être déclenchée à nouveau (par exemple, en pointant à nouveau sur le lien), ce qui entraînera une nouvelle spéculation sur l'URL, remplaçant la spéculation la plus ancienne. 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 d'un délai supplémentaire devrait entraîner une réduction du coût. C'est pourquoi la limite est fixée à un seuil modeste de deux. Les règles de liste statiques 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 lesquelles sont nécessaires et quand.

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

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

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

Chrome n'affiche pas non plus les iFrames multi-origines sur les pages prérendues tant que l'activation n'est pas effectuée.

Toutes ces conditions visent à réduire l'impact de la sur-spéculation lorsqu'elle est 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 de manière dynamique dans la page par JavaScript :

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

Si vous préférez l'insertion dynamique en fonction d'actions telles que le survol ou le clic sur un lien (comme de nombreuses bibliothèques l'ont fait par le passé avec <link rel=prefetch>), nous vous recommandons d'examiner les règles de document, car elles permettent au navigateur de gérer de nombreux cas d'utilisation.

Vous pouvez ajouter des règles de spéculation dans le <head> ou le <body> du frame principal. Les règles de spéculation dans les sous-cadres 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

  • Chrome : 121.
  • Edge : 121.
  • Firefox : non compatible.
  • Safari: non compatible.

Source

Les règles de spéculation peuvent également être transmises à l'aide d'un en-tête HTTP Speculation-Rules, plutôt que d'être incluses directement dans le code HTML du document. Cela permet aux CDN de déployer plus facilement les documents sans avoir à modifier leur contenu.

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"

Cette ressource doit utiliser le bon type MIME et, s'il s'agit d'une ressource multi-origine, passer 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. Sinon, les URL relatives seront relatives à l'URL du fichier JSON des règles de spéculation. Cela peut être particulièrement utile si vous devez sélectionner certains (ou tous) liens de même origine.

Règles de spéculation et SPA

Les règles de spéculation ne sont compatibles qu'avec les navigations de page complète gérées par le navigateur, et non avec les pages d'application shell ou d'application monopage (SPA). Ces architectures n'utilisent pas de récupération de documents, mais effectuent des récupérations partielles ou par API 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 logicielles" peuvent être préchargées par l'application en dehors des règles de spéculation, mais elles ne peuvent pas être préchargées.

Les règles de spéculation peuvent être utilisées pour pré-afficher l'application elle-même à partir d'une page précédente. Cela peut aider à compenser certains des coûts de chargement initiaux supplémentaires de certaines SPA. Toutefois, les modifications de parcours dans l'application ne peuvent pas être prérendues.

Déboguer des règles de spéculation

Consultez l'article dédié au débogage des règles d'extrapolation pour découvrir les nouvelles fonctionnalités des outils pour les développeurs Chrome qui vous aideront à afficher et à déboguer cette nouvelle API.

Plusieurs règles de spéculation

Vous pouvez également ajouter plusieurs règles de spéculation à la même page. Elles s'ajoutent aux règles existantes. Par conséquent, les différentes méthodes suivantes entraînent toutes un prérendu de one.html et de two.html :

Liste des URL :

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

Plusieurs scripts speculationrules :

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

Plusieurs éléments dans un ensemble de speculationrules

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

Navigateurs pris en charge

  • Chrome : 121.
  • Edge : 121.
  • Firefox : non compatible.
  • Safari : non compatible.

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 ne pas avoir d'importance pour la page réellement diffusée par le serveur et 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 ne génèrent généralement pas la diffusion d'une page différente sur le serveur. Cela signifie que page1.html?utm_content=123 et page1.html?utm_content=456 diffusent la même page à partir du serveur. La même page peut donc ê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 ne modifient pas la ressource fournie, et donc de permettre à un navigateur de réutiliser les versions précédemment mises en cache d'un document qui ne diffèrent que par ces paramètres. Cette fonctionnalité est compatible avec Chrome (et les navigateurs basés sur Chromium) pour les spéculations de navigation préchargement (bien que nous souhaitions la prendre en charge également pour le prérendu).

Les règles de spéculation permettent d'utiliser expects_no_vary_search pour indiquer où un en-tête HTTP No-Vary-Search doit être renvoyé. Cela peut vous aider à éviter les 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 /products est identique pour les ID de produit 123 et 124. Cependant, le contenu de la page finit par varier en fonction de l'affichage côté client, qui utilise JavaScript pour extraire les données produit à l'aide du paramètre de recherche id. Nous préchargeons donc cette URL de manière anticipée. Elle doit 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 a alors le choix entre récupérer à nouveau le lien ou 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 de cette précharge.

Restrictions et améliorations futures pour les règles de spéculation

Les règles de spéculation sont limitées aux pages ouvertes dans le même onglet, mais nous mettons tout en œuvre pour réduire cette restriction.

Par défaut, les spéculations sont limitées aux pages de même origine. Spéculation des pages de même origine et de même site (par exemple, https://a.example.com peut prérendre une page sur https://b.example.com). Pour utiliser cette fonctionnalité, la page spéculée (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 la spéculation.

Les futures versions pourront également autoriser le prérendu pour les pages multi-origines qui ne sont pas sur le même site, à condition que les cookies n'existent pas pour la page prérendue et que la page prérendue soit activée avec un en-tête HTTP Supports-Loading-Mode: uncredentialed-prerender similaire.

Les règles de spéculation acceptent déjà les préchargements inter-origines, mais encore une fois, uniquement lorsque les cookies du domaine inter-origine n'existent pas. Si des cookies existent et que l'utilisateur a déjà visité ce site, la spéculation ne sera pas déclenchée et une erreur s'affichera dans DevTools.

Compte tenu de ces limites actuelles, un modèle qui peut améliorer l'expérience utilisateur pour les liens internes et externes, dans la mesure du possible, consiste à prérendre les URL de même origine et à tenter de précharger les URL multi-origine:

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

Pour des raisons de sécurité, la restriction qui vise à empêcher les spéculations multi-origines pour les liens multi-origines est nécessaire par défaut. Il s'agit d'une amélioration par rapport à <link rel="prefetch"> pour les destinations multi-origines, qui n'envoient pas non plus de cookies, mais qui tentent tout de même le préchargement. Cela peut entraîner un préchargement gaspillé qui doit être renvoyé ou, pire encore, un chargement incorrect de la page.

Les règles de spéculation ne sont pas compatibles avec le préchargement des pages contrôlées par des service workers. Nous mettons tout en œuvre pour que cette fonctionnalité soit disponible. Pour en savoir plus, consultez ce problème d'assistance concernant les service workers. Le préchargement est compatible avec les pages contrôlées par un service worker.

Détecter la prise en charge de l'API Speculation Rules

Vous pouvez détecter la prise en charge de l'API Speculation Rules à l'aide de 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 voir 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.

Insérer un élément <script type = "speculationrules"> directement dans le DOM à l'aide de innerHTML n'enregistre pas les règles de spéculation pour des raisons de sécurité. Cet élément doit être ajouté comme indiqué précédemment. Toutefois, le contenu inséré dynamiquement à l'aide de innerHTML qui contient de nouveaux liens sera détecté par les règles existantes de la page.

De même, le fait de modifier directement le panneau Elements dans les outils pour les développeurs Chrome afin d'ajouter l'élément <script type = "speculationrules"> n'enregistre pas les règles de spéculation. À la place, le script qui les ajoute dynamiquement au DOM doit être exécuté depuis la console pour insérer les règles.

Ajouter des règles de spéculation via un gestionnaire de balises

Pour ajouter des règles de spéculation à l'aide d'un gestionnaire de balises tel que Google Tag Manager (GTM), vous devez les insérer via JavaScript, et non en ajoutant directement l'élément <script type = "speculationrules"> via GTM, pour les mêmes raisons que celles mentionnées précédemment :

Configuration de balises HTML personnalisées dans Google Tag Manager
Ajouter des règles de spéculation via Google Tag Manager

Notez que cet exemple utilise var, car GTM n'est pas compatible avec const.

Annuler les règles de spéculation

Si vous supprimez les règles de spéculation, le prérendu sera annulé. Toutefois, à ce stade, des ressources auront probablement déjà été dépensées pour lancer le prérendu. Il est donc recommandé de ne pas effectuer de prérendu si vous risquez d'avoir à l'annuler.

Règles de spéculation et Content Security Policy

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

Vous pouvez ajouter un nouveau inline-speculation-rules à script-src pour prendre en charge les éléments <script type="speculationrules"> injectés à partir de scripts hachés ou avec nonce. Cette méthode n'est pas compatible avec les règles incluses dans le code HTML initial. Par conséquent, les règles doivent ê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 affichage rapide des pages, 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 le prérendu des pages soit effectué, par exemple lorsque les pages changent d'état, soit en fonction de la requête initiale, soit en fonction de l'exécution du code JavaScript sur la page.

Activer et désactiver le préchargement dans Chrome

Le prérendu n'est activé que pour les utilisateurs de Chrome ayant le paramètre "Précharger les pages" dans chrome://settings/performance/. De plus, le prérendu est également désactivé sur les appareils dont la mémoire est limitée ou si le système d'exploitation est en mode Économiseur 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 sont 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 est défini sur prefetch uniquement :

Sec-Purpose: prefetch

Les serveurs peuvent répondre en fonction de cet en-tête pour consigner les requêtes de spéculation, renvoyer un contenu différent ou empêcher un prérendu. Si un code de réponse final autre que "success" est renvoyé (c'est-à-dire qu'il n'est pas compris entre 200 et 299 après les redirections), la page ne sera pas pré-rendue et toute page de préchargement sera supprimée. Notez également que les réponses 204 et 205 ne sont pas valides pour le prérendu, mais le sont pour le préchargement.

Si vous ne souhaitez pas qu'une page spécifique soit préchargée, le meilleur moyen d'éviter cela est de renvoyer un code de réponse autre que 2XX (par exemple, 503). Toutefois, pour offrir la meilleure expérience possible, nous vous recommandons d'autoriser le préchargement, mais de retarder les actions qui ne doivent se produire que lorsque la page est réellement consulté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. Les pages peuvent l'utiliser pour empêcher, ou 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é, la valeur activationStart de PerformanceNavigationTiming est également définie sur une durée non nulle représentant le délai entre le début du prérendu et l'activation effective du document.

Vous pouvez créer une fonction pour vérifier le préchargement et les pages préchargées, comme suit:

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

Le moyen le plus simple de savoir si une page a été prérendu (en totalité ou partiellement) consiste à ouvrir DevTools une fois la page activée, puis à 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 :

Console dans Chrome DevTools affichant un activationStart positif, ce qui indique que la page a été prérendu
Test du prérendu dans la console

Lorsque l'utilisateur consulte la page, l'événement prerenderingchange est distribué sur document, qui peut ensuite être utilisé pour activer les activités qui étaient auparavant démarrées par défaut au chargement de la page, mais que vous souhaitez retarder jusqu'à ce que l'utilisateur consulte réellement la page.

Grâce à ces API, le code JavaScript du frontend peut détecter et traiter les pages prérendues de manière appropriée.

Impact sur les données analytiques

Analytics sont utilisés pour mesurer l'utilisation du site Web, par exemple en utilisant 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 la surveillance des utilisateurs réels (RUM).

Les pages ne doivent être prérendues que lorsqu'il y a une forte probabilité qu'elles soient chargées par l'utilisateur. C'est pourquoi les options de préchargement de la barre d'adresse Chrome ne s'appliquent que lorsque la probabilité est élevée (plus de 80 % du temps).

Toutefois, en particulier lorsque vous utilisez l'API Speculation Rules, les pages prérendues peuvent avoir un impact sur les données analytiques. Les propriétaires de sites peuvent donc avoir besoin d'ajouter du code supplémentaire pour n'activer les données analytiques que pour les pages prérendues lors de l'activation, car tous les fournisseurs d'analyse ne le font pas par défaut.

Pour ce faire, utilisez un Promise qui attend l'événement prerenderingchange si un document est en prérendu ou 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, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

Une autre approche consiste à retarder les activités analytiques jusqu'à ce que la page soit d'abord visible, ce qui couvrirait à la fois le prérendu et lorsque des onglets sont ouverts en arrière-plan (par exemple, avec un clic droit et en s'ouvrant dans un nouvel onglet):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

Bien que cela puisse être pertinent pour les analyses et les cas d'utilisation similaires, vous souhaiterez peut-être charger plus de contenu dans certains cas. Vous pouvez donc utiliser document.prerendering et prerenderingchange pour cibler spécifiquement les pages de préchargement.

Retenir d'autres contenus pendant le prérendu

Les mêmes API que celles décrites précédemment peuvent être utilisées pour retenir d'autres contenus pendant la phase de prérendu. Il peut s'agir de parties spécifiques de JavaScript ou d'éléments de script entiers que vous préférez ne pas exécuter pendant la phase de prérendu.

Prenons l'exemple suivant :

<script src="https://example.com/app/script.js" async></script>

Vous pouvez remplacer cela par un élément de script inséré dynamiquement qui ne s'insère que sur la base de la fonction whenActivated précédente :

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Cela peut être utile pour retenir des scripts distincts qui incluent des données analytiques ou pour afficher du contenu en fonction de l'état ou d'autres variables pouvant changer au cours d'une visite. Par exemple, les recommandations, l'état de connexion ou les icônes du panier peuvent être masquées pour s'assurer que les informations les plus récentes sont présentées.

Bien que cela soit peut-être plus susceptible de se produire avec le prérendu, ces conditions sont également vraies pour les pages chargées dans les onglets en arrière-plan mentionnés précédemment (la fonction whenFirstVisible peut donc être utilisée à la place de whenActivated).

Dans de nombreux cas, l'état doit idéalement également être vérifié pour les modifications générales de visibilitychange. Par exemple, lorsque vous revenez sur une page qui a été en arrière-plan, tous les compteurs du panier doivent être mis à jour avec le dernier nombre d'articles dans le panier. Il ne s'agit donc pas d'un problème spécifique au prérendu, mais le prérendu rend simplement un problème existant plus évident.

Chrome réduit l'encapsulation manuelle des scripts ou des fonctions en retardant certaines API, comme indiqué précédemment. De plus, les iFrames tiers ne sont pas affichés. Seul le contenu supplémentaire doit être retardé manuellement.

Évaluer les performances

Pour mesurer les métriques de performances, les outils d'analyse doivent 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 que les API du navigateur indiquent.

Les Core Web Vitals, mesurés par Chrome via le rapport d'expérience utilisateur Chrome, sont destinés à mesurer l'expérience utilisateur. Elles sont donc mesurées en fonction du temps d'activation. Par exemple, cela se traduit souvent par un LCP de 0 seconde, ce qui montre que c'est 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 si la page a été prérendu entièrement ou partiellement.

Mesurer les prérendus

Si une page est prérendue, vous pouvez l'afficher avec une entrée activationStart différente de zéro pour PerformanceNavigationTiming. Vous pouvez ensuite consigner ces informations à l'aide d'une dimension personnalisée ou d'un élément similaire lorsque vous consignez les 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');

Vos données analytiques pourront ainsi afficher le nombre de navigations prérendues par rapport aux autres types de navigation. Vous pourrez également mettre en corrélation les métriques de performances ou les métriques commerciales avec ces différents types de navigation. Des pages plus rapides signifient des utilisateurs plus satisfaits, ce qui peut souvent avoir un impact réel sur les mesures commerciales, comme le montrent nos études de cas.

Lorsque vous mesurez l'impact commercial du préchargement des pages pour les navigations instantanées, vous pouvez décider s'il est intéressant d'investir davantage dans cette technologie pour permettre de précharger davantage de navigations ou d'examiner pourquoi les pages ne sont pas préchargées.

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 prérendues et non consultées par la suite. Cela peut impliquer d'effectuer trop de préchargement et d'utiliser des ressources précieuses de l'utilisateur pour peu d'avantages.

Pour mesurer cela, déclenchez un événement d'analyse lorsque des règles de spéculation sont insérées (après avoir vérifié que le navigateur est compatible avec le prérendu à l'aide de HTMLScriptElement.supports('speculationrules')) afin d'indiquer que le prérendu a été demandé. Notez que le fait qu'un prérendu ait été demandé ne signifie pas qu'il a été démarré ou terminé. En effet, comme indiqué précédemment, un prérendu est un indice pour le navigateur, qui peut choisir de ne pas prérendre les pages en fonction des paramètres utilisateur, de l'utilisation actuelle de la mémoire ou d'autres heuristiques.

Vous pouvez ensuite comparer le nombre de ces événements au nombre réel de pages vues prérendues. Vous pouvez également déclencher un autre événement à l'activation si cela facilite la comparaison.

Le taux de réussite des requêtes peut ensuite être approximativement calculé en examinant la différence entre ces deux chiffres. Pour les pages pour lesquelles vous utilisez l'API Speculation Rules afin de précharger les pages, vous pouvez ajuster les règles de manière appropriée pour vous assurer de maintenir un taux de requêtes élevé et de trouver le juste équilibre entre utiliser les ressources des utilisateurs pour les aider et les utiliser inutilement.

Sachez que le préchargement peut se produire en raison du préchargement de la barre d'adresse et pas uniquement en raison de vos règles de spéculation. Vous pouvez cocher document.referrer (qui sera vide pour la navigation dans la barre d'adresse, y compris les navigations dans la barre d'adresse prérendues) si vous souhaitez les différencier.

N'oubliez pas d'examiner également les pages qui ne comportent pas de préchargement, car cela peut indiquer qu'elles ne sont pas éligibles au préchargement, même depuis 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 tester l'éligibilité au prérendu, semblables à l'outil de test du cache amélioré. Elle souhaite aussi ajouter éventuellement une API pour déterminer pourquoi un prérendu a échoué.

Impact sur les extensions

Consultez l'article dédié sur les extensions Chrome: extension de l'API pour prendre en charge la navigation instantanée pour en savoir plus sur d'autres points à prendre en compte pour les pages prérendues.

Commentaires

L'équipe Chrome développe activement le prérendu. De nombreux projets visent à étendre le champ d'application de ce qui a été mis à disposition dans la version 108 de Chrome. N'hésitez pas à nous faire part de vos commentaires sur le dépôt GitHub ou via notre outil Issue Tracker. Nous avons hâte de vous entendre et de partager des études de cas sur cette nouvelle API passionnante.

Remerciements

Vignette par Marc-Olivier Jodoin sur Unsplash