Vous avez optimisé votre page d’accueil, compressé vos images, soigné votre LCP. Et pourtant, chaque clic de vos visiteurs vers une nouvelle page repart de zéro : requête, attente serveur, téléchargement, rendu. La Speculation Rules API change radicalement la donne : elle permet au navigateur de précharger, et même de générer entièrement en arrière-plan, la page que l’utilisateur s’apprête à visiter. Résultat : une navigation perçue comme instantanée, avec un LCP qui tombe à quelques millisecondes sur les navigations internes.
Au sein de l’Agence Web Performance, nous déployons cette API systématiquement, avec une configuration adaptée à chaque site, et c’est sur les sites e-commerce que nous observons l’impact le plus significatif. Voici comment elle fonctionne, ce qu’elle rapporte, et surtout comment la déployer sans se tirer une balle dans le pied.
Pourquoi la navigation entre vos pages reste lente
Quand on parle de web performance, on pense presque toujours à la première visite : celle que mesurent nos audits et les outils comme PageSpeed Insights. Mais un visiteur qui parcourt votre site enchaîne des dizaines de navigations, et chacune de ces navigations repaie l’intégralité du coût d’un chargement de page.
Ce qui se passe à chaque clic
À chaque clic sur un lien interne, le navigateur doit émettre une requête HTTP, attendre que le serveur génère et renvoie le HTML (c’est le TTFB, Time To First Byte), puis télécharger ce HTML, découvrir les ressources qu’il référence, les télécharger à leur tour, construire l’arbre de rendu et enfin peindre la page. Même sur un site parfaitement optimisé, cette chaîne prend rarement moins de 500 ms, et dépasse couramment 2 à 3 secondes sur mobile. Le cache navigateur atténue le coût des ressources statiques, mais le HTML lui-même, généralement non mis en cache sur un site dynamique, doit être régénéré à chaque fois.
C’est précisément ce constat qui a poussé les Single Page Applications à déplacer la navigation côté client : le routeur JavaScript évite de recharger une page complète. Mais les SPA paient ce confort au prix fort sur le premier chargement et sur l’indexation, un sujet que nous traitons en détail dans notre prestation d’audit de SPA. La Speculation Rules API offre aux sites classiques, multi-pages, la fluidité d’une SPA sans en hériter les inconvénients.
Les anciennes approches et leurs limites
L’idée d’anticiper la navigation n’est pas neuve. La balise <link rel="prefetch">, issue des Resource Hints du W3C, permettait déjà de télécharger une ressource pour la navigation suivante. Des bibliothèques comme instant.page ou quicklink ont ensuite automatisé le déclenchement au survol. Mais toutes ces approches partagent la même limite fondamentale : elles ne font que télécharger le HTML. Le parsing, le téléchargement des sous-ressources, l’exécution du JavaScript et le rendu restent entièrement à faire au moment du clic. L’ancienne balise <link rel="prerender">, censée aller plus loin, n’a jamais fait un rendu complet et est aujourd’hui dépréciée, comme l’explique la documentation Chrome sur le prerendering.
Côté WordPress, plusieurs plugins d’optimisation ont longtemps proposé une fonctionnalité équivalente en JavaScript : un script qui écoute le survol des liens et précharge la page correspondante. L’intention était la bonne, mais le coût est nettement plus élevé qu’avec l’API native : du JavaScript supplémentaire à télécharger et exécuter, des écouteurs d’événements sur chaque lien, et un simple préchargement du HTML là où le prerender natif prépare la page entière. Un point est crucial : ces fonctionnalités doivent être désactivées quand on active les Speculation Rules, car il s’agit d’une redondance complète. Les laisser cohabiter revient à précharger deux fois les mêmes pages, en pur gaspillage.
Speculation Rules : l’API qui anticipe la navigation
La Speculation Rules API est la réponse moderne à ce problème. Elle se déclare dans un simple bloc JSON embarqué dans la page, et elle permet de demander au navigateur de préparer les navigations futures, jusqu’au rendu complet de la page cible dans un onglet invisible. Quand l’utilisateur clique, le navigateur ne charge rien : il affiche une page déjà construite. Barry Pollard, Web Performance Developer Advocate chez Google, la décrit comme un outil quasi magique pour masquer le coût de la navigation dans sa présentation vidéo de l’API.
Prefetch ou prerender : deux niveaux d’anticipation
L’API propose deux modes. Le prefetch télécharge le HTML de la page cible à l’avance : au clic, on économise l’aller-retour réseau et le temps de génération serveur, soit l’essentiel du TTFB. Le prerender va beaucoup plus loin : il charge la page entière en arrière-plan, sous-ressources comprises, exécute son JavaScript et construit son rendu, comme dans un onglet caché qui remplace l’onglet courant au moment de l’activation, ainsi que le décrit la documentation officielle. C’est ce second mode qui produit l’effet de navigation instantanée : le LCP de la page activée se mesure alors en dizaines de millisecondes.
Des règles déclaratives en JSON
Concrètement, tout tient dans une balise <script type="speculationrules"> contenant du JSON. Depuis Chrome 122 et l’évolution majeure de l’API, les règles dites document peuvent cibler l’ensemble des liens de la page avec des motifs d’URL (href_matches) ou des sélecteurs CSS (selector_matches), ce qui permet de couvrir tout un site avec quelques lignes, en excluant chirurgicalement ce qui ne doit jamais être spéculé. Voici la forme minimale :
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/wp-admin/*" } },
{ "not": { "href_matches": "/wp-login.php*" } }
]
},
"eagerness": "moderate"
}]
}
</script>Un détail qui a son importance : si le JSON est malformé, le navigateur ignore silencieusement la règle, sans la moindre erreur en console. Nous avons audité plus d’un site où l’équipe croyait le prerendering actif alors qu’une virgule en trop l’avait désactivé depuis des mois. La validation fait partie de notre checklist de déploiement.
Le bloc inline n’est d’ailleurs pas la seule voie : les règles peuvent aussi résider dans un fichier JSON externe, déclaré via l’en-tête HTTP Speculation-Rules, comme le décrit la documentation Chrome. C’est le choix retenu par Shopify, qui teste actuellement l’API à l’échelle de sa plateforme en vue d’un déploiement généralisé, là où WordPress a opté pour la déclaration inline dans le HTML. Les deux approches sont fonctionnellement équivalentes ; l’en-tête HTTP facilite simplement un déploiement centralisé sur un parc de sites.
L’eagerness : régler l’agressivité de la spéculation
Le paramètre eagerness détermine quand le navigateur déclenche la spéculation, et c’est le principal curseur entre bénéfice utilisateur et gaspillage de ressources. La documentation Chrome définit quatre niveaux : immediate spécule dès que la règle est lue, eager s’en approche, moderate attend un survol de 200 ms (ou le début du toucher sur mobile), et conservative ne se déclenche qu’au pointerdown, c’est à dire au moment où le doigt ou le bouton de la souris s’enfonce, quelques dizaines de millisecondes avant le clic effectif.
Chrome encadre par ailleurs la mémoire consommée : en immediate, la limite est de 50 prefetch et 10 prerender simultanés ; en moderate ou conservative, elle tombe à 2, gérés en file FIFO : la spéculation la plus ancienne est annulée quand une nouvelle arrive. Ce mécanisme, détaillé dans la même documentation, rend le réglage moderate remarquablement sobre : on ne prépare que ce que l’utilisateur montre l’intention de visiter.
Quid du support navigateur ?
La Speculation Rules API est disponible dans les navigateurs basés sur Chromium (Chrome, Edge, Opera, Brave…) depuis Chrome 121 pour les règles document, comme l’indique la page de compatibilité MDN. Safari et Firefox l’ignorent purement et simplement, sans aucun effet de bord. C’est un cas d’école de progressive enhancement : les navigateurs compatibles, majoritaires sur la plupart des audiences françaises, profitent de navigations instantanées, les autres conservent leur comportement habituel. Aucun risque de régression, uniquement du gain.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Un impact mesurable, en particulier sur l’e-commerce
Passons aux chiffres, car c’est bien là que cette API se distingue de la longue liste des micro-optimisations. Sur les navigations activées depuis un prerender, le LCP descend typiquement sous les 100 ms : la page était déjà rendue, il ne reste qu’à l’afficher. À l’échelle d’un parcours utilisateur complet, l’effet sur les Core Web Vitals mesurés en conditions réelles (le RUM, celui qui alimente le rapport CrUX de Google) est massif, puisque les navigations internes représentent souvent la majorité des pages vues.
Le cas Ray-Ban : des conversions doublées
L’étude de cas la plus parlante est celle de Ray-Ban, documentée par l’équipe Chrome sur web.dev. En déployant le prerender sur les navigations entre pages de listing et fiches produit, la marque a fait passer son LCP mobile de 4,69 s à 2,66 s, soit 43 % d’amélioration.
Mais le chiffre qui intéresse un directeur e-commerce est ailleurs : le taux de conversion sur les fiches produit a progressé de 101 % sur mobile et de 156 % sur desktop, avec un taux de sortie en baisse de 13 %. Ces résultats illustrent une réalité que nous constatons sur tous nos projets : la vitesse perçue au fil du parcours pèse davantage sur la conversion que la vitesse du premier chargement.
Pourquoi l’e-commerce en profite plus que tout autre secteur
Un site e-commerce concentre tout ce qui rend le prerendering rentable. Les parcours y sont profonds et prévisibles : accueil vers catégorie, catégorie vers fiche produit, fiche produit vers panier. Chaque étape franchie rapproche de l’achat, et chaque seconde d’attente entre deux étapes offre une occasion d’abandon.
Le survol d’une vignette produit est un signal d’intention d’une fiabilité redoutable : quand un visiteur laisse sa souris sur un produit 200 ms, la probabilité qu’il clique est élevée, et le prerender a précisément le temps de préparer la fiche pendant ce délai. C’est la raison pour laquelle nous intégrons les Speculation Rules d’office dans nos prestations d’optimisation de la web performance, que le site tourne sous WooCommerce, PrestaShop ou Shopify.
Notre retour d’expérience
Nous déployons aujourd’hui les Speculation Rules systématiquement sur les sites que nous optimisons ou hébergeons, avec une configuration ajustée site par site. Sur les boutiques en ligne, nous observons de manière récurrente des navigations internes activées depuis un prerender avec un LCP quasi nul, des parcours listing vers fiche produit ressentis comme instantanés, et un effet d’entraînement sur les métriques CrUX du domaine dès que la part de navigations prerendered devient significative.
Le cas de figure le plus général est celui de la navigation entre pages de catégories et pages produits. Les Speculation Rules couvrent la navigation en avant (de la catégorie vers la fiche, de la fiche vers la fiche suivante), tandis que le back/forward cache prend en charge les retours en arrière, en restaurant instantanément la page de catégorie depuis la mémoire. L’association des deux produit, d’après ce que nous constatons, des gains allant jusqu’à 35 % de baisse sur les Core Web Vitals consolidées dans le CrUX : la quasi-totalité du parcours devient instantanée, dans les deux sens.
Ce retour d’expérience est cohérent avec les mesures publiées par des tiers : le tutoriel de CDN Planet sur Cloudflare documente par exemple, mesures avant/après à l’appui, l’effondrement du TTFB effectif des navigations spéculées. Précisons l’honnêteté méthodologique : ces observations relèvent de notre pratique d’agence, chaque site ayant ses propres facteurs de conversion ; c’est justement pour cela que nous mesurons systématiquement avant et après via notre monitoring de la web performance.
Comment nous le déployons : notre configuration type
Déployer les Speculation Rules ne consiste pas à coller un snippet trouvé en ligne. La valeur est dans le réglage : choisir le bon mode, la bonne eagerness, et surtout définir les exclusions propres au site. Voici la configuration qui nous sert de point de départ, et que nous adaptons ensuite.
La configuration de référence, commentée
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/wp-admin/*" } },
{ "not": { "href_matches": "/wp-login.php*" } },
{ "not": { "href_matches": "/*\\?*" } },
{ "not": { "href_matches": "/panier/*" } },
{ "not": { "href_matches": "/commande/*" } },
{ "not": { "href_matches": "/mon-compte/*" } },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate"
}],
"prefetch": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/*\\?*" } }
]
},
"eagerness": "conservative"
}]
}
</script>Décortiquons les choix. Le prerender en moderate se déclenche au survol prolongé, le signal d’intention le plus fiable, tout en restant dans la limite sobre de 2 spéculations FIFO. Le prefetch en conservative sert de filet de sécurité pour les clics sans survol préalable. L’exclusion /*\?* écarte toutes les URLs à paramètres : c’est elle qui neutralise en une ligne les URLs d’action de type ?add-to-cart=123, les liens de tri et de filtres à variantes infinies, et les paramètres de campagne.
Les chemins /panier/, /commande/ et /mon-compte/ sont exclus parce que leur contenu dépend de l’état de session et qu’un prerender y serait au mieux inutile, au pire trompeur. Enfin, la classe .no-prerender donne aux équipes un moyen d’exclure n’importe quel lien depuis le HTML, sans retoucher la règle.
Sur WordPress : le plugin Speculative Loading et le cœur de WordPress 6.8
Bonne nouvelle pour l’écosystème WordPress, sur lequel reposent nos prestations de création et d’optimisation WordPress : depuis WordPress 6.8, le chargement spéculatif est intégré au cœur du CMS, comme l’annonce l’équipe performance dans la note officielle Make WordPress Core. Le réglage par défaut est toutefois très prudent : un simple prefetch en conservative.
Pour aller chercher le vrai gain, celui du prerender, le plugin officiel Speculative Loading de l’équipe performance de WordPress active le prerender en moderate et expose le choix du mode et de l’eagerness dans les réglages de lecture. L’extension premium Perfmatters propose le même pilotage du mode et du niveau d’agressivité depuis son interface. Ces deux options sont pratiques quand on n’a pas de besoins particuliers côté exclusions ; dès que le site comporte des URLs d’action ou des pages de session spécifiques, on repasse sur une configuration manuelle.
Pour les exclusions spécifiques, WordPress 6.8 expose un filtre dédié. Voici comment nous ajoutons proprement les chemins sensibles d’un WooCommerce :
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $exclude_paths ) {
$exclude_paths[] = '/panier/*';
$exclude_paths[] = '/commande/*';
$exclude_paths[] = '/mon-compte/*';
return $exclude_paths;
} );À noter que le cœur exclut déjà d’office les URLs à paramètres et les zones d’administration. Notre travail consiste ensuite à vérifier, site par site, qu’aucune extension ne génère de lien d’action en GET non couvert par ces exclusions, un point que nous détaillons dans la section suivante.
Et sur Shopify ou sur une SPA ?
Sur Shopify, la balise <script type="speculationrules"> s’ajoute directement dans le thème Liquid, avec des exclusions adaptées (/cart, /checkout, /account) ; c’est un des leviers que nous actionnons dans nos missions d’optimisation Shopify. Sur une SPA, en revanche, l’API est largement sans objet : la navigation interne ne recharge pas de page, elle relève du routeur JavaScript. Les enjeux s’y déplacent vers le code splitting et le préchargement des données, ce que nous couvrons dans notre audit SPA.
Les pièges qui font la différence entre coller un snippet et savoir déployer
Si nous insistons autant sur la configuration, c’est que les Speculation Rules mal réglées peuvent produire des effets de bord bien réels. En voici les principaux, tous rencontrés sur le terrain.
Les statistiques faussées par les pages jamais vues
Un prerender charge et exécute une page complète : sans précaution, chaque page prerendered mais jamais visitée compterait comme une page vue. Google Analytics 4 gère nativement le cas en différant la mesure jusqu’à l’activation réelle de la page, tout comme Google Publisher Tag et AdSense, ainsi que le précise la documentation Chrome. Mais tous les outils de mesure, de test A/B ou de gestion du consentement n’en font pas autant. Le réflexe d’expert : conditionner l’exécution des scripts sensibles avec document.prerendering et l’événement prerenderingchange :
function initAnalytics() {
// initialisation du tracking, du consentement, etc.
}
if (document.prerendering) {
document.addEventListener('prerenderingchange', initAnalytics, { once: true });
} else {
initAnalytics();
}Les actions déclenchées sans clic
C’est le piège le plus dangereux. Si un lien déclenche une action côté serveur en GET (ajout au panier, déconnexion, suppression d’un élément), le prerender exécutera cette action au simple survol. Un site e-commerce dont les boutons d’ajout au panier pointent vers ?add-to-cart=123 remplirait les paniers de ses visiteurs à leur insu. Nos exclusions sur les URLs à paramètres et les chemins d’action couvrent ce risque, mais la vraie bonne pratique est plus profonde : une action qui modifie un état ne devrait jamais être un GET, c’est un principe d’architecture HTTP que le prerendering ne fait que remettre en lumière.
La charge serveur et les visiteurs sans clic
Chaque spéculation est une vraie requête servie par votre infrastructure. En moderate, le surcoût est marginal : on ne spécule que sur intention manifeste, dans la limite de 2 pages. En immediate sur tous les liens d’une page, en revanche, on peut multiplier le trafic serveur par dix sans aucun bénéfice pour la majorité des pages préparées. C’est un gaspillage de bande passante, de batterie sur mobile, et de ressources serveur.
Sur les infrastructures que nous gérons en hébergement WordPress performant, un cache de page bien configuré rend ces requêtes spéculatives quasi gratuites ; sur un hébergement sans cache, une eagerness agressive peut au contraire dégrader le TTFB de tous les visiteurs. Le réglage dépend donc directement de la qualité de l’infrastructure : encore une raison de ne pas copier-coller une config générique.
Les pages dépendantes de l’état de session
Un prerender fige un instantané de la page au moment de la spéculation. Si la page affiche un contenu qui change entre le survol et le clic (compteur de panier, stock en temps réel, messages personnalisés), l’utilisateur peut voir un état périmé. Chrome annule d’ailleurs automatiquement les prerenders trop anciens, mais la parade robuste consiste à exclure ces pages du prerender, ou à rafraîchir les données sensibles à l’activation via prerenderingchange. C’est typiquement le genre d’arbitrage que nous documentons lors d’un audit de web performance : quelles pages spéculer, lesquelles exclure, et pourquoi.
Comment vérifier que le prerendering fonctionne réellement
Dernier maillon, trop souvent négligé : la vérification. Entre le JSON qui échoue en silence, les limites mémoire et les exclusions, croire que ça marche ne suffit pas, il faut le prouver.
Dans Chrome DevTools
Chrome DevTools consacre aux Speculation Rules une section dédiée, documentée dans le guide officiel de débogage : le panneau Application liste les règles chargées, l’état de chaque spéculation (prête, en cours, échouée) et la raison précise des échecs. C’est le premier réflexe pour diagnostiquer une règle qui ne produit rien : motif d’URL qui ne matche pas, limite atteinte, ou page cible qui refuse le prerender.
En une ligne de console
Sur une page atteinte par navigation interne, la propriété activationStart de l’API PerformanceNavigationTiming dit toute la vérité. Une valeur supérieure à zéro confirme que la page a été activée depuis un prerender :
const nav = performance.getEntriesByType('navigation')[0];
if (nav.activationStart > 0) {
console.log('Page activée depuis un prerender après ' + nav.activationStart + ' ms');
} else {
console.log('Navigation classique, pas de prerender');
}Dans la durée : mesurer le taux de spéculations utiles
Au delà du test ponctuel, la vraie question est celle du rendement : quelle part des navigations bénéficie effectivement d’un prerender, et que gagne-t-on sur les Core Web Vitals réels ? En remontant activationStart comme dimension dans votre outil de mesure, on peut segmenter le LCP des navigations prerendered et des navigations classiques, et piloter le réglage de l’eagerness sur des données de terrain. C’est exactement le type de suivi que nous mettons en place dans notre monitoring de la web performance, avec des seuils d’alerte si le taux de spéculations utiles décroche après une mise en production.
Ce qu’il faut retenir
La Speculation Rules API est l’un des leviers de performance au meilleur ratio effort/impact de ces dernières années : quelques lignes de JSON bien pensées offrent des navigations internes instantanées aux navigateurs Chromium, sans aucun risque pour les autres. Les chiffres publics, Ray-Ban en tête avec ses conversions doublées, confirment ce que nous observons chez nos clients : c’est sur l’e-commerce, où chaque étape du parcours est une occasion d’abandon, que le gain est le plus significatif.
Mais l’API ne pardonne pas l’à-peu-près : exclusions d’URLs d’action, compatibilité analytics, charge serveur et pages à état de session exigent un réglage par site. C’est ce réglage, validé par la mesure, qui transforme une API prometteuse en résultat durable. Envie de savoir ce que des navigations instantanées changeraient pour votre site ? Parlons-en, un audit de web performance est le meilleur point de départ.
