« Preload the next page before the user even clicks it » : c’est, en substance, la promesse du Speculative Loading intégré nativement à WordPress 6.8, sorti en avril 2025. Le navigateur, guidé par des règles de spéculation générées côté serveur, précharge ou prérend une page susceptible d’être visitée ensuite, en anticipant le comportement probable du visiteur.
Pour un auteur d’extension qui génère des liens dynamiquement — un lien de tri, un lien d’action rapide dans une liste, un lien de partage — cette anticipation du navigateur mérite d’être prise en compte dès la conception du lien, pas découverte après coup à travers un comportement inattendu en production.
Ce que fait réellement le Speculative Loading
WordPress 6.8 génère automatiquement des règles de spéculation au format standard du navigateur, indiquant quels liens de la page sont susceptibles d’être préchargés ou prérendus. Par défaut, le cœur applique une politique prudente : seuls les liens internes, avec un comportement de préchargement plutôt que de prérendu complet, sont concernés, et les liens vers l’administration ou contenant certains paramètres sont exclus.
add_filter( 'wp_speculation_rules_configuration', function ( array $configuration ) {
$configuration['mode'] = 'prerender';
return $configuration;
} );
Le risque concret pour une extension : l’effet de bord sur un lien GET

Le problème n’est pas propre à WordPress 6.8 : il existe depuis toujours qu’un lien HTML de méthode GET ne devrait déclencher aucun effet de bord, conformément à la sémantique HTTP. Mais tant que ce lien n’était activé que par un clic explicite de l’utilisateur, une extension mal conçue — un lien « Supprimer cet élément » construit comme une simple ancre plutôt que comme un formulaire avec confirmation — pouvait passer inaperçue en pratique. Avec le préchargement spéculatif, ce même lien peut désormais être appelé par le navigateur avant tout clic, ce qui rend l’effet de bord bien plus probable, voire systématique.
<!-- À proscrire : un lien GET qui déclenche une action -->
<a href="/wp-admin/admin-ajax.php?action=supprimer_favori&id=42">Retirer des favoris</a>
<!-- À privilégier : un bouton qui déclenche une requête explicite -->
<button type="button" data-favori-id="42" class="retirer-favori">Retirer des favoris</button>
Auditer les liens générés par sa propre extension
Avant de considérer une extension compatible, un audit systématique des liens qu’elle génère s’impose, en particulier ceux construits dynamiquement via add_query_arg() ou concaténation de chaînes. Trois questions permettent de trier rapidement :
- Ce lien modifie-t-il un état côté serveur (suppression, changement de statut, incrémentation d’un compteur) ? Si oui, il ne devrait jamais être une simple ancre
GET. - Ce lien pointe-t-il vers une page dont le contenu dépend d’un paramètre de session ou d’un panier temporaire ? Un prérendu prématuré pourrait alors afficher un état obsolète au moment du clic réel.
- Ce lien est-il exclu par défaut des règles de spéculation générées par le cœur (lien d’administration, lien contenant un nonce) ? Dans ce cas, aucune action supplémentaire n’est nécessaire.
Exclure explicitement un groupe de liens sensibles
Pour une extension qui génère des liens dont le comportement ne doit jamais être anticipé par le navigateur — un lien de validation à usage unique, par exemple — il est possible d’ajouter une règle d’exclusion explicite plutôt que de compter uniquement sur les exclusions par défaut du cœur.
add_filter( 'wp_speculation_rules_configuration', function ( array $configuration ) {
$configuration['excludes'][] = [
'href_matches' => '/mon-extension/action/*',
];
return $configuration;
} );
Ne pas confondre avec la question du bcrypt côté mots de passe
Le Speculative Loading n’a aucun lien avec le passage au hachage bcrypt pour les mots de passe, une autre évolution associée à la même période du cœur WordPress mais concernant un tout autre sujet, l’authentification. Les deux évolutions arrivent à des moments proches du calendrier de versions, ce qui entretient parfois une confusion dans les changelogs lus rapidement, mais elles ne partagent ni mécanisme ni code.
En résumé
Le Speculative Loading de WordPress 6.8 ne casse rien par défaut : sa configuration prudente protège la majorité des sites sans intervention. Mais pour une extension qui génère ses propres liens dynamiques, l’audit reste nécessaire, car un lien mal conçu — effet de bord sur méthode GET, dépendance à un état de session volatil — devient plus susceptible d’être déclenché prématurément qu’auparavant. La bonne pratique de longue date, qui consistait déjà à réserver les effets de bord aux requêtes non idempotentes, redevient simplement plus urgente à appliquer.