L'équipe Chrome a travaillé sur des mises à jour intéressantes de l'API Speculation Rules pour améliorer les performances de navigation en préchargeant, voire en préchargeant les navigations futures. Ces améliorations supplémentaires sont désormais toutes disponibles à partir de Chrome 122 (avec certaines fonctionnalités dans les versions antérieures).
Ces modifications facilitent considérablement le déploiement des pages et réduit considérablement le gaspillage, ce qui, nous l'espérons, favorisera l'adoption de ces solutions.
Autres fonctionnalités
Tout d'abord, nous allons vous expliquer les nouveautés que nous avons ajoutées à l'API Speculation Rules et vous expliquer comment les utiliser. Ensuite, nous vous montrerons une démonstration pour 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écharger:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Les règles de spéculation étaient semi-dynamiques : de nouveaux scripts de règles de spéculation pouvaient être ajoutés et d'anciens scripts supprimés 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 était toujours à la charge du site, soit en les envoyant depuis le serveur au moment de la demande de page, soit en créant cette liste dynamiquement via JavaScript côté client.
Les règles de liste restent disponibles pour les cas d'utilisation plus simples (où la navigation suivante provient d'un petit ensemble de cas évidents) ou plus avancés (pour lesquels la liste d'URL est calculée dynamiquement en fonction des méthodes heuristiques 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 basée sur les règles de documents. Pour ce faire, les URL sont récupérées depuis le 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>
Vous pouvez également utiliser les sélecteurs CSS à la place de correspondances "href" ou en les combinant 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 sur l'ensemble du site, au lieu d'avoir des règles spécifiques par page. Les sites peuvent ainsi déployer beaucoup plus facilement des règles de spéculation.
Bien entendu, le préaffichage de tous les liens d'une page serait une source de gaspillage. C'est pourquoi nous avons ajouté un paramètre eagerness.
Impatient
Quelle que soit la nature de la spéculation, il faut faire un compromis entre précision et rappel, et délai de livraison. Le prérendu de tous les liens lors du chargement de la page signifie que vous préchargerez presque certainement un lien sur lequel un utilisateur clique (en supposant qu'il clique sur un lien du même site sur la page), avec autant de délai que possible, mais avec une perte de bande passante potentiellement énorme.
En revanche, le prérendu uniquement après qu'un utilisateur a cliqué sur un lien évite le gaspillage, mais au prix d'un délai de livraison beaucoup plus court. Il est donc peu probable que le prérendu soit terminé avant que le navigateur ne bascule sur cette page.
Le paramètre eagerness vous permet de définir quand les spéculations doivent être exécutées, en séparant quand spéculer sur quelles URL effectuer des spéculations. Le paramètre eagerness est disponible pour les règles sources list et document. Il comporte quatre paramètres, pour lesquels Chrome utilise les méthodes heuristiques suivantes:
immediate:permet de spéculer dès que possible, c'est-à-dire dès que les règles de spéculation sont observées.eager:le comportement actuel est identique au paramètreimmediate, mais nous prévoyons de le placer à l'avenir entreimmediateetmoderate.moderate:des spéculations sont effectuées lorsque vous pointez sur un lien pendant 200 millisecondes (ou sur l'événementpointerdowns'il est antérieur, et sur un appareil mobile où il n'y a pas d'événementhover).conservative:spécule sur le pointeur ou l'atterrissage.
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 avec 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, il convient d'utiliser immediate ou eager pour les règles document avec précaution (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 hâtive peut avoir peu de coût et être bénéfique pour les utilisateurs. Les sites dotés d'architectures plus complexes et de 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 d'intention plus positif de la part des utilisateurs afin de limiter le gaspillage.
L'option moderate est un terrain d'entente. De nombreux sites pourraient bénéficier de la règle de spéculation simple suivante, qui prérendu tous les liens lorsque l'utilisateur pointe ou pointe sur l'écran en tant qu'implémentation basique, mais efficace, de règles de spéculation:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Limites de Chrome
Même si l'option eagerness est sélectionnée, Chrome a mis en place des limites pour éviter toute utilisation excessive de cette API:
eagerness |
Préchargement | Prérendu |
|---|---|---|
immediate/eager |
50 | 10 |
moderate/conservative |
2 (FIFO) | 2 (FIFO) |
Les paramètres moderate et conservative, qui dépendent de l'interaction de l'utilisateur, fonctionnent selon le principe du premier entré, premier sorti (FIFO). 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 nouvelle 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 à quel moment.
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 le lien), ce qui entraîne une nouvelle spéculation sur l'URL. Dans ce cas, la spéculation précédente aura probablement entraîné la mise en cache par le navigateur de certaines ressources dans le cache HTTP pour cette URL. Par conséquent, la répétition de la spéculation devrait entraîner une réduction significative 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 de règles de spéculation à l'aide de ces niveaux de persévérance créera de la capacité en annulant ces spéculations supprimées. Ces URL peuvent également faire l'objet d'une nouvelle spéculation 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:
- Save-Data (Enregistrer les données) :
- Économiseur d'énergie.
- Contraintes de mémoire.
- Lorsque le paramètre "Précharger les pages" est désactivé (il 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 serait préjudiciable aux utilisateurs.
Facultatif source
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 qu'il soit nécessaire de 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, réussir 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. Dans le cas contraire, 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 tous vos liens de même origine ou seulement certains d'entre eux.
Réutilisation améliorée du cache
Nous avons apporté un certain nombre d'améliorations à la mise en cache dans Chrome afin que la préchargement (ou même le prérendu) d'un document permette de stocker et de réutiliser des ressources dans le cache HTTP. Cela signifie que la spéculation peut tout de même présenter des avantages futurs, même si cette spéculation n'est pas utilisée.
Cela rend également la réspéculation (par exemple, pour les règles de document avec un paramètre de persévérance moderate) considérablement moins coûteuse, car Chrome utilise le cache HTTP pour les ressources pouvant être mises en cache.
Nous soutenons également la nouvelle proposition No-Vary-Search pour améliorer 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 être sans importance pour la page effectivement diffusée par le serveur. En outre, ils 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 de différentes pages depuis le serveur. Cela signifie que page1.html?utm_content=123 et page1.html?utm_content=456 vont diffuser la même page à partir du serveur, de sorte que la même page pourra ê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 n'entraînent pas de différence avec la ressource fournie, et permet donc à 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: 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 prennent en charge l'utilisation de expects_no_vary_search pour indiquer où un en-tête HTTP No-Vary-Search doit être renvoyé. Vous éviterez ainsi davantage de 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 de /products est identique pour les ID produit 123 et 124. Toutefois, le contenu de la page diffère finalement en fonction de l'affichage côté client, qui utilise JavaScript pour récupérer les données produit à l'aide du paramètre de recherche id. Nous préchargeons donc hâtivement cette URL, et 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 choisir de récupérer à nouveau le lien ou d'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émonstration
Nous avons créé une version de démonstration à l'adresse https://speculative-rules.glitch.me/common-fruits.html qui permet d'afficher les règles de document avec un paramètre de complexité moderate en action:
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, et triez les données en fonction de la colonne État.
Lorsque vous pointez sur les fruits, les pages se préaffichent. Cliquez dessus pour afficher un LCP beaucoup plus court 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 le précédent article de blog sur le débogage des règles de spéculation pour en savoir plus sur l'utilisation des outils de développement pour déboguer les règles de spéculation.
Plates-formes compatibles avec les règles de spéculation
Bien que les règles de spéculation soient relativement simples à implémenter en injectant les règles dans un élément <script type="speculationrules">, la compatibilité avec la plate-forme permet de résoudre ce problème en un clic. Nous travaillons avec plusieurs plates-formes et partenaires pour faciliter le déploiement des règles de spéculation.
Nous nous efforçons également de normaliser l'API par le biais du Web Incubator Community Group (WICG) afin que d'autres navigateurs puissent implémenter cette API intéressante s'ils le souhaitent.
WordPress
L'équipe WordPress Core Performance (y compris les développeurs de Google) a créé un plug-in Speculation Rules (Règles de spéculation). Ce plug-in permet d'ajouter en un clic la prise en charge des règles de document à n'importe quel site WordPress. Ce plug-in peut également être installé via le plug-in WordPress Performance Lab, que nous vous conseillons également d'installer, car il vous permettra de vous tenir au courant des plug-ins de performance pertinents proposés par l'équipe.
Deux groupes de paramètres sont disponibles, le mode de spéculation et le paramètre Eager :
Pour les 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, et il teste activement l'API Speculation Rules depuis un certain temps déjà. Akamai a publié une documentation expliquant comment les clients peuvent activer cette API dans leurs paramètres CDN. L'entreprise a également partagé avec lui les résultats impressionnants que cette nouvelle API permet de réaliser.
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. Elle vise à fournir un délai plus long que lorsque l'utilisateur pointe sur un lien, mais sans avoir à 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 que les anciennes règles de liste peuvent encore être largement disponibles 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 les personnes qui cherchaient un complément d'information, y compris une discussion autour des points à prendre en compte pour spéculer entre la spéculation tôt et souvent, mais aussi tard et moins fréquemment.
Astro
Astro a ajouté le prérendu des pages à l'aide de l'API Speculation Rules dans la version 4.2 à titre expérimental, ce qui permet aux développeurs qui l'utilisent 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 client sur le prérendu.
Conclusion
Ces ajouts à l'API Speculation Rules permettent d'utiliser beaucoup plus facilement cette nouvelle fonctionnalité très intéressante de performances pour les sites, tout en réduisant le risque de gaspiller des ressources avec des spéculations inutilisées. Il est très intéressant de constater que les plates-formes utilisent déjà cette API. Nous espérons voir plus largement cette API en 2024, et ainsi améliorer les performances pour les utilisateurs finaux.
En plus des gains de performances offerts par l'API Speculation Rules, nous nous réjouissons également de découvrir les nouvelles opportunités que cela offre. View 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 de développement (et disponible derrière un indicateur dans Chrome). Le prérendu est un module complémentaire naturel à cette fonctionnalité pour garantir l'absence de délai, 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 en train de tester cette combinaison.
Nous avons hâte d'adopter l'API Speculation Rules au cours de l'année 2024 et nous vous tiendrons informé de toute autre amélioration que nous y apporterons.
Remerciements
Miniature de Robbie Down sur Unsplash