Navigateurs pris en charge
- 109
- 109
- x
- x
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:
- 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.
- 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.
- 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.
- 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
:
![Page "Prédicteurs Chrome" filtrée pour afficher les prédictions basse (gris), moyenne (orange) et élevée (vert) en fonction du texte saisi.](https://developer.chrome.com/static/docs/web-platform/prerender-pages/image/screenshot-the-chrome-pr-ec7e1506f8378.png?authuser=5&hl=fr)
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:
![Fonctionnalité Typeahead dans la barre d'adresse Chrome](https://developer.chrome.com/static/docs/web-platform/prerender-pages/image/screenshot-the-address-b-7938093dbbc3c.png?authuser=5&hl=fr)
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
Navigateurs pris en charge
- 121
- 121
- x
- x
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ètreimmediate
, mais à l'avenir, nous prévoyons de le placer entreimmediate
etmoderate
.moderate
:cette méthode effectue des spéculations si vous maintenez le pointeur sur un lien pendant 200 millisecondes (ou sur l'événementpointerdown
s'il est plus tôt et sur les appareils mobiles où il n'y a pas d'événementhover
).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
ouconservative
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.
Insérer un élément <script type = "speculationrules">
directement dans le DOM à l'aide de innerHTML
n'enregistre pas les règles de spéculation pour des raisons de sécurité. Cet élément doit être ajouté comme indiqué précédemment. Toutefois, le contenu inséré dynamiquement à l'aide de innerHTML
et qui contient de nouveaux liens sera sélectionné par les règles existantes sur la page.
De même, le fait de modifier directement le panneau Elements dans les outils pour les développeurs Chrome afin d'ajouter l'élément <script type = "speculationrules">
n'enregistre pas les règles de spéculation. À la place, le script qui les ajoute dynamiquement au DOM doit être exécuté depuis la console pour insérer les règles.
Ajouter des règles de spéculation via un gestionnaire de balises
Pour ajouter des règles de spéculation à l'aide d'un gestionnaire de balises 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:
![Configuration de la balise HTML personnalisée dans Google Tag Manager](https://developer.chrome.com/static/docs/web-platform/prerender-pages/image/adding-speculation-rules-via-gtm.png?authuser=5&hl=fr)
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:
![Console dans les outils pour les développeurs Chrome affichant une valeur activationStart positive indiquant que la page a été prérendue](https://developer.chrome.com/static/docs/web-platform/prerender-pages/image/console-chrome-devtools-7d567e77e3ca6.png?authuser=5&hl=fr)
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