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

Barry Pollard

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

Grâce à ces modifications, le préchargement et le préchargement des pages sont considérablement plus faciles à déployer et génèrent moins de gaspillage. Nous espérons ainsi encourager leur adoption.

Autres fonctionnalités

Tout d'abord, nous allons vous présenter les nouveautés que nous avons ajoutées à l'API Speculation Rules et apprendre à les utiliser. Ensuite, nous vous proposerons une démonstration afin que vous puissiez les voir en action.

Règles du document

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

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

Les règles de spéculation étaient semi-dynamiques dans la mesure où de nouveaux scripts de règles de spéculation pouvaient être ajoutés et les anciens scripts supprimés pour les supprimer (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). Cependant, le choix des URL restait toujours en place sur le site, soit en les envoyant depuis le serveur au moment de la demande de page, soit en créant cette liste de manière dynamique à l'aide d'un code JavaScript côté client.

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

À la place, nous sommes heureux de proposer une nouvelle option de recherche automatique de liens à l'aide de règles relatives aux documents. Pour ce faire, les URL proviennent du document lui-même selon 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>

Vous pouvez également utiliser les sélecteurs CSS en tant qu'alternative ou en conjonction avec les 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>

Cela permet d'utiliser un seul ensemble de règles de spéculation pour l'ensemble du site, au lieu d'avoir des règles spécifiques par page, ce qui facilite grandement le déploiement des règles de spéculation pour les sites.

Bien entendu, précharger tous les liens d'une page serait un gaspillage. C'est pourquoi nous avons ajouté un paramètre eagerness grâce à cette nouvelle fonctionnalité.

L'impatience

Quel que soit le type de spéculation, il existe un compromis entre la précision et le rappel, et le délai de livraison. Le préaffichage de tous les liens lors du chargement de la page implique très certainement de précharger un lien sur lequel l'utilisateur clique (en supposant qu'il clique sur un lien du même site de la page). Cela s'effectue le plus rapidement possible, mais avec un gaspillage potentiellement énorme de la bande passante.

D'autre part, le prérendu n'est effectué qu'une fois qu'un utilisateur a cliqué sur un lien, ce qui permet d'éviter les gaspillages, mais cela se traduit par un délai de livraison beaucoup plus court. Il est donc peu probable que le prérendu s'effectue avant que le navigateur n'accède à la page en question.

Le paramètre eagerness vous permet de définir le moment où les spéculations doivent s'exécuter, en séparant quand les spéculations à partir desquelles effectuer ces spéculations. Le paramètre eagerness est disponible à la fois pour les règles sources list et document, et comporte quatre paramètres, pour lesquels Chrome utilise les heuristiques suivantes:

• immediate:cette méthode permet d'effectuer des spéculations dès que possible, c'est-à-dire dès que les règles de spéculation sont observées.
• eager:ce comportement se comporte de la même manière que le paramètre immediate, mais à l'avenir, nous prévoyons de le placer entre immediate et moderate.
• moderate:cette méthode effectue des spéculations si vous pointez sur un lien pendant 200 millisecondes (ou sur l'événement pointerdown s'il est plus tôt et sur les appareils mobiles où il n'y a pas d'événement hover).
• conservative:spécule sur le pointeur ou sur l'écran.

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 comporter de nombreuses URL, vous devez utiliser immediate ou eager pour les règles document avec prudence (consultez également la section Limites de Chrome ci-après).

Le paramètre eagerness à utiliser dépend de votre site. Pour un site statique très simple, effectuer des spéculations plus hâtives peut avoir un coût faible et être bénéfique pour les utilisateurs. Les sites avec des architectures plus complexes et des charges utiles de page plus lourdes peuvent préférer réduire le gaspillage en spéculant moins souvent jusqu'à ce que vous obteniez un signal plus positif de la part des utilisateurs pour limiter le gaspillage.

L'option moderate est une option intermédiaire, et de nombreux sites pourraient bénéficier de la règle de spéculation simple suivante, qui prérendurait tous les liens lors du survol ou du pointeur en tant qu'implémentation de base, mais efficace, 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 a mis en place des limites pour éviter une utilisation abusive de cette API:

Les paramètres moderate et conservative, qui dépendent de l'interaction de l'utilisateur, fonctionnent comme un premier entré, premier sorti (FIFO). Une fois la limite atteinte, une nouvelle spéculation entraînera l'annulation de la spéculation la plus ancienne et son remplacement par la plus récente afin de préserver 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 quelles actions sont nécessaires ni quand.

Une spéculation qui est 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îne la respéculation de cette URL. Dans ce cas, la spéculation précédente aurait probablement amené le navigateur à mettre en cache certaines ressources dans le cache HTTP pour cette URL. Par conséquent, la répétition de la spéculation devrait permettre une bien moindre réduction du réseau et donc des coûts de temps.

Les limites immediate et eager sont également dynamiques. La suppression d'un élément de script des règles de spéculation à l'aide de ces niveaux de disponibilité créera de la capacité en annulant ces spéculations supprimées. Ces URL peuvent également être spécifiées de nouveau si elles sont incluses dans un nouveau script d'URL et que la limite n'a pas été atteinte.

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

• Save Data (Enregistrer les données).
• Économiseur d'énergie.
• Contraintes de mémoire.
• Lorsque l'option "Précharger les pages" (qui est aussi 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 d'une spéculation excessive lorsqu'elle pourrait nuire aux utilisateurs.

source facultatif

Chrome 122 rend la clé source facultative, car elle peut être déduite de la présence des clés 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, au lieu de les inclure directement dans le code HTML du document. Cela facilite le déploiement par les CDN sans avoir à modifier le contenu des documents eux-mêmes.

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 type MIME approprié et, s'il s'agit d'une ressource multi-origine, faire l'objet d'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 les liens de même origine.

Meilleure réutilisation du cache

Nous avons apporté un certain nombre d'améliorations à la mise en cache dans Chrome, de sorte que le préchargement (voire le prérendu) d'un document permet de stocker et de réutiliser des ressources dans le cache HTTP. Cela signifie que les spéculations peuvent toujours présenter des avantages futurs, même si elles ne sont pas utilisées.

Cela réduit également considérablement les spéculations (par exemple, pour les règles de document avec un paramètre d'aptitude moderate), car Chrome utilisera le cache HTTP pour les ressources pouvant être mises en cache.

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

Assistance No-Vary-Search

Lors du préchargement ou du préchargement d'une page, certains paramètres d'URL (techniquement appelés paramètres de recherche) peuvent ne pas avoir d'importance pour la page réellement diffusée par le serveur et ne sont utilisés que par le code JavaScript côté client.

Par exemple, les paramètres UTM sont utilisés par Google Analytics pour mesurer les campagnes, mais ils n'entraînent généralement pas la diffusion d'une page différente à partir du serveur. Cela signifie que page1.html?utm_content=123 et page1.html?utm_content=456 diffuseront la même page à partir du serveur, et pourront donc être réutilisées à 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 n'entraînant aucune différence par rapport à la ressource diffusée. Ainsi, un navigateur peut réutiliser les versions mises en cache précédemment d'un document qui ne diffèrent que par ces paramètres. Remarque: Actuellement, cette fonctionnalité n'est compatible qu'avec Chrome (et les navigateurs basés sur Chromium) pour les spéculations de navigation en préchargement.

Les règles de spéculation acceptent l'utilisation de expects_no_vary_search pour indiquer où un en-tête HTTP No-Vary-Search doit être renvoyé. Cela permet d'éviter des 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 le même pour les ID produit 123 et 124. Cependant, le contenu de la page finit par varier en fonction de l'affichage côté client, qui utilise JavaScript pour extraire les données produit à l'aide du paramètre de recherche id. Nous préchargeons donc hâtivement cette URL. Elle devrait 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 peut ensuite récupérer 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 du préchargement.

Démo

Nous avons créé une démo à l'adresse https://speculative-rules.glitch.me/common-fruits.html qui permet de voir en action les règles de document avec un paramètre de caractère sensible moderate:

</ph>

Ouvrez les outils de développement, puis cliquez sur le panneau Application. Ensuite, dans la section Services d'arrière-plan, cliquez sur Chargements spéculatifs, puis sur le volet Spéculations. Triez les résultats en fonction de la colonne État.

Lorsque vous passez la souris sur les fruits, les pages s'affichent en préchargement. En cliquant dessus, le LCP s'affiche beaucoup plus rapidement qu'avec l'une des recettes, qui ne sont pas prérendues. Cette démonstration est également expliquée dans la vidéo suivante:

Vous pouvez également consulter l'article de blog précédent sur les règles de spéculation de débogage pour en savoir plus sur l'utilisation des outils de développement 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 compatibilité avec la plate-forme peut s'appliquer en un clic. Nous collaborons avec plusieurs plates-formes et partenaires pour faciliter l'application des règles de spéculation.

Nous nous efforçons également de standardiser l'API par le biais du Web Incubator Community Group (WICG) afin de permettre aux autres navigateurs d'implémenter cette API intéressante s'ils le souhaitent.

WordPress

L'équipe WordPress Core Performance (comprenant des développeurs Google) a créé un plug-in Speculation Rules. Ce plug-in permet d'ajouter en un clic des règles de document à n'importe quel site WordPress. Vous pouvez également installer ce plug-in via le plug-in WordPress Performance Lab. Nous vous conseillons également d'installer ce plug-in, car il vous permettra de rester informé des plug-ins de performances associés de l'équipe.

Deux groupes de paramètres sont disponibles: le mode spéculation et le paramètre Eagerness:

</ph>

Pour des configurations plus complexes (pour empêcher le préchargement ou le prérendu de certaines URL, par exemple), consultez la documentation.

Akamai

Akamai est l'un des principaux fournisseurs de CDN au monde et expérimente 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 CDN. Par ailleurs, l'équipe a déjà partagé les résultats impressionnants qu'offre cette nouvelle API.

NitroPack

NitroPack est une solution d'optimisation des performances qui utilise son système Navigation AI 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 le fait de pointer sur un lien, sans perdre de temps à spéculer inutilement sur tous les liens observés. Pour en savoir plus, consultez la documentation de l'API Nitropack Speculation Rules. Cette solution innovante montre qu'il y a encore beaucoup à offrir pour les anciennes règles de liste, lorsqu'elles sont associées à des insights spécifiques aux sites.

L'équipe Chrome a également collaboré avec NitroPack sur un webinaire consacré à l'API Speculation Rules pour en savoir plus. Elle a notamment discuté des points à prendre en compte entre les spéculations anticipées et fréquentes, ainsi que les spéculations tardives et moins fréquentes.

Astro

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

Conclusion

Ces ajouts à l'API Speculation Rules permettent une utilisation beaucoup plus simple de cette nouvelle fonctionnalité de performances très intéressante pour les sites, avec moins de risque de gaspiller des ressources avec des spéculations inutilisées. Nous sommes ravis de constater que des plates-formes exploitent déjà cette API. Nous espérons voir plus largement adopter cette API en 2024 et, à terme, améliorer les performances pour les utilisateurs finaux.

En plus des gains de performances offerts par l'API Speculation Rules, nous sommes impatients de découvrir les nouvelles opportunités qui s'offrent à vous. View Transitions (Afficher les transitions) est une nouvelle API qui permet aux développeurs de spécifier plus facilement des transitions entre les navigations. Cette fonctionnalité est actuellement disponible pour les applications monopages (SPA), mais la version multipage est en cours (et disponible derrière un indicateur dans Chrome). Le prérendu est un module complémentaire naturel de cette fonctionnalité qui permet d'éviter tout 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 qui expérimentaient cette combinaison.

Nous avons hâte de poursuivre l'adoption de l'API Speculation Rules tout au long de l'année 2024. Nous vous tiendrons informé des améliorations que nous apporterons à l'API.

Remerciements

Miniature de Robbie Down sur Unsplash