Publié le 7 mars 2025
L'API Speculation Rules permet aux utilisateurs de bénéficier d'une amélioration des performances en préchargeant ou en prérendant les futures navigations sur les pages afin de les rendre plus rapides, voire instantanées.
L'API a été conçue spécifiquement pour faciliter l'implémentation, mais les sites complexes doivent prendre en compte certains points avant de l'utiliser. Ce guide aide les propriétaires de sites à comprendre ces considérations.
Planification
Avant d'implémenter des règles de spéculation, il est utile de réfléchir à la manière d'implémenter l'API (car il existe plusieurs options) et aux coûts des spéculations (qui devraient vous guider sur les pages à spéculer).
Décider comment implémenter les règles de spéculation
L'une des premières décisions que vous devez prendre consiste à déterminer comment implémenter des règles de spéculation sur votre site. Vous pouvez utiliser différentes méthodes:
- directement dans le code HTML de la page ;
- Utiliser JavaScript
- Utiliser un en-tête HTTP
En fin de compte, chaque méthode a le même effet, mais elle peut présenter des avantages en termes de facilité d'implémentation et de flexibilité.
Les sites doivent choisir l'option qui leur convient le mieux et peuvent même combiner plusieurs options si nécessaire. Ils peuvent également être implémentés à l'aide d'un plug-in (comme le plug-in de chargement spéculatif pour WordPress) ou de bibliothèques ou de plates-formes qui peuvent faire le choix à votre place, mais il est toujours utile de connaître les options disponibles.
Inclure des règles de spéculation directement dans le code HTML de la page
Les règles de spéculation peuvent être implémentées directement sur la page en incluant l'élément <script type="speculationrules"> dans le code HTML. Vous pouvez l'ajouter au moment de la compilation pour les sites statiques à l'aide de modèles, ou au moment de l'exécution par le serveur lorsque la page est demandée. Ils peuvent même être injectés dans le code HTML par les nœuds de calcul Edge (bien que la méthode d'en-tête HTTP abordée plus loin dans ce guide soit probablement plus simple).
Vous pouvez ainsi inclure des règles statiques sur l'ensemble du site, mais les règles de document peuvent toujours être dynamiques. Elles vous permettent de choisir les URL à afficher à partir de la page à l'aide de règles à déclencher par des classes CSS:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Le script précédent prérend les liens avec une classe prerender et précharge de la même manière lorsqu'un lien possède une classe prefetch. Cela permet aux développeurs d'inclure ces classes dans le code HTML pour déclencher des spéculations.
En plus d'inclure les liens de ces classes dans le code HTML initial d'une page, les liens seront également spéculés si ces classes sont ajoutées de manière dynamique par votre application, ce qui lui permet de déclencher (et de supprimer) des spéculations si nécessaire. Cela peut être plus simple que de créer ou de supprimer des règles de spéculation plus spécifiques. Vous pouvez également inclure plusieurs cas de spéculation par page si vous souhaitez une règle de base utilisée par la plupart du site et une ou plusieurs règles spécifiques à la page.
Si vous devez utiliser des règles de spéculation plus spécifiques, vous pouvez définir des règles spécifiques aux pages ou aux modèles pour certaines pages ou certains types de pages.
Enfin, les pages générées côté serveur peuvent également avoir des règles plus dynamiques en fonction des informations disponibles pour le serveur, telles que les informations analytiques pour cette page ou les parcours utilisateur courants pour certaines pages.
Ajouter des règles de spéculation à l'aide de JavaScript
Vous pouvez également injecter les règles à l'aide de JavaScript au lieu de les inclure dans un script sur la page. Cela peut nécessiter moins de mises à jour des modèles de pages. Par exemple, l'injection des règles par un gestionnaire de balises peut être un moyen rapide de déployer des règles de spéculation (et de les désactiver rapidement si nécessaire).
Cette option permet également d'utiliser des règles dynamiques côté client en fonction de la manière dont l'utilisateur interagit avec la page. Par exemple, si l'utilisateur ajoute un article au panier, vous pouvez prérendre la page de paiement. Vous pouvez également l'utiliser pour déclencher des spéculations en fonction de certaines conditions. Bien que l'API inclue un paramètre d'impatience qui permet d'appliquer des règles de base basées sur les interactions, JavaScript permet aux développeurs d'utiliser leur propre logique pour décider quand et sur quelle ou quelles pages spéculer.
Comme indiqué précédemment, une autre approche consiste à insérer une règle de document de base sur la page et à laisser JavaScript déclencher des règles de document en ajoutant des classes appropriées aux liens pour les faire correspondre à la règle.
Ajouter des règles de spéculation à l'aide d'un en-tête HTTP
La dernière option disponible pour les développeurs consiste à inclure les règles à l'aide d'un en-tête HTTP:
Speculation-Rules: "/speculationrules.json"
La ressource de règles (/speculationrules.json dans cet exemple) doit respecter certaines exigences supplémentaires concernant la diffusion et l'utilisation.
Cette option permet un déploiement plus facile par les CDN sans avoir à modifier le contenu des documents. Cela signifie que vous ne pouvez pas modifier les règles de spéculation de manière dynamique à l'aide de JavaScript. Toutefois, les règles de document avec des déclencheurs de sélecteur CSS peuvent toujours autoriser des modifications dynamiques, par exemple en supprimant la classe prerender d'un lien.
Comme pour l'option JavaScript, l'implémentation de règles de spéculation avec un en-tête HTTP permet de les implémenter indépendamment du contenu du site, ce qui peut faciliter l'ajout et la suppression des règles sans avoir à reconstruire entièrement le site.
Tenez compte des implications en termes de coûts
Avant d'implémenter des règles de spéculation, prenez le temps d'examiner les conséquences sur les coûts pour vos utilisateurs et votre site avec cette API. Les coûts incluent la bande passante (qui coûte de l'argent aux utilisateurs et aux sites) et les coûts de traitement (à la fois côté client et côté serveur).
Tenir compte du coût pour les utilisateurs
Le chargement spéculatif consiste à faire une supposition éclairée sur l'endroit où un utilisateur peut accéder. Toutefois, si cette navigation n'a pas lieu, vous risquez de gaspiller des ressources. C'est pourquoi vous devez être conscient de l'impact sur les utilisateurs, en particulier:
- Bande passante supplémentaire utilisée pour télécharger ces futures navigations, en particulier sur mobile, où la bande passante peut être plus limitée.
- Frais de traitement supplémentaires pour afficher ces pages lorsque vous utilisez le prérendu.
Avec des prédictions totalement précises, il n'y a pas de coûts supplémentaires, car les visiteurs visiteront ces pages ensuite. La seule différence est que ces coûts sont répartis sur la période. Toutefois, il est impossible de prédire l'avenir avec une précision parfaite. Plus la stratégie de spéculation est agressive, plus le risque de gaspillage est élevé.
Chrome a soigneusement examiné ce problème. L'API inclut un certain nombre de fonctionnalités qui font que le coût est beaucoup moins élevé que vous ne le pensez. En particulier, en réutilisant le cache HTTP et en ne chargeant pas d'iframes multi-origines, le coût du prérendu d'une navigation sur le même site est souvent considérablement inférieur à celui d'une page complète sans ressources mises en cache, ce qui rend les chargements spéculatifs moins coûteux qu'on pourrait le penser.
Toutefois, même avec ces mesures de protection, les sites doivent examiner attentivement les pages à spéculer et le coût pour l'utilisateur de ces spéculations. Les éléments qui peuvent être raisonnablement prédits avec un degré de confiance élevé (peut-être en fonction des données analytiques ou des parcours utilisateur courants) et lorsque le coût est faible (par exemple, des pages moins riches) sont de bons candidats pour le chargement spéculatif.
Vous pouvez également réfléchir à ce que JavaScript doit retarder jusqu'à l'activation. Comme pour le préchargement de contenu jusqu'à ce qu'il soit nécessaire, cela peut rendre les prérendus moins coûteux, mais offrir une expérience utilisateur bien meilleure. Avec des spéculations moins chères, vous pouvez spéculer plus fréquemment ou avec plus d'enthousiasme.
Si ce n'est pas possible, nous vous recommandons d'utiliser une stratégie moins agressive avec des règles d'impatience modérées ou conservatrices. Vous pouvez également utiliser le préchargement, qui est beaucoup moins coûteux que le prérendu lorsque le niveau de confiance est faible, puis passer à un prérendu complet si le niveau de confiance augmente (par exemple, lorsque l'utilisateur pointe sur un lien ou clique dessus).
Prendre en compte la charge supplémentaire du backend
En plus de tenir compte des coûts supplémentaires pour l'utilisateur, les propriétaires de sites doivent également tenir compte de leurs propres coûts d'infrastructure. Si chaque page génère deux, trois ou même plus de chargements de page, les coûts de backend peuvent augmenter en utilisant cette API.
En vous assurant que vos pages et vos ressources peuvent être mises en cache, vous réduirez considérablement la charge d'origine et donc le risque global. Lorsqu'ils sont associés à un CDN, vos serveurs d'origine devraient subir une charge supplémentaire minimale. Toutefois, tenez compte de toute augmentation des coûts du CDN.
Un serveur ou un CDN peut également être utilisé pour contrôler les résultats de la spéculation, comme indiqué par l'en-tête HTTP sec-purpose. Par exemple, le produit Speed Brain de Cloudflare n'autorise que les spéculations déjà mises en cache sur le serveur de bord d'un CDN et ne renvoie pas de requêtes à l'origine.
Toutefois, comme les chargements spéculatifs sont généralement utilisés pour les chargements de pages de même origine, les utilisateurs disposent déjà de ressources partagées dans le cache de leur navigateur (en supposant qu'elles soient enregistrables en cache). Par conséquent, une spéculation n'est généralement pas aussi coûteuse qu'un chargement de page complet.
Trouver le juste équilibre entre trop de spéculation et pas assez
Pour exploiter pleinement l'API Speculation Rules, vous devez trouver le juste équilibre entre trop de spéculation (c'est-à-dire lorsque les coûts sont payés inutilement et que la spéculation n'est pas utilisée) et trop de prudence (soit trop peu, soit trop tard, ce qui n'apporte que peu d'avantages).
Lorsque les coûts sont faibles (par exemple, pour les petites pages générées de manière statique mises en cache sur les nœuds de périphérie du CDN), vous pouvez vous permettre d'être plus agressif avec les spéculations.
Toutefois, pour les pages plus volumineuses et plus riches qui ne peuvent peut-être pas être mises en cache au niveau du CDN, vous devez faire preuve de plus de prudence. De même, les pages gourmandes en ressources peuvent utiliser la bande passante réseau ou la puissance de traitement, ce qui peut avoir un impact négatif sur la page actuelle. L'objectif de l'API est d'améliorer les performances. Nous ne souhaitons donc pas de régressions des performances. C'est une autre raison de limiter les prérendus à une ou deux pages au maximum (notez également que Chrome limite les prérendus à deux ou dix à la fois, en fonction de l'impatience).
Étapes à suivre pour implémenter les règles de spéculation
Une fois que vous avez décidé de la manière dont vous allez implémenter les règles de spéculation, vous devez planifier ce que vous allez spéculer et comment le déployer. Les sites plus simples, comme les blogs personnels statiques, peuvent passer directement au prérendu complet de certaines pages, mais les sites plus complexes présentent des complexités supplémentaires à prendre en compte.
Commencer par le préchargement
L'implémentation du préchargement est généralement relativement sûre pour la plupart des sites. C'est l'approche initiale adoptée par de nombreuses entreprises, y compris pour les déploiements à grande échelle comme Cloudflare et WordPress.
Les principaux problèmes à prendre en compte sont les suivants : si le préchargement d'une URL entraîne des modifications d'état et des coûts côté serveur, en particulier pour les pages non en cache. Idéalement, les modifications d'état (par exemple, le préchargement d'une page /logout) ne doivent pas être implémentées en tant que liens GET, mais malheureusement, ce n'est pas rare sur le Web.
Vous pouvez exclure spécifiquement ces URL des règles:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Les préchargements peuvent être limités aux navigations courantes d'une page à une autre, ou pour tous les liens de même origine en cas de survol ou de clic à l'aide du paramètre eagerness moderate ou conservative. Le paramètre conservative présente le risque le plus faible, mais aussi la récompense potentielle la plus faible. Si vous commencez à ce niveau, essayez d'atteindre au moins moderate, mais idéalement, passez à eager pour bénéficier de meilleurs résultats (puis passez à prerender si cela est pertinent).
Préchargements à faible risque
Les spéculations de préchargement sont plus faciles à déployer, mais le prérendu offre l'avantage de performances ultime pour l'API. Cela peut nécessiter des considérations supplémentaires lorsque la page n'est pas consultée peu de temps après la spéculation (que nous verrons dans la section suivante). Toutefois, avec un prérendu moderate ou conservative, où la navigation est susceptible de se produire peu de temps après, l'étape suivante peut être relativement peu risquée.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Préchargement des pages courantes pour améliorer les prérendus non impatients
Une tactique courante consiste à précharger un petit nombre de pages suivantes fréquemment consultées lors du chargement avec un paramètre eager (en les spécifiant dans une liste d'URL ou à l'aide de selector_matches), puis à prérendre avec un paramètre moderate. Étant donné que le préchargement HTML est susceptible d'être terminé au moment où l'utilisateur pointe sur le lien, cela améliore le prérendu au survol sans préchargement.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Prérendus précédents
Bien que les règles de document moderate permettent une utilisation relativement peu risquée de l'API avec une facilité d'implémentation associée, ce délai n'est souvent pas suffisant pour un prérendu complet. Pour obtenir la navigation instantanée que cette API permet, vous devrez probablement aller plus loin et prérendre les pages plus rapidement.
Pour ce faire, vous pouvez utiliser une liste statique d'URL (comme dans l'exemple de préchargement précédent) ou selector_matches, qui identifie un petit nombre d'URL (idéalement une ou deux pages), avec des règles de document couvrant les autres URL:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Pour avoir les meilleures chances de prédire avec précision la prochaine navigation, vous devrez peut-être analyser le trafic. Comprendre les parcours client typiques sur votre site peut également vous aider à identifier les éléments à charger de manière spéculative.
Passer à un prérendu plus agressif peut également entraîner davantage de considérations concernant les données analytiques, les annonces et JavaScript, ainsi que la nécessité de mettre à jour une page préremplie, voire d'annuler ou actualiser les spéculations sur les changements d'état.
Analytics, annonces et JavaScript
Lorsque vous utilisez le préchargement, les sites plus complexes doivent également tenir compte de l'impact sur les données analytiques. En règle générale, vous ne souhaitez pas consigner une vue de page (ou d'annonce) lorsque la page est spéculée, mais uniquement lorsque la spéculation est activée.
Certains fournisseurs de données analytiques (comme Google Analytics) et de solutions publicitaires (comme Google Publisher Tag) acceptent déjà les règles de spéculation et n'enregistrent pas les vues tant que la page n'est pas activée. Toutefois, d'autres fournisseurs ou d'autres analyses personnalisées que vous avez implémentées peuvent nécessiter une attention particulière.
Vous pouvez ajouter des vérifications à JavaScript pour empêcher l'exécution de bits de code spécifiques jusqu'à ce que les pages soient activées ou rendues visibles, et même encapsuler des éléments <script> entiers dans de telles vérifications. Lorsque les pages utilisent des gestionnaires de balises pour injecter de tels scripts, il est possible de les traiter tous en même temps en retardant le script du gestionnaire de balises lui-même.
De même, les gestionnaires de consentement permettent de retarder l'exécution des scripts tiers jusqu'à leur activation. Google a travaillé avec différentes plates-formes de gestion du consentement pour les rendre compatibles avec le préchargement. Nous sommes ravis de vous aider si vous souhaitez faire de même. PubTech est l'une de ces entreprises qui permet aux développeurs d'exécuter ou de bloquer son code JavaScript lors du prérendu.
Pour le code de l'application, vous pouvez également ajouter une modification pour retarder l'exécution du code jusqu'à l'activation, en particulier lorsque la page n'a pas besoin du code JavaScript pour s'afficher. Il s'agit d'une option plus rapide et plus sûre, mais cela signifie que tout le code s'exécutera en même temps lors de l'activation. Cela peut entraîner beaucoup de travail au moment de l'activation, ce qui peut avoir un impact sur l'INP, en particulier si la page semble entièrement chargée et prête à être utilisée.
De plus, si un contenu dépend de JavaScript (par exemple, un contenu rendu côté client), le retarder réduira l'impact positif du préchargement sur le LCP et le CLS. Une approche plus ciblée permettant d'exécuter davantage de code JavaScript pendant la phase de préchargement offre une meilleure expérience, mais peut être moins simple à implémenter.
Commencer par retarder complètement de nombreuses balises de script peut être une bonne stratégie pour les sites plus complexes. Toutefois, pour tirer le meilleur parti de l'API, l'objectif ultime est d'autoriser autant de JavaScript que possible à s'exécuter pendant le prérendu.
Les sites qui rencontrent des problèmes d'analyse ou d'annonces peuvent également commencer par le préchargement, qui est moins problématique, tout en réfléchissant à ce qu'il faut faire pour prendre en charge le prérendu.
Mettre à jour les spéculations de préchargement
Lorsque vous prérenduvez des pages avant la navigation, il existe un risque que la page prérendue devienne obsolète. Par exemple, la page prérendu d'un site d'e-commerce peut inclure un panier de paiement, qu'il s'agisse d'un panier complet d'articles ou simplement d'un compteur indiquant le nombre d'articles dans le panier sur d'autres pages. Si vous ajoutez d'autres articles à un panier, puis que vous accédez à une page prérendu, l'utilisateur serait perturbé de voir l'ancien état de paiement.
Ce problème n'est pas nouveau. Lorsque les utilisateurs ont plusieurs onglets ouverts dans le navigateur, ils rencontrent le même problème. Toutefois, avec les pages prérendues, cela est à la fois plus probable et plus inattendu, car l'utilisateur n'a pas déclenché le prérendu sciemment.
L'API Broadcast Channel permet à une page du navigateur de diffuser des mises à jour comme celle-ci sur d'autres pages. Cela résout également le problème des onglets multiples. Les pages prérendues peuvent écouter les messages de diffusion, mais ne peuvent pas envoyer leurs propres messages de diffusion tant qu'elles ne sont pas activées.
Les pages prérendues peuvent également être mises à jour à l'aide du serveur (à l'aide d'une fetch() périodique ou d'une connexion WebSocket), mais les mises à jour peuvent être retardées.
Annuler ou actualiser les spéculations de préchargement
La mise à jour d'une page préremplie est l'approche recommandée pour continuer à utiliser des pages préremplies tout en évitant de créer de la confusion chez les utilisateurs. Si ce n'est pas possible, vous pouvez annuler les spéculations.
Cette méthode peut également être utilisée pour respecter les limites de Chrome si les sites souhaitent prérendre d'autres pages plus susceptibles d'être consultées.
Pour annuler les spéculations, vous devez supprimer les règles de spéculation de la page, ou supprimer les classes ou d'autres critères de correspondance si vous utilisez cette approche. La page inférée peut également appeler window.close() si elle détecte qu'elle n'est plus à jour. Toutefois, si la page est en mesure de le détecter, il est préférable de mettre à jour son état pour la remettre à jour.
Vous pouvez également réinsérer ces règles (ou critères de correspondance) afin de prérendre à nouveau les pages (mais, encore une fois, il est généralement préférable de mettre à jour une page existante, car cela est moins coûteux). Une fois les règles de spéculation supprimées, la réinsertion doit être effectuée dans une nouvelle microtâche ou plus tard, afin que le navigateur puisse remarquer les suppressions et annuler les spéculations. L'exemple suivant montre une approche permettant de supprimer tous les scripts de règles de spéculation:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
Si vous supprimez des règles, les prétendants (ou préchargements) existants seront annulés. Toutefois, si vous les réinsérez, seules les règles immédiates ou avides seront spéculées (y compris les règles de liste d'URL utilisant la valeur par défaut "immédiate"). Toutefois, les spéculations modérées ou conservatrices seront supprimées, mais ne seront pas automatiquement réactivées tant que l'utilisateur n'aura pas interagi à nouveau avec le lien.
Cette option d'actualisation n'est pas limitée aux règles insérées en JavaScript. Les règles statiques incluses dans le code HTML peuvent également être supprimées ou modifiées de la même manière, car il s'agit d'une modification DOM standard. Les règles de spéculation HTTP ne peuvent pas être supprimées, mais les critères de correspondance (par exemple, les classes prerender) peuvent être supprimés et ajoutés à nouveau par JavaScript.
Chrome envisage également d'ajouter la prise en charge de Clear-Site-Header pour permettre aux réponses du serveur d'annuler les prérendus (par exemple, lorsqu'une requête de mise à jour du panier est envoyée).
Mesurer l'impact
Après avoir implémenté des règles de spéculation, vous devez mesurer le succès et ne pas simplement supposer qu'elles accélèrent automatiquement les requêtes. Comme indiqué précédemment, une surspécification peut entraîner une régression des performances si le client ou le serveur est surchargé.
Lorsque vous implémentez plusieurs étapes (préchargement, prérendus à faible risque, puis prérendus anticipés), vous devez effectuer des mesures à chaque étape.
Comment mesurer la réussite
Les règles de spéculation devraient avoir un impact positif sur les métriques de performances clés telles que la LCP (et éventuellement sur la CLS et l'INP), mais cela peut ne pas être évident dans les métriques globales au niveau du site. En effet, les sites peuvent être principalement composés d'autres types de navigation (pages de destination, par exemple) ou les navigations de même origine sont déjà suffisamment rapides pour que même une amélioration spectaculaire ne soit pas forcément visible dans les métriques du 75e percentile, comme indiqué dans le rapport d'expérience utilisateur Chrome.
Vous pouvez utiliser les types de navigation de page dans CrUX pour vérifier le pourcentage de navigations navigate_cache ou prerender et s'il augmente au fil du temps. Toutefois, pour une analyse détaillée, vous devrez peut-être utiliser la surveillance des utilisateurs réels afin de segmenter vos données en navigations supposées et de voir à quel point elles sont plus rapides que les autres navigations.
Mesurer l'utilisation et le gaspillage
Un autre point important à prendre en compte est de mesurer si vous spéculez sur les bonnes pages. Cela évite les gaspillages et vous assure de cibler les pages les plus adaptées à cette API.
Malheureusement, la page qui lance les spéculations ne peut pas voir directement l'état des tentatives de spéculation. De plus, on ne peut pas présumer que des tentatives ont été déclenchées, car le navigateur peut retenir les spéculations dans certaines circonstances. Ils doivent donc être mesurés sur la page elle-même. Pour ce faire, vous devez également vérifier deux API pour voir si la page effectue des spéculations ou si elle l'a déjà fait:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Cette page peut ensuite consigner la tentative de spéculation sur les serveurs backend.
Les fournisseurs (tels que Google Analytics) qui sont compatibles avec le préchargement et ignorent les appels d'analyse jusqu'à l'activation de la page (même les appels d'événement distincts) constituent une complication pour les données analytiques. Par conséquent, les utilisateurs de Google Analytics doivent utiliser une autre option de journalisation côté serveur.
Vous pouvez également effectuer cette opération côté client, où chaque page prérendu consigne le prérendu dans le stockage partagé, et la page appelante le lit. localStorage fonctionne mieux, car il peut être lu lorsque vous quittez une page (notez que sessionStorage ne peut pas être utilisé, car il est géré de manière spéciale pour les pages prérendues). Toutefois, sachez que localStorage n'est pas sécurisé au niveau des transactions et que d'autres pages peuvent le mettre à jour en même temps si plusieurs pages sont prérendues. Cette démonstration utilise un hachage unique et des entrées individuelles pour éviter ce problème.
Conclusion
Les règles de spéculation peuvent considérablement améliorer les performances de vos pages. Ce guide vous donne des conseils à prendre en compte lors de l'implémentation de cette API pour éviter tout problème potentiel et exploiter tout le potentiel de l'API.
Planifier l'implémentation à l'avance permet d'éviter les révisions. En particulier pour les sites plus complexes, il doit être suivi d'un déploiement en plusieurs étapes, en commençant par le préchargement, puis en passant au prérendu à faible risque, puis au prérendu anticipé. Enfin, il est important de mesurer les améliorations, ainsi que toute utilisation et tout gaspillage, pour vous assurer que vous utilisez l'API de manière optimale.