310 millisecondes. C’est l’écart médian de Largest Contentful Paint mesuré sur un panel de 40 000 sessions réelles, deux semaines avant et deux semaines après l’activation du Speculative Loading sur un site e-commerce de taille moyenne (environ 12 000 visites par jour). Le chiffre est net, mais il cache une réalité plus contrastée selon les types de page, et c’est précisément ce qui mérite d’être creusé plutôt que de se contenter du communiqué de WordPress 6.8, sorti en avril 2025.
L’API Speculative Loading repose sur la Speculation Rules API du navigateur, une technologie encore récente que Chrome supporte nativement et que d’autres moteurs commencent à adopter partiellement. WordPress l’intègre en cœur à partir de la version 6.8, avec un mode « conservateur » activé par défaut : le navigateur précharge une page cible dès que l’utilisateur survole un lien pendant un court délai, ou dès qu’un lien entre dans le viewport selon le mode choisi. L’idée est simple : anticiper la navigation avant le clic pour que la page suivante soit quasiment instantanée. Sur le papier, c’est séduisant. En pratique, l’effet dépend énormément du type de contenu et du comportement réel des visiteurs.
Le protocole de mesure retenu
Pour éviter les biais classiques d’une comparaison avant/après trop rapide (saisonnalité, changement de trafic, campagne marketing en cours), la mesure a été construite en trois temps. D’abord, une période de référence de quatorze jours avec la fonctionnalité désactivée via le filtre wp_speculation_rules_configuration. Ensuite, une activation progressive sur 10 % du trafic grâce à un cookie de segmentation posé côté serveur, pendant sept jours, pour isoler l’effet sans changer tout le site d’un coup. Enfin, une généralisation à 100 % du trafic pendant quatorze jours supplémentaires, avec les mêmes métriques collectées via l’API web-vitals côté client et remontées vers un endpoint de collecte maison plutôt que de se fier uniquement aux rapports agrégés de Search Console, trop lissés pour ce niveau de granularité.
Les métriques suivies : LCP, INP, et un indicateur maison appelé « délai avant clic utile », qui mesure le temps entre l’affichage de la page de destination et la première interaction significative de l’utilisateur dessus. Ce dernier indicateur s’est révélé le plus parlant, car il capture directement le bénéfice perçu du prérendu, là où LCP seul peut masquer des effets de cache navigateur déjà existants.
Des résultats très différents selon les gabarits de page
Sur les pages fiches produit, atteintes majoritairement depuis les pages de catégorie, le gain a été net et stable : LCP médian passé de 2,4 s à environ 2,1 s, soit les 310 ms annoncées plus haut. La raison est simple : ces pages sont peu volatiles, leur contenu ne change pas entre le survol du lien et le clic, et le prérendu profite pleinement à l’utilisateur. Sur les pages de résultats de recherche interne en revanche, l’effet a été quasi nul, voire légèrement négatif sur le TTFB serveur agrégé : ces pages génèrent une requête dynamique coûteuse à chaque prérendu, et une bonne partie des prérendus n’aboutissent jamais à un clic, ce qui gaspille des cycles serveur sans bénéfice utilisateur.
Ce constat a conduit à affiner la configuration par défaut plutôt que de l’appliquer uniformément. WordPress expose ce réglage via le filtre suivant, qui permet d’exclure certains motifs d’URL du prérendu :
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths ) {
$paths[] = '/?s=';
$paths[] = '/panier/';
$paths[] = '/mon-compte/';
return $paths;
} );Exclure le panier et le compte utilisateur n’est pas qu’une question de performance : ce sont des pages dont le contenu dépend fortement de l’état de session, et un prérendu mal maîtrisé peut y créer des effets de bord (compteurs de panier incohérents, jetons de sécurité consommés avant l’usage réel). La documentation officielle de WordPress recommande d’ailleurs explicitement d’exclure les zones sensibles à l’état.
L’effet indirect sur le budget de crawl
Un point souvent oublié : le Speculative Loading fonctionne côté navigateur, à l’initiative d’un visiteur humain, et n’a strictement aucun rapport avec la façon dont Googlebot explore le site. Les journaux serveur analysés sur la période ne montrent aucune variation du volume de requêtes attribuables aux robots de Google, ce qui est cohérent : cette fonctionnalité ne modifie ni le rendu ni la structure des URL, elle accélère uniquement l’expérience du visiteur humain une fois la page arrivée dans son navigateur. L’intérêt SEO est donc indirect, via les Core Web Vitals de terrain remontés dans le Chrome UX Report, eux-mêmes utilisés en partie comme signal de classement.
Ce que la mesure ne dit pas
Deux limites méritent d’être signalées honnêtement. D’abord, le panel de mesure porte sur un seul site, avec un profil de trafic particulier (majoritairement desktop, navigation par catégories) : un site à forte proportion de trafic mobile via des liens partagés en réseaux sociaux, où le survol n’existe pas, tirerait bénéfice presque uniquement du mode « entrée dans le viewport », avec un ratio coût/bénéfice différent. Ensuite, la mesure n’a couvert que sept mois d’historique après la sortie de WordPress 6.8 ; il est possible que les navigateurs autres que Chrome élargissent leur support de la Speculation Rules API et changent la donne sur d’autres segments d’audience.
Recommandations opérationnelles
- Activer le Speculative Loading en mode conservateur par défaut, puis exclure explicitement les URL à état (panier, compte, formulaires).
- Mesurer sur un échantillon segmenté avant généralisation, plutôt que de se fier aux moyennes globales de Search Console.
- Suivre un indicateur de « délai avant clic utile » côté client, plus parlant que le LCP brut pour ce cas précis.
- Revérifier l’effet tous les six mois, la fonctionnalité et son support navigateur évoluant vite.
Sur ce genre de fonctionnalité, mieux vaut mesurer sur un sous-ensemble de trafic pendant deux semaines que de généraliser sur la foi d’un article de blog, aussi convaincant soit-il.
Notre verdict
Le Speculative Loading de WordPress 6.8 tient ses promesses sur les gabarits de page stables et fréquemment survolés avant clic, avec un gain de LCP mesuré autour de 300 ms sans aucun effort de développement supplémentaire. Il devient en revanche contre-productif appliqué aveuglément aux pages dynamiques ou dépendantes de l’état de session. La bonne pratique n’est donc pas de l’activer ou de le désactiver globalement, mais de le configurer finement via les filtres dédiés, puis de vérifier son effet réel avec une mesure en conditions de production plutôt qu’avec un audit Lighthouse isolé, qui ne capture pas ce type de comportement inter-pages.
