Chargement spéculatif WordPress : ce que le prefetch ne prépare pas

Le chargement spéculatif est une anticipation de navigation. Le site décrit, en JSON, quelles URL le navigateur peut demander avant que le visiteur les affiche. WordPress imprime ces règles dans une balise dont l’attribut type vaut speculationrules. Un moteur qui ne connaît pas l’API ignore la balise. Le gain, s’il existe, porte sur la page suivante, pas sur la première arrivée.

Depuis WordPress 6.8, sorti le 15 avril 2025, le cœur le fait sans extension. WordPress 7.1, publié le 19 août 2026 et maintenu en 7.1.3 le 6 octobre 2026, garde le même comportement livré : mode prefetch, empressement conservative. La 7.1 ajoute deux leviers d’hébergement. Il n’y a toujours pas de case dans l’administration.

Ce que le cœur active, et pour qui

La fonction wp_get_speculation_rules_configuration() n’arme le mécanisme que si le visiteur n’est pas connecté et si les permaliens jolis sont actifs. Sinon la configuration vaut null : aucune règle n’est imprimée. Un forum, une boutique où l’on reste identifié, ou un site encore servi en ?p=123, ne reçoivent pas le défaut.

La règle est une règle de document : elle vise les liens du même site déjà présents dans la page. WordPress retire toujours, et le filtre d’exclusion ne peut pas les réintroduire, les fichiers wp-*.php dont wp-login.php, tout /wp-admin/, les URL de la médiathèque, de wp-content, des extensions et des thèmes, les liens rel="nofollow", et, avec des permaliens jolis, toute URL qui porte une chaîne de requête.

La classe no-prefetch, sur un bloc ou sur un ancêtre du lien, retire ce lien. En prerender, no-prerender fait de même, et no-prefetch continue d’exclure : un prerender comprend un prefetch. Chrome laisse ces règles de côté en économie de données ou d’énergie, et si la mémoire est trop juste. Firefox et Safari, dans le tableau Can I Use du 13 octobre 2026, ignorent encore l’API. Chrome, Edge et Opera appliquent les règles de document depuis Chrome 121. La couverture y était estimée un peu au-dessus de 75 %.

Le prefetch ne prépare pas un prerender

Un prefetch de cette API télécharge le corps HTML. Il ne charge pas les sous-ressources et n’exécute pas le JavaScript. Le résultat reste en mémoire, attaché à la page courante, et disparaît quand on la quitte, sauf si l’on ouvre précisément ce document. MDN indique que Chrome conserve un prefetch environ cinq minutes : le HTML peut donc avoir quelques minutes de retard.

Un prerender charge la page dans un onglet invisible, sous-ressources comprises, et exécute le JavaScript. À l’activation, cet onglet remplace la page visible. Il reste sur la même origine. Vers une autre origine du même site, la cible doit envoyer Supports-Loading-Mode: credentialed-prerender. Vers un autre site, le prerender n’existe pas.

Si le seul effet de bord vient du JavaScript, le prefetch de WordPress est peu dangereux : ce script ne tourne pas. Le prerender, lui, lance audience, pixels et écritures localStorage comme si la page était déjà vue, tant que le script n’attend pas prerenderingchange.

L’extension Speculative Loading inverse le défaut du cœur : prerender, empressement moderate, écran dans Réglages > Lecture, visiteurs déconnectés seulement. En mars 2025, la note WordPress 6.8 citait environ 1,9 % de taux de passage LCP en plus, en médiane, d’après HTTP Archive et le Chrome User Experience Report, sur les sites de l’extension. Ce n’est pas le gain du prefetch conservateur. Un audit qui ouvre une URL seule ne le voit pas non plus : il n’y a pas eu de clic depuis une autre page du site.

Quatre niveaux d’empressement, un seul livré

L’empressement dit quand spéculer. Les seuils sont des heuristiques de Chrome, déjà retouchées sur mobile, pas un contrat entre navigateurs.

• conservative part au pointerdown ou au toucher, quand le clic a commencé. C’est le défaut.
• moderate part après un survol d’environ 200 ms sur ordinateur, ou plus tôt au pointerdown. Sur mobile, Chrome vise ensuite les liens jugés probables dans la zone visible.
• eager part plus tôt. Chrome l’a longtemps aligné sur immediate.
• immediate part à la lecture des règles. WordPress le refuse : la règle de document serait rejetée, et la page n’en aurait plus.

Chrome plafonne moderate et conservative à deux prefetches et deux prerenders simultanés, en file : le suivant chasse le plus ancien. Pour eager et immediate, la même documentation monte à 50 prefetches et 10 prerenders. Le défaut conservateur gagne une fraction de seconde. Il ne rend pas la page instantanée.

Une URL en GET peut agir deux fois

Le prefetch envoie un vrai GET, avec Sec-Purpose: prefetch. La navigation suivante envoie un second GET, sans cet en-tête. Un prerender s’annonce par Sec-Purpose: prefetch;prerender. Si l’URL ajoute au panier, déconnecte, change la langue ou envoie un code, le premier GET a déjà agi. Le mode conservateur n’évite pas le double effet : le visiteur clique, donc les deux requêtes partent.

Query strings, nofollow, wp-login.php et wp-admin sont déjà exclus. Un permalien réécrit comme /panier/ajouter/42/ ne l’est pas. Le filtre wp_speculation_rules_href_exclude_paths ajoute des chemins ; il n’en rend aucun. Son second argument est le mode. Les motifs suivent URL Pattern, depuis la racine, et WordPress préfixe un sous-répertoire. La référence est sur developer.wordpress.org.

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

Une réponse hors 200–299 bloque prefetch et prerender. Les codes 204 et 205 bloquent seulement le prerender. Mieux vaut répondre, ignorer l’effet de bord quand Sec-Purpose annonce une spéculation, et ne l’appliquer qu’à la vraie navigation. Après une déconnexion ou un panier modifié, Clear-Site-Data: "prefetchCache", "prerenderCache" invalide les copies déjà préparées.

Mesures, pages personnelles, HTML périmé

Un script d’audience placé dans le HTML ne part pas pendant le prefetch : le JavaScript ne s’exécute pas. Les journaux du serveur voient le GET. Un décompte de hits bruts compte donc des demandes jamais affichées.

En prerender, document.prerendering reste true jusqu’à l’activation. La page vue s’envoie sur prerenderingchange. Plusieurs outils connus le font. Un script du site, non.

function envoyerLaPageVue() {
    // Un seul envoi, quand la page est vraiment affichée.
}

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

Ensuite, activationStart sur l’entrée de navigation dépasse 0 si la page a été prerendue. Pour un prefetch, deliveryType vaut navigational-prefetch. La copie est figée : un commentaire publié dans les minutes suivantes peut manquer, une page prerendue déconnectée le reste si l’on se connecte dans un autre onglet, un panier prerendu vide le reste si l’ajout passe par fetch. On rafraîchit l’état à l’activation, ou l’on vide les caches de spéculation au moment du changement.

Monter d’un cran sans prerendre tout le site

Depuis WordPress 7.1, wp_get_speculation_rules_default_configuration() décide de quoi auto se rapproche. Le cœur écrit encore prefetch et conservative. Une constante, ou la variable d’environnement du même nom, peut remplacer l’une des deux valeurs. La constante l’emporte. Une valeur inconnue est ignorée.

define( 'WP_SPECULATIVE_LOADING_DEFAULT_MODE', 'prefetch' );
define( 'WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS', 'moderate' );

Ce couple précharge au survol sans exécuter le JavaScript. C’est le palier raisonnable une fois les URL d’action exclues, si l’origine encaisse le surplus de requêtes. Le filtre wp_speculation_rules_configuration l’emporte sur la constante. Pour ne prerendre que quelques URL stables, on ajoute une règle sans changer le défaut. Le navigateur fusionne les jeux de règles.

add_action(
    'wp_load_speculation_rules',
    function ( WP_Speculation_Rules $rules ) {
        $rules->add_rule(
            'prerender',
            'pages-stables',
            array(
                'source'    => 'list',
                'urls'      => array( '/blog/', '/apprentissage/' ),
                'eagerness' => 'moderate',
            )
        );
    }
);

Une page personnelle, un tunnel de commande ou une URL d’action n’entre pas dans cette liste. Si une Content-Security-Policy restreint script-src, la balise doit être couverte par 'inline-speculation-rules', un hash ou un nonce. En navigation privée, speculationrules apparaît dans le source ; Chrome la détaille dans Application, section Speculative loads. Connecté, la balise est absente. Un lien ?utm_source=test n’est pas préchargé.

Questions fréquentes

Le chargement spéculatif est-il déjà actif sans extension ?

Oui, depuis WordPress 6.8, pour un visiteur déconnecté sur un site à permaliens jolis. Le mode livré est le prefetch conservateur. L’extension ajoute un écran et, par défaut, un prerender plus agressif. La 7.1 ne passe pas au prerender parce qu’un cache objet est présent.

Pourquoi un test de performance ne bouge-t-il pas ?

L’outil charge une URL seule. Le mécanisme n’agit qu’entre deux pages du site. Le LCP d’une arrivée depuis un moteur ou un favori ne change pas.

Un prefetch compte-t-il comme une visite ?

Non pour un script qui ne s’exécute qu’à l’affichage. Oui dans les journaux du serveur, qui voient le GET. En prerender, le script tourne dans l’onglet invisible, sauf s’il attend prerenderingchange.

Faut-il exclure à la main les URL avec un point d’interrogation ?

Non, avec des permaliens jolis : WordPress les retire déjà, y compris un lien ?utm_source=. Les URL d’action réécrites sans query string restent à exclure.

Firefox et Safari en profitent-ils ?

Pas dans leur version livrée au 13 octobre 2026. Ils ignorent la balise. Chrome, Edge et Opera l’appliquent. Aucun script de repli n’est nécessaire pour que le site reste correct.

Peut-on prerendre une page d’un autre domaine ?

Non. Le prerender inter-sites n’est pas disponible. Un prefetch vers un autre site ne part pas si des cookies existent déjà sur la cible.

Pour aller plus loin

Avant un prerender, il faut savoir quels scripts le navigateur peut exécuter. L’article sur la Content-Security-Policy, le nonce et le cache traite ce verrou. La section Apprentissage reprend le HTML et le CSS utiles pour un sélecteur no-prefetch. Les autres notes sont sur le blog.