WordPress et l'API Speculation Rules : navigation ultra-rapide

On parle souvent d’optimisation des performances WordPress côté serveur, de cache ou de CDN… mais il existe une approche encore trop méconnue qui agit directement dans le navigateur, avant même que l’utilisateur clique sur un lien. L’API Speculation Rules, c’est exactement ça : un mécanisme natif qui permet d’anticiper la navigation en préchargeant ou en rendant les pages en arrière-plan. Et le résultat sur les Core Web Vitals peut être vraiment bluffant.

L’API Speculation Rules : c’est quoi exactement ?

L’API Speculation Rules, c’est une fonctionnalité relativement récente des navigateurs modernes qui permet d’anticiper intelligemment la navigation de l’utilisateur. Le principe : on dit au navigateur « hey, l’utilisateur va probablement cliquer sur ce lien », et lui se charge de préparer la page en arrière-plan avant même que le clic n’arrive. C’est de la spéculation, au sens littéral du terme.

Le préchargement classique vs. la Speculation Rules API

Avant l’arrivée de cette API, on disposait déjà de quelques outils pour anticiper la navigation. Les balises HTML <link rel="prefetch"> et <link rel="prerender"> existaient depuis longtemps — mais leurs limitations étaient réelles. Le prerender classique était notamment très gourmand en ressources, peu fiable selon les navigateurs, et il a fini par être déprécié dans sa forme originale.

La Speculation Rules API change la donne. Au lieu de déclarer des balises HTML statiques une par une, on fournit un bloc JSON directement dans la page (via une balise <script type="speculationrules">). Ce JSON définit des règles dynamiques : quels liens précharger, selon quels critères (URL, sélecteurs CSS, etc.), et avec quelle intensité. C’est beaucoup plus souple, plus puissant, et surtout bien mieux géré par le navigateur qui peut décider de ne pas exécuter la spéculation si les ressources sont limitées (batterie faible, connexion lente, etc.).

Prefetch vs. Prerender : deux niveaux de puissance

L’API propose deux modes bien distincts, et la différence est importante.

Prefetch : le navigateur télécharge les ressources de la page cible en avance (HTML, CSS, scripts…), mais ne fait rien de plus. Quand l’utilisateur clique, le chargement est déjà bien avancé, ce qui réduit le temps d’attente.
Prerender : là, on monte d’un cran. Le navigateur charge la page et l’exécute entièrement en arrière-plan — JavaScript inclus. C’est comme s’il ouvrait un onglet invisible avec la page déjà rendue, prête à s’afficher instantanément au moment du clic.

Le prerender, c’est l’option la plus impressionnante. En pratique, la navigation devient quasi-instantanée : l’utilisateur clique, la page apparaît. Pas de spinner, pas d’attente. Mais attention : ce mode consomme plus de ressources, donc il faut l’utiliser avec discernement (on n’active pas le prerender sur 50 liens à la fois !).

Compatibilité navigateurs en 2026

Côté support, la situation est assez favorable pour Chrome et Edge, mais un peu plus nuancée pour les autres.

Chrome et Edge (110+) : support complet du prefetch et du prerender via la Speculation Rules API. C’est là que l’API brille vraiment.
Firefox : support partiel et encore en cours de déploiement. Le prefetch basique fonctionne, mais le prerender via Speculation Rules n’est pas encore disponible en production stable.
Safari / WebKit : la situation est similaire — le support est limité et en cours d’implémentation. Apple avance, mais à son rythme habituel.

En résumé : en 2026, l’API est pleinement opérationnelle pour une large majorité des utilisateurs (Chrome représente toujours plus de 60% des parts de marché). Pour Firefox et Safari, le navigateur ignorera simplement les règles qu’il ne comprend pas — donc pas de bug, juste pas d’optimisation. C’est une amélioration progressive par nature, ce qui est une bonne chose.

Intégrer l’API Speculation Rules dans WordPress

Bonne nouvelle : intégrer l’API Speculation Rules dans WordPress, c’est finalement assez simple. Deux approches principales s’offrent à vous — la voie manuelle pour ceux qui aiment garder le contrôle, et le plugin officiel pour ceux qui préfèrent une solution clé en main. On va voir les deux en détail.

Ajouter les règles manuellement via wp_head

La méthode manuelle consiste à injecter une balise <script type="speculationrules"> directement dans le <head> de vos pages via le hook wp_head. Voici un exemple fonctionnel à ajouter dans votre functions.php (ou mieux, dans un plugin maison dédié) :

add_action( 'wp_head', function () {
    // Définition des règles de speculation
    $rules = [
        'prerender' => [
            [
                'source'    => 'document',       // Analyse les liens présents dans la page
                'eagerness' => 'moderate',        // Déclenche après ~200ms de survol
                'where'     => [
                    'and' => [
                        [ 'href_matches' => '/*' ],          // Toutes les URLs internes
                        [ 'not' => [ 'href_matches' => '/panier*' ] ],   // Exclure le panier
                        [ 'not' => [ 'href_matches' => '/commande*' ] ], // Exclure le checkout
                        [ 'not' => [ 'href_matches' => '/mon-compte*' ] ] // Exclure espace membre
                    ]
                ]
            ]
        ]
    ];

    echo '<script type="speculationrules">'
        . wp_json_encode( $rules )
        . '</script>' . "\n";
} );

L’avantage de cette approche : un contrôle total sur les règles. Vous pouvez adapter le JSON en fonction de votre architecture (WooCommerce, espace membres, etc.) sans dépendre d’un plugin tiers.

Utiliser le plugin WordPress dédié (Speculation Rules)

Si vous préférez éviter de toucher au code, il existe un plugin officiel — développé conjointement par l’équipe WordPress Core et Google — disponible directement sur le répertoire officiel WordPress.org. Il s’appelle tout simplement « Speculation Rules ».

L’installation est classique : Plugins → Ajouter → rechercher « Speculation Rules » → installer et activer. Une fois activé, les réglages apparaissent dans Réglages → Lecture (ou dans un sous-menu dédié selon la version). Vous pouvez y configurer :

Le mode : prefetch (chargement des ressources) ou prerender (rendu complet)
L’eagerness : conservative, moderate ou eager

C’est l’option idéale pour la majorité des sites WordPress qui n’ont pas de cas d’usage complexes. Le plugin gère automatiquement certaines exclusions de base (pages d’admin, login, etc.).

Configurer les règles : eagerness, source, URLs cibles

C’est là que ça devient intéressant. Le JSON des Speculation Rules accepte plusieurs paramètres clés qu’il faut bien comprendre.

source — deux valeurs possibles :

list : vous définissez explicitement un tableau d’URLs à précharger
document : le navigateur analyse les liens présents dans la page courante (plus flexible)

eagerness — c’est le déclencheur du préchargement :

conservative : déclenche uniquement au survol du lien (comportement prudent)
moderate : déclenche après environ 200ms de survol (bon compromis)
eager : déclenche dès que la règle est chargée, sans interaction utilisateur

where avec des sélecteurs CSS ou des patterns d’URL :

{
  "prefetch": [{
    "source": "document",
    "eagerness": "conservative",
    "where": {
      "and": [
        { "href_matches": "/blog/*" },
        { "not": { "selector_matches": ".no-prefetch" } }
      ]
    }
  }]
}

Ici, on précharge uniquement les liens du blog, et on exclut tous les éléments ayant la classe CSS .no-prefetch. Pratique pour exclure des liens spécifiques sans modifier les règles globales.

Bonnes pratiques et pièges à éviter

C’est probablement la partie la plus importante. Mal configurée, l’API Speculation Rules peut causer des effets de bord sérieux.

À ne jamais prerender :

Les pages de checkout WooCommerce (/commande/, /checkout/) — un prerender peut déclencher des effets de bord côté serveur
Les pages d’ajout au panier ou toute URL déclenchant une action POST
Les pages membres ou contenus personnalisés (le prerender se fait sans session utilisateur valide, ce qui peut générer du contenu incorrect mis en cache)

Attention à l’eager : utiliser eager sur source: document peut provoquer le prerender simultané de dizaines de pages dès le chargement. C’est une consommation mémoire et CPU côté client qui peut dégrader l’expérience sur les appareils mobiles, à l’opposé de l’effet recherché.

Utilisez 'not' pour les exclusions — c’est la bonne pratique à retenir :

{ "not": { "href_matches": "/wp-admin/*" } }

En résumé : restez sur moderate ou conservative pour commencer, excluez systématiquement les URLs sensibles, et testez avec les DevTools Chrome (onglet Application → Speculation Rules) avant de déployer en production.

Impact réel sur les performances WordPress : ce que disent les métriques

Bon, on a vu comment configurer l’API Speculation Rules sur WordPress. Mais maintenant, la vraie question : est-ce que ça change vraiment quelque chose en pratique ? La réponse courte, c’est oui — et parfois de façon spectaculaire. Mais (il y a toujours un « mais ») tout dépend de votre contexte.

Résultats sur les Core Web Vitals (LCP, INP)

Le LCP (Largest Contentful Paint) et l’INP (Interaction to Next Paint) sont les deux métriques qui bénéficient le plus du prerender. Rappel utile : l’INP a officiellement remplacé le FID (First Input Delay) dans les Core Web Vitals depuis mars 2024. C’est donc lui qu’on surveille désormais dans Google Search Console et PageSpeed Insights.

Voici ce qui se passe concrètement : quand une page est déjà pré-rendue en arrière-plan, le navigateur n’a plus rien à charger au moment du clic. Le LCP perçu peut alors tomber à 20-50 millisecondes — contre 1 à 3 secondes pour un chargement classique. C’est une différence que l’utilisateur ressent immédiatement.

Quelques ordres de grandeur réalistes à retenir :

Navigation ressentie < 100ms : c’est le seuil en dessous duquel le cerveau humain perçoit une transition comme « instantanée »
Gain LCP typique : de 1,5-2s à moins de 200ms sur des pages statiques bien configurées
Score CrUX amélioré : le Chrome User Experience Report agrège les données réelles des utilisateurs Chrome, donc les gains se reflètent directement dans votre positionnement

L’INP profite également du prerender, puisque les ressources JavaScript sont déjà parsées et exécutées. Les interactions post-navigation deviennent donc plus fluides, surtout sur des thèmes WordPress lourds en scripts.

Néanmoins, soyons honnêtes : ces chiffres s’appliquent aux cas favorables (pages statiques, contenu non personnalisé, règles de spéculation bien ciblées). Sur un site avec beaucoup de blocs dynamiques ou un builder gourmand, les gains seront plus modestes.

Limites et cas où le prerender est contre-productif

Le prerender, c’est puissant — mais ce n’est pas une solution universelle. Voici les cas où je vous déconseille fortement de l’activer sans précautions.

WooCommerce et le stock en temps réel : c’est probablement le piège le plus fréquent. Si une page produit est pré-rendue, elle affiche l’état du stock au moment du prerender, pas au moment du clic. Un produit peut donc apparaître « en stock » alors qu’il a été vendu entre-temps. Frustrant pour l’utilisateur, problématique pour votre gestion de stock.

Les pages d’authentification : pages de connexion, tableaux de bord membres, panier WooCommerce… Ces pages contiennent des données personnalisées par session. Le prerender risque de servir un état incorrect, voire de poser des problèmes de sécurité.

L’impact sur les analytics : le prerender déclenche techniquement un chargement de page. Bonne nouvelle : les navigateurs modernes gèrent ce cas via l’API Page Visibility — une page pré-rendue n’est pas comptabilisée comme une vue tant que l’utilisateur ne navigue pas réellement dessus. Mais certains scripts analytics moins récents peuvent ne pas respecter ce comportement. À vérifier dans votre configuration.

La charge serveur : c’est un point souvent oublié. Chaque prerender déclenche de vraies requêtes HTTP vers votre serveur WordPress. Sur un hébergement mutualisé avec des ressources limitées, une règle trop agressive (eagerness à "eager" sur toutes les pages) peut générer une surcharge notable — pour un gain finalement négligeable si le trafic reste faible.

Sites à très faible trafic : le coût en ressources dépasse souvent le bénéfice
Hébergements mutualisés : à utiliser avec "moderate" ou "conservative" en priorité
Pages avec formulaires dynamiques ou tokens CSRF : risque de tokens expirés

En résumé : activez le prerender là où ça a du sens (pages de contenu statique, articles de blog, pages catégories), et excluez explicitement tout ce qui est transactionnel ou personnalisé.