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

Navigateurs pris en charge

  • 109
  • 109
  • x
  • x

L'équipe Chrome a rétabli le prérendu 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 utilisez la barre de favoris, Chrome peut précharger automatiquement la page si vous maintenez le pointeur de la souris sur l'un des boutons des favoris.
  3. 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.
  4. 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.

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édictions Chrome filtrée pour afficher les prédictions faibles (gris), moyennes (orange) et élevées (vertes) 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, 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é &quot;Typeahead&quot; de la barre d&#39;adresse de Chrome
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 des sélecteurs href (en fonction de l'API URL Pattern) ou des 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 explique comment ajouter des règles de spéculation à un site.

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:les spéculations sont effectuées si vous maintenez le pointeur sur un lien pendant 200 millisecondes (ou sur l'événement pointerdown s'il est plus court, 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.

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érendurait un lien en maintenant le pointeur de la souris sur le lien pendant 200 millisecondes ou sur l'événement "pointer vers le bas" comme une implémentation basique, 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 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>

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"

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 scripts 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>

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 fonctionnalité est compatible avec Chrome (et les navigateurs basés sur Chromium) pour les spéculations de navigation en préchargement. Nous souhaitons toutefois prendre en charge cette fonctionnalité également pour le prérendu.

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 cette restriction.

Par défaut, les spéculations sont limitées aux pages de même origine. Spéculation sur les 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 utiliser cette option, 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 peuvent également autoriser le prérendu pour les pages multi-origines qui ne proviennent pas du même site, à condition que la page prérendue n'ait pas de cookies et que celle-ci 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 pour le domaine multi-origine 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 limites, un modèle susceptible d'améliorer l'expérience utilisateur pour les liens internes et externes, dans la mesure du possible, consiste à précharger les URL de même origine et à tenter de précharger les URL multi-origines:

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

La restriction permettant d'empêcher les spéculations multi-origines pour les liens multi-origines est nécessaire par défaut pour des raisons de sécurité. Il s'agit d'une amélioration par rapport à <link rel="prefetch"> pour les destinations multi-origines qui n'enverront pas de cookies, mais tenteront quand même le préchargement, ce qui entraînera soit un préchargement inutile qui doit être renvoyé, soit, pire encore, le chargement incorrect de la page.

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.

L'insertion d'un élément <script type = "speculationrules"> directement dans le DOM n'enregistre pas les règles de spéculation, car elles doivent être ajoutées comme indiqué précédemment. Par exemple, la modification directe du panneau Éléments 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 permettant d'ajouter ces éléments au DOM de manière dynamique doit être exécuté à partir de 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), celles-ci doivent être insérées 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:

Configuration de la balise HTML personnalisée 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

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 (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:

Console dans les outils pour les développeurs Chrome montrant un &quot;activationStart&quot; positif indiquant que la page était prérendue
Tester le prérendu dans la console

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.

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.

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, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

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

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

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

initAnalytics();

Bien que cela puisse être pertinent pour l'analyse et un cas d'utilisation similaire, dans d'autres cas, vous pouvez vouloir charger davantage de contenu. Dans ce cas, vous pouvez utiliser document.prerendering et prerenderingchange pour cibler spécifiquement les pages en préaffichage.

É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 si la page était prérendue entièrement ou partiellement.

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.

Remerciements

Vignette de Marc-Olivier Jodoin sur Unsplash