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

Barry Pollard

Publié le 2 décembre 2022, dernière mise à jour le 29 octobre 2026

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

L'équipe Chrome a réintroduit le prérendu complet des futures pages auxquelles un utilisateur est susceptible d'accéder.

Bref historique du prérendu

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

Cet ancien prérendu utilisant l'indice de lien rel=prerender a été abandonné au profit du préchargement NoState, qui récupérait les ressources nécessaires à la future page, mais n'effectuait pas de prérendu complet de la page ni n'exécutait JavaScript. Le préchargement NoState permet d'améliorer les performances de la page en améliorant le chargement des ressources, mais il ne permet pas un chargement instantané de la page, contrairement à 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 extension future 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 NoState, en vue de la supprimer à l'avenir.

Comment une page est-elle prérendue ?

Une page peut être prérendue de quatre manières différentes, qui visent toutes à 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éafficher automatiquement la page si, d'après votre historique de navigation, il est fort probable que vous la consultiez.
  2. Lorsque vous utilisez la barre de favoris, Chrome peut préafficher automatiquement la page lorsque vous passez le curseur sur l'un des boutons de 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, si le moteur de recherche lui demande de le faire.
  4. Les sites peuvent utiliser l'API Speculation Rules pour indiquer de manière programmatique à Chrome les pages à pré-afficher. Cette fonctionnalité remplace ce que faisait <link rel="prerender"...> et permet aux sites de prérendre une page de manière proactive en fonction des règles de spéculation de la page. Ils peuvent exister de manière statique sur les pages ou être injectés de manière dynamique par JavaScript, selon les préférences 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 invisible en arrière-plan, puis est "activé" en remplaçant l'onglet au premier plan par cette page prérendue. Si une page est activée avant d'être entièrement prérendue, son état actuel est "foregrounded" (au premier plan) et elle continue de se charger, ce qui signifie que vous pouvez toujours prendre une 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, des invites) 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 s'efforce d'exposer les raisons de l'annulation du prérendu en tant qu'API et d'améliorer les fonctionnalités des outils de développement pour faciliter l'identification de ces cas particuliers.

Impact du prérendu

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

Exemple d'impact du prérendu

L'exemple de site est déjà rapide, mais même dans ce cas, vous pouvez voir comment le prérendu 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 (car tout CLS de chargement se produit avant la vue initiale) et un INP amélioré (car le chargement doit être terminé avant que l'utilisateur n'interagisse).

Même lorsqu'une page s'active avant d'être complètement chargée, le fait d'avoir 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 de prérendu est déplacée vers le frame principal et continue de se charger.

Toutefois, le prérendu utilise de la mémoire et de la bande passante réseau supplémentaires. Veillez à ne pas effectuer de prérendu excessif, au détriment des ressources de l'utilisateur. N'effectuez un prérendu que s'il est fort probable que l'utilisateur accède à la page.

Pour en savoir plus sur la mesure de l'impact réel sur les performances dans vos analyses, 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 afficher les prédictions de Chrome pour les URL sur la page chrome://predictors :

Page &quot;Chrome Predictors&quot; filtrée pour afficher les prédictions faibles (gris), moyennes (orange) et élevées (vert) en fonction du texte saisi.
Page "Chrome Predictors"

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

Cette capture d'écran a été prise dans une installation Chrome relativement récente, et les prédictions de confiance nulle 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 requis pour atteindre un niveau de confiance suffisamment élevé.

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

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

Chrome mettra continuellement à jour ses prédicteurs en fonction de ce que vous saisissez et sélectionnez.

  • Pour un niveau de confiance supérieur à 30 % (indiqué en orange), Chrome se préconnecte de manière proactive au domaine, mais n'effectue pas de prérendu de la page.
  • Si le niveau de confiance est supérieur à 50 % (indiqué en vert), Chrome préaffichera 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 pour indiquer au navigateur les URL à préafficher.

Listes d'URL

Les règles de spéculation peuvent être basées sur des listes d'URL :

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

Règles concernant les documents

Les règles de spéculation peuvent également être des "règles de document" utilisant la syntaxe where. Cette règle spécule sur les liens trouvés dans le document en fonction des sélecteurs href (basés sur l'API format d'URL) 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>

Impatience

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

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 liées à un document :

  • conservative : spécule en cas d'événement tactile ou avec pointeur.
  • moderate : sur ordinateur, effectue des spéculations si vous pointez sur un lien pendant 200 millisecondes ou sur l'événement pointerdown (si c'est plus tôt) et sur mobile où il n'y a pas d'événement hover. Sur mobile, nous avons modifié ce comportement pour nous baser sur des heuristiques de fenêtre d'affichage complexes à partir d'août 2025. Les heuristiques de fenêtre d'affichage complexes se déclenchent 500 ms après que l'utilisateur a arrêté de faire défiler la page, pour les ancres situées à moins de 30 % de la distance verticale par rapport au pointeur précédent, où les ancres sont au moins 0,5 fois plus grandes que la plus grande ancre de la fenêtre d'affichage. Comme décrit dans ce document.
  • eager : ce niveau d'empressement se comportait de la même manière que immediate, mais a changé à partir de Chrome 143. Sur ordinateur, cela effectue des spéculations si vous maintenez le pointeur sur un lien pendant 10 millisecondes. Sur mobile, nous avons modifié ce comportement pour nous baser sur des heuristiques simples de fenêtre d'affichage à partir de janvier 2026. Les heuristiques simples de la fenêtre d'affichage se déclenchent 50 ms après l'entrée de l'ancrage dans la fenêtre d'affichage.
  • immediate : utilisé pour spéculer le plus tôt possible (c'est-à-dire dès que les règles de spéculation sont observées).

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

La valeur eagerness par défaut pour les règles document est conservative. Étant donné qu'un document peut être constitué de nombreuses URL, l'utilisation de immediate pour les règles document doit être effectuée avec précaution (voir également la section Limites de Chrome ci-après).

Le paramètre eagerness à utiliser dépend de votre site. Pour un site statique léger, une spéculation plus agressive peut avoir un coût minime et être bénéfique pour les utilisateurs. Les sites dont l'architecture est plus complexe et dont les charges utiles de page sont 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 juste milieu, et de nombreux sites pourraient bénéficier de la règle de spéculation suivante, qui prérend un lien lorsque le pointeur est maintenu sur le lien pendant 200 millisecondes ou lors de l'événement pointerdown, en tant qu'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 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>

Prerender until script

L'équipe Chrome travaille également à l'ajout de prerender_until_script à l'API Speculation Rules (voir le bug d'implémentation). Il s'agit d'une étape entre le préchargement et le prérendu, qui serait utilisée de la même manière :

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

Comme pour NoState prefetch, cela permet de précharger à la fois le document HTML et les sous-ressources disponibles dans ce code HTML. Toutefois, il va plus loin et commence également à préafficher la page, en s'arrêtant lorsque le premier script est rencontré.

Cela signifie que pour les pages sans JavaScript ou avec du JavaScript uniquement dans le pied de page, la page pourrait être presque entièrement prérendue à l'avance. Les pages contenant des scripts dans le <head> ne pourraient pas être prérendues, mais bénéficieraient tout de même de la récupération des sous-ressources.

Cela permettrait d'éviter les risques d'effets secondaires involontaires de l'exécution de JavaScript, tout en offrant un gain de performances bien plus important que prefetch.

Limites de Chrome

Chrome applique des limites pour éviter une utilisation excessive de l'API Speculation Rules :

empressement Préchargement Prérendu
immediate 50 10
eager/moderate sur mobile 6 (FIFO) 2 (FIFO)
eager/moderate sur ordinateur 2 (FIFO) 2 (FIFO)
conservative 2 (FIFO) 2 (FIFO)
Limites de spéculation dans Chrome

Les paramètres eager, 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 d'économiser de la mémoire.

Une spéculation annulée peut être déclenchée à nouveau (par exemple, en pointant à nouveau sur ce lien), ce qui entraînera une nouvelle spéculation sur cette URL, repoussant la spéculation la plus ancienne. Dans ce cas, la spéculation précédente aura mis en cache toutes les ressources pouvant être mises en cache dans le cache HTTP pour cette URL. Par conséquent, une nouvelle spéculation devrait avoir un coût réduit. C'est pourquoi la limite est définie sur le seuil modeste de 2 par défaut. Nous utilisons un seuil plus élevé de 6 pour la prérécupération sur mobile, car il n'y a pas de "survol", les heuristiques alternatives de la fenêtre d'affichage mobile sont moins précises et la prérécupération est moins coûteuse que le prérendu (nous conservons la limite de 2 pour le prérendu sur mobile).

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 le sont.

Chrome envisage également de porter la limite à 5 sur mobile pour eager et moderate, au moins pour le préchargement, car il s'agit d'une heuristique moins précise. Les développeurs qui utilisent eager peuvent envisager d'utiliser également des règles conservative lorsque plusieurs liens sont disponibles dans la fenêtre d'affichage, afin de continuer à spéculer même s'ils ne sont pas sélectionnés comme l'un des deux premiers liens.

La limite immediate est également dynamique. Par conséquent, la suppression d'un élément de script d'URL list libérera de la capacité en annulant les spéculations supprimées.

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

  • Save-Data.
  • É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 interorigines sur les pages prérendues avant l'activation.

Toutes ces conditions visent à réduire l'impact de la spéculation excessive lorsqu'elle est préjudiciable aux utilisateurs.

Comment 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éafficher l'article le plus récent, si c'est souvent la prochaine navigation 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 de manière dynamique : elles peuvent être basées sur la logique de l'application, personnalisées pour l'utilisateur ou basées sur d'autres heuristiques.

Si vous préférez l'insertion dynamique basée sur des 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 un grand nombre de vos cas d'utilisation.

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

En-tête HTTP Speculation-Rules

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Les règles de spéculation peuvent également être fournies à l'aide d'un en-tête HTTP Speculation-Rules, plutôt que d'être incluses 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 bon type MIME et, s'il s'agit d'une ressource interorigine, 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 les liens de même origine.

Champ de tag des règles de spéculation

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Il est également possible d'ajouter des "tags" dans la syntaxe JSON des règles de spéculation au niveau global pour toutes les règles de spéculation d'un ensemble de règles :

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

ou au niveau de chaque règle :

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

Ce tag est ensuite reflété dans l'en-tête HTTP Sec-Speculation-Tags, qui peut être utilisé pour filtrer les règles de spéculation sur le serveur. L'en-tête HTTP Sec-Speculation-Tags peut inclure plusieurs balises si la spéculation est couverte par plusieurs règles, comme illustré dans l'exemple suivant :

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

Certains CDN injectent automatiquement des règles de spéculation, mais bloquent les spéculations pour les pages non mises en cache en périphérie afin d'éviter que cette fonctionnalité n'entraîne une utilisation accrue du serveur d'origine. Les tags leur permettent d'identifier les spéculations initiées par leur ensemble de règles par défaut, tout en permettant à toutes les règles ajoutées par le site de passer à l'origine.

Les tags d'ensemble de règles sont également affichés dans les outils pour les développeurs Chrome.

Champ target_hint des règles de spéculation

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Les règles de spéculation peuvent également inclure un champ target_hint, qui contient un nom ou un mot clé de contexte de navigation valide indiquant où la page s'attend à ce que le contenu prérendu soit activé :

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

Cet indice permet de gérer les spéculations de prérendu pour les liens target="_blank" :

<a target="_blank" href="next.html">Open this link in a new tab</a>

Pour l'instant, seuls "target_hint": "_blank" et "target_hint": "_self" (valeur par défaut si non spécifiée) sont compatibles avec Chrome, et uniquement pour le prérendu (le préchargement n'est pas pris en charge).

target_hint n'est nécessaire que pour les règles de spéculation urls, car pour les règles liées au document, l'target est connu à partir du lien lui-même.

Règles de spéculation et SPA

Les règles de spéculation ne sont compatibles qu'avec les navigations sur des pages complètes gérées par le navigateur, et non avec les applications monopages (SPA) ou les pages app shell. Ces architectures n'utilisent pas de récupération de documents, mais effectuent des récupérations d'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érendre l'application elle-même à partir d'une page précédente. Cela peut aider à compenser une partie des coûts de chargement initiaux supplémentaires de certaines SPA. Toutefois, les changements de route dans l'application ne peuvent pas être prérendus.

Déboguer des règles de spéculation

Consultez l'article dédié au débogage des règles de spéculation 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 le 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 listes dans un même ensemble de balises speculationrules

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

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

Lors de la prérécupération ou du prérendu d'une page, certains paramètres d'URL (techniquement appelés paramètres de recherche) peuvent ne pas être importants 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 n'entraînent généralement pas la diffusion de pages différentes par le serveur. Cela signifie que page1.html?utm_content=123 et page1.html?utm_content=456 afficheront 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 n'entraînent pas de différence dans la ressource diffusée. Elle permet donc à 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, à la fois pour le préchargement et 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 avant que les réponses ne soient vues.

<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. Toutefois, le contenu de la page finit par différer en fonction du rendu 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 cette URL de manière agressive, et 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 doit alors choisir 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 que ce préchargement soit terminé.

Vous pouvez également ajouter plusieurs paramètres à expects_no_vary_search en les séparant par un espace (puisque No-Vary-Search est un en-tête structuré HTTP) :

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

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

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 prérendus sont limités aux pages de même origine. Il est possible d'activer le prérendu de pages interorigines sur le 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 l'activer 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 interorigines qui ne sont pas sur le même site, à condition qu'il n'existe pas de cookies pour la page prérendue et que celle-ci accepte 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 interorigines. Pour les préchargements interorigines sur le même site, il n'y a aucune restriction. Les préchargements intersites et interorigines ne sont acceptés que si les cookies du domaine interorigine n'existent pas. Si des cookies existent parce que l'utilisateur a déjà visité ce site, la spéculation ne sera pas utilisée et une erreur s'affichera dans les outils de développement.

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

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

La restriction visant à empêcher par défaut les spéculations interorigines pour les liens interorigines est nécessaire pour des raisons de sécurité. Il s'agit d'une amélioration par rapport à <link rel="prefetch"> pour les destinations interorigines, qui n'enverront pas non plus de cookies, mais tenteront tout de même de précharger la page. Cela entraînera soit un préchargement inutile qui devra être renvoyé, soit, pire encore, le chargement d'une page incorrecte.

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

Vous pouvez détecter la compatibilité avec 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.

L'insertion d'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é. Elles doivent être ajoutées comme indiqué précédemment. Toutefois, le contenu inséré de manière dynamique à l'aide de innerHTML et contenant de nouveaux liens sera détecté par les règles existantes sur la page.

De même, modifier directement le panneau Éléments dans les outils de développement 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 cet élément au DOM 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), vous devez les insérer via JavaScript, plutôt que 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. Cependant, lorsque cela se produit, des ressources ont probablement déjà été dépensé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. En revanche, les ressources mises en cache peuvent toujours être réutilisées. Les annulations ne sont donc pas forcément inutiles et peuvent toujours profiter aux spéculations et navigations futures.

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Les spéculations peuvent également être annulées à l'aide de l'en-tête HTTP Clear-Site-Data avec les directives prefetchCache et prerenderCache.

Cela peut être utile lorsque l'état est modifié sur le serveur. Par exemple, lors de l'appel d'une API "add-to-basket" (ajouter au panier) ou d'une API de connexion ou de déconnexion.

Idéalement, ces mises à jour d'état devraient être propagées aux pages prérendues à l'aide d'API telles que l'API Broadcast Channel. Toutefois, lorsque cela n'est pas possible ou jusqu'à ce que cette logique soit implémentée, il peut être plus facile d'annuler la spéculation.

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 l'en-tête 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 hachés ou non. Cela n'est pas compatible avec les règles incluses dans le code HTML initial. Les règles 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 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 peut être difficile à obtenir autrement.

Toutefois, il peut arriver que vous ne souhaitiez pas que les pages soient préaffichées, par exemple lorsque l'état des pages change, soit en fonction de la requête initiale, soit en fonction du code JavaScript exécuté 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 activé le paramètre "Précharger les pages" dans chrome://settings/performance/. De plus, le prérendu est également désactivé sur les appareils disposant de peu de mémoire, 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échargées 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 est 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 un contenu différent ou empêcher un prérendu. Si un code de réponse final d'échec 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 préchargée sera supprimée. Notez également que les réponses 204 et 205 ne sont pas valides pour le prérendu, mais qu'elles le sont pour la prérécupération.

Si vous ne souhaitez pas qu'une page spécifique soit prérendue, renvoyer un code de réponse autre que 2XX (comme 503) est le meilleur moyen de l'éviter. Toutefois, pour offrir une expérience optimale, il est recommandé d'autoriser le prérendu, 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 valeur non nulle représentant le temps écoulé entre le début du prérendu et l'activation effective du document.

Vous pouvez utiliser une fonction pour vérifier les pages prérendues et en cours de prérendu, 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 après l'activation de la page et à saisir performance.getEntriesByType('navigation')[0].activationStart dans la console. Si une valeur non nulle est renvoyée, cela signifie que la page a été prérendue :

Console des outils pour les développeurs Chrome affichant une valeur positive pour activationStart, ce qui indique que la page a été prérendue
Tester le prérendu dans la console

Lorsque l'utilisateur active la page en l'affichant, l'événement prerenderingchange est envoyé sur document. Il peut ensuite être utilisé pour activer des activités qui, auparavant, auraient été lancées par défaut au chargement de page, mais que vous souhaitez retarder jusqu'à ce que l'utilisateur affiche réellement la page.

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

Impact sur les données analytiques

Les données analytiques permettent de 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éaffichées que s'il est fort probable qu'elles soient chargées par l'utilisateur. C'est pourquoi les options de prérendu de la barre d'adresse de Chrome ne se produisent que lorsque la probabilité est très élevée (supérieure à 80 % du temps).

Toutefois, en particulier lors de l'utilisation de l'API Speculation Rules, les pages prérendues peuvent avoir un impact sur les analyses. Les propriétaires de sites peuvent donc avoir besoin d'ajouter du code supplémentaire pour n'activer les analyses que pour les pages prérendues lors de l'activation, car tous les fournisseurs d'analyses 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 cours de 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 d'analyse jusqu'à ce que la page soit visible pour la première fois, ce qui couvre à la fois le cas du prérendu et l'ouverture d'onglets en arrière-plan (par exemple, en effectuant un clic droit et en 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 l'analyse et d'autres cas d'utilisation similaires, vous pouvez parfois souhaiter charger davantage de contenu pour ces cas d'utilisation. Vous pouvez alors utiliser document.prerendering et prerenderingchange pour cibler spécifiquement les pages de prérendu.

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 l'étape de prérendu.

Par exemple, prenons le script suivant :

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

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

Bien que cela soit plus susceptible de se produire plus souvent avec le prérendu, ces conditions s'appliquent également aux pages chargées dans les onglets d'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 être vérifié lors des modifications générales de visibilitychange. Par exemple, lorsque l'utilisateur revient sur une page qui a été mise 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 un problème existant plus évident.

Pour limiter la nécessité d'encapsuler manuellement des scripts ou des fonctions, Chrome retient certaines API, comme mentionné précédemment, et n'affiche pas les iFrames tiers. Seul le contenu au-dessus de ces éléments doit donc être retenu 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 Core Web Vitals, mesurés par Chrome via le rapport sur l'expérience utilisateur de Chrome, sont destinés à mesurer l'expérience utilisateur. Elles sont donc mesurées en fonction du temps d'activation. Cela se traduit 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.

À partir de 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

Vous pouvez savoir si une page est prérendue grâce à une entrée activationStart non nulle de PerformanceNavigationTiming. Vous pouvez ensuite consigner ces informations à l'aide d'une dimension personnalisée ou d'un élément similaire lors de l'enregistrement 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 d'afficher le nombre de navigations prérendues par rapport aux autres types de navigation, et de mettre en corrélation les métriques de performances ou les métriques d'entreprise 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.

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

Mesurer les taux de succès

En plus de mesurer l'impact des pages visitées après un prérendu, il est également important de mesurer les pages qui sont prérendues et qui ne sont pas visitées par la suite. Cela peut signifier que vous effectuez trop de prérendus et que vous utilisez des ressources précieuses de l'utilisateur pour un bénéfice minime.

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 avoir vérifié que le navigateur est compatible avec 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 ait été demandé n'indique pas qu'il a été démarré ou terminé. Comme indiqué précédemment, un prérendu est un indice pour le navigateur, qui peut choisir de ne pas préafficher 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 lors de l'activation si cela facilite la comparaison.

Le "taux de réussite" peut ensuite être estimé en examinant la différence entre ces deux chiffres. Pour les pages où vous utilisez l'API Speculation Rules pour pré-afficher les pages, vous pouvez ajuster les règles de manière appropriée afin de maintenir un taux d'accès élevé et de trouver un équilibre entre l'utilisation des ressources des utilisateurs pour les aider et leur utilisation inutile.

Sachez qu'un prérendu peut être effectué en raison du prérendu de la barre d'adresse, et pas seulement de vos 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 prérendues dans la barre d'adresse) si vous souhaitez les différencier.

N'oubliez pas de consulter également les pages qui n'ont pas de prérendu, car cela peut indiquer qu'elles ne sont pas éligibles au prérendu, même depuis la barre d'adresse. Cela peut signifier que vous ne bénéficiez pas de cette amélioration des performances. L'équipe Chrome cherche à ajouter des outils supplémentaires pour tester l'éligibilité au prérendu, peut-être semblables à l'outil de test bfcache, et potentiellement à ajouter une API pour expliquer pourquoi un prérendu a échoué.

Impact sur les extensions

Consultez l'article dédié sur les extensions Chrome : étendre l'API pour prendre en charge la navigation instantanée, qui détaille 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 sont prévus pour étendre le champ d'application de ce qui a été mis à disposition dans la version Chrome 108. N'hésitez pas à nous faire part de vos commentaires sur le dépôt GitHub ou à l'aide de notre outil Issue Tracker. Nous avons hâte de découvrir et de partager des études de cas sur cette nouvelle API prometteuse.

Remerciements

Vignette par Marc-Olivier Jodoin sur Unsplash