Speculation Rules : prerender sans casser l'analytics

Pourquoi une page peut-elle s'afficher en zéro milliseconde alors qu'elle n'a même pas commencé à se charger quand vous cliquez ? Parce que le navigateur l'a déjà rendue en arrière-plan, dans un onglet invisible, avant que vous ne décidiez d'y aller. C'est exactement ce que fait la Speculation Rules API : elle anticipe la navigation suivante et prérend la page complète, JavaScript exécuté, layout calculé, prête à être affichée d'un coup. Sous le capot, c'est une promesse simple et un piège analytics que beaucoup de devs découvrent trop tard.

La feature de base n'a rien d'expérimental. Le prefetch et le prerender via Speculation Rules sont stables dans Chrome depuis la version 109. Le paramètre eagerness, l'en-tête HTTP Speculation-Rules et le hint No-Vary-Search sont arrivés en stable avec Chrome 121. Autrement dit, ça tourne en production sur la majorité du parc Chromium depuis un bon moment, Edge inclus. Ce n'est pas une API de demain. C'est une API d'aujourd'hui que la plupart des sites n'ont jamais activée.

Le mécanisme tient dans une balise <script type="speculationrules"> qui contient du JSON. Vous y déclarez des objets prerender ou prefetch, chacun étant un tableau de règles. La version la plus directe liste les URLs en dur :

<script type="speculationrules">
	{
		"prerender": [
			{
				"urls": ["/produit-phare/", "/contact/"]
			}
		]
	}
</script>

Plus malin : les document rules. Plutôt que d'énumérer des URLs, vous décrivez une condition via le champ where, avec des sous-champs href_matches ou selector_matches et les opérateurs logiques and, or, not. Couplé au paramètre eagerness, c'est là que tout se joue.

Le champ eagerness accepte quatre valeurs et c'est le réglage qui sépare un site rapide d'un site qui crame sa bande passante pour rien. immediate lance le prérendu dès le chargement, c'est le défaut des règles par liste. eager déclenche à 10 ms de survol desktop (le comportement a changé en Chrome 143, avant c'était identique à immediate). moderate attend 200 ms de hover ou un pointerdown. conservative ne bouge qu'au pointer ou touch down, juste avant le clic réel. Plus vous descendez vers conservative, moins vous spéculez à perte, mais plus le gain de latence se réduit. Le bon réglage dépend de la confiance que vous avez dans la prochaine destination du visiteur.

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

Chrome borne le tout pour éviter les abus. La limite de prérendus concurrents est de 10 en immediate ou eager, et de 2 en moderate ou conservative. Pour le prefetch, c'est 50 et 2. En moderate ou conservative, le comportement est FIFO : au-delà du quota, la spéculation la plus ancienne est annulée et remplacée par la nouvelle. Vous ne pouvez donc pas prérendre tout votre catalogue d'un coup, et c'est tant mieux.

Le prérendu réduit le LCP au moment de la navigation parce que le rendu est déjà fait, et il améliore l'INP parce que le JavaScript a déjà tourné. Attention au raccourci, par contre. On lit parfois que le LCP tombe à zéro. C'est faux dans les métriques. Ce que le visiteur perçoit comme instantané, oui. Mais les Core Web Vitals et CrUX mesurent à partir de l'activation, c'est-à-dire du moment où la navigation a réellement lieu. Le prérendu améliore donc votre LCP mesuré, il ne l'annule pas.

Le cas Ray-Ban le montre noir sur blanc. Sur mobile, le LCP est passé de 4,69 s à 2,66 s, soit 43,28 % de mieux. Sur desktop, de 3,03 s à 1,74 s, soit 42,57 %. L'INP de la page Women Sunglasses a reculé de 521 ms à 395 ms, et le CLS s'est effondré de 0,46 à 0,08. Côté business, le taux de conversion mobile a grimpé de 101,47 %, le desktop de 156,16 %. Leur implémentation n'avait rien de sorcier : eagerness: "moderate" sur desktop pour les tuiles de listing au survol, eagerness: "immediate" sur les quatre premières tuiles en mobile. C'est ça le vrai sujet, du réglage fin, pas une formule magique.

Si vous mesurez vos propres sections au lieu de vous fier au LCP global, l'approche se marie bien avec la Container Timing API qui chronomètre le rendu de vos blocs. Et pour comprendre pourquoi ces trois métriques pèsent désormais dans le classement, le rappel sur les seuils Core Web Vitals 2026 et leur impact SEO reste la base à avoir en tête avant de toucher au prérendu.

Voilà où ça se complique, et honnêtement c'est le point où j'ai vu le plus de devs se planter. En mode prerender standard, le JavaScript de la page prérendue s'exécute pendant le prérendu, en arrière-plan. Votre snippet analytics part donc compter une vue de page que le visiteur n'a peut-être jamais regardée. Résultat : des pages vues fantômes, des taux de rebond faussés, des conversions attribuées à des sessions qui n'ont jamais eu lieu.

La protection existe et elle tient dans deux primitives. La propriété document.prerendering est un booléen en lecture seule qui vaut true tant que la page est en cours de prérendu. L'événement prerenderingchange se déclenche quand la page prérendue est activée, donc quand le visiteur navigue pour de vrai. Le pattern recommandé pour un tracking maison : vérifier document.prerendering, et différer l'initialisation de l'analytics jusqu'à l'événement prerenderingchange.

if (document.prerendering) {
	document.addEventListener('prerenderingchange', initAnalytics, {
		once: true,
	})
} else {
	initAnalytics()
}

Bonne nouvelle pour la majorité des sites : Google Analytics et Google Publisher Tag gèrent nativement le prérendu, pas de double comptage à craindre de leur côté. Le risque est sur votre tracking custom et sur les scripts tiers qui ne se sont jamais posé la question. Pour distinguer une vraie navigation d'un démarrage à froid, PerformanceNavigationTiming.activationStart donne le délai entre le début du prérendu et l'activation, et vaut 0 si la page n'a pas été prérendue. Pratique pour recaler vos timings.

C'est ici que le numéro de version porte à confusion. Le blog Chrome for Developers a annoncé le 23 janvier 2026 une variante nommée prerender-until-script. Le principe est élégant : le navigateur prérend le DOM mais suspend l'exécution du JavaScript jusqu'à la navigation réelle. Conséquence directe sur le sujet précédent, l'analytics ne se déclenche pas toute seule pendant le prérendu, puisque le script ne tourne pas. Le double comptage disparaît par construction, sans avoir à instrumenter quoi que ce soit.

Soyons clairs sur le statut, parce que le slug pourrait laisser croire le contraire : prerender-until-script est en origin trial, pas en stable. L'essai couvre Chrome 144 à 150 environ, sur desktop et Android, hors WebView. Vous pouvez le tester localement via chrome://flags/#prerender-until-script. Deux LGTM ont été obtenus côté blink-dev, ce qui est bon signe pour la suite, mais au 19 juin 2026 la feature n'est stable dans aucune version de Chrome. Bâtir une stratégie de production dessus aujourd'hui serait prématuré. La syntaxe utilise une clé JSON distincte, prerender_until_script, avec les mêmes champs urls ou where. À garder sous le coude, pas à déployer en confiance.

Côté navigateurs, Chrome et Edge 109+ couvrent le prefetch et le prerender de base. Firefox supporte une position favorable pour le prefetch dans les standards mais ne l'a pas encore expédié. Safari 26.2 embarque le support mais désactivé par défaut (source secondaire, à confirmer). La détection se fait proprement via HTMLScriptElement.supports("speculationrules"), et de toute façon la balise est silencieusement ignorée sur les navigateurs qui ne la comprennent pas. Progressive enhancement par défaut, donc rien à casser.

Mon conseil après l'avoir branché sur plusieurs sites : commencez en moderate sur les liens de navigation principale et les tuiles de listing, vérifiez vos métriques d'activation avant de monter en immediate, et auditez votre tracking maison avant même d'écrire la première règle. Le prérendu ne sert à rien si vos chiffres deviennent illisibles derrière. Pour aller plus loin sur la mesure des interactions une fois la page activée, le bilan INP au percentile 75 mi-2026 éclaire ce que vous gagnez vraiment côté réactivité. À vous de tester.

• Chrome for Developers Blog : prerender-until-script origin trial : https://developer.chrome.com/blog/prerender-until-script-origin-trial
• blink-dev mailing list : prerender-until-script : https://groups.google.com/a/chromium.org/g/blink-dev/c/ik4zDGK_yxY
• Chrome Developers : prerender-pages : https://developer.chrome.com/docs/web-platform/prerender-pages
• Chrome Developers : implementing-speculation-rules : https://developer.chrome.com/docs/web-platform/implementing-speculation-rules
• Chrome Developers Blog : speculation-rules-improvements : https://developer.chrome.com/blog/speculation-rules-improvements
• DebugBear : Speculation Rules : https://www.debugbear.com/blog/speculation-rules
• web.dev : Ray-Ban case study : https://web.dev/case-studies/rayban-speculation-rules
• MDN : Document.prerendering : https://developer.mozilla.org/en-US/docs/Web/API/Document/prerendering
• MDN : prerenderingchange event : https://developer.mozilla.org/en-US/docs/Web/API/Document/prerenderingchange_event
• MDN : PerformanceNavigationTiming.activationStart : https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming/activationStart
• MDN : Speculation Rules API : https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API