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.
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
pushStated’InstantSearch empêche toute pré-navigation de document, même si un préchargement avait eu lieu sur lehref. - 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.
