La Speculation Rules API change la manière d’anticiper les navigations sur un site web. Elle permet au navigateur de précharger ou de pré-rendre des pages probables avant le clic, afin que la page suivante se charge presque instantanément. Pensée pour les sites multi-pages, elle vise surtout les parcours où l’on peut prévoir la suite logique de la visite.
En quelques lignes :
La Speculation Rules API permet d’anticiper la page suivante sur un site multi pages, pour que la navigation apparaisse presque instantanée et améliore la perception de vitesse.
- Ciblez finement les URLs à forte probabilité de visite (étapes d’un tunnel, article suivant d’une série) plutôt que de préparer massivement tous les liens.
- Je vous recommande de privilégier le prerender sur quelques pages stratégiques et d’utiliser le prefetch pour les scénarios moins certains, afin de limiter l’usage de ressources.
- Choisissez la méthode d’intégration la mieux adaptée à votre architecture : balise
<script type="speculationrules">, injection JavaScript ou entête HTTP pour centraliser la configuration. - Testez et mesurez les effets sous Chromium, suivez la bande passante et la mémoire consommées, et ajustez les règles selon les données réelles de navigation.
Qu’est-ce que la Speculation Rules API et à quoi sert-elle ?
La Speculation Rules API est une interface web conçue pour améliorer les performances des navigations futures. Son principe est simple, le navigateur reçoit des règles qui lui indiquent quelles pages méritent d’être préparées à l’avance, en fonction d’une probabilité de visite.
Elle s’adresse avant tout aux sites en navigation basée sur des documents, souvent appelés MPA, plutôt qu’aux applications à page unique, les SPA. Dans un MPA, chaque changement de page entraîne une nouvelle navigation document, ce qui rend l’anticipation particulièrement utile.
Concrètement, l’API agit avant même que l’utilisateur clique. Elle anticipe le parcours et permet d’offrir une sensation de chargement immédiat sur la page suivante. Cette logique est très intéressante sur des sites où les chemins de navigation sont prévisibles, comme un tunnel de commande, un guide pas à pas ou une arborescence éditoriale dense.
Elle succède aussi à <link rel="prerender">, désormais déprécié, et se distingue du simple <link rel="prefetch"> par une gestion plus fine des pages entières. Là où le préfetch classique récupère surtout des ressources, la Speculation Rules API raisonne à l’échelle d’un document complet.
Pour mieux situer l’intérêt de cette approche, voici une comparaison rapide entre les deux modes principaux.
| Mode | Ce que fait le navigateur | Résultat côté utilisateur |
|---|---|---|
| Prefetch | Télécharge la page ciblée en arrière-plan, sans l’exécuter | Le contenu est déjà récupéré, le gain se voit surtout au moment de la navigation |
| Prerender | Récupère et exécute la page en arrière-plan | La page peut s’afficher presque instantanément au clic |
Fonctionnement et mode d’intégration de la Speculation Rules API
L’intégration de cette API repose sur des règles déclaratives. Vous indiquez au navigateur quelles URL spéculer, puis il choisit d’appliquer un prefetch ou un prerender selon la configuration et le niveau d’anticipation souhaité.
La formulation des règles peut se faire de plusieurs façons. Le choix dépend surtout de la structure du site et de la manière dont les liens sont générés ou filtrés au fil de la visite.
Trois façons d’intégrer les règles
La méthode la plus directe consiste à intégrer les règles dans le HTML via une balise <script type="speculationrules">. Le contenu est alors écrit en JSON, ce qui permet de déclarer clairement les URL ciblées.
Il est aussi possible d’injecter les règles dynamiquement en JavaScript. Cette approche convient bien lorsqu’une logique métier détermine la prochaine page probable, par exemple en fonction d’un panier, d’une catégorie consultée ou d’un comportement utilisateur observé pendant la session.
Enfin, les règles peuvent être fournies depuis un fichier JSON externe référencé via l’en-tête HTTP Speculation-Rules. Cette option est intéressante lorsque la configuration doit être maintenue côté serveur ou distribuée à grande échelle.
Structure d’une règle JSON
Une règle Speculation Rules repose sur un objet JSON avec des sélecteurs et des critères de ciblage. Les documentations mentionnent par exemple href_matches pour viser des URL selon un motif, ou selector_matches pour cibler des liens précis dans le DOM.
Cette logique est plus expressive que les anciennes approches, car elle permet de combiner des critères adaptés au contexte. Vous pouvez ainsi viser uniquement certains liens de navigation, une catégorie donnée ou une page de suite logique dans un parcours.
Voici un exemple très simple de règle de pré-rendu pour une prochaine page probable.
{
"prerender": [
{
"source": "list",
"urls": ["/etape-suivante.html"]
}
]
}Les implémentations réelles sont souvent plus nuancées, avec des filtres basés sur des motifs d’URL ou sur des sélecteurs CSS. L’intérêt est de laisser le navigateur préparer seulement ce qui a une vraie probabilité d’être utile.
Différence entre prefetch et prerender
Le prefetch est plus léger. Le navigateur télécharge la page à l’avance, mais il ne l’exécute pas. C’est utile lorsqu’on veut gagner du temps sans mobiliser trop de ressources.
Le prerender va plus loin. La page est récupérée, construite et exécutée en arrière-plan, comme si elle était déjà prête derrière le rideau. Au clic, l’utilisateur a alors le sentiment d’une navigation immédiate.
Ce choix n’est pas anodin. Plus l’anticipation est ambitieuse, plus il faut être précis dans le ciblage pour éviter une consommation inutile de bande passante, de mémoire ou de temps processeur.
Points forts, limites et scénarios recommandés
La Speculation Rules API apporte une approche plus souple que les mécanismes historiques de préchargement. Elle donne au navigateur des instructions plus fines et plus dynamiques, ce qui permet de mieux coller au comportement réel des visiteurs.
Pour autant, elle ne doit pas être utilisée partout de la même façon. Son efficacité dépend fortement du type de site, de la structure des pages et de la capacité à prédire le prochain clic.
Les points forts à retenir
Le premier avantage est sa syntaxe plus expressive. Vous pouvez définir des règles plus lisibles et plus précises que les anciens systèmes basés sur un simple lien de préchargement.
Le deuxième atout est sa capacité à s’adapter au contexte. Les règles peuvent être mises à jour selon le parcours, la page consultée ou certaines interactions, ce qui rend l’anticipation plus intelligente.
Enfin, elle permet d’atteindre une navigation quasi instantanée sur un site multi-pages lorsque le ciblage est bien pensé. Sur des parcours séquentiels, le gain perçu peut être très net.
Les sites pour lesquels elle est adaptée
Cette API est particulièrement pertinente pour les sites MPA où le prochain clic se devine assez bien. C’est le cas des sites de contenu, des guides structurés, des tutoriels par étapes, des sites e-commerce avec tunnel simple ou des espaces documentaires très arborescents.
À l’inverse, elle n’est pas destinée à faire le travail d’une SPA. Dans une application à page unique, la logique de navigation repose davantage sur le routage client et l’actualisation partielle de l’interface, ce qui réduit l’intérêt de préparer des documents complets en amont.
Pourquoi le ciblage fin est indispensable
Le meilleur résultat vient d’une sélection précise des pages à préparer. Il vaut mieux spéculer sur quelques URLs à forte probabilité de visite que de tenter un prérendu large de tous les liens visibles.
Un prérendu trop agressif peut consommer trop de ressources et dégrader l’expérience au lieu de l’améliorer. Il faut donc réserver cette mécanique aux pages réellement stratégiques du parcours.
Le tableau ci-dessous résume les principaux cas d’usage et les points de vigilance associés.
| Scénario | Intérêt | Vigilance |
|---|---|---|
| Parcours séquentiel | La page suivante est facile à prévoir | Limiter les règles aux étapes les plus probables |
| Site de contenu volumineux | Réduit la latence sur les lectures en chaîne | Éviter de spéculer sur trop de liens éditoriaux |
| Boutique avec tunnel linéaire | Améliore la fluidité entre fiche, panier et paiement | Ne pas pré-rendre toutes les variantes du catalogue |
Du côté de la compatibilité, la documentation met surtout en avant l’écosystème Chromium et Chrome. Il faut donc garder à l’esprit que le support n’est pas uniformément réparti sur tous les navigateurs.
Pour explorer d’autres capacités du navigateur, voyez WebGPU, qui illustre ce que le navigateur peut exécuter en local.
Autre point à surveiller, cette API n’est pas un simple cache de ressources. Elle travaille sur la navigation de document et sur la préparation de pages entières, ce qui change complètement son usage et ses limites.
Les erreurs à éviter
La première erreur consiste à la confondre avec un système de cache classique. Elle ne sert pas à stocker des fichiers de manière générale, mais à anticiper une navigation probable.
La deuxième erreur est de l’utiliser sans vraie stratégie de sélection. Injecter des règles sur tous les liens d’un site peut gaspiller la bande passante et mobiliser inutilement le navigateur.
La troisième erreur est de la considérer comme une solution universelle. Son fonctionnement dépend du navigateur et du contexte, donc il faut vérifier sa pertinence avant de la généraliser.
Les documentations de Chrome montrent d’ailleurs un suivi actif de cette API, avec des améliorations régulières et des recommandations mises à jour. Cela confirme que le sujet évolue encore, en particulier du côté des usages de performance et d’optimisation de navigation.
En résumé, la Speculation Rules API est un bon levier quand vous savez quoi anticiper, quand l’anticiper et jusqu’où aller. Bien utilisée, elle donne une sensation de vitesse très nette sur les sites multi-pages les plus prévisibles.
