Speculation Rules API : précharger un site sans risque

La Speculation Rules API permet à un navigateur de précharger, voire de prérendre, les pages qu’un visiteur est susceptible d’ouvrir ensuite. Pour un site bien ciblé, cela peut rendre une navigation presque instantanée et améliorer les Core Web Vitals. Pour un projet PME, le gain est réel, mais il faut cadrer les règles pour éviter bande passante gaspillée, mesures analytics faussées et comportements imprévus.

Qu’est-ce que la Speculation Rules API change concrètement ?

La Speculation Rules API est une API web, c’est-à-dire une capacité fournie par le navigateur, conçue pour anticiper les navigations futures. Au lieu d’attendre qu’un utilisateur clique sur un lien, le site peut déclarer à l’avance quelles pages méritent d’être préparées.

Deux actions comptent aujourd’hui pour un décideur. Le prefetch télécharge le document HTML d’une page probable. Le prerender va plus loin : le navigateur charge et rend la page en arrière-plan, JavaScript compris, avant que l’utilisateur ne l’affiche réellement.

La différence business est simple. Un préchargement bien placé réduit l’attente. Un prérendu bien placé peut donner l’impression que la page s’ouvre instantanément. Chrome indique que le prérendu peut produire un LCP proche de zéro, réduire certains décalages visuels au chargement, et améliorer l’INP lorsque le travail de chargement est terminé avant l’interaction.

Le LCP, ou Largest Contentful Paint, mesure le temps nécessaire pour afficher le principal contenu visible. L’INP, ou Interaction to Next Paint, évalue la réactivité après une action utilisateur. Ces indicateurs font partie des Core Web Vitals, souvent surveillés dans les audits SEO et UX ; si votre site est déjà lent, commencez aussi par comprendre comment les mises à jour Google réagissent aux signaux de qualité.

Prefetch, prerender, prerender_until_script : trois niveaux d’anticipation

Le prefetch est le niveau le plus prudent. Le navigateur récupère le futur document, mais ne l’exécute pas comme une page complète. C’est utile pour une page catégorie, un article suivant ou une fiche produit consultée très souvent après une page donnée.

Le prerender est plus puissant, donc plus risqué. La page est chargée et rendue avant le clic, avec ses scripts, ses ressources et son état. D’après MDN, un prérendu consomme approximativement les ressources d’un rendu dans une <iframe>, ce qui devient vite lourd sur mobile ou sur des pages riches.

Une troisième action, prerender_until_script, est indiquée par Chrome comme expérimentale et sous origin trial depuis janvier 2026, à partir de Chrome 144. Les notes de Microsoft Edge 146 la mentionnent aussi. Honnêtement, cette option ne se justifie que pour des équipes techniques capables de suivre l’évolution des navigateurs et d’accepter une part d’instabilité.

La Speculation Rules API reste d’ailleurs marquée comme « Limited availability » et « Experimental » par MDN en 2026. Elle fonctionne surtout dans l’écosystème Chromium, notamment Chrome, Edge et Opera. Safari et Firefox ne doivent pas être considérés comme acquis dans un chiffrage projet.

Comment précharger ses pages avec la Speculation Rules API ?

Les règles peuvent être déclarées directement dans la page avec une balise <script type="speculationrules">. Elles peuvent aussi être envoyées via un en-tête HTTP Speculation-Rules, qui pointe vers un fichier JSON externe ; Chrome précise alors que la ressource doit être servie avec le type application/speculationrules+json.

Pour un responsable de projet, le point n’est pas de choisir une syntaxe élégante. Le vrai sujet est le ciblage. Précharger toutes les pages d’un menu parce que c’est techniquement possible est une mauvaise idée : vous augmentez la consommation réseau sans garantir de bénéfice perceptible.

Chrome recommande de limiter les prérendus à une ou deux pages au maximum. Le navigateur applique aussi ses propres limites selon le niveau d’empressement, appelé eagerness, qui indique si la règle se déclenche tôt ou seulement après un signal fort comme le survol ou le début d’un clic.

Sur les projets que nous menons, nous voyons souvent un arbitrage très rentable : commencer par une règle prudente sur deux ou trois transitions fréquentes, mesurer, puis élargir. Une boutique peut cibler la fiche produit la plus probable depuis une liste. Un média peut cibler l’article suivant. Un site B2B peut préparer la page contact seulement après un passage par une page offre.

1. Identifier les parcours les plus fréquents dans Matomo, Google Analytics 4 ou les logs serveur.
2. Écarter les pages sensibles : panier, compte, tunnel de paiement, formulaires préremplis.
3. Tester d’abord prefetch, puis réserver prerender aux pages vraiment prévisibles.
4. Contrôler les effets dans Chrome DevTools, section Application puis Speculative loads.
5. Mesurer LCP, INP, conversions et consommation serveur avant d’étendre.

WordPress 6.8 : une porte d’entrée plus simple, mais pas magique

WordPress 6.8 a introduit le chargement spéculatif dans le cÅ“ur du CMS en 2025. Make WordPress Core indique que le cÅ“ur inclut une règle par défaut au comportement conservateur, et que les développeurs peuvent ajouter leurs propres règles via wp_load_speculation_rules.

Le plugin WordPress « Speculative Loading » prend aussi en charge la Speculation Rules API et cible les navigateurs basés sur Chromium en version 121 ou supérieure, comme Chrome, Edge et Opera. Sa documentation indique que le chargement spéculatif est activé par défaut seulement pour les utilisateurs déconnectés, car les pages non authentifiées sont généralement plus faciles à mettre en cache et plus efficaces à précharger.

Cette nuance est essentielle. Un site vitrine WordPress avec cache serveur, CDN Cloudflare et pages publiques stables est un bon candidat. Un extranet, un WooCommerce complexe ou un espace membre avec contenus personnalisés réclame davantage de prudence.

Les fonctions et filtres WordPress disponibles en 2026, comme wp_speculation_rules_configuration, wp_get_speculation_rules(), WP_Speculation_Rules ou les filtres d’exclusion, permettent d’affiner le comportement. Côté agence, le réflexe est de traiter ces réglages comme une fonctionnalité de performance, pas comme une case à cocher dans l’administration.

Si votre projet repose déjà sur beaucoup d’extensions, il faut aussi regarder la chaîne complète : cache page, CDN, consentement cookies, scripts publicitaires, balises marketing et sécurité. Les risques ressemblent à ceux qu’on rencontre dans les architectures connectées à plusieurs services tiers, sujet proche des failles invisibles côté API quand les événements ne se déclenchent pas au moment attendu.

Gains mesurés : intéressants, mais dépendants du contexte

Les cas publics donnent des ordres de grandeur utiles. Google Search utilise le prefetch via Speculation Rules sur Android depuis octobre 2022 et l’a déployé sur desktop jusqu’en septembre 2024. Les résultats A/B rapportés par Chrome mentionnent, selon les lancements, une amélioration desktop de 7,6 ms sur le FCP et 9,5 ms sur le LCP, puis une autre amélioration LCP de 58,6 ms avec Chrome desktop.

Ces chiffres paraissent modestes. À l’échelle de Google Search, ils comptent. Pour une PME, ils montrent surtout que le prefetch seul n’est pas une baguette magique si la page est déjà rapide ou si le clic suivant est peu prévisible.

Les résultats deviennent plus parlants avec le prérendu. Une étude de cas Ray-Ban publiée sur web.dev en 2024 rapporte une baisse du taux de sortie de 13 % et un doublement du taux de conversion après usage du prérendu avec la Speculation Rules API. Une étude Monrif début 2025, combinant Speculation Rules prerender et bfcache, indique une réduction du LCP de 17,9 % et une amélioration de l’engagement de 8,9 %.

La bfcache, ou back-forward cache, est une mémoire du navigateur qui garde une page prête lorsqu’un utilisateur revient en arrière ou avance. Elle se travaille en parallèle du prérendu, car beaucoup de lenteurs ressenties viennent des allers-retours entre pages. C’est aussi là que des interfaces modernes, comme les transitions entre vues, peuvent compléter la performance technique ; le sujet rejoint les approches décrites autour de la View Transitions API si votre site en fait usage.

Un piège fréquent : confondre vitesse perçue et vitesse réelle de l’infrastructure. Le prérendu peut masquer une page lente après activation, mais il ne réduit pas toujours la charge serveur. Il peut même l’augmenter si des pages sont préparées puis jamais consultées.

Budget, délais et arbitrages pour un projet PME

Sur un WordPress récent, un premier test propre peut tenir en une demi-journée à deux jours si le thème est standard, le cache bien configuré et les parcours simples. Comptez plutôt trois à six jours pour un site e-commerce ou un site avec tracking avancé, car il faut exclure les pages à risque et vérifier les événements.

En budget français, selon les prestataires, l’ajout encadré de règles spéculatives sur un site existant se situe souvent autour de 500 à 2 500 € HT pour un audit léger, l’implémentation et la recette. Un chantier plus complet de performance, incluant Core Web Vitals, CDN, cache, images, JavaScript et mesures avant/après, peut monter entre 3 000 et 10 000 € HT selon la dette technique.

À ce budget, mieux vaut ne pas vendre la Speculation Rules API comme une action isolée si le site charge déjà 3 Mo de JavaScript inutile. Le meilleur retour sur investissement consiste souvent à réduire d’abord ce qui ralentit toutes les pages, puis à prérendre les deux navigations qui comptent vraiment.

La compatibilité impose aussi un arbitrage. Comme l’API n’est pas disponible partout, elle doit améliorer l’expérience des navigateurs compatibles sans dégrader les autres. C’est une amélioration progressive : Chrome et Edge en profitent, les autres continuent avec le fonctionnement classique.

Pour le SEO, restez pragmatique. Les sources fiables récentes insistent surtout sur le gaspillage de ressources et de bande passante en cas de mauvais ciblage, pas sur un impact direct prouvé sur le budget crawl de Googlebot. Si votre objectif est la visibilité, travaillez aussi les contenus, les données structurées et la cohérence éditoriale ; les données Schema.org utiles à la compréhension des pages peuvent compléter un chantier de performance.

Les pièges techniques que les non-techniciens découvrent trop tard

Le premier risque concerne l’analytics. Pendant un prérendu, une page existe déjà en arrière-plan, mais l’utilisateur ne l’a pas encore vue. Le codelab Google indique que Google Analytics et Google Publisher Tag retardent automatiquement certaines actions jusqu’à l’activation, mais d’autres fournisseurs ou scripts maison peuvent ne pas le faire.

Résultat possible : pages vues gonflées, pixels publicitaires déclenchés trop tôt, A/B tests faussés. Pour une direction marketing, c’est gênant. Vous prenez des décisions sur des données contaminées.

Autre limite : l’origine des pages. Chrome indique que le prérendu même origine est le comportement par défaut. Le prérendu cross-origin same-site exige que la cible accepte explicitement avec l’en-tête Supports-Loading-Mode: credentialed-prerender. Le prérendu cross-site n’est actuellement pas possible.

Dit simplement : vous ne pouvez pas prérendre librement n’importe quelle page d’un domaine tiers. Si votre tunnel de réservation, votre paiement ou votre configurateur est hébergé ailleurs, il faudra vérifier l’architecture. Même chose pour certains sous-domaines mal alignés.

Les pages avec état utilisateur méritent enfin une attention particulière. Panier, compte client, espace privé, devis dynamique, consentement cookies : tout ce qui dépend d’une session doit être exclu ou traité finement. Une navigation instantanée ne vaut pas une erreur de panier ou une donnée affichée au mauvais moment.

Cadrer ce type de projet en amont évite la plupart des mauvaises surprises : choix des pages, règles d’exclusion, mesure avant/après, puis déploiement progressif. C’est souvent là qu’un regard extérieur fait gagner du temps, surtout quand performance, SEO, hébergement et tracking se croisent.

FAQ sur la Speculation Rules API

La Speculation Rules API fonctionne-t-elle sur tous les navigateurs ?

Non. En 2026, MDN la classe encore en disponibilité limitée et expérimentale. Elle concerne surtout les navigateurs basés sur Chromium comme Chrome, Edge et Opera.

Faut-il activer le prérendu sur toutes les pages WordPress ?

Non. Il vaut mieux commencer par les pages publiques très probables et exclure panier, compte, paiement, formulaires et contenus personnalisés. WordPress 6.8 adopte justement un comportement conservateur par défaut.

La Speculation Rules API améliore-t-elle directement le SEO ?

Elle peut améliorer des signaux de performance comme le LCP ou l’expérience perçue, ce qui aide un site déjà cohérent. Elle ne remplace pas un contenu utile, une architecture claire ni un travail technique global.

Quel est le coût réaliste pour l’implémenter ?

Pour un site existant simple, prévoyez souvent 500 à 2 500 € HT selon le niveau de test. Un chantier performance plus large peut atteindre 3 000 à 10 000 € HT.

Comment vérifier que les règles fonctionnent ?

Chrome DevTools propose une section Application puis Speculative loads pour inspecter les règles, les tentatives et les erreurs. Il faut compléter avec des mesures réelles sur LCP, conversions et analytics.