Comment utiliser l'API Speculation Rules sur Shopify

Points clés

• Shopify déploie déjà les speculation rules sur chaque storefront. La plateforme renvoie un en-tête de réponse Speculation-Rules qui pointe vers un fichier JSON pour prefetch les URL des produits, collections, pages, recherches, blogs et politiques avec une eagerness définie sur moderate.
• Shopify fait uniquement du prefetch. Il ne fait jamais de prerender. Ajouter votre propre règle prerender dans theme.liquid est la vraie opportunité, et la documentation des thèmes Shopify précise que les thèmes peuvent ajouter leurs propres règles.
• Le prefetch télécharge le HTML. Le prerender charge la page entière dans un onglet masqué, y compris les sous-ressources et le JavaScript. Le prerender est beaucoup plus rapide et beaucoup plus coûteux, alors limitez-le de façon ciblée.
• L’eagerness contrôle le déclencheur : immediate, eager, moderate (200ms de hover sur desktop) et conservative (pointer down). Les document rules sont sur conservative par défaut, les list rules sur immediate.
• Les vrais risques sur Shopify sont les effets de bord sur le panier et les réductions, les analytics comptés en double, et les scripts tiers qui se déclenchent avant l’arrivée du visiteur. Excluez les chemins /cart, /account, /checkouts et /discount, et conditionnez vos analytics sur document.prerendering.

L’API Speculation Rules permet à une page d’indiquer au navigateur quelles URL le visiteur est susceptible d’ouvrir ensuite, pour que le navigateur puisse les récupérer (fetch) ou les pré-rendre entièrement à l’avance. Sur Shopify, c’est l’un des rares moyens restants de rendre la navigation instantanée plutôt que simplement rapide.

La plupart des guides sur les speculation rules supposent que vous partez de zéro. Sur Shopify, ce n’est pas le cas. La plateforme injecte déjà un ensemble de règles pour vous, et le vrai travail consiste à savoir ce qu’il couvre, ce qu’il laisse délibérément de côté, et ce que vous pouvez ajouter en toute sécurité par-dessus dans theme.liquid.

Pourquoi vous pouvez nous faire confiance

Nous sommes dans l’écosystème Shopify depuis plus de quatre ans et avons travaillé avec des centaines de marques Shopify sur leurs storefronts. Jacques a plus de 15 ans d’expérience en développement. Nous créons Fudge, un éditeur de storefront IA noté 5.0 sur le Shopify App Store et ayant le statut Built for Shopify, nous travaillons donc directement dans la couche du thème où vivent ces règles.

Qu’est-ce que l’API Speculation Rules ?

C’est un bloc JSON à l’intérieur d’une balise <script type="speculationrules">. Le JSON désigne des URL, ou un pattern qui matche les liens du document, et dit au navigateur de les prefetch ou de les prerender.

<script type="speculationrules">
{
  "prerender": [
    { "where": { "href_matches": "/products/*" }, "eagerness": "moderate" }
  ]
}
</script>

Cela remplace les anciens resource hints. <link rel="prefetch"> réchauffait seulement le cache HTTP et ne donnait aucun contrôle sur le timing. <link rel="prerender"> n’a jamais été implémenté de manière cohérente et est obsolète. Les speculation rules vous offrent du pattern matching, des exclusions, des déclencheurs par règle et un ensemble défini de restrictions sur ce qu’une page spéculée est autorisée à faire.

Les règles sont une indication, pas un ordre. Un navigateur qui ne comprend pas la balise script l’ignore. Chrome lui-même refuse de spéculer quand le mode Save-Data est activé, quand l’appareil manque de RAM, quand l’économiseur d’énergie est actif sur batterie faible, ou quand l’utilisateur a désactivé le préchargement des pages.¹ Rien ne casse quand la spéculation n’a pas lieu. Le visiteur a juste droit à une navigation normale.

Prefetch vs Prerender

Le prefetch est le choix par défaut sûr. Le prerender est ce qui permet d’obtenir des chiffres spectaculaires, mais c’est aussi là que se cachent tous les risques évoqués dans ce guide.

Quelles speculation rules Shopify exécute-t-il déjà ?

Shopify a déployé les speculation rules sur l’ensemble de la plateforme fin juin 2025 et a signalé une amélioration moyenne de 130ms sur desktop et 180ms sur mobile sur tous les percentiles et toutes les métriques de chargement, c’est-à-dire le TTFB, le FCP et le LCP confondus.²

Les règles ne sont pas dans votre thème. Shopify envoie un en-tête de réponse Speculation-Rules pointant vers un fichier JSON sur son CDN, servi en tant que application/speculationrules+json. Faites un fetch de ce fichier sur n’importe quel storefront en ligne et vous obtiendrez les règles actuelles de la plateforme :

{
  "tag": "shopify_storefront_moderate",
  "prefetch": [
    {
      "where": {
        "or": [
          { "href_matches": "/(products|collections|pages|search|shop|blogs|policies){/*}?" },
          { "href_matches": "/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/(products|collections|pages|search|shop|blogs|policies){/*}?" },
          { "href_matches": "/" },
          { "href_matches": "/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?{/}?" }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}

Il y a trois choses intéressantes à tirer de ce bloc.

C’est uniquement du prefetch. Il n’y a pas de clé prerender à l’intérieur. Shopify récupère juste le document en avance et rien de plus.

C’est une allowlist, pas une blocklist. Seuls les produits, collections, pages, recherches, shop, blogs, politiques et la page d’accueil matchent, à la fois sous leur forme racine et préfixée par marché. Les URL de panier (cart), de compte et de checkout ne matchent jamais, elles ne sont donc jamais spéculées.

L’eagerness est à moderate. Shopify a commencé avec conservative puis a revu le paramètre par défaut à la hausse, signalant des gains médians sur desktop de 285ms sur le TTFB, 224ms sur le FCP et 228ms sur le LCP, avec environ 10% des navigations spéculées arrivant à un TTFB de 0ms. Les gains sur mobile étaient beaucoup plus faibles (environ 25ms, 20ms et 24ms). Le coût a été une augmentation de 14% du nombre total de requêtes HTML de la part des navigateurs compatibles.³

La documentation de Shopify sur les performances des thèmes confirme que les thèmes sont autorisés à ajouter leurs propres règles par-dessus. Votre job n’est donc pas de réimplémenter le prefetch. C’est de décider où le prerender est vraiment utile.

Les niveaux d’eagerness, et lequel choisir

L’eagerness est le déclencheur, pas la priorité. Ça répond à la question “quand est-ce que le navigateur applique cette règle”.

Sur mobile il n’y a pas de hover, donc Chromium se rabat sur des heuristiques liées au viewport. L’eagerness eager sur mobile se déclenche peu après qu’une balise <a> entre dans le viewport, un comportement qui a changé avec Chrome 143 ; avant cela, eager se comportait comme immediate. L’eagerness moderate sur mobile attend que le scroll s’arrête.

Les valeurs par défaut diffèrent selon le type de règle. Une list rule avec urls est par défaut sur immediate. Une document rule avec where est par défaut sur conservative. Si vous écrivez une document rule et oubliez de préciser l’eagerness, vous obtiendrez le comportement le plus prudent, ce qui n’est généralement pas ce que vous vouliez.

Pour un storefront Shopify, moderate est le point de départ raisonnable pour le prerender. Un prerender immediate sur une page collection essaierait de pré-rendre jusqu’à dix pages produit que l’acheteur n’ouvrira peut-être jamais, sur un appareil que vous ne contrôlez pas.

Document rules vs list rules

Les list rules nomment les URL directement. Elles conviennent pour une étape suivante connue et fixe.

{ "prefetch": [ { "urls": ["/collections/all", "/pages/size-guide"] } ] }

Les document rules matchent les liens déjà présents dans la page en utilisant where. Elles sont adaptées à un storefront, où les URL intéressantes sont générées par Liquid et changent selon la page.

href_matches utilise la syntaxe URL Pattern, donc * est un wildcard et {...}? indique un groupe optionnel. selector_matches prend un sélecteur CSS, ce qui permet d’exclure des liens individuels avec une classe. Les deux acceptent des arrays, et vous pouvez les composer avec and, or et not.

C’est cette combinaison qui rend les exclusions pratiques. Vous pouvez cibler “tous les liens de la page sauf ceux qui modifient l’état du serveur”.

Comment ajouter les speculation rules dans un thème Shopify

Les règles vont dans le layout pour exister sur toutes les pages qui l’utilisent. Ouvrez l’éditeur de code de votre thème, modifiez layout/theme.liquid, et placez le script juste avant la balise fermante </head>. Si vous n’avez jamais modifié de fichiers de thème auparavant, commencez par notre guide sur comment modifier un thème Shopify, et dupliquez le thème avant d’y toucher.

La version ciblée : prerender les produits depuis les pages de navigation

C’est la version avec laquelle il faut commencer. Elle fait un prerender des pages produit, et uniquement depuis les templates où l’acheteur est réellement en train de choisir un produit.

{%- if request.page_type == 'collection'
   or request.page_type == 'index'
   or request.page_type == 'search' -%}
  <script type="speculationrules">
  {
    "tag": "theme-product-prerender",
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": [
                "/products/*",
                "/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/products/*"
              ]
            },
            { "not": { "selector_matches": ".no-prerender" } },
            { "not": { "selector_matches": "[rel~=nofollow]" } }
          ]
        },
        "eagerness": "moderate"
      }
    ]
  }
  </script>
{%- endif -%}

Le if Liquid utilise request.page_type, que Shopify définit avec des valeurs comme collection, index, search, product et cart. Mettre cette condition évite que la règle ne s’applique sur des templates où le prerender d’une page produit ne sert à rien.

La deuxième entrée href_matches gère les marchés. Shopify préfixe les URL localisées avec un segment de locale, et le groupe ici est copié depuis le propre fichier de règles de Shopify pour que les deux se comportent de la même façon.

L’échappatoire .no-prerender est importante. Ajoutez cette classe à n’importe quel lien qu’un merchandiser décide par la suite de ne pas spéculer, et vous n’aurez pas besoin de toucher au code.

La version large : tout sauf les chemins dangereux

Si vous voulez une couverture plus large, inversez la logique. Matchez tous les liens, puis soustrayez les routes qui modifient l’état.

<script type="speculationrules">
{
  "tag": "theme-broad-prerender",
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": [
              "/cart{/*}?",
              "/checkouts/*",
              "/account{/*}?",
              "/discount/*",
              "/apps/*",
              "/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/cart{/*}?",
              "/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/account{/*}?",
              "/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/discount/*"
            ]
          }},
          { "not": { "href_matches": "/*\\?*(^|&)logout=*" } },
          { "not": { "selector_matches": "[rel~=nofollow]" } },
          { "not": { "selector_matches": ".no-prerender" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

/discount/* mérite sa propre ligne. Les liens de réduction Shopify appliquent un code et définissent un cookie avec une simple requête GET, donc prerender ce type de lien applique la réduction avant même que l’acheteur ait cliqué.

Testez d’abord les deux versions sur une copie non publiée de votre thème. Une speculation rule est facile à écrire, et tout aussi facile à rater subtilement.

Support navigateur en 2026

Les speculation rules sont une feature Chromium. Le prerender via l’API a été lancé dans Chrome 109, et Edge, Opera et Samsung Internet ont suivi sur le même moteur.

Le support global se situe autour de 75% du trafic traqué.⁴ Pour une boutique Shopify dont l’audience penche vers iOS Safari, la part atteignable est sensiblement plus faible, ce qui est une bonne raison de limiter le coût de vos règles plutôt qu’une raison de s’en passer.

Les navigateurs non compatibles ignorent tout simplement la balise script. Il n’y a pas de polyfill, aucun fallback n’est nécessaire, et aucune pénalité au-delà de quelques centaines d’octets de HTML en plus.

Les vrais risques sur Shopify

Bande passante gaspillée et charge serveur supplémentaire

Toute spéculation non suivie d’un clic est une requête que personne n’a utilisée. Shopify a mesuré une augmentation de 14% des requêtes HTML simplement en montant l’eagerness du prefetch d’un cran. Le prerender est encore plus lourd, car il télécharge les sous-ressources et exécute les scripts.

Shopify absorbe la charge côté serveur pour vous, mais ce n’est pas le cas de vos applications et des API tierces. Si une page produit appelle une API d’avis ou un service de personnalisation au chargement, le prerender de cette page fera de même.

Les analytics comptés en double

Une page en prerender exécute son JavaScript avant que l’acheteur ne la voie. Si vous n’y faites rien, cela gonfle vos pages vues et fausse tous les taux de conversion en aval.

La solution est de différer tout ce qui enregistre ou se déclenche jusqu’à l’activation :

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

Google Analytics gère le prerender nativement. Le tracking personnalisé, les widgets de chat, les timers de popup et la répartition des tests A/B ne le gèrent généralement pas. Auditez les scripts que votre thème charge avant d’activer le prerender, et si cet inventaire vous semble étranger, notre guide sur les scripts bloquants (render-blocking) sur Shopify est un bon moyen de les énumérer.

Effets de bord sur le panier et la session

C’est le danger spécifique à Shopify. Toute URL qui modifie l’état sur une requête GET est dangereuse à spéculer : liens de réduction, liens ?logout=, permaliens de panier, paramètres query d’ajout au panier, URL d’affiliation et de parrainage. Le propre ruleset de Shopify contourne tout le problème en mettant en allowlist uniquement des routes en lecture seule. Copiez cet instinct.

Vous ne pouvez pas filtrer côté serveur avec Liquid

Les navigateurs envoient Sec-Purpose: prefetch ou Sec-Purpose: prefetch;prerender sur les requêtes spéculatives, et un backend normal peut traiter ce header. Pas Liquid. L’objet request n’expose que host, origin, path, page_type, locale, design_mode et visual_preview_mode, sans accès aux en-têtes HTTP de la requête. Sur un thème Shopify, tous les garde-fous doivent se trouver dans la règle elle-même ou dans du JavaScript côté client.

Conflit avec les scripts de prefetch existants dans le thème

Beaucoup de thèmes payants intègrent encore un script de hover-preload, que ce soit instant.page ou un équivalent maison. instant.page précharge après 65ms de hover en utilisant son propre fetch, de manière totalement indépendante de la mécanique de spéculation du navigateur. Le faire tourner en même temps que le prefetch moderate de Shopify signifie que deux systèmes réclament le même document pour à peu près le même déclencheur.

Cherchez instant.page et rel="prefetch" dans les assets de votre thème avant d’ajouter des règles. Si un script fait doublon avec ce que la plateforme fait déjà, supprimez-le. Consultez comment ajouter du JavaScript personnalisé sur Shopify pour savoir où se cachent généralement ces snippets.

Comment vérifier si ça a marché

Chrome DevTools. Ouvrez le panneau Application et cherchez Speculative loads sous Background services. Il contient trois onglets : le statut de la page actuelle, tous les rulesets trouvés sur la page, et toutes les URL spéculées à partir de ces règles avec leur résultat. Les échecs sont accompagnés d’explications (comme une réponse non-2xx ou une limite déjà atteinte). Rechargez la page après avoir ouvert le panneau sinon il reste vide.

Field data. CrUX sépare les métriques par type de navigation depuis mars 2024, et prerender est l’un de ces types avec navigate, back_forward_cache et restore. C’est le moyen le plus honnête de voir quelle part de votre trafic réel atterrit sur une page en prerender, et à quoi ressemble son LCP comparé à une navigation à froid.

À quoi s’attendre. Le prerender améliore principalement le LCP, car la page est déjà affichée quand le clic se produit. L’INP peut s’améliorer par effet domino, puisque les scripts ont déjà été parsés et exécutés. Aucune de ces métriques ne bougera pour la part de visiteurs sur Safari ou Firefox, donc une moyenne à l’échelle du site sous-estimera toujours l’impact sur les utilisateurs de Chrome.

Les speculation rules sont une optimisation de la navigation, pas une solution pour le poids d’une page. Une page produit lente reste lente la première fois que quelqu’un la visite. Combinez cela avec les bases expliquées dans comment accélérer un thème Shopify, et jetez un œil à l’état des performances Shopify en 2026 pour voir où se situent les boutiques classiques aujourd’hui.

Le rôle de Fudge

Les speculation rules sont un petit bloc de JSON, mais le vrai travail se passe dans le thème : trouver le bon endroit dans theme.liquid, mettre des conditions sur request.page_type, auditer quels scripts se lancent au chargement, et retirer un vieux script de préchargement qui fait désormais doublon avec la plateforme.

Fudge est un éditeur de storefront IA qui écrit directement du Liquid, CSS et JavaScript natif dans votre thème. Vous pouvez lui demander d’ajouter un ruleset de prerender limité aux liens de produits sur les pages de collection, ou de trouver et supprimer le script de hover-preload inclus dans votre thème, puis lire le diff avant de publier.

Étant donné que le résultat est du code de thème et non une surcouche générée par une app, il n’y a pas de balise script supplémentaire venant d’un fournisseur externe, et rien ne disparaît si vous désinstallez l’app. Il en va de même pour tout ce que vous construisez avec le Shopify store editor.

FAQ