Speculation Rules : accélérer la navigation sans tout précharger

Un site peut afficher un excellent score de chargement initial et rester frustrant à utiliser dès le deuxième clic. La page d’accueil est rapide, les images sont optimisées, le JavaScript est contenu… puis chaque navigation relance la séquence habituelle : requête du document, réponse serveur, chargement des ressources, rendu et hydratation éventuelle.

C’est précisément le problème que les Speculation Rules cherchent à traiter. Cette API web laisse le navigateur anticiper certaines navigations probables avec deux mécanismes : prefetch, qui récupère un futur document, et prerender, qui prépare une future page de manière bien plus complète.

L’objectif n’est pas de transformer chaque lien en téléchargement anticipé. Une telle stratégie déplacerait simplement le coût : plus de données transférées, plus de pression sur le cache, davantage de travail pour le serveur et parfois du CPU consommé pour des pages que personne ne visitera. L’enjeu consiste à repérer les transitions réellement prévisibles, à choisir le bon niveau d’anticipation et à vérifier l’effet dans les données terrain.

Pourquoi les clics de navigation restent un point faible des sites rapides

Les optimisations du chargement initial sont bien connues : HTML rendu côté serveur, feuilles de style limitées, images adaptées, cache HTTP cohérent, JavaScript différé quand il n’est pas nécessaire. Sur Forge Front, cette logique rejoint les recommandations présentées dans notre guide pour réduire le temps de chargement d’un site moderne.

Mais une navigation interne reste une nouvelle transaction. Même sur un site multipage très sobre, le navigateur doit généralement obtenir le prochain document avant de pouvoir produire le contenu utile. Sur une application JavaScript, il peut aussi devoir télécharger des modules, demander des données à une API et reconstruire l’interface.

Ce délai est particulièrement visible dans quelques parcours fréquents :

• une page de catégorie menant vers une fiche produit ;
• une liste d’articles menant vers un article ;
• un résultat de recherche menant vers une page de détail ;
• une page de documentation menant vers l’étape suivante ;
• un tunnel où la prochaine étape est explicite et attendue.

Une interface peut masquer une partie de l’attente avec un état de chargement. Cela reste préférable à une zone figée, mais ce n’est pas équivalent à une page déjà disponible. Les Speculation Rules s’intéressent à la vitesse perçue entre deux documents : elles exploitent le temps pendant lequel l’utilisateur lit, hésite ou survole un lien avant son clic.

Cette approche n’annule pas le besoin d’optimiser la destination. Une page lente à produire, une API instable ou un bundle excessif resteront des problèmes. L’anticipation est une couche complémentaire, pas une permission de négliger le HTML, le cache ou le poids des ressources.

Speculation Rules : ce que le navigateur peut anticiper

Les règles sont déclarées dans le document avec un élément script dont le type est speculationrules. Son contenu est du JSON. Le navigateur compatible peut alors décider de lancer des chargements spéculatifs selon les URL ou les liens correspondant aux critères fournis.

La documentation de référence est disponible sur MDN Web Docs. Il faut retenir un point important : les règles expriment une intention. Le navigateur conserve la décision finale selon son contexte, ses politiques et les conditions de l’appareil.

Prefetch : récupérer le prochain document à moindre coût

Avec prefetch, le navigateur peut récupérer le document d’une page susceptible d’être visitée. Au clic, il peut ainsi éviter une partie de l’attente réseau si cette ressource est encore exploitable dans son cache.

Le prefetch est le premier niveau à envisager lorsque la navigation est probable mais pas suffisamment certaine pour justifier un prérendu complet. C’est souvent le cas d’une grille d’articles, d’un catalogue ou d’une documentation comportant beaucoup de liens.

Son effet dépend toutefois des réponses HTTP, du cache, du moment où l’utilisateur clique et de la structure de la page cible. Il ne faut donc pas le présenter comme une garantie de navigation instantanée. Il réduit une partie du chemin critique potentiel ; il ne remplace pas une architecture performante.

Prerender : préparer une page avant l’activation

Avec prerender, le navigateur prépare une future navigation de façon plus poussée. Lorsqu’un utilisateur active effectivement le lien concerné, la page préparée peut être activée au lieu de suivre un chargement conventionnel.

Le gain potentiel est supérieur, mais le coût l’est aussi. Le prérendu peut mobiliser davantage de réseau, de mémoire et de CPU qu’un simple prefetch. Il convient donc aux cas où la prochaine page est très prévisible : un bouton « Continuer », la page suivante d’un processus linéaire, ou un lien mis en avant dans une interface dont l’usage est bien observé.

Il faut également penser au comportement applicatif. Une page préparée avant activation ne devrait pas déclencher prématurément une action irréversible, une mesure métier assimilée à une visite réelle ou un appel qui modifie des données. Le navigateur expose notamment document.prerendering et l’événement prerenderingchange pour adapter le code aux phases de prérendu et d’activation.

Le modèle de règles : URL explicites ou sélection de liens

Deux familles de règles répondent à des besoins distincts. Les list rules désignent une liste d’URL connue à l’avance. Les document rules ciblent des liens présents dans le document, à partir de conditions portant notamment sur leur URL.

Une liste explicite est appropriée quand l’étape suivante est unique ou presque unique. Par exemple, après une étape validée dans un assistant, une application peut savoir que la destination pertinente est la page suivante. C’est le terrain naturel d’un prérendu prudent.

Les règles appliquées aux liens sont plus adaptées à un contenu éditorial ou à un catalogue. Elles permettent de couvrir un ensemble d’URL, par exemple les pages situées sous un chemin donné, sans maintenir manuellement chaque lien.

Voici une structure volontairement simple pour précharger des pages d’articles internes :

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

Dans un document réel, ce JSON est placé dans un élément de type speculationrules. La condition href_matches sert ici à limiter le périmètre aux URL d’articles. La propriété eagerness indique le niveau d’empressement attendu. Les valeurs telles que conservative, moderate et eager permettent d’aligner le déclenchement sur l’intention observée de l’utilisateur plutôt que de tout lancer dès l’affichage.

La syntaxe exacte et les capacités disponibles évoluent avec les implémentations. Avant un déploiement, validez les règles dans les navigateurs réellement utilisés par votre audience et consultez la spécification des règles de spéculation ainsi que la documentation navigateur à jour.

Choisir les bonnes pages à anticiper, et seulement celles-là

Le critère déterminant n’est pas « cette page est importante ». Une page peut être importante pour l’entreprise et rester peu probable à l’instant où l’utilisateur consulte un écran. La bonne question est : quelle destination a une forte probabilité d’être ouverte très prochainement depuis cette page précise ?

Commencez par les parcours où l’intention est claire :

• le lien vers l’article depuis lequel un lecteur arrive le plus souvent après une page de liste ;
• la fiche détaillée mise en avant après l’application de filtres ;
• l’étape suivante d’un processus dont les données nécessaires sont déjà validées ;
• la navigation précédente ou suivante dans une documentation séquentielle ;
• le lien de continuité affiché à la fin d’un contenu long.

À l’inverse, évitez de spéculer agressivement sur :

• tous les liens visibles dans une mégaliste ou un menu global ;
• les résultats de recherche qui changent constamment ;
• les pages lourdes en médias, en visualisations ou en données privées ;
• les URL avec des paramètres instables ou fortement personnalisés ;
• les liens de déconnexion, de suppression, de paiement ou d’action métier sensible.

Un catalogue de 100 liens ne contient pas 100 prochaines pages probables. Précharger chaque fiche revient souvent à consommer de la bande passante pour des pages ignorées. Sur mobile, cette décision est encore plus coûteuse : le contexte réseau et la consommation de données comptent autant que le délai théorique gagné au clic.

La stratégie la plus sûre consiste à cibler un sous-ensemble réduit, puis à l’élargir uniquement lorsque les observations le justifient. Les règles de spéculation doivent suivre les parcours réels, pas une hypothèse esthétique sur la navigation.

Prefetch ou prerender : une décision de coût, pas de mode

Le prefetch est généralement le choix raisonnable pour une première expérimentation. Il permet de tester une hypothèse de navigation sans préparer intégralement chaque destination. Si une liste d’articles conduit régulièrement vers certaines pages, précharger ces documents sous une condition d’intention modérée est une piste cohérente.

Le prerender est réservé aux transitions où l’incertitude est faible. Une page « Confirmation » n’a pas vocation à être prérendue avant qu’une commande soit réellement validée. En revanche, une page suivante dans un lecteur de documentation, après un clic explicite sur « Continuer », peut constituer un candidat plus pertinent.

La distinction est aussi technique :

• prefetch vise principalement à avancer le téléchargement du document ;
• prerender prépare une navigation complète et impose donc une vigilance plus forte sur les effets de bord ;
• les deux mécanismes restent dépendants de la décision du navigateur et ne doivent pas être considérés comme des requêtes obligatoires ;
• les deux doivent cohabiter avec une politique de cache HTTP saine, pas la contourner.

Sur un site qui utilise déjà des transitions de navigation, l’API peut compléter une expérience fluide, mais elle ne fait pas le même travail. Les View Transitions concernent surtout la continuité visuelle entre états ; les Speculation Rules cherchent à réduire l’attente avant que l’état suivant soit disponible.

Préserver le cache, le serveur et les parcours authentifiés

Anticiper une page revient à créer du trafic avant une navigation confirmée. Pour un site de contenu statique servi par CDN, ce coût peut être acceptable sur un périmètre étroit. Pour une application connectée dont chaque document déclenche des requêtes personnalisées, le bilan mérite beaucoup plus d’attention.

Examinez notamment les pages candidates sous ces angles :

• le document est-il correctement mis en cache lorsqu’il peut l’être ?
• sa génération sollicite-t-elle une base de données ou des services coûteux ?
• embarque-t-il des scripts tiers non essentiels ?
• contient-il des éléments personnalisés, privés ou sensibles ?
• produit-il des événements d’analytics qu’il faut distinguer d’une visite activée ?

Le cache HTTP reste le mécanisme de base. Les en-têtes de cache, les URL stables et l’invalidation maîtrisée rendent un prefetch plus utile et moins risqué. À l’inverse, une application qui répond systématiquement avec du contenu non réutilisable limitera mécaniquement le bénéfice de l’anticipation.

Pour les pages authentifiées, vérifiez les comportements dans une session réelle, avec les rôles pertinents et les redirections éventuelles. Une règle qui semble anodine sur un environnement local peut révéler un parcours coûteux, une réponse personnalisée ou un effet de bord une fois connectée.

Une stratégie progressive pour un site moderne

Les Speculation Rules sont conçues comme une amélioration progressive. Un navigateur qui ne les prend pas en charge ignore le script de règles et suit la navigation normale. Il ne faut donc pas construire une fonctionnalité métier qui en dépend, ni exiger un comportement identique partout.

Une mise en œuvre pragmatique peut suivre quatre étapes :

• Cartographier : identifiez une ou deux transitions fréquentes avec vos données d’analytics, vos journaux serveur ou votre outil de mesure produit.
• Commencer par le prefetch : ciblez des liens internes vers des documents légers et cacheables, avec un niveau d’intention prudent.
• Auditer la destination : vérifiez les appels réseau, les scripts tiers, les redirections et les effets de bord avant d’envisager le prérendu.
• Élargir seulement si le gain est démontré : ajoutez peu à peu d’autres règles, plutôt que de poser une règle globale sur tous les liens.

Cette progression rejoint une règle plus générale de performance : supprimer le travail inutile avant de chercher à l’exécuter plus tôt. Elle est compatible avec une approche où le JavaScript reste ciblé, comme expliqué dans notre article sur le JavaScript optionnel. Un document simple, rapide et bien mis en cache est une meilleure destination de spéculation qu’une page surchargée.

Mesurer le résultat plutôt que se fier à une démo

Une démonstration locale peut être impressionnante tout en ayant un effet faible, ou négatif, sur les vrais utilisateurs. Testez d’abord sur des navigateurs compatibles, sur des profils de réseau variés et avec le cache froid comme avec le cache chaud.

Les outils de développement du navigateur aident à observer les requêtes et le comportement de navigation. Mais la validation doit aussi passer par des données réelles : durée des navigations, taux d’abandon entre étapes, volume de données transférées, charge serveur et évolution des indicateurs métier du parcours concerné.

Pour les navigations activées depuis un prérendu, les API de performance fournissent des informations dédiées à l’activation, notamment via activationStart dans les entrées de navigation. Cela peut enrichir une instrumentation RUM, à condition de comparer des groupes cohérents et de ne pas confondre un chargement spéculatif avec une consultation effective.

Déployez avec un mécanisme de contrôle : un pourcentage limité de trafic, un drapeau de fonctionnalité ou une règle activée sur un seul type de page. Gardez aussi un œil sur les signaux moins flatteurs : hausse des octets transférés sans baisse perceptible des délais, pression supplémentaire sur l’origine, ou préchargements souvent non suivis d’un clic.

Le meilleur préchargement n’est pas celui qui couvre le plus de liens : c’est celui qui accélère une navigation réellement probable sans faire payer ce gain à tous les autres utilisateurs.

Conclusion : anticiper avec précision, pas avec excès

Les Speculation Rules offrent une solution native pour améliorer les navigations entre pages, sans imposer une couche applicative complexe. Le prefetch peut réduire l’attente de transitions plausibles ; le prerender peut rendre presque immédiates des étapes très prévisibles. Dans les deux cas, leur valeur dépend moins de la syntaxe JSON que de la qualité de votre sélection.

Commencez petit : un parcours observé, quelques URL internes, une destination propre et cacheable, puis une mesure avant extension. Cette discipline permet d’accélérer l’expérience sans transformer votre site en machine à télécharger des pages inutiles. Si vous cherchez un prochain chantier concret, analysez les transitions les plus fréquentes de votre site et testez une première règle de prefetch ciblée.