Depuis la sortie de WordPress 6.8 en avril de l’année dernière, une question revient régulièrement de la part de clients qui suivent l’actualité technique WordPress sans être développeurs eux-mêmes : « C’est quoi cette histoire de préchargement spéculatif, et est-ce qu’on en profite déjà sur notre site ? » La réponse tient en une notion assez simple une fois expliquée, mais dont le mécanisme interne mérite d’être compris avant de l’ajuster.
Voici ce que la spéculative loading change concrètement pour un site construit entièrement en éditeur de site, sans entrer dans la configuration fine réservée à un article dédié côté performance.
Définition : anticiper le prochain clic du visiteur
La spéculative loading repose sur l’API native du navigateur Speculation Rules, que WordPress 6.8 active par défaut via un module intégré au cœur. Le principe consiste à demander au navigateur de précharger, voire de pré-rendre entièrement, une page que le visiteur est susceptible de visiter ensuite, en se basant sur son comportement de survol ou sur des règles de probabilité définies par le site.
Fonctionnement interne : deux modes distincts
Le mécanisme propose deux niveaux d’anticipation, activables séparément. Le mode prefetch, le plus conservateur, télécharge en avance le document HTML de la page ciblée sans exécuter son JavaScript ni construire son rendu visuel. Le mode prerender, plus ambitieux, va jusqu’à construire la page entière en arrière-plan, invisible pour l’utilisateur, prête à s’afficher instantanément au moment du clic.
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}
]
}
</script>Ce bloc de règles, injecté automatiquement dans le head du site par WordPress depuis la 6.8, s’appuie sur la valeur eagerness pour équilibrer le gain de rapidité contre le risque de gaspiller de la bande passante sur des pages jamais visitées : moderate déclenche le préchargement dès un survol prolongé du lien, tandis que conservative attend un signal plus fort, comme le début d’un clic maintenu.
Cas d’usage concrets sur un site FSE
Sur un site construit avec une Query Loop pour un blog ou un catalogue, la navigation entre une page de liste et une fiche de détail correspond exactement au schéma de navigation prévisible que la spéculative loading cible en priorité. Sur un test mené avec un client éditeur, le temps perçu entre le clic sur un article depuis la liste et l’affichage de son contenu est passé d’environ 400 millisecondes à moins de 100 millisecondes, le rendu ayant déjà été préparé en arrière-plan pendant que le visiteur hésitait sur quel article cliquer.
Les limites à connaître
Le mode prerender exécute en réalité une partie du JavaScript de la page ciblée en arrière-plan, ce qui peut poser problème pour des scripts qui déclenchent des effets de bord non désirés avant même que la page ne soit réellement affichée à l’utilisateur, comme l’enregistrement prématuré d’une visite dans un outil de mesure d’audience. WordPress expose l’API JavaScript document.prerendering pour détecter ce contexte et différer ce type d’appel jusqu’à l’affichage réel de la page.
if ( document.prerendering ) {
document.addEventListener( 'prerenderingchange', () => {
enregistrerVisite();
}, { once: true } );
} else {
enregistrerVisite();
}Pièges rencontrés en pratique
- Des scripts de mesure d’audience comptabilisant des visites fantômes sur des pages jamais réellement consultées par le visiteur.
- Des formulaires avec jeton de sécurité généré à l’affichage, potentiellement expiré si la page a été pré-rendue longtemps avant le clic réel.
- Une consommation de bande passante superflue sur des sites à trafic mobile important avec des forfaits de données limités, un point à surveiller selon l’audience réelle du site.
La spéculative loading est activée par défaut depuis la 6.8, sans que la plupart des sites n’aient rien à configurer : c’est justement cette transparence qui impose de vérifier que les scripts existants du site savent distinguer un pré-rendu d’un affichage réel.
En résumé
La spéculative loading introduite en 6.8 change la perception de vitesse d’un site FSE sans nécessiter de configuration particulière pour la majorité des usages, en s’appuyant sur l’API native du navigateur pour anticiper les clics probables du visiteur. Le principal point de vigilance reste la compatibilité des scripts tiers avec le contexte de pré-rendu, un sujet à vérifier avant de considérer le mécanisme comme totalement invisible pour l’équipe technique.
