# Speculative Loading de WordPress 6.8 face à Algolia InstantSearch

> Le préchargement spéculatif testé en bêta de WordPress 6.8 profite-t-il à une recherche instantanée qui réécrit l'URL sans recharger la page ? La réponse dépend d'un détail d'implémentation qu'on ne voit qu'en observant le réseau.

- Auteur : Clément Hadrot
- Publié le : 2025-03-14
- Mis à jour le : 2025-03-14
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/speculative-loading-6-8-algolia-instantsearch/

## L’essentiel

- Le Speculative Loading précharge des URL, pas des états d'application
- Algolia InstantSearch change l'URL sans navigation classique
- Résultat : gain nul, voire négatif, sans réglage de l'API JavaScript

Le Speculative Loading précharge-t-il vraiment ce qu'un visiteur va cliquer ensuite, ou seulement ce qu'il pourrait cliquer si la page se comportait comme un site classique ? C'est la question posée en testant la bêta de WordPress 6.8 sur un site marchand équipé d'Algolia InstantSearch, où chaque clic sur une facette de recherche réécrit l'URL avec l'API History sans jamais recharger le document.

L'API Speculative Loading, en cours de stabilisation pour la version 6.8, s'appuie sur la `Speculation Rules API` du navigateur pour précharger ou pré-rendre les pages vers lesquelles un visiteur est susceptible de naviguer, en observant les liens présents dans le DOM. Sur le papier, une recherche instantanée avec des dizaines de résultats affichés en façade semblait un candidat idéal. En pratique, le comportement observé a été très différent de l'intuition de départ.

## Ce que le Speculative Loading regarde réellement

WordPress génère les règles de spéculation via la fonction `wp_get_speculation_rules`, en mode `eagerness` réglable (conservative, moderate ou eager), et cible par défaut les liens `<a href>` classiques du document, à l'exclusion des liens marqués `rel="nofollow"` ou pointant hors du domaine. Le mécanisme repose sur l'observation du DOM au chargement et sur les mutations ultérieures, mais il attend une vraie balise `<a>` avec un `href` qui correspond à une navigation de document.

Algolia InstantSearch, dans sa configuration par défaut avec le widget `hits`, génère bien des balises `<a>` pour chaque résultat, mais intercepte le clic en JavaScript pour appliquer un `history.pushState` et ne recharge jamais la page. Le `href` existe dans le DOM, mais la navigation réelle ne suit jamais ce chemin classique observé par le navigateur pour la spéculation.

> L'essentiel à retenir : Le Speculative Loading précharge des URL, pas des états d'application ; Algolia InstantSearch change l'URL sans navigation classique ; Résultat : gain nul, voire négatif, sans réglage de l'API JavaScript

## Le test réseau qui a tranché

Avec l'onglet Réseau des DevTools filtré sur les requêtes de préchargement (`Purpose: prefetch`), le constat a été net sur la configuration par défaut du site testé : zéro requête de préchargement déclenchée sur les liens de résultats InstantSearch, malgré une eagerness réglée sur `moderate`. En comparaison, les liens du menu de navigation classique déclenchaient bien des préchargements dès le survol.

- Les liens générés dynamiquement après une frappe dans la barre de recherche ne sont pas toujours détectés si l'observation DOM du navigateur ne se redéclenche pas correctement.
- Le `pushState` d'InstantSearch empêche toute pré-navigation de document, même si un préchargement avait eu lieu sur le `href`.
- Le gain espéré (charger la fiche produit avant le clic) ne se matérialise donc jamais dans ce scénario précis.

## Un préchargement qui peut même nuire

Pire : sur une eagerness poussée à `eager`, le navigateur a commencé à précharger un grand nombre de fiches produits visibles dans les dix premiers résultats, y compris celles jamais consultées par l'utilisateur, ajoutant une charge réseau et serveur inutile sur un site déjà sollicité par les requêtes Algolia elles-mêmes. Le gain net était négatif sur ce cas précis.

> Sur un site avec une recherche instantanée en JavaScript, nous désactivons désormais le Speculative Loading sur les zones de résultats via un attribut dédié, plutôt que de le laisser deviner un comportement qu'il ne peut pas observer correctement.

## La solution : cibler explicitement les zones concernées

WordPress 6.8 permet d'exclure des zones du document grâce à l'attribut `data-no-speculative-loading` ou en filtrant directement les règles générées via le filtre `wp_speculation_rules_configuration`. Sur ce site, la zone de résultats InstantSearch a été explicitement exclue, pendant que la navigation classique du site (menu, articles de blog, pages catégories) reste couverte par le Speculative Loading avec une eagerness modérée.

| Zone du site | Speculative Loading | Effet observé |
| --- | --- | --- |
| Menu principal | Activé, moderate | Préchargement au survol, navigation perçue plus rapide |
| Résultats InstantSearch | Exclu | Aucune charge réseau parasite, comportement JS inchangé |
| Articles de blog liés | Activé, conservative | Gain léger sans surcharge notable |

## Ce que cela signifie pour les sites à recherche JavaScript

Le Speculative Loading n'a pas vocation à comprendre les frameworks de recherche côté client : il observe le DOM et les navigations de document, point final. Tout site qui s'appuie sur du `pushState`, que ce soit pour une recherche instantanée, un filtre de catalogue ou une navigation de type application monopage partielle, doit auditer explicitement quelles zones bénéficient réellement du mécanisme avant de l'activer largement.

## Le verdict

Sur ce site, activer le Speculative Loading sans réglage fin aurait été contre-productif. Le gain réel s'est trouvé ailleurs, sur la navigation classique du site, tandis que la zone la plus visible — la recherche — est restée hors du périmètre du mécanisme. Un test réseau de dix minutes suffit à éviter ce genre de fausse bonne idée.