Qu’est-ce que le Speculative Loading ? Comment WordPress charge les pages avant le clic

Vous cliquez sur un lien, et la page suivante est tout simplement là. Pas d’écran blanc, pas d’attente. Bien souvent, ce n’est pas un serveur plus rapide qui se cache derrière, mais un navigateur qui a pris les devants. Voilà exactement ce qu’est le Speculative Loading : le navigateur devine quelle page vous allez ouvrir ensuite et commence à la charger. S’il voit juste, le changement de page paraît instantané. S’il se trompe, il a chargé quelques kilooctets pour rien. Depuis WordPress 6.8, cette technique fait partie intégrante de WordPress, et beaucoup de propriétaires de sites ignorent que leur site l’utilise déjà. Vous allez découvrir ici comment tout cela fonctionne, ce que WordPress configure par défaut et dans quels cas il vaut la peine d’affiner les réglages.

Qu’est-ce que le Speculative Loading ? Une explication simple

Le Speculative Loading, en français à peu près « chargement spéculatif », est le terme générique qui désigne les techniques permettant à un navigateur de demander des pages avant que quiconque ne les ouvre réellement. Spéculatif, parce que personne ne sait avec certitude si le visiteur va vraiment cliquer sur le lien. Le navigateur fait un pari.

Imaginez la serveuse attentionnée du café où vous avez vos habitudes. Elle vous voit passer la porte et lance votre cappuccino avant même que vous ayez commandé. La plupart du temps, elle tombe juste, et vous avez votre café sans attendre. Le jour où, pour une fois, vous commandez un thé, le cappuccino a été préparé pour rien. Le Speculative Loading fonctionne à peu près de la même manière.

L’idée n’est pas nouvelle. Il y a des années déjà, <link rel="prefetch"> et <link rel="prerender"> permettaient aux sites de recommander au navigateur des pages à précharger, et des bibliothèques comme instant.page ou Quicklink ont ajouté la même fonction en JavaScript. Rien de tout cela n’était vraiment fiable. Chrome a même remplacé depuis longtemps l’ancien rel="prerender" par une variante allégée qui n’effectue plus aucun rendu. Quand on parle aujourd’hui de Speculative Loading, il s’agit donc presque toujours de la Speculation Rules API, que Google a introduite dans Chrome.

Pourquoi se donner tant de mal ? Parce que le temps de chargement compte directement dans les Core Web Vitals. Si une page est entièrement préparée en coulisses, le Largest Contentful Paint (LCP) tombe pratiquement à zéro pour le visiteur. Impossible de faire plus rapide.

Comment fonctionne la Speculation Rules API ?

Le site transmet au navigateur quelques règles. Elles sont écrites en JSON dans un bloc de type speculationrules. Voici à quoi ressemble une règle simple :

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

En clair : tous les liens de ce site peuvent être rendus à l’avance dès que le visiteur montre de l’intérêt, par exemple en laissant la souris un instant sur le lien. Ces règles, qui portent sur les liens du document, s’appellent des Document Rules. Il existe aussi des List Rules, avec lesquelles vous donnez au navigateur une liste fixe d’URL, par exemple la page suivante d’une série d’articles.

Deux choses rendent l’API agréablement simple. D’abord, c’est le navigateur qui décide en dernier ressort s’il suit la règle. Si la batterie est presque vide ou si la mémoire vive vient à manquer, il s’abstient. Ensuite, les navigateurs qui ne connaissent pas l’API ignorent tout simplement ce bloc. Rien ne peut donc casser. Au lieu de figurer dans le HTML, les règles peuvent d’ailleurs aussi être transmises par un header dans la réponse du serveur (Speculation-Rules), ce que font surtout les CDN.

Prefetch ou Prerender : quelle est la différence ?

La Speculation Rules API connaît deux modes, et la différence entre les deux est plus grande que leurs noms ne le laissent penser.

Avec le Prefetch, le navigateur récupère uniquement le HTML brut de la page cible et le garde sous le coude un court instant. Images, feuilles de style et scripts restent de côté, et rien n’est exécuté. Quand le visiteur clique, il s’épargne le temps d’attente du serveur, soit pour l’essentiel le Time to First Byte. Le navigateur charge le reste comme d’habitude. Le Prefetch est peu coûteux et n’a presque aucun effet secondaire.

Avec le Prerender, le navigateur sort le grand jeu. Il charge la page complète, avec ses images, son CSS et son JavaScript, dans un onglet invisible et la construit entièrement. Au clic, il se contente de remplacer la page visible. Pour le visiteur, c’est comme si la page avait toujours été là. Le prix à payer : plus de données, plus de puissance de calcul, et du JavaScript qui s’exécute alors que rien ne garantit que le visiteur verra un jour la page. Pour des raisons de sécurité, le Prerender ne fonctionne par défaut que pour les pages du même domaine.

En règle générale, le Prefetch est le réglage de base sans risque, et le Prerender le turbo pour les pages qui ont de fortes chances d’être ouvertes ensuite.

Ne confondez pas ces deux modes avec preload et preconnect. Ces indications accélèrent le chargement de fichiers de la page actuelle, par exemple des polices ou de la plus grande image. Notre article Utiliser preload et preconnect pour les polices et ressources dans WordPress explique comment les employer correctement.

À quel moment démarre le préchargement ? Les quatre niveaux d’eagerness

Avec eagerness (que l’on pourrait traduire par « empressement »), vous définissez à quel moment le navigateur a le droit de se lancer. Plus c’est tôt, plus le gain de temps est important, mais plus il se trompe souvent.

• immediate : tout de suite, dès que le navigateur lit la règle. À réserver à une poignée d’URL pour lesquelles vous êtes vraiment sûr de vous.
• eager : presque aussi tôt. Chrome a affiné ce comportement dans ses dernières versions, si bien que ce niveau se situe désormais entre immediate et moderate.
• moderate : sur ordinateur, la spéculation démarre quand le pointeur reste environ 200 millisecondes sur un lien, ou plus tôt si le bouton de la souris est enfoncé. Sur smartphone, où le survol n’existe pas, Chrome s’appuie sur d’autres signaux, comme un appui sur l’écran.
• conservative : seulement quand le visiteur clique vraiment, plus précisément au moment où il appuie sur le bouton de la souris ou pose le doigt sur l’écran. Il ne s’écoule qu’une fraction de seconde avant que le clic soit terminé. L’avance est faible, mais presque aucune spéculation n’est perdue.

Chrome veille par ailleurs à ce que personne n’exagère. Avec moderate et conservative, le navigateur garde au maximum deux spéculations en réserve et écarte la plus ancienne dès qu’une nouvelle arrive. Avec immediate et eager, jusqu’à 50 Prefetches et 10 Prerenders sont autorisés. En mode économie d’énergie, avec l’économiseur de données activé, quand la mémoire vive se fait rare ou si l’utilisateur a désactivé le préchargement des pages dans les paramètres, Chrome ne spécule pas du tout. Google détaille tout cela dans sa documentation pour Chrome.

Speculative Loading dans WordPress : ce qui se passe automatiquement depuis la version 6.8

L’équipe Performance de WordPress a d’abord testé la fonction sous la forme d’une extension autonome baptisée Speculative Loading. Elle tournait sur plus de 50 000 sites, et selon l’analyse de HTTP Archive et du Chrome UX Report, le taux de réussite au Largest Contentful Paint de ces sites s’est amélioré d’environ 1,9 pour cent en médiane. Cela paraît peu, mais pour une fonction qui ne demande aucun travail, c’est un gain appréciable. Avec WordPress 6.8, en avril 2025, l’ensemble a rejoint le cœur de WordPress. Le réglage par défaut est volontairement prudent :

• Mode prefetch, eagerness conservative. Seul le HTML est donc chargé, et seulement une fois qu’un clic a déjà commencé.
• Uniquement pour les visiteurs non connectés. Les utilisateurs connectés voient la barre d’outils et souvent des contenus personnels. Ces pages n’atterrissent dans aucun cache et coûteraient cher à précharger.
• Uniquement avec les Pretty Permalinks. Si l’option « Simple » est encore sélectionnée sous Réglages › Permaliens, la fonction reste désactivée.
• Pas d’URL avec paramètres. Tout ce qui contient un point d’interrogation dans l’adresse est exclu, par exemple la recherche ou un lien comme ?add-to-cart=123 dans une boutique en ligne. L’espace d’administration, la page de connexion et les liens avec rel="nofollow" sont eux aussi hors limites.
• Exceptions par classe. Les liens qui portent la classe no-prefetch, ou qui se trouvent dans un bloc doté de cette classe, ne sont jamais préchargés. La classe no-prerender exclut uniquement le Prerender.

Pourquoi tant de prudence ? L’extension utilisait encore par défaut Prerender avec moderate et gagnait ainsi en rapidité. Mais avec des millions de sites et d’innombrables combinaisons de thèmes et d’extensions, l’équipe jugeait trop grand le risque de voir du JavaScript s’exécuter sur des pages que personne ne visite jamais. C’est d’ailleurs l’argument qu’elle avance dans son annonce officielle. Si vous en voulez davantage, vous pouvez toujours installer l’extension Speculative Loading. Elle ajoute sous Réglages › Lecture une interface qui vous permet de changer le mode et l’eagerness sans code et, si vous le souhaitez, d’activer aussi la fonction pour les utilisateurs connectés.

Comment personnaliser ou désactiver le Speculative Loading dans WordPress ?

Sans extension, tout passe par des filtres. Les extraits suivants se placent dans le fichier functions.php de votre Child Theme ou, mieux encore, dans une petite extension maison, afin de survivre à un changement de thème.

Utiliser Prerender au lieu de Prefetch :

add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
	if ( is_array( $config ) ) {
		$config['mode']      = 'prerender';
		$config['eagerness'] = 'moderate';
	}
	return $config;
} );

La vérification avec is_array() est importante. Pour les utilisateurs connectés et les sites sans Pretty Permalinks, WordPress transmet ici null, et grâce à cette vérification, la fonction reste désactivée dans ces cas.

Exclure certaines sections :

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
	$paths[] = '/go/*';
	if ( 'prerender' === $mode ) {
		$paths[] = '/panier/*';
	}
	return $paths;
}, 10, 2 );

Les candidats typiques sont les redirections de liens d’affiliation qui comptabilisent un clic à chaque appel, un panier ou des pages dont le contenu change sans arrêt. Vous indiquez les chemins par rapport à la page d’accueil. Si WordPress est installé dans un dossier, il ajoute automatiquement ce dossier au chemin. Grâce au deuxième paramètre, vous pouvez exclure des chemins pour un seul mode, dans l’exemple le panier uniquement pour le Prerender.

Exclure des liens isolés : Attribuez au lien ou au bloc qui l’entoure la classe no-prefetch. Dans l’éditeur de blocs, cela se fait sous « Avancé », dans le champ des classes CSS additionnelles, sans la moindre ligne de code.

Désactiver complètement le Speculative Loading :

add_filter( 'wp_speculation_rules_configuration', '__return_null' );

Ne désactivez entièrement la fonction que si vous avez une raison concrète de le faire. Avec le réglage par défaut, elle ne coûte pour ainsi dire rien.

Quels sont les inconvénients du Speculative Loading ?

Le gain de vitesse n’est pas entièrement gratuit. Voici les points que vous devriez connaître :

Plus de charge sur le serveur. Chaque spéculation est une vraie requête. Si un Page Cache livre la page toute prête, le serveur ne s’en aperçoit presque pas. Sans cache, chaque Prefetch lance PHP et des requêtes en base de données, comme si un vrai visiteur était là. Sur un Shared Hosting aux ressources comptées, un réglage agressif comme immediate ou eager peut donc se faire sentir. Il en va de même, à plus petite échelle, pour les visiteurs dont le forfait de données est limité.

Les liens qui déclenchent quelque chose. En principe, un simple lien ne devrait jamais rien modifier. Dans la pratique, certains le font pourtant : liens de déconnexion, compteurs de clics pour liens d’affiliation, votes en un clic ou un rapide « Ajouter au panier ». En excluant toutes les URL avec paramètres, WordPress intercepte une bonne partie de ces cas, mais pas les adresses lisibles comme /go/partenaire/. Vous devriez exclure ces adresses de manière ciblée.

Des statistiques faussées. Le Prefetch n’exécute aucun JavaScript, si bien que les outils d’analyse comme Matomo ou Google Analytics n’en voient rien. Les statistiques établies à partir des fichiers journaux du serveur, comme celles de l’espace client de nombreux hébergeurs, risquent en revanche de compter ces requêtes comme des pages vues. Avec le Prerender, le JavaScript s’exécute réellement. Google Analytics et Google Publisher Tag attendent d’office que la page soit effectivement affichée. Les outils qui ne le font pas comptent des visites qui n’ont jamais eu lieu. Pour vos propres scripts, une simple vérification suffit :

if (document.prerendering) {
	document.addEventListener('prerenderingchange', startTracking, { once: true });
} else {
	startTracking();
}

Côté serveur, vous reconnaissez les requêtes spéculatives au header Sec-Purpose, qui contient la valeur prefetch ou prefetch;prerender.

Le contenu peut être légèrement daté. Chrome conserve les pages préchargées pendant quelques minutes. Avec conservative, cela ne joue aucun rôle, car le clic suit immédiatement. Avec les niveaux plus précoces, une page dont le contenu change vite, comme un suivi en direct, peut déjà avoir quelques minutes au moment où elle s’ouvre.

Quels navigateurs prennent en charge le Speculative Loading ?

Chrome prend entièrement en charge la Speculation Rules API, tout comme Edge, Opera et les autres navigateurs basés sur Chromium. Safari travaille à sa propre implémentation, qui, dans les versions récentes, reste toutefois cachée derrière un réglage réservé aux développeurs. Firefox ne prend pas encore en charge l’API.

Cela ressemble à une lacune, mais en pratique ce n’est pas un problème. Comme les navigateurs ignorent les règles qu’ils ne comprennent pas, tous ceux qui utilisent Chrome en profitent, et pour les autres, rien ne change. Sur la plupart des sites, Chrome représente de toute façon, et de loin, le plus gros morceau. Dès le début de l’année 2025, donc avant même le lancement dans WordPress, plus de 8 pour cent de toutes les pages vues dans Chrome passaient déjà par les Speculation Rules, selon l’équipe Performance de WordPress.

Comment vérifier si le Speculative Loading est actif sur mon site ?

Trois méthodes rapides :

1. Consulter le code source. Ouvrez votre site dans une fenêtre de navigation privée, pour ne pas être connecté, et cherchez speculationrules dans le code source. WordPress place les règles dans le pied de page.
2. Utiliser les Chrome DevTools. Dans l’onglet Application, vous trouvez sous Background services la section Speculative loads. Vous y voyez les règles actives, les URL qui ont été préchargées et la raison pour laquelle une spéculation n’a pas abouti.
3. Vérifier les headers. Si un CDN ajoute ses propres règles, par exemple Cloudflare avec sa fonction Speed Brain, elles ne figurent pas dans le HTML mais dans le header Speculation-Rules de la réponse. Il se peut alors que deux jeux de règles tournent en parallèle. Ce n’est pas gênant, mais mieux vaut le savoir avant de modifier un réglage à un endroit et de vous demander pourquoi rien ne change.

Comment InspectWP vous aide à garder un œil sur le temps de chargement et les Resource Hints

Le rapport InspectWP vous montre d’abord quelle version de WordPress tourne sur votre site. À partir de la 6.8, vous savez ainsi que le Speculative Loading est actif par défaut pour les visiteurs non connectés, à condition que les Pretty Permalinks soient activés. Dans la section HTML, le rapport liste en outre les Resource Hints classiques, à savoir Prefetch, DNS Prefetch, Preconnect et Prerender, et signale les entrées présentes plusieurs fois dans le code source. C’est souvent le signe d’extensions qui se marchent sur les pieds. Si un ancien rel="prerender" y figure encore, c’est une bonne occasion de passer à la Speculation Rules API. Comme les pages préchargées coûtent nettement moins cher avec un cache, il est aussi utile de regarder les extensions de cache détectées et les headers de la réponse du serveur. Un rapport gratuit vous montre en quelques instants où en est votre site.