Sur un site statique multi-pages, sans framework JavaScript, chaque clic sur un lien déclenche un vrai chargement de page. C'est ce qui rend ces sites légers et fiables. Mais ça veut aussi dire qu'il y a, à chaque navigation, un petit temps mort : la requête part, le serveur répond, la page s'affiche. Une API récente des navigateurs, la Speculation Rules API, permet de faire partir ce temps mort avant le clic. Voici ce qu'elle fait, et comment je l'utilise — avec prudence.
Le problème que ça résout
Les sites qui donnent une impression de vitesse instantanée sont, la plupart du temps, des applications JavaScript qui gèrent la navigation elles-mêmes (routing côté client) : elles remplacent juste le contenu de la page sans recharger tout le document. Ça marche, mais ça a un coût — plus de JavaScript à télécharger et à exécuter, donc souvent moins de fiabilité et un temps d'interaction plus lent au premier chargement.
Sur les sites que je construis, je préfère l'inverse : peu de JavaScript, des vraies pages, un vrai rechargement. La Speculation Rules API permet de garder cette architecture simple tout en réduisant le temps mort perçu à la navigation, sans écrire une ligne de routing.
Ce que fait concrètement l'API
Le principe : on déclare, dans un bloc JSON, quelles pages le navigateur peut aller chercher en avance — avant même que le visiteur clique. Deux niveaux existent. Le prefetch télécharge juste la réponse du serveur en arrière-plan. Le prerender va plus loin : il charge et affiche la page dans un onglet invisible, prête à apparaître instantanément au clic.
Ça se déclare avec un simple <script type="speculationrules"> :
<script type="speculationrules">
{
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/contact" } }
]
},
"eagerness": "moderate"
}
]
}
</script>Le champ eagerness règle à quel point le navigateur est gourmand : conservative attend un vrai début de clic (mousedown) avant de charger, moderate réagit dès que le lien est survolé ou visible à l'écran, immediate charge tout de suite. Plus on est gourmand, plus la navigation suivante est rapide — et plus on charge de pages qui, finalement, ne seront jamais visitées.
Ce que j'utilise, et ce que j'évite
Je pars toujours du niveau moderate : un bon compromis, qui précharge surtout les pages qu'un visiteur regarde vraiment (survol, scroll), sans tout précharger sans discernement. Et j'exclus explicitement certains liens du prerender : la page de contact si elle contient un formulaire, tout lien de déconnexion, tout lien externe. La raison est simple — un prerender charge et exécute la page en arrière-plan, y compris son JavaScript. Si cette page déclenche un effet de bord (envoi d'un événement analytics, invalidation d'une session), il se produirait avant même que le visiteur ait cliqué.
C'est aussi pour ça que je n'utilise pas de traceur tiers sur les sites que je livre : moins de scripts avec effets de bord, moins de risques de ce genre avec le préchargement spéculatif.
Une prudence supplémentaire : ce n'est pas partout pareil
Cette API n'est pas un standard universellement supporté. Elle fonctionne aujourd'hui dans les navigateurs à moteur Chromium (Chrome, Edge) ; Firefox et Safari ne l'implémentent pas encore, et elle n'est pas considérée comme « Baseline » (le repère de MDN pour dire qu'une fonctionnalité marche partout de façon fiable). Ce n'est pas gênant en soi : c'est exactement le genre de fonctionnalité à traiter en amélioration progressive. Le navigateur qui ne la comprend pas ignore simplement le bloc <script> et charge la page normalement, comme avant. Rien ne casse, personne n'est pénalisé — certains visiteurs ont juste une navigation plus rapide que d'autres.
Ce que ça change pour un visiteur
Concrètement : sur un site qui utilise prerender avec prudence, cliquer sur un lien interne peut donner l'impression que la page suivante était déjà là. Aucune ligne de routing côté client, aucun framework supplémentaire, juste un petit bloc JSON dans le <head>. C'est le genre d'amélioration que j'aime : elle ne complique rien côté visiteur, elle ne demande pas de compromis sur la sobriété du site, et elle ne fonctionne que dans un sens — vers plus de rapidité, jamais vers moins de fiabilité.
Un site qui traîne à la navigation, ou un projet à reconstruire sur des bases plus légères ? Parlons-en.