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

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 pris en charge au-delà de Chrome et n'était pas une API très expressive.

L'ancien prérendu à l'aide du lien rel=prerender a été abandonné au profit de NoState Prefetch (préchargement NoState), qui permettait à la place de récupérer les ressources nécessaires à la page future, mais qui ne prérenait pas complètement la page ni n'exécutait JavaScript. Le préchargement NoState permet d'améliorer les performances des pages en optimisant le chargement des ressources, mais il ne fournit pas de chargement instantané de la page comme le ferait un prérendu complet.

L'équipe Chrome a réintroduit le prérendu complet dans Chrome. Pour éviter toute complication avec l'utilisation existante et permettre l'extension future 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, et peut être supprimée à un moment ultérieur.

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

Une page peut être prérendue de quatre manières différentes, 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 la page automatiquement s'il est très probable que vous la consulterez, en fonction de votre historique de navigation.
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écharger automatiquement la page de résultats de recherche lorsque le moteur de recherche vous y invite.
4. Les sites peuvent utiliser l'API Speculation Rules pour indiquer de manière programmatique à Chrome les pages à précharger. Cela remplace la fonction <link rel="prerender"...> et permet aux sites de précharger de manière proactive une page en fonction des règles de spéculation. Celles-ci peuvent exister de manière statique sur les pages ou être injectées de manière dynamique par JavaScript selon le 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 invisible en arrière-plan. Il est ensuite "activé" en remplaçant l'onglet au premier plan par cette page prérendue. Si une page est activée avant qu'elle n'ait été entièrement prérendue, son état actuel est "en avant" et continue à se charger, ce qui signifie que vous pouvez toujours prendre une longueur d'avance.

Lorsque la page prérendue est ouverte dans un état masqué, un certain nombre d'API qui provoquent des comportements intrusifs (par exemple, des invites) ne sont pas activées dans cet état. Elles sont différé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 s'efforce de présenter les motifs d'annulation du prérendu sous forme d'API et d'améliorer les fonctionnalités des outils de développement pour faciliter l'identification de ces cas limites.

Impact du prérendu

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

L'exemple de site est déjà rapide, mais vous pouvez même constater à quel point le préchargement 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 proche de zéro, un CLS réduit (puisque tout CLS de chargement se produit avant l'affichage initial) et une amélioration de l'INP (puisque le chargement doit être terminé avant que l'utilisateur n'interagisse avec l'application).

Même lorsqu'une page s'active avant qu'elle ne soit complètement chargée, une longueur d'avance sur 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 cours de prérendu est déplacée vers le cadre principal et continue de se charger.

Toutefois, le prérendu utilise davantage de mémoire et de bande passante réseau. Veillez à ne pas effectuer un prérendu trop important, au détriment des ressources de l'utilisateur. Uniquement s'il est très probable que la page soit consultée.

Pour savoir comment mesurer l'impact réel sur les performances dans vos données analytiques, consultez la section Mesure des performances.

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

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

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

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

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

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

• Pour un niveau de confiance supérieur à 50 % (en orange), Chrome se pré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

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échargent les liens trouvés dans le document en fonction de sélecteurs href (selon l'API de format d'URL) 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.

L'impatience

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

• immediate:cette méthode permet d'effectuer des spéculations 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 à l'avenir, nous prévoyons de le placer 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 sur le pointeur ou sur l'écran.

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 comporter de nombreuses URL, vous devez utiliser immediate ou eager pour les règles document avec prudence (consultez également la section Limites de Chrome ci-après).

Le paramètre eagerness à utiliser dépend de votre site. Pour un site statique et léger, spéculer plus hâtivement peut avoir un coût faible 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 une option intermédiaire, et de nombreux sites pourraient bénéficier de la règle de spéculation suivante, qui prérendurait un lien en maintenant le pointeur sur le lien pendant 200 millisecondes ou lors de l'événement de pointeur en tant qu'implémentation de base, mais efficace, 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 servir à précharger uniquement des pages, sans prérendu complet. Cela peut souvent être une bonne première étape avant 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 excessive de l'API Speculation Rules:

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

Les paramètres moderate et conservative, qui dépendent de l'interaction de l'utilisateur, fonctionnent de la façon premier entré, premier sorti (FIFO): une fois la limite atteinte, toute nouvelle spéculation annulera la spéculation la plus ancienne et la remplacera 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 de l'URL, repoussant ainsi 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 d'un délai supplémentaire devrait entraîner une réduction du coût. C'est pourquoi la limite est fixée au seuil minimal 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 lesquelles sont nécessaires ni quand elles sont nécessaires.

Les limites immediate et eager étant également dynamiques, la suppression d'un élément de script d'URL list entraînera l'annulation des spéculations supprimées.

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

• Save Data (Enregistrer les 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é (il l'est également explicitement 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'a pas été activée.

Toutes ces conditions visent à réduire l'impact d'une spéculation excessive lorsqu'elle pourrait nuire 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 presse ou un blog peut précharger l'article le plus récent 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 spéculer lorsque les utilisateurs interagissent avec les 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.

Ceux qui privilégient l'insertion dynamique en fonction d'actions comme le fait de pointer sur un lien ou de cliquer dessus (comme de nombreuses bibliothèques le faisaient auparavant avec <link rel=prefetch>) sont recommandés pour examiner les règles de document, car elles permettent au navigateur de gérer de nombreux 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-cadres ne sont pas prises en compte, et les règles de spéculation dans les pages prérendues ne le sont qu'une fois cette page activée.

En-tête HTTP Speculation-Rules

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 avoir à 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"

Cette ressource doit utiliser le type MIME approprié et, s'il s'agit d'une ressource multi-origine, faire l'objet d'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 les liens de même origine.

Règles de spéculation et applications monopages

Les règles de spéculation ne sont compatibles qu'avec les navigations en pleine page gérées par le navigateur, et non pour les applications monopages (SPA) ni les pages shell d'application. Ces architectures n'utilisent pas d'extractions 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 permettent de précharger l'application proprement dite à partir d'une page précédente. Cela permet de compenser une partie des coûts de chargement initial supplémentaires de certaines applications monopages. Toutefois, les modifications de routage dans l'application ne peuvent pas être préchargées.

Règles de spéculation de débogage

Consultez l'article consacré au débogage des règles de spéculation afin de découvrir les nouvelles fonctionnalités des outils pour les développeurs Chrome afin de faciliter l'affichage et le débogage de cette nouvelle API.

Règles de spéculation multiples

Vous pouvez également ajouter plusieurs règles de spéculation sur une même page, qui s'ajoutent aux règles existantes. Par conséquent, les différentes manières suivantes entraînent le prérendu one.html et 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 listes dans un ensemble de speculationrules

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

Assistance No-Vary-Search

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 diffuseront la même page à partir du serveur, et pourront donc être réutilisées à 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 n'entraînant pas de différence par rapport à la ressource diffusée. Ainsi, un navigateur peut réutiliser des versions mises en cache précédemment 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 en préchargement (bien que nous cherchions également à l'accepter pour le prérendu).

Les règles de spéculation acceptent l'utilisation de expects_no_vary_search pour indiquer où un en-tête HTTP No-Vary-Search doit être renvoyé. Cela permet d'éviter des 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 le même pour les ID 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 hâtivement cette URL. 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 récupérer 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 du préchargement.

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 nous efforçons de réduire cette restriction.

Par défaut, les spéculations sont limitées aux pages d'origine identique. Spéculation de pages multi-origines sur un même site (par exemple, https://a.example.com peut précharger une page sur https://b.example.com). Pour utiliser cette méthode, la page spéculative (https://b.example.com dans cet exemple) doit être activée en incluant un en-tête HTTP Supports-Loading-Mode: credentialed-prerender, sans quoi Chrome annulera la spéculation.

Les futures versions peuvent également autoriser le prérendu pour les pages multi-origines qui n'appartiennent pas au même site, à condition qu'il n'existe pas de cookies 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 sont déjà compatibles avec les préchargements multi-origines, mais uniquement lorsque les cookies du domaine multi-origines n'existent pas. S'il existe des cookies provenant d'un utilisateur ayant déjà visité ce site, la spéculation ne sera pas déclenchée et affichera un échec dans les outils de développement.

Compte tenu de ces limitations actuelles, le préchargement des URL d'origine identique et le préchargement des URL multi-origines peuvent améliorer l'expérience utilisateur à la fois pour les liens internes et les liens externes, dans la mesure du possible:

<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 de cookies, mais tentent tout de même d'effectuer le préchargement. Cela peut entraîner un préchargement inutile qui doit être renvoyé ou, pire encore, un chargement de page incorrect.

Les règles de spéculation ne sont pas compatibles avec le préchargement pour les pages contrôlées par des service workers. Nous mettons tout en œuvre pour que cette fonctionnalité soit disponible. Suivez ce problème lié aux service workers d'assistance pour obtenir les dernières informations. Le prérendu est compatible avec les pages contrôlées par un service worker.

Compatibilité avec l'API de détection des règles de spéculation

Vous pouvez détecter la compatibilité de l'API Speculation Rules avec les fonctionnalités à 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);
}

Pour regarder une démonstration du prérendu de l'API Speculation Rules avec l'insertion JavaScript, consultez cette page de démonstration du prérendu.

L'insertion d'un élément <script type = "speculationrules"> directement dans le DOM n'enregistre pas les règles de spéculation, car celles-ci doivent être ajoutées comme indiqué précédemment. Par exemple, la modification directe du panneau Elements dans les outils pour les développeurs Chrome pour ajouter l'élément <script type = "speculationrules"> n'enregistre pas les règles de spéculation. À la place, le script permettant d'ajouter dynamiquement ces éléments 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 comme Google Tag Manager (GTM), vous devez les insérer via JavaScript au lieu d'ajouter l'élément <script type = "speculationrules"> directement via GTM pour les mêmes raisons que celles mentionnées précédemment:

Notez que cet exemple utilise var, car GTM n'accepte pas const.

Annuler les règles de spéculation

La suppression des règles de spéculation entraîne l'annulation du prérendu. Toutefois, au moment où cela s'est produit, les ressources ont probablement déjà été utilisées pour lancer le prérendu. Il est donc recommandé de ne pas effectuer de prérendu s'il est probable que vous deviez 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).

Un nouveau inline-speculation-rules peut être ajouté à script-src pour permettre la prise en charge des é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. 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, dans certains cas, vous ne souhaitez pas que le prérendu des pages soit effectué, par exemple lorsque les pages changent d'état, que ce soit en fonction de la demande initiale ou de l'exécution de 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 ayant le paramètre "Précharger les pages" 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 Économie 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 des contenus différents ou empêcher un prérendu. Si un code de réponse qui échoue (c'est-à-dire, 200 ou 304) est renvoyé, la page n'est pas prérendue et toute page en préchargement est supprimée.

Si vous ne souhaitez pas qu'une page spécifique soit préchargée, c'est le meilleur moyen d'éviter que cela ne se produise. Toutefois, pour une expérience optimale, nous vous recommandons d'autoriser le préchargement, mais de retarder les actions qui ne doivent se produire qu'une fois la page 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. 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 disposer d'une fonction pour vérifier les pages prérendues et prérendues comme suit:

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 (en totalité ou en partie) consiste à ouvrir les outils de développement une fois la page activée et à 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:

Lorsque la page est activée par l'utilisateur qui la consulte, l'événement prerenderingchange est envoyé au document, qui peut ensuite être utilisé pour activer les activités qui étaient démarrées par défaut lors 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 d'interface peut détecter les pages prérendues et agir en conséquence 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. ou en mesurant 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 proposées que lorsque la probabilité est très élevée (plus de 80% du temps).

Toutefois, en particulier avec l'API Speculation Rules, les pages prérendues peuvent avoir un impact sur les analyses et les propriétaires de sites peuvent avoir besoin d'ajouter du code supplémentaire pour activer l'analyse des pages prérendues uniquement lors de l'activation. En effet, tous les fournisseurs de solutions d'analyse ne peuvent pas le faire 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 utile pour les analyses et des cas d'utilisation similaires, dans d'autres cas, vous souhaiterez peut-être charger davantage de contenu. Vous pouvez donc utiliser document.prerendering et prerenderingchange pour cibler spécifiquement les pages de prérendu.

Bloquer le reste du contenu pendant le prérendu

Les API mentionnées précédemment peuvent être utilisées pour bloquer 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 ne souhaitez pas exécuter pendant la phase de prérendu.

Par exemple, pour ce script:

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

Vous pouvez le remplacer par un élément de script inséré dynamiquement, qui ne s'insère qu'en fonction 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 bloquer des scripts distincts qui incluent des données analytiques, ou pour afficher le contenu en fonction de l'état ou d'autres variables susceptibles de changer au cours d'une visite. Par exemple, les recommandations, l'état de connexion ou les icônes de panier peuvent tous être masqués afin de s'assurer que les informations les plus récentes sont présentées.

Bien que cela soit peut-être plus susceptible de se produire plus souvent avec l'utilisation du prérendu, ces conditions s'appliquent également aux pages chargées dans les onglets en arrière-plan mentionnés précédemment (vous pouvez donc utiliser la fonction whenFirstVisible à la place de whenActivated).

Dans de nombreux cas, l'état doit idéalement être également vérifié sur les modifications générales de visibilitychange. Par exemple, lorsque vous revenez à une page en arrière-plan, tous les compteurs de 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.

Pour que Chrome atténue une partie de la nécessité d'encapsuler manuellement des scripts ou des fonctions, certaines API sont bloquées, comme indiqué précédemment. De plus, les iFrames tiers ne sont pas affichés. Seul le contenu doit donc être bloqué 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 indiqué par les API du navigateur.

Les métriques Core Web Vitals, mesurées par Chrome via le rapport sur l'expérience utilisateur de Chrome, visent à évaluer l'expérience utilisateur. Elles sont donc mesurées en fonction du temps d'activation. Cela se traduira souvent par un LCP de 0 seconde, par exemple, 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 si la page a été entièrement ou partiellement prérendue.

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. Ces informations peuvent ensuite être consignées à l'aide d'une dimension personnalisée, ou d'une dimension similaire lors de la consignation 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 analyses de comparer le nombre de navigations prérendues par rapport à d'autres types de navigation, et vous permettra également de corréler les métriques de performance ou les métriques commerciales à ces différents types de navigation. Si les pages sont rapides, les utilisateurs sont plus satisfaits, ce qui peut souvent avoir un impact réel sur les mesures commerciales, comme le montrent nos études de cas.

En mesurant l'impact commercial du prérendu des pages pour les navigations instantanées, vous pouvez décider s'il vaut la peine d'investir davantage d'efforts dans l'utilisation de cette technologie pour permettre le préchargement de plus de navigations, ou pour déterminer pourquoi les pages ne sont pas prérendu.

Mesurer les taux d'accè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 qui ne sont pas consultées par la suite. Cela peut impliquer que votre préchargement soit trop important et que vous consommez de précieuses ressources de l'utilisateur pour peu d'avantages.

Vous pouvez mesurer cela en déclenchant un événement d'analyse lors de l'insertion de règles de spéculation (après avoir vérifié que le navigateur accepte le prérendu à l'aide de HTMLScriptElement.supports('speculationrules')) pour indiquer que le prérendu a été demandé. Notez que le fait qu'un prérendu a été demandé n'indique pas qu'un prérendu a été lancé ou 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 selon les paramètres utilisateur, l'utilisation actuelle de la mémoire ou d'autres méthodes heuristiques.

Vous pouvez ensuite comparer le nombre de ces événements avec le nombre réel de pages vues prérendues. Vous pouvez également déclencher un autre événement lors de l'activation pour faciliter la comparaison.

Vous pouvez ensuite estimer le "taux d'appels réussis" en observant la différence entre ces deux valeurs. Pour les pages dont le préchargement est effectué à l'aide de l'API Speculation Rules, vous pouvez ajuster les règles de manière appropriée afin de maintenir 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 le prérendu peut avoir lieu en raison du prérendu de la barre d'adresse, et pas seulement des règles de spéculation. Vous pouvez vérifier document.referrer (qui sera vide pour la navigation dans la barre d'adresse, y compris les navigations dans la barre d'adresse prérendue) 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 que ces pages ne sont pas éligibles au préchargement, 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 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

Le prérendu est en cours de développement par l'équipe Chrome, et de nombreux projets visent à é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 via Issue Tracker. Nous sommes impatients de recevoir et de partager des études de cas sur cette nouvelle API.

Liens associés

• Atelier de programmation sur les règles de spéculation
• Déboguer les règles de spéculation
• Présentation du préchargement NoState
• Spécification de l'API Speculation Rules
• Dépôt GitHub de la spéculation de navigation
• Extensions Chrome: extension de l'API pour prendre en charge la navigation instantanée

Remerciements

Vignette de Marc-Olivier Jodoin sur Unsplash