Accélérer le Web avec les Speculation Rules : le Guide Complet

Concept

L’instant d’origine

Dans les années 2010, Alexandre Dieulot a observé un délai de 200 à 300 millisecondes entre le survol et le clic sur un lien. Il a décidé d’utiliser ce laps de temps pour précharger la page, la rendant ainsi instantanée au clic. Cette idée simple nécessitait de définir le préchargement (une requête Le HTTP (HyperText Transfer Protocol) est un protocole utilisé pour transférer des données sur le web, permettant la communication entre un navigateur et un serveur pour afficher des pages web. XHR) et d’exclure les téléchargements, et a donné naissance à la célèbre bibliothèque JS JavaScript est un langage de programmation dynamique principalement utilisé pour ajouter des fonctionnalités interactives aux pages web. Il permet de manipuler le DOM, de gérer des événements, et d'effectuer des requêtes asynchrones. instant.page. C’est ce même principe qu’exploitent les Speculation Rules.

Définition

Les Speculation Rules permettent d’effectuer un chargement spéculatif. Elles offrent aux navigateurs la capacité d’anticiper les actions des visiteurs, préchargeant ainsi les pages avant même qu’ils ne cliquent.

Ce chargement spéculatif fonctionne en préchargeant ou en pré-rendant les pages web en arrière-plan.

• Le préchargement (prefetch) consiste à télécharger la page (code HTML Le HTML (HyperText Markup Language) est le langage standard utilisé pour structurer et afficher le contenu sur le web. Il définit des éléments comme les titres, paragraphes, liens, images, et autres composants d'une page web. ) en arrière-plan. Notez qu’aucune des sous-ressources référencées par la page n’est téléchargée.
• Le prérendu (prerender), quant à lui, va encore plus loin en chargeant et en exécutant entièrement la page en arrière-plan. Ainsi, lorsque l’utilisateur clique sur le lien, la page s’affiche instantanément.

L’investissement dans cette technique en vaut la peine, car un site web rapide est crucial pour le SEO Le référencement naturel, ou SEO (Search Engine Optimization), est l'ensemble des techniques visant à améliorer la visibilité d'un site web dans les résultats de recherche des moteurs comme Google, sans utiliser de publicité payante. . Les moteurs de recherche favorisent les sites offrant une excellente expérience utilisateur L'expérience utilisateur (UX) désigne la qualité de l'interaction d'un utilisateur avec un produit ou service, en termes de satisfaction, facilité d'utilisation et efficacité. , et le chargement spéculatif via les Speculation Rules contribue grandement à optimiser les performances web, notamment en ce qui concerne les Core Web Vitals.

NB : Ne confondez pas les Speculation Rules avec <link rel="preload" >. L’attribut preload est utilisé pour optimiser le chargement des ressources essentielles à la page actuelle, telles que les polices, les images et les scripts. À l’inverse, les Speculation Rules sont conçues pour anticiper et charger les pages subséquentes que l’utilisateur est susceptible de consulter, améliorant ainsi la rapidité de la navigation.

Comprendre les Speculation Rules

La syntaxe

Les Speculation Rules s’implémentent via un objet JavaScript, intégré directement dans le code HTML de votre page. Cette syntaxe permet de définir les URLs à charger de manière spéculative, ainsi que le type de chargement spéculatif à appliquer (prefetch ou prérendu).

<script type="speculationrules">
{ 
  "prefetch": [
     { "urls": ["page1.html", "page2.html"] }
  ] 
}
</script>

Chaque règle est définie dans un tableau d’objets, où chaque objet spécifie une URL Une URL (Uniform Resource Locator) est l'adresse unique d'une ressource sur Internet, comme une page web, une image ou un fichier, permettant de la localiser et d'y accéder via un navigateur. à charger et le type d’action (prerender ou prefetch). Les développeurs peuvent affiner le chargement spéculatif en utilisant des sélecteurs pour cibler des liens spécifiques ou en définissant des conditions pour le chargement. Ils peuvent même combiner les deux.

Enfin un paramètre eagerness permet de contrôler le moment où une page est préchargée ou prérendue avec 3 modes possibles :

• immédiat : La page est pré-rendue ou pré-extraite immédiatement.
• modéré : La page est pré-rendue ou pré-extraite lorsque l’utilisateur survole un lien pendant 200 millisecondes.
• conservateur : La page est pré-rendue ou pré-extraite lorsque l’utilisateur lance un clic sur le lien. On pourrait se demander quel est l’intérêt de ce paramètre, étant donné que cliquer sur un lien ouvre de toute façon la page suivante. La raison est que, grâce à la règle de spéculation, la page suivante commence à se charger en arrière-plan dès que l’utilisateur appuie sur le bouton de la souris ou touche l’écran sur un appareil mobile. Un clic n’est enregistré qu’une fois que le bouton de la souris est relâché.

L’interprétation par les navigateurs

Les navigateurs modernes sont conçus pour traiter ces règles de manière asynchrone, minimisant l’impact sur le chargement initial de la page. Lors du chargement spéculatif, le navigateur télécharge les ressources nécessaires ou effectue un rendu complet de la page en arrière-plan. Les ressources préchargées ou les pages pré-rendues sont généralement stockées dans le cache Le cache est un espace de stockage temporaire qui conserve des données fréquemment utilisées pour accélérer leur accès ultérieur, réduisant ainsi les temps de chargement et la consommation de ressources. du navigateur. Lorsque l’utilisateur clique sur un lien correspondant, le navigateur peut récupérer la page directement depuis ce cache. Ce processus, bien que complexe, se traduit par des chargements de pages beaucoup plus rapides lorsque l’utilisateur navigue vers des pages ainsi préchargées.

Mise en œuvre

Commencez par bien définir vos besoins ! Il est essentiel de réfléchir aux pages qui ne devraient pas être pré-affichées. Si le pré-affichage d’une page entraîne des effets secondaires indésirables, vous devez évaluer si la page doit être pré-affichée. Par exemple, une page qui déconnecte l’utilisateur ne devrait pas être pré-affichée.

Comment implémenter les Speculation Rules ?

Comme dit précédemment, les règles de spéculation peuvent être définies directement dans le code HTML dans une balise script. Mais elles peuvent aussi être définies dans un fichier texte externe référencé par l’en-tête HTTP « Speculation-Rules », via un fichier JSON Le JSON (JavaScript Object Notation) est un format léger de données structuré en texte, utilisé pour échanger des données entre un serveur et un client web. Il est lisible par l'homme et facile à analyser par les machines. avec la même structure que celle fournie ci-dessus par exemple. Il faudra penser à envoyer ce fichier avec le bon mime-type à savoir "application/speculationrules+json". Cela peut être très utile lorsque les développeurs ne peuvent pas modifier directement le document lui-même.

Chaque règle spéculative est définie autour de 3 points :

1. Son mode de préchargement prefetch ou prerender.
2. Une liste d’urls via un simple tableau d’urls (voir l’exemple ci-dessus)
   ou une instruction where bien plus complexe.
3. Et le moment de l’exécution avec le paramètre eagerness avec les valeurs "immediate", "moderate" ou "conservative". Si "eagerness" n’est spécifié explicitement, les règles basé sur une liste d’urls utiliseront "immediate" et celles basées sur where prennent par défaut la valeur "conservative".

Il y a un quatrième point optionnel : « source » qui indique la source des URL auxquelles la règle s’applique. Cette option est facultative, car la valeur peut toujours être déduite d’autres propriétés ; mais peut être très pratique dans le cas d’un fichier centralisé.

Détails de l’instruction where  :

• href_matches : cible les liens dont l’URL correspond à un ou plusieurs motifs définis.
• relative_to : spécifie le contexte d’URL pour href_matches.
• selector_matches : cible les liens correspondant à un ou plusieurs sélecteurs CSS Le CSS (Cascading Style Sheets) est un langage utilisé pour décrire l'apparence et la mise en page des documents HTML, en définissant des styles comme les couleurs, polices, marges, et positionnements des éléments sur une page web. .

Auquel on ajoute des opérateurs classiques "and", "or" et "not".

Vous pouvez bien sûr définir plusieurs règles au sein d’un même JSON.

Voici 2 cas d’usages à adapter selon vos besoins.

Speculation Rules : le Cas simple

Premier cas d’implémentation, pour reprendre le concept d’instant.page décrit plus haut, il vous suffira d’instancier ce bout de code.

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

Cas avancé : prérendu systématique avec des exceptions

Avec un prérendu, toutes les pages ne devraient pas être prérendues, mais vous pouvez spécifier des exceptions.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } },
            { "not": { "selector_matches": ".no-prerender" } }
          ]
        },
      "eagerness": "moderate"
    }
  ]
}
</script>

En résumé, cette règle demande au navigateur de pré-rendre toutes les pages du site, à l’exception de la page de déconnexion et des liens marqués avec la classe "no-prerender", et ce avec une priorité modérée. Cela permet d’améliorer la rapidité de navigation pour la plupart des pages, tout en évitant les effets secondaires indésirables.

Un plugin, puis une intégration dans le core de WordPress

Il existe déjà un plugin pour WordPress WordPress est un système de gestion de contenu (CMS) open-source qui permet de créer et gérer facilement des sites web, des blogs et des boutiques en ligne sans compétences en programmation. : Speculative Loading conçu par la WordPress Performance Team.

C’est donc tout naturellement que cette fonctionnalité sera intégrée prochainement au core de WordPress, dès la sortie de la version 6.8 du CMS. Encore une idée merveilleuse de l’équipe WordPress qui n’a que des bonnes idées depuis l’intégration de Gutenberg ! Sentez le ton ironique de cette dernière phrase, parce qu’il y a quand même quelques…

Considérations Techniques

Support navigateurs des Speculation Rules

Pour l’instant, seuls les navigateurs basés sur Chrome ont franchi le cap. Cela représente tout de même plus de 70% des parts du marché mondial.

Là encore, il s’agit de faire valoir l’amélioration progressive, puisque l’utilisation des Speculation Rules sera tout bonnement ignorée par les autres navigateurs sans que cela perturbe leur comportement.

Limitations des Speculation Rules

Chrome a mis en place des limites pour éviter une utilisation excessive de l’ API Une API (Application Programming Interface) est un ensemble de règles permettant à différents logiciels de communiquer entre eux. Elle simplifie l'intégration et l'échange de données entre systèmes. selon la valeur du paramètre eagerness :

• Immediate : Ces spéculations ne dépendent pas des actions de l’utilisateur, ont des limites plus élevées et permettent un ajustement dynamique de la capacité en supprimant les anciennes spéculations.
• Moderate / Conservative : Ces paramètres sont déclenchés par l’utilisateur, suivent une logique FIFO (premier entré, premier sorti) avec une limite de 2 spéculations simultanées, remplaçant les plus anciennes pour économiser la mémoire.

Ce qui nous donne en nombre de pages conservées :

Considérations sur l’utilisation des ressources

Bien que les Speculation Rules offrent des avantages significatifs, il est crucial de prendre en compte les problèmes potentiels suivants :

• Consommation excessive de ressources :
  Précharger ou pré-rendre trop de pages peut consommer une quantité importante de bande passante, de CPU et de mémoire. Cela peut ralentir l’appareil de l’utilisateur, en particulier sur les appareils mobiles ou les connexions lentes, notamment pendant une interaction avec l’utilisateur.
• Charge serveur accrue :
  Le préchargement ou le pré-rendu de nombreuses pages peut augmenter la charge sur le serveur, car le serveur doit répondre à ces requêtes supplémentaires.
• Impact sur les traqueurs analytiques :
  Le pré-rendu peut affecter certaines métriques d’analyse, car les pages sont interprétées avec leurs scripts même si l’utilisateur ne les visite pas réellement. Et ça c’est un vrai problème.

La documentation de MDN est d’ailleurs très prévenante au sujet de l’emploi des Speculation Rules, et précise même qu’il est plus simple d’utiliser prefetch que prerender.

JavaScript à la rescousse du prérendu

Par exemple, pour éviter de lancer des scripts de tracking, il vous faudra détecter le support de l’API et faire un aiguillage en fonction de l’état de la page notamment avec document.prerendering. Pour cela, il faudra bien étudier la question et je vous recommande la prose de Barry Pollard spécifiquement sur le sujet de l’impact du prérendu sur les analytics.

Attention, lorsqu’on attaque les problématiques liées au prérendu et JavaScript, il faut savoir que plusieurs fonctionnalités d’API potentiellement intrusives ne sont pas activées tant que la page n’est réellement affichée. Elles sont différées jusqu’à l’activation de la page. C’est le cas de la géolocalisation, des notifications et bien d’autres.

Mon avis sur les Speculation Rules

La promesse est trop belle et bien trop magique pour que cela ne cache pas une foule de détails à régler ! J’adore le principe. J’ai déjà recommandé instant.page à quelques clients pour en exploiter l’approche. La nouveauté de l’API est surtout celle du prérendu. Et là je mets un warning !

Prérendre une page qui ne sera pas affichée n’est pas quelque chose de viable à ce jour. D’un point de vue écoconception, cela n’est même pas souhaitable. Ce qui limite l’usage du prerender pour être prudent au mode Conservative. Le coté anticipation de l’API devient beaucoup moins sexy. Les modes immediate et moderate pour le prerendu devraient être réservés à des cas extrêmement spécifiques et bien bordés.

A l’inverse, le prefetch est plus sécure. Il faudra rester raisonnable, mais le gain peut être intéressant. La gestion centralisée des règles pourrait permettre avec un peu d’ingéniosité de définir les pages à précharger selon les statistiques d’audience ou mieux selon les préférences utilisateurs.

Là où je suis enthousiaste, c’est l’usage conjoint des Speculation Rules et des View Transitions. D’après mes quelques tests, l’UX devient vraiment plus fluide et avec un ressenti d’immédiateté. Mais cela ne reste applicable qu’avec des performances d’un bon niveau. Pour conclure, mon conseil : testez pour mesurer et faites vos choix.

Et au pire, vous savez qui contacter pour vous accompagner !

Sources : boris.schapira.dev, kinsta.com.
Visuel généré à partir d’une intelligence artificielle.