Speculation Rules : prefetch et prerender pour le e-commerce

Sur un site e-commerce, le clic sur une fiche produit prend en moyenne 800 ms à 2 s avant le premier affichage. Les Speculation Rules permettent de ramener ce temps à quasi zéro – en préchargeant la page avant même que l'utilisateur ne clique.

Le principe : anticiper le prochain clic

Les Speculation Rules sont une API déclarative intégrée à Chrome depuis la version 121. Elles remplacent l'ancien <link rel="prefetch"> par un mécanisme plus puissant et plus contrôlable. Deux niveaux d'anticipation existent :

• Prefetch – télécharge le HTML et les sous-ressources critiques de la page cible. Le rendu se fait au clic.
• Prerender – va plus loin : le navigateur construit le DOM complet en arrière-plan. Au clic, la page s'affiche instantanément.

L'implémentation tient en un bloc JSON dans un tag <script type="speculationrules"> :

<script type="speculationrules">
{
  "prerender": [
    { "where": { "selector_matches": ".product-card a" }, "eagerness": "moderate" }
  ]
}
</script>

Le paramètre eagerness contrôle le déclenchement : conservative attend le hover, moderate anticipe un peu plus, eager précharge immédiatement.

Rayban : un des premiers à déployer en production

Rayban a été parmi les premières marques à intégrer les Speculation Rules sur ses PLP. Leur approche – cibler les liens des fiches produits visibles dans le viewport avec un eagerness: moderate. Résultat : les transitions PLP → PDP passent sous la barre des 200 ms de LCP perçu, contre 1,2 s auparavant.

💡 Le choix du moderate est stratégique. Un eager sur une PLP de 48 produits déclencherait 48 prerenders simultanés – un désastre pour la bande passante mobile. En moderate, Chrome ne précharge que les liens survolés ou proches du viewport.

Ce que j'ai mis en place pour CHANEL

Chez CHANEL, le contexte était différent. Le site est très visuel, avec des assets lourds – images haute résolution, vidéos. Le prerender complet aurait consommé trop de bande passante. On a opté pour une approche hybride :

• Prefetch sur les PLP pour les 6 premières fiches produits visibles
• Prerender uniquement dans le méga menu – les entrées qui absorbent la plus grande partie de la navigation sur certains axes.

⚠️ Jamais de spéculation sur les pages avec de la donnée dépendante de l'utilisateur (account, cart, checkout)

Le gain mesuré sur le terrain : –380 ms sur le LCP médian des pages concernées, et un impact mesurable sur les conversions

Quand les Speculation Rules apportent-elles un vrai gain ?

Tous les sites n'en tirent pas le même bénéfice. Les cas où le gain est le plus net :

• PLP → PDP avec des fiches produits prévisibles – les 3 à 6 premiers résultats captent la majorité des clics
• Méga menus vers des catégories phares – le parcours est très prédictible
• Pages éditoriales avec des CTA vers des landing pages fixes
• Moteur de recherche interne – prefetch du premier résultat

En revanche, sur un checkout multi-step ou un configurateur produit, les Speculation Rules n'apportent rien. Le parcours est linéaire et la page suivante dépend d'un formulaire côté serveur.

Les pièges à éviter

Le prerender consomme de la mémoire et du CPU. Chrome limite à 2 prerenders simultanés en moderate, 10 en eager. Dépasser ces limites ne déclenche pas d'erreur – les anciennes spéculations sont simplement abandonnées.

• Ne jamais prerender une page avec des effets de bord (ajout au panier, tracking de conversion)
• Monitorer l'impact sur la bande passante via PerformanceObserver avec le type speculation-rules
• Tester sur des connexions 3G lentes – un prefetch de 500 Ko sur du réseau limité peut ralentir la page en cours
• Vérifier la compatibilité : Chrome 121+ uniquement. Safari et Firefox ignorent silencieusement le tag.

Comment tester les speculation rules ?

Pour vérifier le bon fonctionnement des règles mises en place, le Chrome Devtools est généreux en détails. Dans l'onglet Application, il est possible de voir toutes les règles définies pour la page courante. Lors d'un prefetch ou d'un preload, celui-ci est enregistré dans l'onglet dédié aux Speculative loads. Il peut être trouvé dans Application > Background services > Speculative loads.

Mesurer l'impact réel

Le CrUX ne capture pas directement les gains de speculation (il est uniquement possible de voir quelle part des pages vues ont été pré-chargées) – les métriques LCP/FCP sont mesurées sur le chargement initial, pas sur les navigations soft. Pour mesurer l'effet, il faut instrumenter côté RUM :

performance.getEntriesByType("navigation").forEach(entry => { if (entry.activationStart > 0) { console.log("Page prerendered, activation delay:", entry.activationStart); } });

La propriété activationStart est non-nulle quand la page a été prérendue. C'est le seul moyen fiable de quantifier combien et quelles navigations ont bénéficié du prerender.

Les Speculation Rules ne remplacent pas les optimisations classiques – un mauvais TTFB reste un mauvais TTFB, prerender ou pas. Mais sur un site déjà bien optimisé, elles effacent le dernier point de friction : le temps de transition entre pages.