Pourquoi anticiper la navigation change la perception de performance

Une page rapide n’est pas seulement une page dont le JavaScript est optimisé ou dont les images sont bien compressées. C’est aussi une page qui donne l’impression de répondre immédiatement aux intentions de l’utilisateur.

Sur un site de formation, une documentation, un blog technique ou une application avec beaucoup de pages, l’utilisateur suit souvent des chemins prévisibles : ouvrir un article recommandé, passer à la leçon suivante, consulter une fiche produit, revenir à une liste. La Speculation Rules API permet d’exploiter cette prévisibilité en demandant au navigateur de précharger, voire de prérendre, certaines pages avant le clic.

L’idée est simple : au lieu d’attendre que l’utilisateur clique pour démarrer la requête HTML, le navigateur peut commencer le travail plus tôt, sous contrôle déclaratif. Cette approche complète d’autres optimisations comme l’optimisation des images web, les Service Workers ou le cache frontend stale-while-revalidate, mais elle cible un moment très précis : la navigation entre deux documents.

Prefetch et prerender : deux niveaux d’anticipation

La Speculation Rules API repose principalement sur deux stratégies.

Prefetch

Le prefetch demande au navigateur de récupérer une ressource en avance, généralement le document HTML d’une page susceptible d’être visitée. Si l’utilisateur clique ensuite sur ce lien, une partie du coût réseau a déjà été payée.

C’est relativement peu intrusif : la page n’est pas exécutée entièrement, et le navigateur garde davantage de marge pour décider s’il est pertinent de lancer ou non le chargement.

Prerender

Le prerender va plus loin : le navigateur peut charger la page, construire le document, exécuter une partie du JavaScript et préparer le rendu dans un contexte isolé. Si l’utilisateur navigue vers cette page, elle peut apparaître quasiment instantanément.

C’est aussi plus coûteux. Une page prérendue consomme de la mémoire, du CPU, du réseau, et peut déclencher du code applicatif. Il faut donc l’utiliser sur des scénarios très probables, pas sur tous les liens d’un site.

Déclarer des règles de spéculation en HTML

La forme la plus directe consiste à ajouter un script de type speculationrules dans votre document. Ce script contient du JSON, pas du JavaScript exécutable.

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "list",
      "urls": [
        "/articles/cache-frontend-stale-while-revalidate",
        "/articles/service-workers-hors-ligne"
      ]
    }
  ]
}
</script>

Ici, le navigateur reçoit une indication : ces deux URLs sont de bonnes candidates au préchargement. Ce n’est pas une obligation absolue. Le navigateur peut tenir compte de l’état du réseau, de la batterie, de la mémoire ou de ses propres heuristiques.

Cette dimension est importante : vous exprimez une intention de performance, vous ne forcez pas mécaniquement le comportement.

Cibler les liens avec des règles automatiques

Énumérer les URLs à la main fonctionne pour quelques liens stratégiques, mais devient vite pénible. La Speculation Rules API permet aussi de cibler des liens selon des sélecteurs CSS.

<nav class="article-navigation">
  <a href="/articles/web-streams-api-javascript">Article précédent</a>
  <a href="/articles/performanceobserver-mesurer-frontend" class="next">Article suivant</a>
</nav>

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "selector_matches": ".article-navigation a.next"
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Dans cet exemple, on indique que le lien vers l’article suivant est un bon candidat au prerender. C’est typiquement pertinent dans un parcours linéaire : tutoriel, documentation, formation, onboarding ou tunnel de lecture.

Le champ eagerness permet de doser l’agressivité de la spéculation. Une stratégie prudente évite de gaspiller des ressources sur des liens peu susceptibles d’être visités.

Intégrer la Speculation Rules API dans une application

Dans un site généré avec un framework ou un moteur de templates, les règles peuvent être produites dynamiquement. L’objectif n’est pas de tout prérendre, mais de sélectionner les navigations les plus probables.

type SpeculationRules = {
  prefetch?: Array<{
    source: "list";
    urls: string[];
  }>;
  prerender?: Array<{
    source: "list";
    urls: string[];
  }>;
};

export function createSpeculationRules(urls: string[]): string {
  const rules: SpeculationRules = {
    prefetch: [
      {
        source: "list",
        urls: urls.slice(0, 3)
      }
    ]
  };

  return JSON.stringify(rules, null, 2);
}

Vous pouvez ensuite injecter ce JSON dans un layout serveur, une page Next.js, un template Nuxt ou un générateur statique. Dans une architecture moderne, cette logique gagne à rester côté serveur : vous connaissez souvent les contenus connexes, les articles suivants ou les pages prioritaires avant même d’envoyer le HTML.

Cette logique rejoint les problématiques abordées dans les React Server Components : moins vous attendez le navigateur pour prendre des décisions structurelles, plus vous pouvez livrer une expérience fluide avec peu de JavaScript client.

Bien choisir les pages candidates

Une mauvaise règle de spéculation peut dégrader la performance au lieu de l’améliorer. Le point clé est donc la sélection.

Les bons candidats sont généralement :

  • la page suivante dans une progression linéaire ;
  • les premiers résultats d’une navigation très utilisée ;
  • une page de détail depuis une liste lorsque l’intention est forte ;
  • une route critique après une étape de formulaire ;
  • une page interne légère, stable et fortement cacheable.

Les mauvais candidats sont souvent :

  • les pages qui déclenchent des effets de bord ;
  • les pages personnalisées avec des données sensibles ;
  • les routes très lourdes en JavaScript ;
  • les pages rarement visitées ;
  • les liens de déconnexion, paiement, suppression ou validation.

Le prerender exige une vigilance particulière. Une page prérendue ne doit pas déclencher une action métier simplement parce qu’elle a été préparée. Une route GET doit rester une route de lecture. Les mutations doivent passer par des actions explicites, généralement en POST, PUT, PATCH ou DELETE.

Vérifier que votre code supporte le prerender

Une page prérendue peut être activée plus tard. Certains traitements doivent donc attendre que la page devienne réellement visible.

function runWhenPageIsVisible(callback: () => void) {
  if (document.visibilityState === "visible") {
    callback();
    return;
  }

  document.addEventListener(
    "visibilitychange",
    () => {
      if (document.visibilityState === "visible") {
        callback();
      }
    },
    { once: true }
  );
}

runWhenPageIsVisible(() => {
  console.log("La page est réellement consultée");
});

Ce type de garde est utile pour l’analytics, les animations coûteuses, les connexions temps réel ou certains calculs différés. Pour les métriques de performance, vous pouvez compléter cette approche avec PerformanceObserver, afin de mesurer l’effet réel sur vos navigations.

Exemple avec une page d’article

Imaginons une page d’article avec trois liens importants : l’article suivant, un article lié et la page de formation associée. On peut adopter une stratégie mixte : prerender pour l’article suivant, prefetch pour les ressources secondaires.

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/articles/urlsearchparams-javascript"]
    }
  ],
  "prefetch": [
    {
      "source": "list",
      "urls": [
        "/articles/progressive-enhancement-web",
        "/formations/javascript"
      ]
    }
  ]
}
</script>

Cette stratégie est plus raisonnable qu’un prerender massif. Elle réserve le coût le plus élevé à la navigation la plus probable, tout en donnant un coup d’avance aux autres destinations.

Speculation Rules, SEO et accessibilité

La Speculation Rules API ne remplace pas une structure HTML correcte. Vos liens doivent rester de vrais éléments a avec des URLs valides. C’est indispensable pour l’accessibilité, le SEO, l’ouverture dans un nouvel onglet, la navigation clavier et le fonctionnement sans JavaScript.

C’est aussi une bonne illustration du progressive enhancement : le site doit fonctionner normalement sans spéculation, puis devenir plus rapide quand le navigateur prend en charge cette optimisation.

Côté SEO, cette API ne doit pas servir à masquer une architecture lente ou confuse. Elle améliore la perception de navigation, mais ne corrige pas un HTML trop lourd, des ressources bloquantes ou des pages mal structurées. Pour aider les moteurs à comprendre le contenu, les données structurées JSON-LD restent un outil plus directement adapté.

Bonnes pratiques d’adoption

Commencez petit. Ajoutez une règle sur un parcours évident, mesurez, puis élargissez progressivement. Les meilleures optimisations de performance sont celles que l’on peut vérifier.

Une méthode pragmatique consiste à :

  • identifier les navigations les plus fréquentes dans vos analytics ;
  • exclure toutes les pages à effets de bord ;
  • utiliser prefetch avant prerender ;
  • limiter le nombre d’URLs candidates ;
  • mesurer les gains réels sur les navigations ;
  • surveiller le poids réseau et l’usage mémoire.

Il faut également penser à la cohérence avec vos autres couches de cache. Une page déjà servie efficacement par le cache HTTP ou un Service Worker n’a pas les mêmes besoins qu’une page dynamique non cacheable. La Speculation Rules API est une brique supplémentaire, pas une stratégie de performance complète.

Conclusion

La Speculation Rules API est intéressante parce qu’elle ramène une idée très puissante dans le web multi-pages : anticiper les intentions sans imposer une architecture SPA. Pour un site de contenu, une documentation, une plateforme de formation ou une application à parcours prévisible, elle peut rendre certaines transitions presque instantanées.

Son efficacité dépend toutefois de votre discipline d’architecture. Les liens doivent rester sémantiques, les routes GET doivent être sans effet de bord, les règles doivent être limitées, et les gains doivent être mesurés. Utilisée avec parcimonie, cette API permet d’améliorer nettement la perception de vitesse sans complexifier inutilement le frontend.