Speculative Loading WordPress : la navigation quasi instantanée

Tu as tout fait. Le cache serveur tourne, le CDN distribue, les images sont optimisées, la base est dégraissée, ton PageSpeed affiche du vert pétant. Et pourtant, quand un visiteur passe d’une page à l’autre, il attend. Une demi-seconde. Parfois plus. Ce micro-temps mort, c’est le dernier maillon que personne n’optimise… parce qu’on est persuadé qu’il est incompressible.

Il ne l’est pas. Et la solution ne coûte rien, ne s’installe parfois même pas, et tourne déjà sur ton site sans que tu le saches. Depuis WordPress 6.8, le cœur du CMS charge la page suivante avant que tu cliques. Ça porte un nom un peu pompeux, Speculative Loading, et c’est sans doute l’optimisation la plus rentable que tu n’as jamais réglée. Je vais te montrer ce que c’est, comment le pousser, où sont les pièges, et surtout ce que j’ai mesuré, chiffres à l’appui.

Le Speculative Loading, c’est quoi au juste ?

Le Speculative Loading est une fonctionnalité native de WordPress (depuis la version 6.8) qui s’appuie sur la Speculation Rules API du navigateur pour précharger ou prérendre les pages vers lesquelles le visiteur va probablement cliquer. Tout se passe côté navigateur : WordPress glisse un petit bloc de règles JSON dans le HTML, et c’est Chrome, Edge ou Opera qui décide quoi charger en avance. WordPress dit où regarder, le navigateur fait le travail.

La nuance qui fait tout tient en deux mots : prefetch et prerender. Le prefetch télécharge le HTML de la page cible et le garde sous le coude, sans l’afficher ni exécuter son JavaScript. Au clic, le document est déjà là, l’aller-retour réseau est économisé. Le prerender, lui, va beaucoup plus loin : le navigateur construit la page entière dans un onglet invisible, JavaScript compris. Au clic, elle s’affiche d’un coup, comme si elle était déjà ouverte. C’est la différence entre avoir téléchargé le plat et l’avoir déjà fait cuire.

Précharger, ce n’est pas charger plus vite. C’est avoir déjà chargé au moment où le visiteur clique.

Et si le navigateur ne connaît pas l’API ? Rien. Safari et Firefox ignorent le bloc de règles, point. C’est une amélioration progressive : aucun effet de bord, le site se comporte comme avant. Felix Arntz, qui a piloté la fonctionnalité côté équipe performance, le dit noir sur blanc dans l’annonce officielle : les navigateurs sans support ignorent simplement sa présence. Tu ne casses rien en l’activant. Au pire, ça ne fait rien pour une partie de tes visiteurs.

Le périmètre navigateur : la Speculation Rules API avec réglage d’eagerness fonctionne sur les navigateurs Chromium (Chrome, Edge, Opera) à partir de la version 121, soit la grande majorité du trafic mondial. C’est une spécification web ouverte (groupe WICG), documentée sur MDN, pas un bricolage propriétaire.

Petit point d’histoire, parce qu’il en dit long sur la maturité de la chose. Le Speculative Loading n’a pas débarqué d’un coup dans le cœur. L’équipe performance de WordPress l’a d’abord publiée en extension autonome le 19 janvier 2024 pour la tester grandeur nature. Lors de son intégration dans WordPress 6.8, l’annonce officielle parlait de plus de 50 000 sites utilisateurs. Le plugin affiche aujourd’hui plus de 70 000 installations actives. C’est une base sérieuse, mais certainement pas des millions d’installations.

Ce n’est PAS le preload de ton plugin de cache

Là, j’arrête tout, parce que c’est le malentendu numéro un chez les gens qui ont déjà touché à la perf. On range trois choses très différentes sous le même mot, "préchargement", et on croit que parce qu’on a coché "Preload" dans WP Rocket, on a déjà ce dont je parle. C’est faux.

Le preload du cache désigne le "Preload" de WP Rocket ou le crawler de LiteSpeed : il génère les fichiers de cache à l’avance, côté serveur, pour que la page soit prête quand un visiteur la demande. Utile, mais ça n’accélère en rien le passage d’une page à l’autre une fois le visiteur sur ton site.

Le preload des liens correspond à l’option "Preload Links" de WP Rocket, ou à la vieille librairie instant.page : un script JavaScript qui va chercher le HTML d’une page au survol du lien, après 65 à 100 ms de survol selon l’outil. C’est l’ancêtre direct de ce qui nous intéresse. Sauf qu’il fait du prefetch, et seulement du prefetch.

Le Speculative Loading natif, lui, est piloté par le navigateur via la Speculation Rules API, sans le moindre script à charger, et il sait faire ce que les deux autres ne savent pas : prérendre la page complète. C’est le successeur des bidouilles, en standardisé. Les deux peuvent coexister (l’un en JavaScript, l’autre natif), mais le natif rend le "Preload Links" de WP Rocket largement redondant, et en plus propre.

Prefetch, prerender, eagerness : le tableau qui clarifie

Deux réglages pilotent tout : le mode (prefetch ou prerender) et l’eagerness, c’est-à-dire le moment où le navigateur déclenche le préchargement. Plus l’eagerness est agressive, plus le gain ressenti est grand… et plus tu risques de précharger des pages que personne ne visitera. Tout l’arbitrage tient là-dedans.

Eagerness	Déclencheur	Pour qui
conservative	Quand le doigt appuie sur le lien (pointerdown)	Défaut du cœur. Le plus économe, gain modéré
moderate	Au survol du lien (environ 200 ms)	Défaut du plugin. Bon équilibre vitesse / coût
eager	Au moindre survol (~10 ms sur desktop ; sur mobile, selon le viewport)	Navigation interne courte et maîtrisée seulement

Quelle combinaison pour quel résultat ? Prefetch + conservative, le défaut natif, t’enlève l’aller-retour réseau du document au moment du clic, sans risque fonctionnel. Prerender + moderate, le défaut du plugin officiel, déclenche plus tôt et rend la page entière d’avance : c’est la combinaison qui donne la fameuse sensation de navigation instantanée. Le prix à payer, on y vient…

Vérifier en 30 secondes que ça tourne déjà chez toi

Avant de toucher à un seul réglage, fais l’état des lieux. Deux méthodes, de la plus brute à la plus propre.

La méthode brute : ouvre une page de ton site en navigation privée, affiche le code source, puis cherche speculationrules. Si tu tombes sur un bloc <script type="speculationrules">, le cœur travaille déjà. Si tu ne trouves rien, vérifie tes permaliens et ta session. Le comportement est désactivé pour les utilisateurs connectés par défaut, mais le plugin officiel permet de les inclure volontairement depuis sa version 1.6.

La méthode propre, côté navigateur : ouvre les outils de développement de Chrome, onglet Application, section Background services, puis Speculative loads. Trois vues t’attendent : l’état de prérendu de la page courante, les jeux de règles trouvés, et la liste des URLs préchargées ou prérendues. Le piège qui fait perdre dix minutes à tout le monde, et que la doc Chrome signale : il faut recharger la page après avoir ouvert ces panneaux, sinon ils restent désespérément vides.

L’activer sous WordPress : ce qui est déjà là, et le cran au-dessus

Première bonne nouvelle, et pas la moindre : si ton site tourne sous WordPress 6.8 ou plus récent, avec des permaliens jolis (le réglage par défaut), tu n’as rien à faire. Le cœur injecte déjà ses règles de prefetch pour les visiteurs non connectés. Voici le bloc qu’il génère, capturé sur wordpress.org et réindenté pour la lecture (tu le récupères brut d’un curl -s https://wordpress.org/news/ | grep -A1 speculationrules) :

<script type="speculationrules">
{"prefetch":[{
  "source":"document",
  "where":{"and":[
    {"href_matches":"/news/*"},
    {"not":{"href_matches":[
      "/news/wp-*.php","/news/wp-admin/*","/news/files/*",
      "/news/wp-content/*","/news/wp-content/plugins/*",
      "/news/wp-content/themes/wporg-news-2021/*","/news/*\\?(.+)"
    ]}},
    {"not":{"selector_matches":"a[rel~=\"nofollow\"]"}},
    {"not":{"selector_matches":".no-prefetch, .no-prefetch a"}}
  ]},
  "eagerness":"conservative"
}]}
</script>

Précision utile : wordpress.org tourne dans un sous-dossier /news/. Sur une install à la racine du domaine, lis / au lieu de /news/, et /wp-content/uploads/ au lieu de /news/files/. Le reste est identique.

Regarde ce que le cœur exclut tout seul : l’admin, les fichiers PHP, les médias, le dossier wp-content (plugins et thème actif compris), et surtout toutes les URLs qui portent un paramètre (le \?(.+) de la fin). Les liens en nofollow et tout ce que tu marques d’une classe .no-prefetch dégagent aussi. C’est déjà une sacrée protection : les liens de déconnexion, les actions WooCommerce, les paniers, tout ce qui porte un jeton de sécurité voyage avec un paramètre, donc rien de tout ça n’est préchargé par accident.

Rien à installer : sur un WordPress 6.8+ à jour avec permaliens jolis, le prefetch conservative est déjà actif pour tes visiteurs. La fonctionnalité la plus rentable de l’année est peut-être celle que tu n’as jamais eu à activer.

Deux conditions désactivent volontairement la chose dans le cœur, et il faut les avoir en tête. D’abord, les utilisateurs connectés n’y ont pas droit par défaut. Le plugin officiel ajoute un opt-in pour ce cas depuis sa version 1.6, et affiche un avertissement si aucun cache objet persistant n’est présent. Ensuite, les sites sans permaliens jolis, ceux qui gardent les URLs en ?p=123, sont exclus puisque ces URLs ressemblent aux URLs à paramètres que WordPress veut éviter.

Et si tu veux le prerender ? Le cœur reste volontairement en prefetch conservative. Pour passer au prerender, deux chemins. Le plus simple : installer le plugin officiel Speculative Loading, maintenu par l’équipe performance de WordPress (version 1.7.0, testée jusqu’à WordPress 7.1, réglages dans Réglages > Lecture). Il bascule par défaut en prerender + moderate et te laisse choisir mode et eagerness depuis l’admin, sans une ligne de code. Une contrainte à connaître avant de cliquer sur "Installer" : depuis sa version 1.7.0, le plugin réclame WordPress 6.9 au minimum et PHP 7.4. Si tu es resté en 6.8, le prefetch du cœur tourne quand même, mais ce plugin-là ne s’installera pas : il te reste le filtre décrit juste en dessous.

Le chemin du développeur, lui, tient en quelques lignes dans un plugin maison ou le fichier de fonctions. Le cœur expose un filtre wp_speculation_rules_configuration (introduit avec WordPress 6.8) qui prend un tableau avec le mode et l’eagerness :

// Passer le coeur de WordPress en prerender + moderate
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
    return array(
        'mode'      => 'prerender',
        'eagerness' => 'moderate',
    );
} );

Le même filtre accepte null à la place du tableau : tu coupes alors complètement le Speculative Loading pour la requête en cours. Pratique pour le désactiver sur un type de page précis, une landing sensible par exemple.

Concrètement, sur wpformation.com, Next.js précharge les données de certaines routes liées par son composant Link en production. Le détail dépend du type de route et de la configuration du cache : ce n’est donc pas l’équivalent exact d’un prerender complet. La promesse ressentie reste proche, mais la mécanique et les limites ne sont pas les mêmes.

Pour les pros : prérendre tes pages stratégiques

Changer le mode global, c’est bien. Cibler chirurgicalement tes pages à fort trafic, c’est mieux, et ça limite le gaspillage. Le cœur expose pour ça une action wp_load_speculation_rules (depuis WordPress 6.8) qui te passe un objet WP_Speculation_Rules, sur lequel tu ajoutes tes propres règles. Weston Ruter, l’un des développeurs du cœur, en donne un exemple : prérendre la page d’accueil dès qu’on est sur un article, en ne ciblant que le vrai lien présent sur la page. Son code d’origine pousse l’eagerness en eager, je la ramène ici à moderate, plus prudente :

add_action( 'wp_load_speculation_rules', function ( WP_Speculation_Rules $rules ) {
    if ( is_singular() ) {
        // add_rule( string $mode, string $id, array $rule )
        $rules->add_rule( 'prerender', 'prerender-accueil', array(
            'source'    => 'document',
            'where'     => array( 'selector_matches' => 'a[rel="home"]' ),
            'eagerness' => 'moderate',
        ) );
    }
} );

L’astuce de la méthode : tu prérends seulement une URL dont tu sais qu’elle existe vraiment comme lien sur la page (ici, le lien d’accueil), au lieu de lâcher le navigateur sur tout ce qui bouge. Tu gardes le défaut prudent du cœur partout, et tu mets le turbo uniquement là où le parcours est prévisible. C’est ce niveau de finesse qui sépare un réglage à l’arrache d’une vraie stratégie de préchargement.

Les réglages que je recommande (et pourquoi)

Mon conseil dépend d’abord de la solidité de ton hébergement WordPress. Le prerender déclenche une requête et construit la page côté navigateur. Si la réponse n’est pas déjà servie par un cache, le serveur travaille pour une page qui ne sera peut-être jamais affichée. Sur un mutualisé un peu juste, la différence se sent vite. Sur un VPS correct ou un hébergement infogéré avec un cache efficace, le calcul change.

Concrètement, sur un mutualisé d’entrée de gamme, je reste sur le défaut du cœur : prefetch + conservative, zéro risque, un vrai petit gain. Sur un hébergement solide (VPS, infogéré, cache objet persistant), je passe en prerender + moderate via le plugin, et c’est là que la navigation devient bluffante. Et sur une boutique WooCommerce ? Prerender oui, mais en excluant soigneusement les pages à effet de bord : tunnel de commande, espace compte, liens affiliés cloakés. On ne prérend pas une page dont le simple chargement déclenche une action. Et avant de généraliser le prerender à toute la boutique, teste en conditions réelles : c’est là que la conso serveur grimpe le plus vite.

Justement, pour exclure des chemins, le cœur expose un deuxième filtre, wp_speculation_rules_href_exclude_paths (depuis WordPress 6.8). Note pour les puristes : /wp-login.php et /wp-admin/* sont exclus en dur par le cœur, ce filtre ne peut pas les rétablir. Les URLs avec paramètre sont déjà hors-jeu, mais tes liens affiliés maquillés en /go/ ou ton espace compte, eux, sont en GET propre. Autant les sortir :

// Exclure des chemins sensibles du prechargement
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( array $paths ) {
    $paths[] = '/go/*';         // liens affilies cloakes
    $paths[] = '/mon-compte/*'; // espace membre
    return $paths;
} );

Plus chirurgical encore : sur un lien précis dans l’éditeur, ajoute la classe CSS no-prefetch (ou no-prerender) et ce lien-là sera ignoré, sans toucher au reste. Parfait pour un bouton de téléchargement, un lien de paiement isolé, ou n’importe quel lien dont le clic déclenche autre chose qu’un simple affichage.

Les risques qu’on ne te dit pas

Le discours commercial autour de la fonctionnalité ne parle que de vitesse. Il y a trois revers à regarder en face, surtout en prerender. Bon. Rien de dramatique, mais autant être prévenu.

La conso serveur d’abord. Chaque prerender, c’est une page générée pour de vrai côté serveur, exécutée côté client, et parfois jetée parce que le visiteur n’a finalement pas cliqué. En eagerness moderate ou eager, sur un site à fort trafic, ça fait une charge bien réelle de pages fantômes. C’est exactement pour ça que le cœur reste prudent par défaut : Felix Arntz explique que le défaut conservative minimise le risque de chargements spéculatifs sans navigation derrière.

Les analytics ensuite, et c’est le point où la plupart des articles se plantent. Une page prérendue exécute son JavaScript dans un onglet invisible. Si ton outil de mesure compte une vue à ce moment-là, tu gonfles tes stats avec des pages que personne n’a regardées. La bonne nouvelle : Google Analytics 4 et le Google Publisher Tag gèrent déjà le prerender. La documentation Chrome l’indique. Ils s’appuient sur la propriété document.prerendering et attendent l’activation réelle de la page. Le souci vient surtout d’un tracking maison ou ancien qui se déclenche au chargement sans vérifier la visibilité.

Les ressources gaspillées enfin, côté visiteur cette fois. Sur mobile, précharger des pages jamais ouvertes, c’est de la batterie et du forfait qui partent en fumée. Prends un visiteur en itinérance, avec un forfait data compté au mégaoctet : en eager, tu lui fais télécharger en tâche de fond trois ou quatre pages qu’il ne verra jamais. L’eagerness conservative limite la casse, elle attend l’intention de clic. Une raison de plus de ne pas pousser en eager à l’aveugle sur un site grand public. Bref. On l’oublie trop souvent, mais la vitesse a un coût, et ce coût se déplace parfois chez le visiteur.

Comment mesurer le gain sans se raconter d’histoires

J’ai bien vérifié la présence du bloc speculationrules sur une installation WordPress classique avec des permaliens jolis et une session déconnectée. En revanche, je n’ai pas conservé de trace HAR publique ni de série de mesures assez solide pour transformer mon chronomètre en preuve. Je préfère donc retirer les chiffres ponctuels de mon labo et garder ce qui est reproductible.

Le bon test se fait entre deux pages. Ouvre Chrome DevTools, onglet Application, puis Speculative loads. Recharge la première page, déclenche une navigation et vérifie si la seconde a été prefetched ou prerendered. Pour comparer les temps, enregistre la navigation dans l’onglet Performance ou exporte un fichier HAR. Répète le parcours plusieurs fois avec et sans la règle, sur la même connexion et le même appareil.

Pourquoi pas Lighthouse ? Parce qu’un audit Lighthouse mesure une page chargée à froid, isolée. Le Speculative Loading accélère la navigation suivante. Un score identique avant et après ne réfute donc rien : il répond à une autre question.

Le chiffre public vient du terrain. À partir des jeux HTTP Archive et CrUX, et au moment de l’intégration dans WordPress 6.8 en mars 2025, l’équipe performance de WordPress a observé chez les sites utilisateurs une amélioration médiane d’environ 1,9 % du taux de navigations passant le seuil Largest Contentful Paint. Ce n’est ni 1,9 seconde gagnée, ni 1,9 point de score Lighthouse. Et ce résultat agrégé ne prédit pas celui de ton site : mesure ton parcours avant de généraliser.

Alors, tu l’actives ou pas ?

Si tu es sous WordPress 6.8 ou plus, la question est déjà tranchée pour le prefetch conservative : c’est en place, laisse-le tranquille. Le vrai arbitrage porte sur le prerender. Mon avis, après avoir regardé les chiffres et les contreparties : active-le dès que ton hébergement encaisse, surveille tes pages à effet de bord, et garde un œil sur tes analytics maison si tu en as. Sur un blog ou un site vitrine bien hébergé, le prerender + moderate transforme vraiment le ressenti de navigation, sans rien casser pour les visiteurs Safari ou Firefox.

C’est typiquement le réglage qui ne remplace pas le travail de fond, mais qui le couronne. Si tu n’as pas encore solidifié le cache, l’hébergement et les images, commence par là : j’ai détaillé tout ça dans mon guide pour accélérer WordPress. Le Speculative Loading, c’est la cerise. Une cerise qui charge la page d’après pendant que tu lis celle-ci… et ça, en 2026, ça reste étonnamment peu exploité. Autant en faire un de tes avantages discrets.

Fondateur de WPServeur, hébergeur WordPress, j’ai passé des années à regarder ce qu’un serveur encaisse vraiment quand on lui demande de fabriquer des pages d’avance. Quand une fonctionnalité native passe sous les radars alors qu’elle améliore la vie des visiteurs, j’ai du mal à la laisser dormir.

Sources à garder sous la main

• Annonce technique de l’intégration dans WordPress 6.8, avec le comportement par défaut et la mesure CrUX.
• Fiche officielle du plugin Speculative Loading, version, installations et opt-in des utilisateurs authentifiés.
• Guide Chrome pour inspecter et déboguer les chargements spéculatifs.
• Weston Ruter, prérendre chirurgicalement des URLs clés, la méthode dont je m’inspire plus haut.

Article original sur WPFormation