Pages à chargement instantané avec les règles de spéculation

Apprenez à améliorer les Core Web Vitals en rendant le chargement des pages instantané grâce à la nouvelle API de règles de spéculation

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

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

Vous êtes-vous déjà demandé pourquoi certaines pages semblent se charger instantanément ? C'est probablement parce que cette page a implémenté les règles de spéculation !

L'API Speculation Rules améliore la vitesse des futurs chargements de pages dans les applications multi-pages (MPA) en les préchargeant (prefetch) ou même en les prérendant (prerender). Les développeurs peuvent configurer des règles de spéculation pour suggérer au navigateur de précharger ou de prérendre des documents pour des chargements de page plus rapides (ou instantanés). Les règles de spéculation remplacent les anciennes techniques comme `<link rel="prefetch">` pour le préchargement des ressources ou la fonctionnalité obsolète propre à Chrome `<link rel="prerender">`.

Les règles de spéculation fonctionnent au niveau du document, ce qui les rend adaptées aux MPA impliquant des navigations complètes. Les applications à page unique (SPA) qui utilisent principalement des appels API ou des mises à jour partielles de contenu ne bénéficieraient pas autant 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 depuis une page d'atterrissage, compensant potentiellement le temps de chargement initial.

Démarrage rapide avec les règles de spéculation

Vous savez déjà ce que sont les règles de spéculation ? Génial ! Voici quelques extraits prêts à l'emploi pour commencer immédiatement. Choisissez simplement l'extrait qui vous convient et placez-le dans le <head> de votre page (n'hésitez pas à changer preload en prefetch et/ou l'eagerness) ! 

<!-- 
   WordPress speculation rules by corewebvitals.io 
   prefetches all internal links
   skips links that match wp-login, wp-admin, wp content 
   skips links that have the nofollow attribute
   skips links that have a questy string for example: /search->
<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>
<!-- Data-preload triggered speculation rules by corewebvitals.io -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

Conseil : si vous avez besoin de créer rapidement vos propres règles de spéculation, pourquoi ne pas essayer le générateur de règles de spéculation

Avantages des règles de spéculation


Expérience utilisateur (UX) améliorée : En prédisant et en préchargeant le contenu, les règles de spéculation assurent des chargements de page quasi-instantanés, rendant la navigation fluide pour les utilisateurs. Cela rivalise avec les performances des applications à page unique, même pour les sites web multi-pages traditionnels, sans la complexité et la dépendance au JavaScript. Des temps de chargement plus rapides signifient une meilleure expérience de navigation, augmentant probablement l'engagement des utilisateurs et réduisant les taux de rebond.

Avantages SEO : Puisque l'amélioration de la vitesse de page est un facteur de classement direct et qu'un meilleur Time to First Byte (TTFB) entraînera un meilleur Largest Contentful Paint (LCP), la mise en œuvre de règles de spéculation améliorera inévitablement les Core Web Vitals et vous donnera ce bonus de vitesse de page.

Complexité réduite : Des chargements de page quasi-instantanés étaient auparavant possibles en utilisant une SPA ou en écrivant une logique de préchargement personnalisée pour les MPA.
Pour de nombreux cas d'utilisation, l'inconvénient d'une SPA est le temps de démarrage initial, qui peut être considérable car elles dépendent fortement de JavaScript, ainsi que 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 également le processus de 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 s'appuyaient sur JavaScript pour effectuer ces vérifications et injecter des pages à précharger. Les navigateurs peuvent nativement prendre en compte le contexte de l'utilisateur, comme une mémoire faible sur les appareils mobiles ou le mode économie de batterie, pour décider de prérendre ou non. Cette adaptation dynamique aide à conserver les ressources de l'utilisateur et assure une expérience plus fluide même sous contraintes.

Autres avantages : L'en-tête HTTP Speculation-Rules permet un déploiement plus facile via les réseaux de diffusion de contenu (CDN), éliminant 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 pour le préchargement ou le prérendu en fonction 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, équilibrant la vitesse de préchargement et la consommation de ressources. Cela aide à réduire le préchargement inutile et empêche le gaspillage de ressources.

Mécanique des règles de spéculation

Les règles de spéculation sont définies à l'aide d'une structure JSON et peuvent être implémentées de deux manières :

  • Script en ligne : Incluez le JSON dans une balise `<script type="speculationrules">` soit dans le `<head>`, soit dans le `<body>` du document HTML principal.
  • En-tête HTTP : Délivrez les règles en utilisant 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, facilitant les déploiements CDN sans modifier directement le contenu HTML.

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

  • urls (une liste d'URL) Un tableau d'URL à précharger ou à prérendre.
  • where (règles de document) Un objet qui utilise des conditions pour déterminer quels liens sur la page doivent être préchargés ou prérendus.

Chaque règle est définie comme un objet qui inclut 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," indiquant qu'un préchargement cross-origin doit anonymiser l'adresse IP du client.
  • target_hint Une chaîne fournissant un indice sur le nom de la cible navigable, permettant à l'agent utilisateur d'optimiser le processus de chargement. Cela n'a aucune implication normative au-delà d'être un indice.
  • referrer_policy Une politique de référent à appliquer aux URL préchargé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 précharger ou prérendre. Les paramètres disponibles sont "immediate," "eager," "moderate," et "conservative," chacun avec des déclencheurs différents.
  • expects_no_vary_search Une chaîne utilisée pour fournir un indice de variance de recherche d'URL, permettant aux développeurs de signaler si l'URL spéculée est censée avoir une réponse différente en fonction des paramètres de recherche. .

Enfin, chaque règle a un paramètre "eagerness" qui vous permet de définir quand les spéculations doivent s'exécuter, séparant le moment de la spéculation des URL sur lesquelles effectuer les spéculations. Le paramètre "eagerness" est disponible pour les règles de source de liste et de document et comporte quatre réglages : immediate, eager, moderate et conservative.

  • immediate : Utilisé pour spéculer dès que possible, dès que les règles de spéculation sont observées.
  • eager : Se comporte actuellement de manière identique au paramètre immediate, mais à l'avenir, il se situera quelque part entre immediate et moderate.
  • moderate : Effectue des spéculations si vous survolez un lien pendant 200 millisecondes (ou sur l'événement pointerdown si cela se produit plus tôt, et sur mobile où il n'y a pas d'événement de survol).
  • conservative : Spécule au clic ou au toucher (pointer ou touch down).

Prefetch ou Prerender

L'API Speculation Rules prend en charge deux formes principales de chargement spéculatif : le prefetching (préchargement) et le prerendering (prérendu). Bien que les deux techniques puissent entraîner des chargements de page plus rapides, elles diffèrent par leur complexité et leur consommation de ressources.

  • Prefetching 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 (TTFB). Un meilleur Time To First Byte conduira à de meilleures métriques d'affichage comme le Largest Contentful Paint (LCP) et le First Contentful Paint (FCP).
  • Prerendering fait bien plus que simplement télécharger le HTML. Il télécharge le HTML, toutes les sous-ressources et rend la page entière dans un onglet caché et invisible. Lors de la navigation vers cette page, cela entraîne un affichage quasi-instantané. Cette technique améliore le Largest Contentful Paint (LCP) de bien plus de façons qu'en améliorant simplement le Time To First Byte ; elle télécharge et rend également l'élément LCP. Le prerendering peut également éliminer le Cumulative Layout Shift (CLS) car les dimensions des ressources sont déjà connues après le prérendu.

Alors, qu'est-ce qui est mieux ? Prerendering ou Prefetching ? Cela dépend de la page et du "visiteur moyen". Bien que le prerendering puisse être plus rapide par conception, il utilise également beaucoup plus de ressources, tant sur le client que sur le serveur. Le choix entre prerendering et prefetching dépend de :

  • Capacités de l'appareil de l'utilisateur : Le prerendering pourrait ne pas être le meilleur choix si un pourcentage élevé de visiteurs utilise des appareils avec une mémoire limitée.
  • Spécificité de la règle de prerender ou prefetch. "Certains liens sont plus susceptibles d'être cliqués et certaines pages sont plus susceptibles de convertir". Ces pages sont des candidats parfaits pour une règle de prerender. D'autres pages pourraient être plus adaptées au prefetch.

CoreWebVitals.io tient à mettre en garde contre un prerendering excessif en raison de ses exigences en ressources, en particulier sur les appareils mobiles ou les connexions plus lentes. Les avantages potentiels du prerendering doivent être mis en balance avec le risque de dégradation des performances et de gaspillage des ressources.

Définir le bon 'Eagerness' - un jeu d'équilibre

Le paramètre eagerness à utiliser dépend de votre site. Pour un site statique très simple, spéculer avec plus d'empressement peut avoir peu de coût et être bénéfique pour les utilisateurs. Les sites avec des architectures plus complexes et des charges de page plus lourdes peuvent préférer réduire le gaspillage en spéculant moins souvent jusqu'à obtenir un signal d'intention plus positif des utilisateurs pour limiter le gaspillage.

Le paramètre eagerness dans l'API Speculation Rules influence le moment où un navigateur doit précharger ou prérendre du contenu en fonction de la navigation prévue de l'utilisateur. Ce paramètre offre un compromis entre la maximisation des avantages du préchargement et la minimisation du gaspillage de ressources.

L'eagerness par défaut pour les règles de liste est immediate. Les options moderate et conservative peuvent être utilisées pour limiter les règles de liste aux URL avec lesquelles un utilisateur interagit dans une liste spécifique. Dans de nombreux cas, des règles de document avec une condition where appropriée peuvent être plus appropriées.

L'eagerness par défaut pour les règles de document est conservative. Étant donné qu'un document peut comporter de nombreuses URL, l'utilisation de immediate ou eager pour les règles de document doit être faite avec prudence.

Le choix de l'eagerness dépend de la structure du site web, des modèles de comportement des utilisateurs et de l'évaluation par le développeur de la consommation potentielle de ressources par rapport aux avantages pour l'expérience utilisateur. Par exemple, un site statique simple pourrait bénéficier d'un paramètre "eager", conduisant à des temps de chargement plus rapides. Inversement, les sites web aux architectures complexes et aux charges de page exigeantes peuvent opter pour une approche "moderate" ou "conservative" moins agressive pour limiter l'utilisation des ressources jusqu'à ce qu'une intention utilisateur plus claire soit détectée.

Lors de la configuration de l'eagerness, les développeurs doivent prendre en compte l'expérience utilisateur, les coûts des ressources et les limitations du navigateur. Une spéculation excessive peut solliciter la bande passante, la mémoire et le processeur de l'utilisateur, dégradant potentiellement les performances, en particulier sur les réseaux ou appareils contraints. Chrome impose des limites sur les pages préchargées et prérendues simultanées pour atténuer la surutilisation. De plus, des facteurs tels que les modes Data Saver configurés par l'utilisateur, les conditions de batterie faible ou les extensions de navigateur peuvent outrepasser les règles de spéculation, donnant la priorité à 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 DevTools Chrome, allez dans le panneau Application et naviguez vers Background Services > Speculative Loads > Speculations. (ouvrez le volet Speculations avant de charger la page que vous souhaitez déboguer) Ce panneau fournit des informations sur :

  • Le nombre de spéculations réussies.
  • Les URL individuelles en cours de prérendu ou de préchargement.
  • 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 besoin de changer le contexte des DevTools. De plus, vous pouvez changer 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 des pages. Recherchez des améliorations du LCP pour les pages prérendues par rapport aux pages non prérendues.
  • Tests A/B : Effectuez des tests A/B pour comparer différentes configurations de règles de spéculation et identifier la configuration optimale pour votre site web spécifique et votre base d'utilisateurs.

speculation rules rum tracking table coredash

Considérations - les mauvais côtés

Consommation de ressources : L'utilisation excessive de la spéculation peut avoir un impact négatif sur la bande passante, la mémoire et l'utilisation du processeur.

Compatibilité des navigateurs : Tous les navigateurs ne prennent pas entièrement en charge l'API Speculation Rules, vérifiez donc la compatibilité des navigateurs avant l'implémentation.

Confidentialité : Les développeurs doivent être conscients de la manière dont les règles de spéculation peuvent révéler les habitudes de navigation des utilisateurs et mettre en œuvre des mesures de confidentialité appropriées.

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 considérations, les développeurs peuvent tirer parti de cette API pour créer des sites web plus rapides et plus attrayants.

Code WordPress pour les règles de spéculation

L'équipe WordPress Core Performance a créé un plugin Speculation Rules qui rend l'ajout de la prise en charge des règles de document à tout site WordPress une affaire d'un clic. Le plugin offre deux groupes de paramètres :

  • Mode de spéculation : Choisissez entre prefetch et prerender. Le prerendering entraînera des temps de chargement plus rapides que le prefetching. Cependant, le prefetching pourrait être un choix plus sûr pour le contenu interactif.
  • Eagerness (Empressement) : 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é avec laquelle les chargements spéculatifs sont déclenchés.
Pages à chargement instantané avec les règles de spéculationCore Web Vitals Pages à chargement instantané avec les règles de spéculation