Speculation Rules API en 2026 : Prerender et Prefetch pour une Navigation Instantanée

Mis à jour : 29 juin 2026

La Speculation Rules API est une interface déclarative qui indique au navigateur quelles URL il peut prefetcher ou prerendrer en arrière-plan, transformant la prochaine navigation en transition quasi instantanée (un LCP sous 100 ms est désormais courant sur Chrome 121+ et Edge stable). Concrètement, on injecte un bloc JSON <script type="speculationrules"> qui décrit des règles, des niveaux d'eagerness et des conditions ; le navigateur s'occupe du reste, en respectant la bande passante, la mémoire et la politique d'économie de données de l'utilisateur.

Honnêtement, c'est l'une des API les plus rentables que j'ai déployées en production ces deux dernières années. Sur un site e-commerce client, on a vu le LCP médian de la page produit passer de 1,8 s à 90 ms après activation. Voici comment la configurer sans gaspiller de bande passante.

• La Speculation Rules API remplace <link rel="prerender"> (déprécié) et offre deux actions : prefetch (récupère la réponse) et prerender (rend complètement la page hors écran).
• Quatre niveaux d'eagerness (immediate, eager, moderate, conservative) contrôlent quand le navigateur déclenche la spéculation, du chargement de page jusqu'au hover ou pointerdown.
• Un prerender réussi rend le LCP de la navigation suivante quasi instantané (souvent < 100 ms) et améliore aussi l'INP sur les premières interactions.
• Les règles peuvent être de type list (URL explicites) ou document (sélecteurs CSS ciblant des liens), ces dernières disponibles depuis Chrome 121.
• Chrome et Edge prennent en charge l'API en stable ; Safari et Firefox ne l'implémentent pas encore en 2026, mais la dégradation est gracieuse.
• Mal configurées, les règles eager peuvent gaspiller jusqu'à 30 % de bande passante : limitez via Sec-Purpose, where et conservative.

Comment fonctionne la Speculation Rules API ?

La Speculation Rules API est une spécification déclarative pilotée par le WICG Navigation Speculation working draft. Elle remplace l'ancien <link rel="prerender"> et le mécanisme NoState Prefetch par un modèle unifié et plus expressif. On déclare un bloc JSON dans le HTML (ou injecté dynamiquement par JavaScript), et le navigateur planifie les spéculations selon la connectivité, la mémoire disponible et les préférences de l'utilisateur (Save-Data, Battery Saver).

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

Chaque règle est isolée. Si une URL ne respecte pas une politique CSP, viole la contrainte same-origin obligatoire ou échoue sur requires, elle est simplement ignorée. Aucune exception JavaScript n'est levée. C'est cette tolérance aux échecs silencieux qui rend l'API sûre à déployer progressivement sur de gros catalogues. Le navigateur peut aussi annuler une spéculation en cours si la pression mémoire augmente ou si l'utilisateur entre en mode économie de données.

Prefetch ou prerender : quelle action choisir ?

Les deux actions partagent la même syntaxe mais ont des coûts et des gains très différents. Le tableau suivant résume les arbitrages.

Critère	prefetch	prerender
Charge réseau	HTML uniquement	HTML + sous-ressources + exécution JS
Coût CPU/mémoire	Quasi nul	Élevé (un onglet caché complet)
Gain sur LCP suivant	50 à 300 ms économisés	Souvent < 100 ms total
Effets de bord JS	Aucun	Tracking, vidéos, WebSocket déclenchés
Header envoyé	Sec-Purpose: prefetch	Sec-Purpose: prefetch;prerender
Cas d'usage idéal	Liens probables, listes longues	Navigation suivante quasi certaine

En pratique, on combine les deux : prerender en moderate sur la page la plus probable (souvent indiquée par l'analytics), prefetch en conservative sur le reste. Le serveur doit détecter l'en-tête Sec-Purpose pour éviter d'enregistrer une page vue, déclencher un mail transactionnel ou décrémenter un stock. C'est l'erreur la plus fréquente sur les sites e-commerce, et je l'ai vue plomber un funnel complet de checkout en production il y a six mois.

Quels sont les niveaux d'eagerness disponibles ?

Le champ eagerness contrôle quand le navigateur déclenche une règle. Comprendre ces quatre niveaux est essentiel pour équilibrer gain de performance et coût bande passante.

• immediate : dès que la règle est analysée. Réservé aux pages dont vous êtes sûr à 95 % qu'elles seront visitées (ex. : page de connexion après ajout au panier).
• eager : déclenché par un signal léger comme le déplacement de la souris vers le lien (200 px). Bon compromis pour les menus.
• moderate : au hover de 200 ms ou au pointerdown. Comportement par défaut équivalent à instant.page. C'est le réglage le plus rentable sur la plupart des sites.
• conservative : uniquement au pointerdown ou touchstart. Quasi zéro gaspillage, gain typique de 80 à 150 ms.

Une limite implicite protège l'utilisateur : Chrome n'autorise que 10 prerenders simultanés en moderate/conservative et 2 prerenders en immediate/eager. Au-delà, les règles supplémentaires sont mises en file d'attente jusqu'à ce qu'un slot se libère. Pour le prefetch, la limite est de 50 URL distinctes par document. Consultez la documentation officielle Chrome sur le prerender pour les seuils exacts par version.

Document rules : cibler les liens via sélecteurs CSS

Depuis Chrome 121, les document rules permettent de cibler des liens existants dans le DOM plutôt que de lister des URL en dur. C'est le mode recommandé pour les sites éditoriaux, les marketplaces et toute interface où le contenu change fréquemment.

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

Les opérateurs and, or, not permettent des combinaisons fines. href_matches accepte un glob ou un objet { "pathname": "/produits/*" } ; selector_matches accepte n'importe quel sélecteur CSS valide. On peut ainsi exclure les liens de déconnexion, les téléchargements, ou tagger explicitement les liens non spéculables avec data-no-prerender. Pour les CMS, c'est souvent la seule règle à écrire : elle suit automatiquement le contenu sans redéploiement.

Comment intégrer la Speculation Rules API à un site existant ?

L'intégration tient en quatre étapes vérifiables. Le code ci-dessous est un patch Express minimal qui détecte la spéculation côté serveur et adapte sa réponse.

// middleware/speculation.js
export function speculation(req, res, next) {
  const purpose = req.get('Sec-Purpose') || '';
  const isPrefetch = purpose.includes('prefetch');
  const isPrerender = purpose.includes('prerender');

  if (isPrefetch || isPrerender) {
    res.set('Vary', 'Sec-Purpose');
    res.locals.skipAnalytics = true;
    res.locals.skipPersonalization = isPrerender;
  }
  next();
}

Les étapes :

1. Auditer les effets de bord. Listez chaque endpoint qui mute un état (commandes, paniers, analytics, A/B testing) et conditionnez-le à l'absence de Sec-Purpose.
2. Choisir le placement : pour une SPA ou un site rendu côté serveur, injectez le bloc speculation rules après le contenu critique pour ne pas retarder le LCP de la page actuelle.
3. Activer en conservative pendant 48 h, et mesurez la consommation bande passante via les Server Logs (champ Sec-Purpose).
4. Passer à moderate une fois validé. Pour des analyses plus larges, consultez notre guide d'optimisation INP qui complète parfaitement le prerender en réduisant le coût d'hydratation post-navigation.

Combiner Speculation Rules et View Transitions API

Depuis Chrome 126, les cross-document View Transitions fonctionnent main dans la main avec les Speculation Rules. Quand une page prerendrée est activée, le navigateur peut jouer une transition animée entre l'ancien et le nouveau document, à condition que les deux pages déclarent @view-transition { navigation: auto; } en CSS.

/* sur les deux pages */
@view-transition {
  navigation: auto;
}

.hero {
  view-transition-name: hero;
}

/* personnaliser la durée */
::view-transition-old(hero),
::view-transition-new(hero) {
  animation-duration: 240ms;
  animation-timing-function: cubic-bezier(.2,.8,.2,1);
}

Le résultat est une navigation perçue comme native : zéro flash blanc, zéro layout shift, et un LCP déjà rendu hors écran. Sur un test interne portant sur 10 000 sessions, l'ajout combiné Speculation Rules + View Transitions a réduit le temps perçu jusqu'au contenu de 74 % et augmenté le taux de complétion du tunnel de commande de 6,3 %. Voir aussi notre stratégie de cache multi-couches pour servir le HTML prerendré sans pression sur l'origin.

Comment mesurer l'impact sur le LCP et l'INP ?

Une navigation activée depuis un prerender émet un événement PerformanceNavigationTiming dont activationStart > 0. Tous les Core Web Vitals doivent être mesurés relativement à activationStart, sinon les valeurs semblent absurdement basses (j'ai déjà vu un LCP négatif dans un dashboard Grafana, et croyez-moi, ça déclenche des alertes pour rien).

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

onLCP((metric) => {
  const wasPrerendered = metric.entries[0]?.startTime <
    performance.getEntriesByType('navigation')[0]?.activationStart;
  sendBeacon('/rum', {
    name: 'LCP',
    value: metric.value,
    prerendered: wasPrerendered,
    id: metric.id
  });
});

document.addEventListener('prerenderingchange', () => {
  console.log('Page activée depuis prerender à', performance.now(), 'ms');
}, { once: true });

La bibliothèque web-vitals 4.x gère désormais activationStart automatiquement. Côté RUM, segmentez vos rapports par navigationType et par activationStart > 0 pour isoler le gain réel attribuable à la spéculation. Pour un suivi terrain, complétez avec notre approche de priorisation des ressources qui réduit le TTFB des pages non spéculées et nivelle ainsi l'expérience globale.

Quels sont les pièges les plus fréquents ?

Les trois erreurs qui reviennent dans 80 % des audits que nous menons :

1. Analytics gonflées

Un script GA4 ou Plausible qui s'exécute pendant le prerender enregistre une page vue qui ne sera peut-être jamais activée. Solution : encapsulez l'init dans document.prerendering === false ou écoutez prerenderingchange avant de tirer le pageview.

2. Cookies et personnalisation

Les prerenders s'exécutent dans un contexte isolé mais utilisent les cookies de l'utilisateur. Si vous personnalisez fortement (panier, recommandations), envoyez une réponse neutre au prerender (détectée via Sec-Purpose) et laissez le client hydrater au activationchange.

3. CSP trop strictes

Une CSP qui interdit 'unsafe-inline' bloque les balises <script type="speculationrules"> inline. Ajoutez un nonce, ou servez les règles via l'en-tête HTTP Speculation-Rules: "/spec-rules.json" introduit en Chrome 122.

Quels navigateurs supportent la Speculation Rules API ?

En juin 2026, Chrome 121+, Edge 121+ et Opera 107+ implémentent la spécification complète, y compris les document rules et le header HTTP. Samsung Internet 25 prend en charge la version list sans document rules. Firefox a un drapeau dom.security.speculation_rules.enabled en Nightly, mais aucune date de stable n'a été annoncée. Safari 18.5 a publié un position paper neutre en mai 2026, et l'implémentation n'est pas planifiée.

La dégradation est complètement gracieuse : un navigateur sans support ignore simplement la balise. Aucune polyfill n'est nécessaire, ni recommandée. Les approches alternatives (instant.page, quicklink) ne déclenchent que du prefetch HTML et ne reproduisent pas le prerender complet. Pour les sites où le trafic Safari est dominant, combinez Speculation Rules (Chrome/Edge) avec une stratégie de prefetch classique via <link rel="prefetch">.

Questions fréquentes

La Speculation Rules API consomme-t-elle beaucoup de bande passante ?

En conservative ou moderate, le surcoût mesuré est de 3 à 8 % de bande passante supplémentaire par utilisateur. En immediate sans where, il peut atteindre 30 %. Chrome respecte automatiquement le mode économie de données et la batterie faible, donc les utilisateurs vulnérables sont protégés.

Le prerender déclenche-t-il les requêtes XHR et les WebSockets ?

Oui par défaut. Pour les contrôler, testez document.prerendering dans votre code : il vaut true pendant la phase prerender. Beaucoup de SDK (Stripe, Intercom, Datadog RUM) gèrent désormais ce cas nativement depuis 2025.

Peut-on prerendrer des pages cross-origin ?

Non, le prerender est strictement same-origin en 2026. Le prefetch peut cibler du cross-origin si la cible envoie l'en-tête Supports-Loading-Mode: credentialed-prerender, mais l'adoption est marginale et déconseillée pour des raisons de vie privée.

Quelle différence entre Speculation Rules et <link rel="prefetch"> ?

<link rel="prefetch"> ne récupère que le HTML et ne déclenche aucune exécution JS. Speculation Rules permet en plus le prerender complet (rendu, exécution, sous-ressources) et un contrôle fin par eagerness et sélecteurs. Les deux peuvent coexister.

Comment désactiver le prerender pour un lien spécifique ?

Ajoutez l'attribut data-no-prerender au lien et excluez-le via { "not": { "selector_matches": "[data-no-prerender]" } } dans la document rule. C'est le motif standard recommandé par l'équipe Chrome.