Améliorations apportées à l'API Speculation Rules

Barry Pollard

L'équipe Chrome a travaillé sur des mises à jour intéressantes de l'API Speculation Rules, qui permet d'améliorer les performances de navigation en préchargeant ou même en prérendant les futures navigations. Ces améliorations supplémentaires sont désormais toutes disponibles à partir de Chrome 122 (certaines fonctionnalités sont disponibles à partir de versions antérieures).

Ces modifications rendent le préchargement et le prérendu des pages beaucoup plus faciles à déployer et moins gaspilleurs, ce qui, nous l'espérons, encouragera leur adoption.

Autres fonctionnalités

Nous allons d'abord vous expliquer les nouvelles fonctionnalités ajoutées à l'API Speculation Rules et comment les utiliser. Nous vous montrerons ensuite une démonstration pour que vous puissiez les voir en action.

Règles concernant les documents

Auparavant, l'API Speculation Rules fonctionnait en spécifiant une liste d'URL à précharger ou à prérendre:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Les règles de spéculation étaient semi-dynamiques, car vous pouviez ajouter de nouveaux scripts de règles de spéculation et supprimer les anciens pour supprimer ces spéculations (notez que la mise à jour de la liste urls d'un script de règles de spéculation existant ne déclenche pas de modification des spéculations). Toutefois, le choix des URL restait toujours à la charge du site, soit en les envoyant depuis le serveur au moment de la requête de page, soit en créant dynamiquement cette liste via JavaScript côté client.

Les règles de liste restent une option pour les cas d'utilisation plus simples (lorsque la navigation suivante provient d'un petit ensemble d'URL évidentes) ou plus avancés (lorsque la liste des URL est calculée dynamiquement en fonction des heuristiques que le propriétaire du site souhaite utiliser, puis insérée dans la page).

Nous proposons également une nouvelle option de recherche automatique de liens à l'aide de règles liées au document. Pour ce faire, les URL sont extraites du document lui-même en fonction d'une condition where. Cela peut être basé sur les liens eux-mêmes:

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/logout/*"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

Les sélecteurs CSS peuvent également être utilisés à la place ou en plus des correspondances href pour trouver des liens sur la page actuelle:

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

Vous pouvez ainsi utiliser un seul ensemble de règles de spéculation pour l'ensemble du site, au lieu d'en avoir des spécifiques par page. Cela permet aux sites de déployer beaucoup plus facilement des règles de spéculation.

Bien sûr, prérendre tous les liens d'une page serait vraiment inutile. C'est pourquoi nous avons introduit un paramètre eagerness avec cette nouvelle fonctionnalité.

Impatience

Avec tout type de spéculation, il existe un compromis entre la précision et le rappel, et le délai. Si vous prérenduvez tous les liens au chargement de la page, vous prérendrez presque certainement un lien sur lequel un utilisateur clique (en supposant qu'il clique sur un lien du même site sur la page), et avec un délai d'attente aussi long que possible, mais avec un gaspillage de bande passante potentiellement énorme.

En revanche, ne prérendre que lorsqu'un utilisateur a cliqué sur un lien évite le gaspillage, mais au prix d'un délai de traitement beaucoup plus court. Cela signifie qu'il est peu probable que le prérendu soit terminé avant que le navigateur ne passe à cette page.

Le paramètre eagerness vous permet de définir quand les spéculations doivent s'exécuter, en 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 list et document. Il comporte quatre paramètres, pour lesquels Chrome dispose des heuristiques suivantes:

• immediate : permet de spéculer le plus tôt possible, c'est-à-dire dès que les règles de spéculation sont observées.
• eager:comportement actuellement identique à celui du paramètre immediate, mais nous allons, à l'avenir, chercher à le placer quelque part entre immediate et moderate.
• moderate:effectue des spéculations si vous pointez sur un lien pendant 200 millisecondes (ou sur l'événement pointerdown si c'est plus tôt) et sur mobile où il n'y a pas d'événement hover.
• conservative:spécule en cas d'événement tactile ou avec pointeur.

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

La valeur eagerness par défaut pour les règles document est conservative. Étant donné qu'un document peut contenir de nombreuses URL, l'utilisation de immediate ou de eager pour les règles document doit être utilisée avec prudence (voir également la section Limites de Chrome ci-dessous).

Le paramètre eagerness à utiliser dépend de votre site. Pour un site statique très simple, une spéculation plus volontaire peut avoir un faible coût et être bénéfique pour les utilisateurs. Les sites dont les architectures sont plus complexes et dont les charges utiles de page sont plus lourdes peuvent préférer réduire le gaspillage en spéculant moins souvent jusqu'à ce que les utilisateurs envoient des signaux plus positifs sur leur intention.

L'option moderate est un compromis. De nombreux sites pourraient bénéficier de la règle de spéculation simple suivante, qui prérendrait tous les liens en cas de survol ou de pointage vers le bas, comme une implémentation de base (mais puissante) des règles de spéculation:

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

Limites de Chrome

Même si vous choisissez eagerness, Chrome met en place des limites pour éviter une utilisation excessive de cette API:

Les paramètres moderate et conservative, qui dépendent de l'interaction de l'utilisateur, fonctionnent de manière FIFO (First In, First Out). Une fois la limite atteinte, une nouvelle spéculation entraîne l'annulation de la spéculation la plus ancienne et son remplacement par la plus récente pour économiser de la mémoire.

Le fait que les spéculations moderate et conservative soient déclenchées par les utilisateurs nous permet d'utiliser un seuil plus modeste de 2 pour économiser de la mémoire. Les paramètres immediate et eager ne sont pas déclenchés par une action de l'utilisateur. Ils ont donc une limite plus élevée, car le navigateur ne peut pas savoir lesquels sont nécessaires et quand.

Une spéculation annulée en étant retirée de la file d'attente FIFO peut être déclenchée à nouveau (par exemple, en pointant de nouveau sur ce lien), ce qui entraînera une nouvelle spéculation sur cette URL. Dans ce cas, la spéculation précédente a probablement entraîné la mise en cache de certaines ressources dans le cache HTTP pour cette URL. La répétition de la spéculation devrait donc avoir un impact beaucoup plus faible sur le réseau et donc sur les coûts en temps.

Les limites immediate et eager sont également dynamiques. Supprimer un élément de script de règles de spéculation à l'aide de ces niveaux d'impatience crée de la capacité en annulant les spéculations supprimées. Ces URL peuvent également être re-spéculées si elles sont incluses dans un nouveau script d'URL et que la limite n'a pas été atteinte.

Chrome empêche également l'utilisation de spéculations dans certaines conditions, y compris les suivantes:

• Économiseur de données.
• Économiseur d'énergie
• Contraintes de mémoire
• Lorsque le paramètre "Précharger les pages" est désactivé (ce qui est également explicitement désactivé par les extensions Chrome telles que uBlock Origin).
• Pages ouvertes dans des onglets en arrière-plan.

Toutes ces conditions visent à réduire l'impact de la sur-spéculation lorsqu'elle est préjudiciable aux utilisateurs.

source facultatif

Chrome 122 rend la touche source facultative, car elle peut être déduite de la présence des touches url ou where. Ces deux règles de spéculation sont donc identiques:

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

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

En-tête HTTP Speculation-Rules

Les règles de spéculation peuvent également être transmises à l'aide d'un en-tête HTTP Speculation-Rules, plutôt que d'être incluses directement dans le code HTML du document. Cela permet aux CDN de déployer plus facilement les documents sans avoir à modifier leur contenu.

L'en-tête HTTP Speculation-Rules est renvoyé avec le document et pointe vers l'emplacement d'un fichier JSON contenant les règles de spéculation:

Speculation-Rules: "/speculationrules.json"

Cette ressource doit utiliser le bon type MIME et, s'il s'agit d'une ressource multi-origine, passer une vérification CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Si vous souhaitez utiliser des URL relatives, vous pouvez inclure la clé "relative_to": "document" dans vos règles de spéculation. Sinon, les URL relatives seront relatives à l'URL du fichier JSON des règles de spéculation. Cela peut être particulièrement utile si vous devez sélectionner certains (ou tous) liens de même origine.

Meilleure réutilisation du cache

Nous avons apporté un certain nombre d'améliorations au stockage en cache dans Chrome afin que le préchargement (ou même le prérendu) d'un document stocke et réutilise les ressources dans le cache HTTP. Cela signifie que la spéculation peut toujours avoir des avantages futurs, même si elle n'est pas utilisée.

Cela rend également la re-spéculation (par exemple, pour les règles de document avec un paramètre d'impatience moderate) considérablement moins coûteuse, car Chrome utilisera le cache HTTP pour les ressources en cache.

Nous soutenons également la nouvelle proposition No-Vary-Search pour améliorer encore la réutilisation du cache.

Assistance No-Vary-Search

Lors du préchargement ou du prérendu d'une page, certains paramètres d'URL (appelés techniquement paramètres de recherche) peuvent être sans importance pour la page réellement fournie par le serveur et ne servir qu'au code JavaScript côté client.

Par exemple, Google Analytics utilise les paramètres UTM pour mesurer les campagnes, mais ils ne génèrent généralement pas de pages différentes sur le serveur. Cela signifie que page1.html?utm_content=123 et page1.html?utm_content=456 diffusent la même page à partir du serveur. La même page peut donc être réutilisée à partir du cache.

De même, les applications peuvent utiliser d'autres paramètres d'URL qui ne sont gérés que côté client.

La proposition No-Vary-Search permet à un serveur de spécifier des paramètres qui ne modifient pas la ressource fournie, et donc de permettre à un navigateur de réutiliser des versions précédemment mises en cache d'un document qui ne diffèrent que par ces paramètres. Remarque: Pour le moment, cette fonctionnalité n'est compatible qu'avec Chrome (et les navigateurs basés sur Chromium) pour les spéculations de navigation préchargement.

Les règles de spéculation permettent d'utiliser expects_no_vary_search pour indiquer où un en-tête HTTP No-Vary-Search doit être renvoyé. Cela peut vous aider à éviter les téléchargements inutiles.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

Dans cet exemple, le code HTML de la page initiale /products est identique pour les ID de produit 123 et 124. Toutefois, le contenu de la page finit par différer en fonction du rendu côté client à l'aide de JavaScript pour extraire les données produit à l'aide du paramètre de recherche id. Nous préchargeons donc cette URL de manière anticipée. Elle doit renvoyer un en-tête HTTP No-Vary-Search indiquant que la page peut être utilisée pour n'importe quel paramètre de recherche id.

Toutefois, si l'utilisateur clique sur l'un des liens avant la fin du préchargement, il est possible que le navigateur n'ait pas reçu la page /products. Dans ce cas, le navigateur ne sait pas s'il contiendra l'en-tête HTTP No-Vary-Search. Le navigateur a alors le choix entre récupérer à nouveau le lien ou attendre la fin du préchargement pour voir s'il contient un en-tête HTTP No-Vary-Search. Le paramètre expects_no_vary_search permet au navigateur de savoir que la réponse de la page doit contenir un en-tête HTTP No-Vary-Search et d'attendre la fin de cette précharge.

Démo

Nous avons créé une démonstration sur https://speculative-rules.glitch.me/common-fruits.html qui vous permet de voir les règles de document avec un paramètre d'impatience moderate en action:

Ouvrez les outils pour les développeurs, puis cliquez sur le panneau Application. Dans la section Services en arrière-plan, cliquez sur Charges spéculatives, puis sur le volet Spéculations, puis triez par colonne État.

Lorsque vous pointez sur les fruits, le prérendu des pages s'affiche. Si vous cliquez dessus, le temps de LCP sera beaucoup plus court que celui de l'une des recettes, qui n'est pas prérendu. Cette démonstration est également expliquée dans la vidéo suivante:

Vous pouvez également consulter l'article de blog sur le débogage des règles de spéculation précédent pour en savoir plus sur l'utilisation de DevTools pour déboguer les règles de spéculation.

Compatibilité des plates-formes avec les règles de spéculation

Bien que les règles de spéculation soient relativement simples à implémenter en les injectant dans un élément <script type="speculationrules">, la prise en charge de la plate-forme peut les implémenter en un clic. Nous avons collaboré avec diverses plates-formes et partenaires pour faciliter le déploiement des règles de spéculation.

Nous mettons également tout en œuvre pour standardiser l'API via le Web Incubator Community Group (WICG) afin de permettre à d'autres navigateurs d'implémenter également cette API intéressante, s'ils le souhaitent.

WordPress

L'équipe WordPress Core Performances (y compris des développeurs de Google) a créé un plug-in Speculation Rules. Ce plug-in permet d'ajouter facilement, en un clic, la prise en charge des règles de document à n'importe quel site WordPress. Vous pouvez également installer ce plug-in via le plug-in WordPress Performance Lab, que nous vous recommandons également d'installer, car il vous permettra de vous tenir informé des plug-ins de performances associés de l'équipe.

Deux groupes de paramètres sont disponibles: le paramètre Mode de spéculation et le paramètre Eagerness (Impétuosité) :

Pour des configurations plus complexes (par exemple, pour exclure certaines URL du préchargement ou du prérendu), consultez la documentation.

Akamai

Akamai est l'un des principaux fournisseurs de CDN au monde. Il teste activement l'API Speculation Rules depuis un certain temps. Akamai a publié une documentation expliquant comment les clients peuvent activer cette API dans leurs paramètres de CDN. Il a également partagé les résultats impressionnants possibles avec cette nouvelle API.

NitroPack

NitroPack est une solution d'optimisation des performances qui utilise son IA de navigation personnalisée pour prédire les pages à ajouter aux règles de spéculation. L'objectif est de fournir un délai plus long que celui obtenu en pointant sur un lien, mais sans gaspiller de spéculations inutiles sur tous les liens observés. Pour en savoir plus, consultez la documentation de l'API Nitropack Speculation Rules. Cette solution innovante montre que les anciennes règles de liste ont encore beaucoup à offrir lorsqu'elles sont associées à des insights spécifiques au site.

L'équipe Chrome a également travaillé avec NitroPack sur un webinaire sur l'API Speculation Rules pour les personnes qui souhaitent en savoir plus. Il inclut une bonne discussion sur les considérations à prendre en compte entre la spéculation précoce et fréquente, et la spéculation tardive et moins fréquente.

Astro

Astro a ajouté le préchargement des pages à l'aide de l'API Speculation Rules dans la version 4.2 à titre expérimental, ce qui permet aux développeurs qui utilisent Astro d'activer facilement cette fonctionnalité, tout en revenant à un préchargement standard pour les navigateurs qui ne sont pas compatibles avec l'API Speculation Rules. Pour en savoir plus, consultez la documentation sur le prérendu client.

Conclusion

Ces ajouts à l'API Speculation Rules permettent d'utiliser cette nouvelle fonctionnalité de performances pour les sites de manière beaucoup plus simple, avec moins de risques de gaspiller des ressources avec des spéculations inutilisées. Nous sommes ravis de voir que les plates-formes s'appuient déjà sur cette API. Nous espérons que cette API sera davantage adoptée en 2024, ce qui permettra d'améliorer les performances des utilisateurs finaux.

En plus des gains de performances qu'offre l'API Speculation Rules, nous sommes également impatients de voir quelles nouvelles opportunités elle ouvre. View Transitions est une nouvelle API qui permet aux développeurs de spécifier plus facilement les transitions entre les navigations. Cette fonctionnalité est actuellement disponible pour les applications monopages (SPA), mais la version multipages est en cours de développement (et disponible derrière un indicateur dans Chrome). Le préchargement est un complément naturel de cette fonctionnalité pour s'assurer qu'il n'y a pas de retard, ce qui empêcherait l'amélioration de l'expérience utilisateur que la transition est censée apporter. Nous avons déjà vu des sites tester cette combinaison.

Nous espérons que l'API Speculation Rules sera davantage adoptée en 2024. Nous vous tiendrons informé de toute nouvelle amélioration apportée à l'API.

Remerciements

Miniature par Robbie Down sur Unsplash