Pages à chargement instantané avec les Speculation Rules

Apprenez à améliorer les Core Web Vitals en rendant le chargement des pages instantané avec l'API Speculation Rules.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-26

Améliorez instantanément les Core Web Vitals avec l'API Speculation Rules

Vous vous demandez pourquoi certaines pages semblent se charger instantanément ? C'est probablement parce que cette page a implémenté les Speculation Rules.

L'API Speculation Rules améliore la vitesse des futurs chargements de page dans les applications multipages (MPA) via le prefetch ou le prerender. Les développeurs peuvent configurer des règles de spéculation pour suggérer au navigateur d'effectuer un prefetch ou un prerender des documents pour des chargements plus rapides (ou instantanés). Les règles de spéculation remplacent les anciennes techniques comme <link rel="prefetch"> pour le prefetch des ressources ou l'obsolète <link rel="prerender"> exclusif à Chrome.

Les règles de spéculation fonctionnent au niveau du document. Cela les rend adaptées aux MPA qui impliquent des navigations de pages complètes. Les applications monopages (SPA) qui utilisent principalement des appels d'API ou des mises à jour partielles de contenu bénéficieraient moins de cette API pour leurs changements de route internes. Cependant, les règles de spéculation peuvent toujours profiter aux SPA en prérendant l'état initial de l'application à partir d'une landing page. Cela compense le temps de chargement initial.

Dernière révision par Arjen Karel en février 2026

Démarrage rapide des Speculation Rules

Vous connaissez déjà les règles de spéculation ? Parfait. Voici quelques extraits prêts à l'emploi pour commencer immédiatement. Choisissez l'extrait adapté et placez-le dans le <head> de votre page (remplacez prerender par prefetch ou modifiez l'eagerness selon vos besoins).

<!--
   Règles de spéculation WordPress par corewebvitals.io
   prefetch tous les liens internes
   ignore les liens qui correspondent à wp-login, wp-admin, wp-content
   ignore les liens avec l'attribut nofollow
   ignore les liens avec une chaîne de requête, par exemple : /search?q=welcome
-->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "and": [
                { "href_matches": "\\/*" },
                { "not": {
                    "href_matches": [
                        "\\/wp-login.php",
                        "\\/wp-admin\\/*",
                        "\\/*\\\\?*",
                        "\\/wp-content\\/*"
                    ]
                }},
                { "not": {
                    "selector_matches": "a[rel~=\\"nofollow\\"]"
                }}
            ]
        },
        "eagerness": "moderate"
    }]
}
</script>
<!-- Règles de spéculation déclenchées par data-preload par corewebvitals.io -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

Astuce : pour créer rapidement vos propres règles de spéculation, utilisez le <b>générateur de règles de spéculation</b>.

Impact en conditions réelles

Les règles de spéculation ne sont pas théoriques. Les plus grands noms du web les utilisent déjà avec des résultats mesurables.

Ray-Ban a implémenté des règles de prerender sur ses pages de liste de produits avec un eagerness moderate. Le LCP est passé de 4,69 secondes à 2,66 secondes sur mobile (43 % plus rapide). Les taux de conversion sur mobile ont augmenté de 101 % et de 156 % sur desktop.

Shopify a déployé un prefetch conservative sur l'ensemble de sa plateforme en juin 2025. Leurs tests A/B ont montré une amélioration moyenne de 130 ms sur desktop et de 180 ms sur mobile sur toutes les métriques d'affichage.

Cloudflare Speed Brain, lancé en septembre 2024, ajoute par défaut des règles de spéculation à tous les forfaits Cloudflare. Les sites avec des prefetches réussis ont constaté une réduction de 45 % du LCP.

Même la recherche Google utilise des règles de spéculation. Les résultats de recherche sont prefetchés avec un eagerness eager. Cela économise 67 ms sur le LCP Android par clic.

Sur les sites surveillés par CoreDash, les navigations prérendues ont un LCP p75 de 320 ms. Les navigations standards sur les mêmes sites affichent 1 800 ms. C'est une amélioration de 82 % grâce à une seule API. Les sites utilisant des règles de spéculation avec un eagerness moderate voient environ 28 % de leurs navigations réussies en prefetch ou en prerender. Les navigations en prefetch affichent un TTFB p75 de seulement 45 ms. Le HTML est déjà dans le cache en mémoire du navigateur.

Avantages des règles de spéculation

Amélioration de l'expérience utilisateur (UX) : En prédisant et en préchargeant le contenu, les règles de spéculation garantissent des chargements de page presque instantanés. La navigation devient fluide pour les utilisateurs. Cela rivalise avec les performances des SPA, même pour les sites web multipages traditionnels, sans la complexité et la dépendance au JavaScript. Des temps de chargement plus rapides signifient une meilleure expérience de navigation. Cela augmente l'engagement des utilisateurs et réduit les taux de rebond.

Avantages SEO : L'amélioration de la vitesse des pages est un facteur de classement direct. Un meilleur Time to First Byte entraînera un meilleur Largest Contentful Paint. L'implémentation de règles de spéculation améliorera inévitablement les Core Web Vitals. Elle vous donnera ce bonus PageSpeed.

Complexité réduite : Des chargements de page presque instantanés n'étaient possibles qu'avec une SPA ou en écrivant une logique de prefetch personnalisée pour les MPA. Le principal inconvénient d'une SPA est son temps de démarrage initial. Il peut être considérable en raison de la forte dépendance au JavaScript et de la complexité accrue par rapport à une MPA. Les règles de spéculation n'ont pas ces problèmes. Cela rend le chargement rapide accessible à un plus large éventail de sites web, en particulier ceux axés sur le contenu.

L'API simplifie la décision des pages à prérendre en déléguant une grande partie de la logique au navigateur. C'est une énorme amélioration par rapport aux méthodes précédentes qui utilisaient du JavaScript pour effectuer ces vérifications et injecter les pages à précharger. Les navigateurs peuvent nativement prendre en compte le contexte de l'utilisateur pour décider de prérendre. Ils détectent une mémoire faible sur les appareils mobiles ou le mode économie d'énergie. Cette adaptation dynamique préserve les ressources de l'utilisateur et garantit une expérience fluide même sous contraintes.

Autres avantages : L'en-tête HTTP Speculation-Rules facilite le déploiement via les réseaux de diffusion de contenu (CDN). Il élimine le besoin de modifier directement le contenu du document. Le contrôle granulaire avec les règles de document permet aux développeurs de définir des conditions précises de prefetch ou de prerender basées sur des modèles d'URL ou des sélecteurs CSS. Cela réduit la spécification manuelle des URL et permet des ensembles de règles de spéculation à l'échelle du site. Le paramètre « eagerness » offre un contrôle fin sur le moment où la spéculation se produit. Il équilibre la vitesse de préchargement et la consommation des ressources. Cela réduit les préchargements inutiles et évite le gaspillage des ressources.

Support navigateur

Les règles de spéculation sont supportées dans Chrome 109+, Edge 109+ et tous les navigateurs basés sur Chromium. Cela couvre environ 79 % du trafic mondial selon Can I Use. Firefox a déclaré une position favorable sur les standards pour la partie prefetch, mais n'a pas encore déployé de support. Safari 26.2 possède une implémentation fonctionnelle derrière un flag. Elle n'est pas activée par défaut.

Pour les navigateurs qui ne supportent pas les règles de spéculation, utilisez la détection de fonctionnalités pour un fallback vers <link rel="prefetch"> :

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  // le navigateur supporte les règles de spéculation
} else {
  // fallback : injecte <link rel="prefetch">
  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = '/next-page.html';
  document.head.append(link);
}

Mécanismes des règles de spéculation

Les règles de spéculation sont définies par une structure JSON et s'implémentent de deux manières :

  • Script inline : Incluez le JSON dans une balise <script type="speculationrules"> dans le <head> ou le <body> du document HTML principal.
  • En-tête HTTP : Fournissez les règles via l'en-tête HTTP Speculation-Rules dans la réponse du document. Cet en-tête pointe vers un fichier JSON contenant les règles. Cela facilite les déploiements CDN sans modifier directement le contenu HTML.

La structure JSON utilise des tableaux « prefetch » et « prerender » pour contenir les règles de chaque type de chargement spéculatif. Chaque règle peut utiliser différentes sources : une liste d'URL ou des règles de document.

  • urls (une liste d'URL) : Un tableau d'URL pour le prefetch ou le prerender.
  • where (règles de document) : Un objet qui utilise des conditions pour déterminer quels liens sur la page doivent faire l'objet d'un prefetch ou d'un prerender.

Chaque règle est définie comme un objet incluant des propriétés telles que :

  • requires : Un tableau de chaînes pour définir des restrictions sur les spéculations. Actuellement, la seule chaîne valide est « anonymous-client-ip-when-cross-origin ». Elle indique qu'un prefetch cross-origin doit anonymiser l'adresse IP du client.
  • target_hint : Une chaîne fournissant une indication sur le nom de la cible navigable (« _self » ou « _blank »). Elle permet à l'agent utilisateur d'optimiser le processus de chargement.
  • referrer_policy : Une politique de référent à appliquer aux URL préfetchées ou prérendues.
  • relative_to (uniquement pour la source « list ») : Spécifie si les URL fournies dans le tableau « urls » sont relatives à l'URL de base du document (« document ») ou à l'emplacement du fichier JSON des règles de spéculation (« ruleset »).
  • eagerness : Contrôle l'agressivité avec laquelle le navigateur doit effectuer le prefetch ou le prerender. Les paramètres disponibles sont « immediate », « eager », « moderate » et « conservative », chacun ayant des déclencheurs différents.
  • expects_no_vary_search : Une indication informant le navigateur si l'URL spéculée est censée avoir une réponse différente selon les paramètres de recherche. Utile pour les pages avec des paramètres UTM ou d'autres chaînes de requête de suivi qui ne modifient pas le contenu.

Enfin, chaque règle possède un paramètre eagerness. Il permet de définir quand les spéculations doivent s'exécuter. Il sépare le moment de la spéculation des URL sur lesquelles spéculer. Le paramètre eagerness est disponible pour les règles de source list et document. Il a quatre paramètres : immediate, eager, moderate et conservative.

  • immediate : Utilisé pour spéculer le plus tôt possible, dès l'observation des règles de spéculation.
  • eager : Sur desktop, se déclenche après un survol de lien de 10 millisecondes. Sur mobile (à partir de janvier 2026), se déclenche 50 ms après l'entrée d'un lien dans le viewport.
  • moderate : Effectue les spéculations si vous survolez un lien pendant 200 millisecondes. Se déclenche aussi sur l'événement pointerdown s'il survient plus tôt, et sur mobile où l'événement de survol n'existe pas.
  • conservative : Spécule lors d'un appui de pointeur ou d'un toucher.

Limites de Chrome

Chrome impose des limites sur les spéculations simultanées pour éviter les abus et protéger les ressources de l'appareil :

  • immediate / eager : Jusqu'à 50 prefetches et 10 prerenders.
  • moderate / conservative : Jusqu'à 2 prefetches et 2 prerenders (FIFO : les nouvelles spéculations remplacent les plus anciennes).

Chrome désactive également complètement la spéculation lorsque le mode d'économie de données est activé, que l'appareil est en mode d'économie d'énergie avec une batterie faible, ou que l'utilisateur a désactivé le paramètre de préchargement des pages.

Prefetch ou Prerender

L'API Speculation Rules supporte deux formes principales de chargement spéculatif : le prefetch et le prerender. Bien que les deux techniques accélèrent les chargements de page, elles diffèrent par leur complexité et leur consommation de ressources.

  • Le prefetch est la forme la plus légère de chargement spéculatif. Il télécharge et met en cache le HTML de l'URL cible sans rendre la page ni ses sous-ressources. Cette approche améliore principalement le Time to First Byte. Un meilleur Time to First Byte conduit à de meilleures métriques d'affichage comme le Largest Contentful Paint et le First Contentful Paint.
  • Le prerender fait bien plus que télécharger le HTML. Il télécharge le HTML, toutes les sous-ressources et rend la page entière dans un onglet masqué et invisible. Lors de la navigation vers cette page, l'affichage est quasi instantané. Cette technique améliore le Largest Contentful Paint au-delà de la simple amélioration du Time to First Byte. Elle télécharge et rend également l'élément LCP. Le prerender peut aussi éliminer le Cumulative Layout Shift car les dimensions des ressources sont déjà connues après le prerender.

Il existe aussi une troisième option : le prerender until script. Cette nouvelle fonctionnalité (Chrome 144, janvier 2026) récupère le HTML, commence le rendu et le chargement des sous-ressources, mais suspend l'exécution du JavaScript à la première balise de script bloquante. Cela élimine les effets secondaires des scripts (comme le déclenchement des analytics) tout en préchargeant le CSS, les images et les polices.

Lequel est le meilleur ? Le prerender ou le prefetch ? Cela dépend de la page et du visiteur moyen. Le prerender est plus rapide par conception. Il consomme cependant beaucoup plus de ressources, côté client et côté serveur. Le choix entre le prerender et le prefetch dépend de :

  • Capacités de l'appareil de l'utilisateur : Le prerender n'est pas le meilleur choix si un pourcentage élevé de visiteurs navigue sur des appareils à mémoire limitée.
  • Spécificité des règles de prerender ou de prefetch. Certains liens ont plus de chances d'être cliqués. Certaines pages convertissent mieux. Ces pages sont de parfaites candidates pour une règle de prerender. D'autres pages conviendront mieux au prefetch.

Évitez le prerender excessif en raison de ses exigences en ressources. Soyez particulièrement prudent sur les appareils mobiles ou les connexions lentes. Pesez les avantages potentiels du prerender face au risque de dégradation des performances et de gaspillage des ressources.

Définir le bon eagerness

Le paramètre eagerness à utiliser dépend de votre site. Pour un site statique très simple, une spéculation agressive coûte peu et profite aux utilisateurs. Les sites avec des architectures complexes et des payloads plus lourds doivent réduire le gaspillage. Spéculez moins souvent. Attendez un signal d'intention plus clair de la part des utilisateurs.

Le paramètre eagerness de l'API Speculation Rules influence le moment où le navigateur effectue un prefetch ou un prerender du contenu selon la navigation prédite. Ce paramètre offre un compromis entre la maximisation des avantages du préchargement et la minimisation du gaspillage des ressources.

L'eagerness par défaut pour les règles list est immediate. Les options moderate et conservative limitent les règles list aux URL d'une liste spécifique avec lesquelles l'utilisateur interagit. Dans de nombreux cas, des règles document avec une condition where appropriée seront plus pertinentes.

L'eagerness par défaut pour les règles document est conservative. Un document contient souvent de nombreuses URL. Utilisez immediate ou eager pour les règles document avec précaution.

Lors de la configuration de l'eagerness, tenez compte de l'expérience utilisateur, des coûts en ressources et des limites du navigateur. Une spéculation excessive sature la bande passante, la mémoire et le CPU de l'utilisateur. Elle dégrade potentiellement les performances, surtout sur les réseaux ou appareils contraints. De plus, des facteurs comme les modes d'économie de données, une batterie faible ou des extensions de navigateur peuvent ignorer les règles de spéculation et prioriser la conservation des ressources.

Vérifier et déboguer les règles de spéculation

Pour vérifier les règles de spéculation sur une page, ouvrez les Chrome DevTools. Allez dans le panneau Application, puis naviguez vers Background Services > Speculative Loads > Speculations (ouvrez le panneau Speculations avant de charger la page à déboguer). Ce panneau fournit des informations sur :

  • Le nombre de spéculations réussies.
  • Les URL individuelles en cours de prerender ou de prefetch.
  • Le statut de chaque spéculation.

La piste Network dans le panneau Performance affiche l'activité réseau liée aux ressources prérendues sans avoir à changer le contexte des DevTools. Vous pouvez également basculer le contexte des DevTools vers une page prérendue pour l'inspecter comme une page normale.

speculative loads inspector devtools

Surveillance et analyse des règles de spéculation

  • Real User Monitoring (RUM) : Utilisez des outils RUM pour mesurer l'expérience utilisateur réelle. Observez des métriques comme le Largest Contentful Paint (LCP) pour évaluer l'impact des règles de spéculation sur les temps de chargement de page. Cherchez les améliorations du LCP pour les pages prérendues par rapport aux pages non prérendues.
  • A/B Testing : Effectuez des tests A/B pour comparer différentes configurations de règles de spéculation. Identifiez la configuration optimale pour votre site web et votre base d'utilisateurs.

speculation rules rum tracking table coredash

Considérations

Consommation des ressources : L'abus de spéculation impacte négativement la bande passante, la mémoire et l'utilisation du CPU. Commencez avec un eagerness conservative ou moderate. Surveillez les résultats avant d'augmenter.

Compatibilité des navigateurs : Tous les navigateurs ne supportent pas entièrement l'API Speculation Rules. Utilisez le code de détection de fonctionnalités ci-dessus pour fournir un fallback aux navigateurs non basés sur Chromium.

Confidentialité : Soyez conscient de la manière dont les règles de spéculation peuvent révéler les habitudes de navigation des utilisateurs. Implémentez des mesures de confidentialité appropriées. Pour un prefetch cross-origin, utilisez l'exigence « anonymous-client-ip-when-cross-origin ». Elle masque l'IP du client via le proxy prefetch privé de Chrome.

Analytics : Les pages prérendues exécutent le JavaScript. Les scripts d'analytics se déclencheront avant que l'utilisateur ne navigue réellement. Google Analytics et Google Publisher Tag gèrent cela automatiquement. Pour d'autres outils d'analytics, retardez l'initialisation jusqu'à l'activation de la page :

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

L'API Speculation Rules offre une approche puissante pour améliorer les performances et l'expérience utilisateur des applications web. En comprenant ses mécanismes, ses avantages et ses contraintes, utilisez cette API pour créer des sites web plus rapides et plus engageants.

Speculation Rules et WordPress

Depuis WordPress 6.8 (avril 2025), les règles de spéculation sont intégrées au cœur de WordPress. La configuration par défaut utilise un prefetch avec un eagerness conservative. Elle s'applique à toutes les pages frontend lorsque le visiteur n'est pas connecté et que les permaliens sont activés.

L'équipe WordPress Core Performance maintient également un plugin Speculative Loading autonome (+40 000 installations actives) qui offre plus de contrôle. Le plugin propose deux groupes de paramètres :

  • Mode de spéculation : Choisissez entre prefetch et prerender. Le prerender entraînera des temps de chargement plus rapides que le prefetch. Cependant, le prefetch peut être un choix plus sûr pour le contenu interactif.
  • Eagerness : Choisissez entre conservative (généralement au clic), moderate (généralement au survol) ou eager (à la moindre suggestion). Le paramètre eagerness détermine la rapidité de déclenchement des chargements spéculatifs.

Vous pouvez exclure des chemins spécifiques de la spéculation via un filtre PHP :

add_filter(
  'plsr_speculation_rules_href_exclude_paths',
  function($paths) {
    $paths[] = '/cart/*';
    $paths[] = '/checkout/*';
    return $paths;
  }
);

Pour d'autres méthodes pour différer les scripts et optimiser le chargement, consultez notre guide complet.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Search Console râle sur votre site ?

Je vous livre une liste de fix priorisés appuyée sur vos données terrain. Pas un PDF de 50 pages.

Demander un audit
Pages à chargement instantané avec les Speculation Rules Core Web Vitals Pages à chargement instantané avec les Speculation Rules