Speculation Rules : accélérer le web sans tout précharger

Rendre une page rapide ne suffit pas toujours : il faut aussi réduire le temps perçu entre un clic et l’affichage de la destination. C’est précisément le terrain de la Speculation Rules API. Cette API navigateur permet de déclarer des URL que le navigateur peut préparer avant que l’utilisateur ne clique, via deux mécanismes distincts : le prefetch et le prerender.

L’idée n’est pas neuve. Les navigateurs connaissent depuis longtemps <link rel="prefetch"> et <link rel="prerender">, tandis que les équipes web préchargent des scripts, des polices ou des données depuis des années. La différence est importante : les Speculation Rules donnent au navigateur une description structurée des navigations probables, avec des règles d’éligibilité et des niveaux d’empressement. Elles permettent donc de raisonner en termes de parcours utilisateur, pas seulement en termes de ressources isolées.

Bien utilisée, cette API peut rendre une transition quasi instantanée sur un tunnel, une liste d’articles ou une interface métier. Mal configurée, elle peut faire télécharger ou exécuter des pages que personne ne consultera, brouiller les métriques analytics et augmenter inutilement la charge serveur. Le sujet n’est donc pas « faut-il tout prerendre ? », mais « quelles navigations méritent réellement d’être anticipées ? ».

Ce que la Speculation Rules API change face au préchargement classique

Le préchargement classique répond d’abord à une logique de dépendances. Par exemple, rel="preload" indique qu’une police, une image ou une feuille de style sera nécessaire rapidement. C’est utile pour le rendu de la page courante. Le prefetch historique, lui, invite le navigateur à récupérer une ressource susceptible d’être utile plus tard, souvent avec une priorité faible.

La Speculation Rules API travaille à un autre niveau : celui des documents de navigation. Elle se déclare généralement dans un script JSON embarqué dans la page.

Le navigateur garde la main sur la décision finale. Une règle décrit une intention de spéculation ; elle ne garantit pas qu’un téléchargement ou un prerender aura lieu dans tous les contextes.

Une règle simple de préchargement d’URL explicites peut prendre cette forme :

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": [
        "/guides/performance-web",
        "/guides/cache-http"
      ]
    }
  ]
}
</script>

Cette approche est déjà plus lisible qu’une succession de balises dispersées dans un template. Mais son intérêt devient plus net avec les règles documentaires : on peut cibler des liens présents dans la page à partir de sélecteurs CSS et de critères d’URL.

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": {
        "and": [
          { "selector_matches": "main article a" },
          { "href_matches": "/articles/*" }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Ici, l’intention est claire : anticiper certains liens éditoriaux dans la zone principale, sans toucher aux liens de navigation, aux pages de compte, aux liens externes ou aux destinations potentiellement coûteuses.

La documentation de référence est disponible sur MDN Web Docs. Avant toute mise en production, il faut aussi vérifier le support réel dans les navigateurs ciblés : l’API est principalement portée par les navigateurs basés sur Chromium, et une stratégie de performance ne doit jamais dépendre uniquement d’un mécanisme absent chez une partie des visiteurs.

Prefetch et prerender : deux niveaux d’anticipation très différents

La Speculation Rules API propose principalement deux actions : prefetch et prerender. Elles ne répondent pas au même besoin et n’ont pas du tout le même coût.

Le prefetch prépare surtout le réseau

Un prefetch demande au navigateur de récupérer la ressource de navigation afin qu’elle puisse être disponible plus vite si l’utilisateur choisit finalement cette destination. Il s’agit du choix le plus prudent pour une liste de contenus, une pagination, une catégorie ou une interface où plusieurs actions restent plausibles.

Le navigateur peut réutiliser les réponses obtenues selon les règles HTTP, le cache et le contexte de la navigation. Mais il ne faut pas considérer le prefetch comme une promesse de cache universelle : les en-têtes de réponse, les cookies, les redirections, les en-têtes Vary et le comportement du navigateur influencent la réutilisation effective.

Le prefetch est pertinent lorsque :

• la destination a une probabilité raisonnable d’être visitée ;
• le document est relativement léger ;
• la navigation n’exécute pas une action sensible ;
• un gain réseau est utile, sans nécessiter une page déjà prête à l’écran.

Le prerender prépare la page avant le clic

Le prerender va beaucoup plus loin. Le navigateur charge la page cible en amont et la prépare afin de pouvoir l’activer rapidement lorsque la navigation correspondante se produit. Cela peut fortement réduire la latence perçue, car le travail de navigation commence avant le clic.

Cette puissance explique son coût. Prerender une page revient à potentiellement charger son HTML, ses styles, ses scripts, ses images, ses appels API et ses ressources tierces alors même que l’utilisateur n’a pas confirmé son intention. Ce n’est donc pas un outil à appliquer à tous les liens d’un site.

Le prerender convient plutôt à un parcours séquentiel et à forte intention :

• le bouton « Continuer » d’un formulaire à étapes ;
• la page suivante d’un onboarding ;
• une fiche produit ouverte depuis un résultat dont l’utilisateur manifeste clairement l’intérêt ;
• un article vers lequel le pointeur se dirige ou sur lequel l’utilisateur appuie, selon la règle choisie.

Pour une première adoption, garder les règles sur des URL de même origine simplifie nettement les sujets de confidentialité, d’authentification, de cache et de diagnostic. Les navigations inter-origines introduisent des contraintes supplémentaires ; elles ne sont pas le bon point de départ pour un déploiement pragmatique.

Choisir le bon niveau d’empressement selon le parcours

Les règles peuvent inclure une propriété eagerness. Elle indique à quel point le navigateur peut être agressif pour déclencher la spéculation. Les valeurs disponibles comprennent notamment immediate, eager, moderate et conservative.

Il serait tentant de choisir immediate partout pour maximiser la sensation de vitesse. C’est précisément la mauvaise approche : une navigation probable n’est pas forcément une navigation certaine. L’empressement doit refléter l’intention observable, pas un souhait abstrait de performance.

Une grille de décision simple

• Conservative : pour une destination qui ne doit être anticipée qu’au plus près d’une interaction explicite. C’est un bon point de départ pour le prerender.
• Moderate : pour des liens ayant une probabilité crédible d’être activés, par exemple dans une liste de résultats ou un sommaire éditorial.
• Eager : à réserver à une petite sélection de destinations très prévisibles, comme l’étape suivante d’un parcours strictement linéaire.
• Immediate : à employer avec une extrême parcimonie, lorsqu’une page donnée est réellement l’étape quasi certaine et que son coût est maîtrisé.

Un site de contenu peut, par exemple, prefetche les liens des articles visibles dans le flux principal avec une règle modérée. En revanche, prerender toutes les fiches liées depuis une page d’accueil serait rarement justifiable : les visiteurs ouvrent une fraction de ces liens, tandis que le serveur et le réseau devraient potentiellement traiter beaucoup plus de pages.

Une interface SaaS a souvent un meilleur terrain d’application. Si une étape de configuration valide localement les données nécessaires et que le bouton principal mène presque toujours à l’écran suivant, un prerender prudent de cette étape peut être pertinent. Il faut toutefois exclure les écrans déclenchant des effets métier, des exports lourds, des requêtes de données volumineuses ou des flux dépendant d’autorisations susceptibles de changer.

Les coûts cachés : bande passante, serveur, cache et énergie

Une page spéculée mais jamais visitée n’est pas gratuite. Le premier coût est visible : des octets transitent sur le réseau. Sur une connexion mobile limitée, en itinérance ou sur un appareil modeste, ce trafic supplémentaire peut détériorer l’expérience globale au lieu de l’améliorer.

Le deuxième coût est côté infrastructure. Une page serveur peut exécuter une authentification, appeler une base de données, interroger un CMS, calculer des recommandations ou solliciter plusieurs API internes. Si le prerender multiplie ces requêtes sur des pages abandonnées, le serveur traite du travail sans bénéfice utilisateur.

Le troisième coût concerne le cache. Un document personnalisé par cookie, localisé ou variable selon l’utilisateur peut réduire les possibilités de réutilisation. À l’inverse, une page publique avec des réponses cacheables constitue un meilleur candidat. Il est utile de vérifier les en-têtes Cache-Control, les redirections et les variantes introduites par Vary avant de conclure qu’un prefetch apporte réellement un gain.

Enfin, une anticipation trop large consomme des ressources CPU, de la mémoire et de l’énergie. Cela compte en particulier sur mobile. Une stratégie de performance responsable ne vise pas uniquement le meilleur résultat sur une machine de développement connectée en fibre : elle évite aussi de déplacer le coût vers les visiteurs qui n’ont rien demandé.

Le bon indicateur n’est pas le nombre de pages spéculées. C’est la part des spéculations qui améliorent une navigation réellement effectuée, sans dégrader le reste du parcours.

Analytics et effets de bord : ce qu’un prerender peut fausser

Le prerender modifie le cycle de vie d’une page. Une page préparée n’est pas encore une page effectivement consultée. Or beaucoup de scripts analytics, tags publicitaires, pixels et outils de session replay sont initialisés dès le chargement du document. Sans précaution, une page non activée peut produire des événements qui ressemblent à des visites, des pages vues ou des conversions de parcours.

Le navigateur expose notamment document.prerendering et l’événement prerenderingchange. Ces signaux permettent de différer les opérations qui ne doivent démarrer qu’après activation réelle de la page.

function startAnalytics() {
  // Initialiser ici les mesures qui correspondent
  // à une page réellement affichée.
}

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

Ce principe vaut aussi pour certains effets applicatifs :

• envoyer un événement de consultation ;
• démarrer un minuteur de lecture ;
• déclencher une notification ou une boîte de dialogue ;
• lancer un polling coûteux ;
• effectuer une opération d’écriture côté serveur.

Il ne faut pas supposer que tous les scripts tiers traiteront correctement le prerender par défaut. Pour chaque outil réellement utilisé, qu’il s’agisse de Google Analytics, Matomo, Sentry, d’un gestionnaire de tags ou d’une solution publicitaire, vérifiez la documentation, observez les requêtes réseau et comparez les événements avant et après activation.

Les outils de développement des navigateurs et les traces réseau sont indispensables ici. Une règle de prerender doit être testée avec un compte connecté, un compte déconnecté, des données réelles et des cas de redirection. Tester uniquement une page statique en local ne permet pas d’identifier les effets de bord d’un produit réel.

Écrire des règles ciblées plutôt que précharger tous les liens

La grande force des Speculation Rules est de permettre un ciblage précis. C’est aussi leur principal piège : une règle trop large peut embarquer des zones du site qui n’auraient jamais dû être candidates.

Évitez, par exemple, une règle générique qui cible tous les liens a d’une page. Elle peut inclure :

• les liens du footer ;
• la déconnexion ;
• les mentions légales ;
• des filtres ou des recherches ;
• des liens sortants ;
• des pages d’administration ou de compte ;
• des URL avec paramètres coûteux.

Préférez des sélecteurs ancrés dans une zone fonctionnelle et des motifs d’URL restrictifs. Sur un média, on peut viser les liens d’articles du contenu principal. Sur une boutique, on peut viser une fiche mise en avant, pas l’intégralité du catalogue. Sur une application, on peut viser l’étape immédiatement suivante, pas tous les éléments du menu latéral.

Voici un exemple de règle prudente pour prerender des liens d’articles, à adapter et à tester :

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "selector_matches": "main .article-list a.article-link" },
          { "href_matches": "/articles/*" }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

Le sélecteur .article-list a.article-link est volontairement spécifique. Il impose une discipline utile : donner une classe ou un attribut explicite aux liens éligibles vaut mieux que tenter d’inférer l’intention depuis toute la structure du DOM.

Déployer progressivement avec des règles mesurables

La bonne méthode n’est pas de livrer une grande règle globale, puis d’espérer que les Core Web Vitals s’améliorent. Il faut procéder par itérations courtes, avec un périmètre réduit et des critères de décision explicites.

1. Choisir un parcours unique

Commencez par une navigation fréquente et prévisible : passage d’une liste à une fiche, étape suivante d’un onboarding, ou article suivant dans une série. Écartez les pages qui produisent des effets de bord ou dont le poids est inconnu.

2. Établir un état de référence

Mesurez la navigation sans règles de spéculation. Les données de terrain sont préférables aux seuls tests synthétiques. Le Web Vitals et les outils de mesure internes peuvent aider à suivre la réactivité et le ressenti de navigation, mais il faut compléter par des indicateurs métier : taux de clic, taux d’aboutissement, erreurs applicatives et volume de requêtes.

3. Démarrer par le prefetch

Le prefetch est généralement le moyen le moins risqué de valider l’hypothèse : la destination est-elle assez souvent visitée pour justifier le trafic anticipé ? Si le taux de réutilisation est faible, un prerender ne fera qu’amplifier le gaspillage.

4. Passer au prerender sur une cible étroite

Ajoutez ensuite une seule règle de prerender avec un niveau d’empressement conservateur. Contrôlez les requêtes, les logs serveur, les événements analytics et les erreurs JavaScript. Vérifiez qu’une page préparée mais non activée ne déclenche pas d’action métier indésirable.

5. Comparer le gain au coût

Une expérimentation doit répondre à deux questions : les utilisateurs qui naviguent vers la cible voient-ils un gain concret, et quelle proportion des chargements anticipés est abandonnée ? Si la seconde réponse est défavorable, réduisez la portée de la règle, baissez son empressement ou revenez au prefetch.

Compatibilité, dégradation gracieuse et maintenance

Les Speculation Rules ne doivent jamais être un prérequis fonctionnel. Un visiteur dont le navigateur ne les prend pas en charge doit pouvoir naviguer normalement, avec les mêmes liens, les mêmes routes et les mêmes données. L’API doit être conçue comme une optimisation progressive.

Pour cette raison, ne changez pas la logique d’un lien ou d’un bouton pour « accompagner » le prerender. Gardez une navigation HTML standard, des URL stables et des réponses serveur correctes. Le navigateur compatible accélérera éventuellement le parcours ; les autres suivront le flux normal.

La maintenance compte aussi. Une règle basée sur un sélecteur CSS est liée à la structure du front. Une refonte de composant peut rendre la règle trop large, inopérante ou orientée vers une mauvaise zone. Intégrez les règles de spéculation aux revues de code, aux tests de parcours et à l’observabilité applicative, au même titre que les redirections, le cache ou les balises SEO.

Enfin, gardez un inventaire minimal des règles en place : page source, URL cible, mécanisme choisi, raison métier, coût estimé et métriques surveillées. Ce document évite que des optimisations ponctuelles se transforment, au fil des versions, en préchargement généralisé impossible à expliquer.

Conclusion : accélérer les intentions, pas les hypothèses

La Speculation Rules API offre un levier concret pour rendre certaines navigations plus fluides sans imposer une architecture JavaScript lourde. Son intérêt est réel lorsque le parcours est prévisible, que la page cible est saine et que les effets réseau, serveur et analytics sont maîtrisés.

La méthode la plus robuste reste volontairement sobre : commencer par un parcours, préférer le prefetch quand l’incertitude est élevée, réserver le prerender aux intentions fortes, puis mesurer la réutilisation et les effets de bord. Avant d’ajouter une règle, examinez vos données de navigation réelles : elles indiqueront mieux que n’importe quelle promesse technique les liens qui méritent d’être anticipés.