Speculation Rules API : Guide Complet (2026)

En 2026, les utilisateurs abandonnent un site si le contenu ne s'affiche pas en moins de 3 secondes. C'est brutal, mais c'est comme ça. Et même avec un LCP optimal et un bundle JavaScript réduit au strict minimum, chaque clic vers une nouvelle page relance tout le cycle : résolution DNS, connexion TLS, téléchargement HTML, parsing CSS, exécution JS. La Speculation Rules API vient casser cette mécanique en chargeant et en rendant les pages en arrière-plan avant que l'utilisateur ne clique. Le résultat est assez spectaculaire : un LCP à 0,4 s contre 3,1 s sans pré-rendu, soit une amélioration de 85 %.

Dans ce guide, on va voir comment implémenter cette API pas à pas, configurer les niveaux d'empressement (eagerness), éviter les pièges courants — analytics faussées, effets de bord — et l'intégrer dans vos frameworks préférés. Tout le code est prêt à copier-coller.

Qu'est-ce que la Speculation Rules API ?

La Speculation Rules API est une fonctionnalité native des navigateurs Chromium (Chrome, Edge, Opera) qui permet de précharger (prefetch) ou pré-rendre (prerender) des pages en arrière-plan via des règles déclaratives au format JSON. Elle remplace l'ancien <link rel="prerender"> — déprécié depuis un bon moment — et surpasse <link rel="prefetch"> grâce à une syntaxe plus expressive et un contrôle bien plus granulaire.

Point important : contrairement aux SPA qui simulent des navigations instantanées via un framework JavaScript souvent lourd, cette API cible les applications multi-pages (MPA). Vous obtenez la même fluidité sans la complexité ni le poids d'une SPA. Honnêtement, c'est l'un des meilleurs arguments en faveur des architectures MPA aujourd'hui.

Prefetch vs Prerender : quelle différence ?

L'API propose deux modes de chargement spéculatif. Chacun a son propre compromis coût/performance.

Prefetch (préchargement)

Télécharge uniquement le document HTML de la page cible
Les sous-ressources (CSS, JS, images) ne sont pas chargées à l'avance
Consomme peu de bande passante et de mémoire
Accélère la navigation, mais la page doit encore être rendue au moment du clic

Prerender (pré-rendu)

Télécharge la page complète et la rend dans un onglet invisible en arrière-plan
Charge toutes les sous-ressources, exécute le JavaScript, effectue les appels réseau
La page s'affiche quasi-instantanément lors de la navigation
Consomme plus de mémoire et de bande passante (c'est le prix à payer)

En pratique : utilisez le prefetch quand la probabilité de navigation est faible à modérée, et le prerender quand elle est élevée — typiquement la page suivante d'un tunnel d'achat ou le lien principal de navigation.

Implémentation : balise script inline

La méthode la plus directe, et souvent la première qu'on met en place, consiste à insérer un bloc <script type="speculationrules"> dans le <head> de la page.

Règles par liste d'URLs (list rules)

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/produits", "/a-propos", "/contact"]
    }
  ],
  "prefetch": [
    {
      "urls": ["/blog", "/faq"]
    }
  ]
}
</script>

Les list rules ciblent des URLs spécifiques. Leur eagerness par défaut est immediate : le navigateur lance la spéculation dès que le script est lu. Simple et efficace.

Règles par document (document rules)

Les document rules sont bien plus intéressantes car elles s'appliquent dynamiquement à tous les liens correspondant à un pattern :

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/deconnexion" } },
          { "not": { "href_matches": "/panier/*" } },
          { "not": { "selector_matches": ".no-prerender" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Ici, toutes les pages internes sont pré-rendues sauf la déconnexion et le panier (qui ont des effets de bord — on y reviendra). Le eagerness: "moderate" déclenche la spéculation au survol du lien pendant 200 ms, un bon compromis entre réactivité et économie de ressources.

Implémentation : en-tête HTTP Speculation-Rules

Si vous préférez garder un HTML propre (et franchement, qui n'aime pas un HTML propre ?), vous pouvez externaliser les règles via un en-tête HTTP :

# Réponse HTTP du serveur
Speculation-Rules: "/speculation-rules.json"

Le fichier JSON doit être servi avec le type MIME application/speculationrules+json :

{
  "prefetch": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}

Et voici la configuration Nginx correspondante :

location /speculation-rules.json {
    types { application/speculationrules+json json; }
    add_header Cache-Control "public, max-age=3600";
}

Cette approche est particulièrement adaptée aux sites dynamiques où les règles sont gérées côté serveur, sans toucher au front-end.

Niveaux d'empressement (eagerness) : ce qui a changé en 2026

Le paramètre eagerness contrôle quand le navigateur déclenche la spéculation. C'est probablement le réglage le plus important à bien comprendre.

Eagerness	Déclenchement	Cas d'usage
`immediate`	Dès que la règle est lue	Pages à très forte probabilité de visite
`eager`	Desktop : survol 10 ms (Chrome 143+). Mobile : heuristiques viewport (janvier 2026)	Liens principaux de navigation
`moderate`	Survol 200 ms ou pointerdown	Bon compromis pour la plupart des sites
`conservative`	Uniquement au pointerdown / touchstart	Sites à bande passante limitée

Nouveauté 2026 : depuis Chrome 143, le niveau eager n'est plus identique à immediate — une distinction qui n'existait pas avant. Sur desktop, il attend un survol de 10 ms. Sur mobile, depuis janvier 2026, il utilise des heuristiques de viewport qui analysent la position des liens par rapport au scroll de l'utilisateur. Un changement subtil mais qui a un vrai impact sur la consommation de ressources.

Valeurs par défaut (à retenir) :

List rules (urls) → immediate
Document rules (where) → conservative

Limites imposées par Chrome

Chrome protège les utilisateurs (et leurs forfaits data) contre la sur-spéculation en imposant des limites strictes :

Eagerness	Prefetch max	Prerender max
`immediate` / `eager`	50	10
`moderate`	2 (FIFO)	2 (FIFO)
`conservative`	2 (FIFO)	2 (FIFO)

Les niveaux moderate et conservative fonctionnent en FIFO (First In, First Out) : quand la limite est atteinte, la spéculation la plus ancienne est annulée pour faire place à la nouvelle. Pas d'inquiétude cependant — elle peut être relancée si l'utilisateur survole à nouveau le lien.

À noter que Chrome désactive complètement les spéculations dans certains cas :

Mode Économie d'énergie activé
Contraintes mémoire (appareils bas de gamme)
Option « Précharger les pages » désactivée (ou bloquée par des extensions comme uBlock Origin)
Onglets ouverts en arrière-plan

Éviter les analytics faussées et les effets de bord

C'est LE piège classique. Le pré-rendu exécute le JavaScript de la page cible, ce qui peut déclencher vos scripts analytics ou d'autres actions indésirables avant même que l'utilisateur n'ait visité la page.

Problème : double comptage des pages vues

Si votre script analytics s'exécute normalement pendant le prerender, chaque page pré-rendue sera comptée comme une visite réelle. Imaginez l'impact sur vos métriques quand un utilisateur survole dix liens sans cliquer dessus.

Solution : utiliser document.prerendering

// Différer l'initialisation analytics jusqu'à l'activation réelle
function initAnalytics() {
  // Votre code Google Analytics, Matomo, etc.
  gtag('event', 'page_view');
}

if (document.prerendering) {
  // La page est en cours de pré-rendu — attendre l'activation
  document.addEventListener('prerenderingchange', () => {
    initAnalytics();
  }, { once: true });
} else {
  // Navigation normale
  initAnalytics();
}

Google Tag Manager (GTM) conditionnel

// Injecter GTM uniquement après activation
function loadGTM() {
  const script = document.createElement('script');
  script.src = 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXXX';
  document.head.appendChild(script);
}

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

Bonne nouvelle toutefois : Google Analytics 4 et Google Publisher Tag gèrent déjà nativement le prerender et ne comptent les vues qu'après l'activation. Mais vérifiez bien vos outils tiers — Matomo, Plausible, scripts maison — car eux ne le font pas forcément.

Exclure les URLs à effets de bord

Ne pré-rendez jamais des pages qui déclenchent des actions serveur sur un GET. Voici un exemple de configuration défensive :

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/deconnexion" } },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "href_matches": "/panier/ajouter/*" } },
          { "not": { "href_matches": "/paiement/*" } },
          { "not": { "selector_matches": "[data-no-prerender]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Intégration dans les frameworks populaires

WordPress : plugin officiel Speculative Loading

L'équipe WordPress Core Performance (qui inclut des développeurs Google) a créé le plugin Speculative Loading. L'installation est simple — un clic suffit — et il ajoute automatiquement des document rules à toutes vos pages.

# Installation via WP-CLI
wp plugin install speculation-rules --activate

Dans les réglages, vous choisissez le mode (prefetch ou prerender) et le niveau d'empressement. Des filtres PHP permettent d'exclure des URLs spécifiques si besoin.

Astro : support expérimental natif

Depuis Astro 4.2, le support est disponible en mode expérimental. Avec Astro 6 (sorti en mars 2026), l'intégration Cloudflare native apporte encore plus de possibilités :

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  prefetch: {
    prefetchAll: true,
    defaultStrategy: 'viewport'
  },
  experimental: {
    clientPrerender: true  // Active la Speculation Rules API
  }
});

Ce qui est bien pensé, c'est qu'Astro utilise automatiquement la Speculation Rules API pour les navigateurs compatibles et se rabat sur un prefetch classique pour les autres. Pas de code conditionnel à écrire de votre côté.

Injection JavaScript universelle

Pour tout autre framework ou site statique, l'injection dynamique fait le travail :

// Ajouter des règles de spéculation dynamiquement
if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {

  const rules = {
    prerender: [{
      where: { href_matches: '/*' },
      eagerness: 'moderate'
    }]
  };

  const script = document.createElement('script');
  script.type = 'speculationrules';
  script.textContent = JSON.stringify(rules);
  document.head.appendChild(script);
}

Le test HTMLScriptElement.supports('speculationrules') vérifie la compatibilité avant d'injecter quoi que ce soit. Les navigateurs non supportés ignorent simplement le bloc — aucune erreur, aucun fallback à gérer manuellement.

Combiner avec la View Transitions API

Alors là, on entre dans ce qui est (à mon avis) la combinaison la plus excitante pour le web en 2026. La Speculation Rules API et la View Transitions API forment un duo redoutable pour recréer l'expérience fluide d'une SPA sur un site multi-pages :

/* Activer les View Transitions cross-document */
@view-transition {
  navigation: auto;
}

/* Transition de fondu pour le contenu principal */
main {
  view-transition-name: main-content;
}

::view-transition-old(main-content) {
  animation: fade-out 150ms ease-out;
}

::view-transition-new(main-content) {
  animation: fade-in 150ms ease-in;
}

@keyframes fade-out {
  from { opacity: 1; }
  to { opacity: 0; }
}

@keyframes fade-in {
  from { opacity: 0; }
  to { opacity: 1; }
}

Le prerender garantit que la page cible est prête instantanément, et la View Transition anime le changement visuellement. L'utilisateur perçoit une navigation fluide, sans aucune latence — comparable à une app native. Pour avoir testé cette combinaison sur plusieurs projets, la différence d'expérience utilisateur est vraiment frappante.

Déboguer avec Chrome DevTools

Conseil : ne déployez jamais vos règles sans les avoir d'abord testées dans DevTools. Chrome propose un panneau dédié pour ça.

Ouvrez DevTools (F12)
Allez dans l'onglet Application
Dans le menu latéral, trouvez Speculative Loads
Cliquez sur Rules pour voir vos règles actives
Cliquez sur Speculations pour suivre les spéculations en cours

Vous pouvez observer en temps réel quels liens sont préchargés ou pré-rendus quand vous survolez les éléments de la page. Le statut de chaque spéculation (pending, running, ready, failure) est affiché avec la raison d'un éventuel échec.

Astuce pratique : dans l'onglet Network, filtrez par Purpose: prefetch pour isoler les requêtes de la Speculation Rules API. Ça permet de vérifier rapidement que seules les bonnes pages sont préchargées.

Résultats de performance mesurés

Les chiffres parlent d'eux-mêmes. Voici des données terrain qui montrent l'impact réel de cette API :

Métrique	Sans prerender	Avec prerender	Amélioration
LCP (P75)	714 ms	537 ms	-25 %
LCP (P95)	~1 200 ms	~700 ms	-42 %
LCP (avec Navigation AI)	3 100 ms	400 ms	-87 %
CLS	0,30	0,06	-80 %

Dans les tests terrain, 59 % des navigations ont déclenché un pré-rendu, avec un gain LCP moyen de 177 ms. Sur les sites e-commerce, cette réactivité se traduit directement en conversions. Ce n'est pas juste de l'optimisation théorique — c'est du chiffre d'affaires.

Checklist de déploiement

Auditer les URLs sensibles — identifiez les pages avec effets de bord (logout, panier, API) et excluez-les
Commencer par le prefetch — c'est moins risqué et ça valide que vos règles fonctionnent correctement
Passer au prerender progressivement — ciblez d'abord les liens de navigation principale
Choisir le bon eagerness — moderate est le meilleur compromis pour la grande majorité des sites
Protéger vos analytics — wrappez l'initialisation avec document.prerendering
Tester avec DevTools — vérifiez les règles dans Application → Speculative Loads
Mesurer l'impact — comparez LCP/CLS avant et après avec CrUX ou PageSpeed Insights
Surveiller le gaspillage — trackez le ratio spéculations déclenchées vs réellement activées

FAQ

La Speculation Rules API fonctionne-t-elle sur Firefox et Safari ?

Non, en avril 2026, elle est uniquement supportée par les navigateurs Chromium (Chrome, Edge, Opera, Chrome Android). Firefox et Safari ignorent silencieusement les règles — aucune erreur, les pages se chargent normalement. C'est du progressive enhancement pur : ceux qui supportent l'API en profitent, les autres ne sont pas pénalisés. Utilisez HTMLScriptElement.supports('speculationrules') si vous voulez proposer un fallback explicite.

Le prerender consomme-t-il trop de bande passante sur mobile ?

Moins qu'on pourrait le craindre. Chrome intègre des garde-fous : les spéculations sont désactivées en mode Économie d'énergie, en cas de mémoire insuffisante, et les limites FIFO plafonnent à 2 pré-rendus simultanés en mode moderate. Pour les connexions lentes, le niveau conservative (déclenchement au touchstart uniquement) est votre meilleur allié. Et depuis janvier 2026, les heuristiques viewport sur mobile optimisent automatiquement les déclenchements.

Comment mesurer le taux de spéculations « gaspillées » ?

Le plus simple : déclenchez un événement analytics à chaque insertion de règle, puis comparez avec les navigations effectivement réalisées. Chrome DevTools affiche aussi le statut de chaque spéculation (ready, triggered, activated). Si votre taux d'activation tombe sous 50 %, c'est un signal clair pour passer à un eagerness plus conservateur.

Puis-je combiner la Speculation Rules API avec un Service Worker ?

Tout à fait. Le Service Worker peut intercepter les requêtes de prefetch et servir des réponses depuis le cache. Les pages pré-rendues, elles, chargent leurs sous-ressources indépendamment. La stratégie qui fonctionne le mieux en pratique : le Service Worker pour le cache des ressources statiques, la Speculation Rules API pour le préchargement des documents HTML.

La Speculation Rules API remplace-t-elle les Resource Hints classiques ?

Elle remplace <link rel="prerender"> (déprécié) et améliore considérablement <link rel="prefetch">. En revanche, <link rel="preconnect"> et <link rel="dns-prefetch"> restent tout à fait pertinents pour les ressources tierces (CDN, API externes), car la Speculation Rules API ne cible que les documents HTML, pas les ressources individuelles.