Une grande partie du travail sur la performance web consiste à accélérer ce qui se passe après le clic : un serveur plus rapide, des ressources plus légères, un rendu plus efficace. Mais il existe un moyen d’aller plus loin : commencer à charger la page suivante avant que l’utilisateur ne l’ouvre. Si le navigateur a déjà téléchargé, et même affiché, la page au moment où l’utilisateur touche le lien, la navigation devient pratiquement instantanée. C’est ce que rend possible l’API Speculation Rules, avec ses deux outils principaux, prefetch et prerender.
Dans cet article, nous voyons comment elle fonctionne, quels résultats elle peut apporter sur les Core Web Vitals, comment la configurer avec prudence et quels effets secondaires garder sous contrôle, de l’analytics à la charge du serveur.
Prefetch et prerender : la différence
Avec le prefetch, le navigateur télécharge à l’avance le document HTML de la page suivante et le garde de côté. Au clic de l’utilisateur, le document est déjà disponible : on économise le temps de la requête vers le serveur, c’est-à-dire le TTFB, mais les images, les feuilles de style et les scripts doivent encore être téléchargés et la page construite.
Avec le prerender, le navigateur va beaucoup plus loin : il charge toute la page dans un onglet invisible, télécharge les ressources, exécute le JavaScript et l’affiche. Au clic, la page prête est simplement montrée. C’est le cas où la navigation devient instantanée, mais aussi celui qui consomme le plus de ressources, aussi bien sur l’appareil que sur le serveur.
Il y a un détail important pour les métriques. Pour une page en prerender, le LCP et les autres métriques de chargement sont mesurés à partir du moment où l’utilisateur l’ouvre réellement, et non de celui où le navigateur a commencé à la charger en arrière-plan. Une page activée à la suite d’un prerender réussi affiche donc un LCP très proche de zéro, et ces visites comptent dans les données d’utilisateurs réels du Chrome UX Report.
Comment s’écrivent les règles
Les règles se déclarent avec un bloc JSON dans un élément <script type="speculationrules">. Elles peuvent lister des URL précises ou, plus commodément, décrire quels liens de la page sont candidats, avec des conditions sur les adresses et des sélecteurs CSS :
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/cart/*" } },
{ "not": { "href_matches": "/checkout/*" } },
{ "not": { "href_matches": "/*\\?*add-to-cart=*" } },
{ "not": { "href_matches": "/wp-login.php" } },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate"
}]
}
</script>Dans cet exemple, tous les liens internes sont candidats au prerender, sauf le panier, le tunnel de commande (checkout), les liens qui ajoutent des produits au panier, la connexion et tout lien marqué d’une classe dédiée. Les règles peuvent être placées dans le HTML ou envoyées avec l’en-tête HTTP Speculation-Rules, qui pointe vers un fichier JSON : utile quand on veut gérer la configuration au niveau du serveur ou du CDN.
Eagerness : jusqu’où anticiper
La propriété eagerness décide du moment où le navigateur doit démarrer. C’est le choix le plus important, car il équilibre deux besoins opposés : plus on démarre tôt, plus il est probable que la page soit prête au clic ; plus on démarre tôt, plus on charge de pages que l’utilisateur n’ouvrira jamais.
- immediate : dès la lecture des règles.
- eager : très tôt, sur des signaux d’intérêt faibles.
- moderate : quand le pointeur reste sur un lien pendant environ 200 millisecondes.
- conservative : quand l’utilisateur appuie du doigt ou du bouton de la souris sur le lien, un instant avant le clic proprement dit.
Pour la plupart des sites, moderate pour le prerender et conservative pour le prefetch offrent un bon équilibre. immediate et eager doivent être réservés à quelques liens très probables, par exemple l’étape suivante d’un parcours guidé ou le premier résultat d’une recherche. N’oubliez pas que sur smartphone il n’y a pas de survol à la souris : les modes moderate et conservative démarrent en pratique au toucher, et l’avance est plus courte. Même un avantage de cent millisecondes s’ajoute cependant à toutes les autres optimisations.
Prise en charge et WordPress
Speculation Rules est pris en charge par les navigateurs basés sur Chromium, comme Chrome et Edge. Les autres navigateurs ignorent simplement le bloc, sans erreur : pour leurs utilisateurs, la navigation reste la navigation normale. C’est donc une amélioration progressive, qui n’a pas besoin de solution de repli.
Depuis la version 6.8, WordPress intègre nativement le chargement spéculatif : pour les visiteurs non connectés, il insère des règles de prefetch avec l’eagerness conservative, en excluant les espaces d’administration. C’est un point de départ prudent, qu’on peut rendre plus incisif en passant au prerender ou à une autre eagerness grâce aux filtres fournis par le cœur, après avoir vérifié les effets sur l’analytics et le serveur.
La configuration se modifie avec le filtre wp_speculation_rules_configuration, qui accepte le mode (prefetch ou prerender) et l’eagerness. Un second filtre, wp_speculation_rules_href_exclude_paths, permet d’ajouter des chemins à exclure, avec la même syntaxe à caractères génériques que celle des règles :
// Prerender avec eagerness moderate pour les visiteurs non connectés
add_filter(
'wp_speculation_rules_configuration',
function ( $config ) {
if ( is_array( $config ) ) {
$config['mode'] = 'prerender';
$config['eagerness'] = 'moderate';
}
return $config;
}
);
// Chemins à ne jamais charger à l’avance
add_filter(
'wp_speculation_rules_href_exclude_paths',
function ( $paths ) {
$paths[] = '/cart/*';
$paths[] = '/checkout/*';
$paths[] = '/my-account/*';
return $paths;
}
);Le cœur exclut déjà automatiquement l’espace d’administration, les fichiers de connexion et les adresses avec des paramètres de requête, et ne génère pas de règles pour les utilisateurs connectés, pour lesquels les pages sont souvent personnalisées et non mises en cache. On peut aussi exclure des liens individuels en leur ajoutant la classe no-prerender, que le cœur reconnaît, ou no-prefetch pour les exclure aussi du simple prefetch. Qui utilise des plugins d’optimisation qui insèrent leurs propres règles doit vérifier de ne pas se retrouver avec deux configurations qui se chevauchent : le navigateur lit les deux, et le résultat peut être plus agressif que prévu.
Les effets secondaires à gérer
Charger des pages que l’utilisateur n’ouvrira peut-être pas a des conséquences qu’il faut anticiper avant d’activer le prerender à grande échelle.
- Les liens qui changent d’état. Un prerender fait une requête GET et, dans le cas du prerender, exécute aussi le JavaScript de la page. Les liens qui ajoutent au panier, déconnectent l’utilisateur, confirment un abonnement ou enregistrent un vote ne doivent jamais être candidats : ils doivent être explicitement exclus, et idéalement ne pas être de simples liens.
- Analytics et publicité. Une page préchargée en prerender mais jamais ouverte ne doit pas compter comme une vue de page. Les principaux outils d’analytics gèrent déjà ce cas, mais le code sur mesure, les pixels et les publicités demandent une vérification : le navigateur expose la propriété
document.prerenderinget l’événementprerenderingchange, qui permettent de reporter des actions jusqu’à l’activation réelle. - Charge du serveur. Chaque prerender inutile est une requête supplémentaire. Sur un site avec un cache de page efficace, le coût est minime ; sur des pages générées dynamiquement sans cache, il peut devenir significatif. Le navigateur envoie l’en-tête
Sec-Purposesur les requêtes spéculatives : le serveur peut donc les reconnaître et, si nécessaire, les refuser aux heures de pointe. - Contenus personnalisés. Les pages qui dépendent de données changeant entre le prerender et l’activation, comme les prix ou les disponibilités dynamiques, doivent être exclues ou mises à jour au moment de l’ouverture.
// Reporter une action jusqu’à ce que la page soit réellement affichée
function quandoVisibile( azione ) {
if ( document.prerendering ) {
document.addEventListener( 'prerenderingchange', azione, { once: true } );
} else {
azione();
}
}
quandoVisibile( () => inviaVisualizzazione() );Le navigateur, de son côté, fixe des limites : le nombre de prerenders simultanés est faible, et sur les appareils à peu de mémoire, ou avec le mode économiseur de données ou d’énergie activé, les spéculations peuvent être suspendues. C’est une raison de plus pour ne pas y voir une garantie, mais un accélérateur opportuniste.
Quelles pages en profitent le plus
Le chargement spéculatif fonctionne le mieux là où le parcours de l’utilisateur est prévisible : de la page de catégorie à la fiche produit, de la liste d’articles à l’article, de la recherche au premier résultat, du panier au tunnel de commande (checkout), à condition de traiter ce dernier avec le soin nécessaire. Sur les sites éditoriaux et les boutiques en ligne, où une part importante des visites se poursuit vers une deuxième page, l’effet sur l’expérience est immédiat : on a l’impression d’une application qui répond instantanément.
Il ne remplace pas les autres optimisations, cependant. La première page d’une visite, celle qui arrive depuis Google ou un réseau social, ne peut pas être préchargée en prerender par le site lui-même ; et, comme nous l’avons vu en parlant du CSS critique, pour beaucoup de visites la première page est aussi la dernière. Speculation Rules accélère la navigation interne ; le chargement de la page d’entrée revient à un serveur, un cache et un front end bien optimisés.
Le lien avec le back/forward cache
Le prerender accélère la navigation vers l’avant, vers des pages pas encore visitées. Pour la navigation vers l’arrière, il existe un mécanisme complémentaire, le back/forward cache, qui garde en mémoire les pages qu’on vient de quitter et les restaure instantanément quand l’utilisateur appuie sur le bouton Retour. Ensemble, ils couvrent une très grande partie de la navigation interne : les navigations vers l’avant sont anticipées par Speculation Rules, celles vers l’arrière sont servies depuis la mémoire du navigateur.
Les deux techniques partagent aussi quelques règles de bonne cohabitation. Le code qui suppose qu’une page n’est chargée qu’une seule fois, et que l’utilisateur la voit tout de suite, doit être revu dans les deux cas : avec le prerender, la page existe avant d’être vue ; avec le back/forward cache, elle redevient visible sans être rechargée. Les événements prerenderingchange et pageshow sont les points où mettre à jour l’analytics, les contenus dynamiques et l’état de l’interface. Nous traiterons en détail le back/forward cache et les raisons pour lesquelles il ne fonctionne souvent pas dans le prochain article.
Comment vérifier que ça fonctionne
Dans le panneau Application des DevTools de Chrome, la section consacrée au chargement spéculatif montre les règles lues dans la page, les URL candidates, l’état de chaque spéculation et, en cas d’échec, la raison. C’est l’outil principal pour contrôler les exclusions et l’eagerness. Dans le panneau Réseau, les requêtes spéculatives sont reconnaissables, et côté serveur, l’en-tête Sec-Purpose permet de mesurer leur volume dans les journaux.
Sur le terrain, le Chrome UX Report distingue les types de navigation et indique la part des visites arrivées par prerender : la suivre dans le temps, avec le LCP au 75e percentile, montre l’effet réel de la configuration. Le real-user monitoring peut faire la même chose au niveau d’une page individuelle, en distinguant les visites en prerender des visites normales.
Une adoption progressive
Le parcours recommandé est progressif. On commence par le prefetch conservative, déjà actif sur les WordPress récents, et l’on vérifie l’absence d’effets indésirables. On passe ensuite au prerender avec l’eagerness moderate sur les sections les plus prévisibles, comme de la liste d’articles à l’article seul ou de la catégorie à la fiche produit, avec des exclusions explicites pour tout ce qui change d’état. On contrôle l’analytics, les journaux et la charge du serveur, et seulement alors on étend la configuration au reste du site. Chaque étape est mesurée : types de navigation et LCP dans les données d’utilisateurs réels, requêtes spéculatives sur le serveur, éventuelles différences dans les rapports marketing.
En résumé
Speculation Rules permet au navigateur de télécharger, voire d’afficher à l’avance la page que l’utilisateur s’apprête à ouvrir. Le prefetch supprime l’attente du serveur, le prerender rend la navigation pratiquement instantanée, avec un LCP proche de zéro pour les pages activées. L’eagerness règle le compromis entre avance et gaspillage, et WordPress en intègre déjà une version prudente.
Comme tout outil puissant, il demande une configuration soignée : exclusions pour les liens qui changent d’état, bonne gestion de l’analytics et de la publicité, contrôle de la charge du serveur et adoption progressive. Bien fait, il transforme la navigation interne du site en une expérience que les utilisateurs perçoivent comme immédiate, et c’est l’une des rares interventions qui améliorent la vitesse sans rien alléger : les choses arrivent simplement plus tôt.
