Speculation Rules et préchargement : ce que l'analytique comprend de travers sur les pages préchargées
L'API Speculation Rules de Chrome peut rendre une page avant même qu'un utilisateur ne clique. Voici comment cela fausse une analytique naïve — et comment une mesure sans cookies, en périphérie, reste honnête.
La page qui s'est chargée avant le clic
L'API Speculation Rules, désormais largement déployée dans les navigateurs Chromium, permet à un site de déclarer quelles URL le navigateur doit précharger ou rendre entièrement à l'avance (prerender) avant la navigation. Lorsqu'un utilisateur survole un lien ou manifeste une intention, la destination peut déjà être rendue dans un onglet masqué, puis affichée instantanément. Le gain est un Largest Contentful Paint quasi nul à l'activation. Le problème, pour la mesure, c'est qu'une page préchargée exécute vos scripts avant même que quiconque ait décidé de la visiter.
Si votre analytique déclenche une vue de page au chargement, le préchargement gonfle vos compteurs avec des visites qui n'ont jamais eu lieu. Pire encore, cela fausse les données de performance : une page rendue en arrière-plan enregistre des temps qui n'ont aucun rapport avec ce qu'un véritable utilisateur a vécu.
Ce qui se passe réellement pendant le prerender
Un document préchargé s'exécute normalement, mais dans un état de cycle de vie particulier. document.prerendering vaut true, et la page n'a pas encore été activée dans l'onglet visible. L'événement prerenderingchange se déclenche lorsque — et seulement si — l'utilisateur y navigue réellement. De nombreux prerenders ne sont jamais activés ; le navigateur peut les abandonner.
Cela compte pour deux raisons :
- Le comptage. Un
sendBeaconnaïf surDOMContentLoadedsignalera une vue de page pour un document qui pourrait ne jamais être vu. - L'attribution de performance. Les Core Web Vitals sont définis par rapport au chargement perçu par l'utilisateur. La bibliothèque web-vitals et les spécifications sous-jacentes Paint Timing et Event Timing prennent en compte le prerender en mesurant à partir du point d'activation, et non du début de la navigation d'origine. Une métrique collectée sans cette prise en compte est tout simplement fausse.
Le bon schéma
La plateforme web vous offre des signaux clairs. Reportez toute mesure jusqu'à ce que la page soit réellement visible pour une personne :
if (document.prerendering) {
document.addEventListener('prerenderingchange', recordPageview, { once: true });
} else {
recordPageview();
}
Pour le timing, PerformanceNavigationTiming.activationStart donne le décalage entre le début de la navigation et l'activation. Tout horodatage de rendu ou d'interaction doit être mesuré par rapport à cette valeur, en ramenant les valeurs négatives à zéro. C'est exactement ce que fait en interne la bibliothèque web-vitals de Google : si vous calculez vous-même le LCP ou l'INP, reproduisez cette logique.
La même discipline s'applique au prefetch, le cousin plus léger du prerender. Le prefetch ne récupère que la réponse ; il n'exécute pas de scripts, il pollue donc rarement l'analytique directement. Mais il consomme de la bande passante et peut fausser les journaux de requêtes côté serveur — un rappel que les décomptes bruts des journaux et les visites réelles divergent plus que jamais.
Pourquoi c'est plus simple sans cookies ni état client
Le prerender piloté par la spéculation est un casse-tête pour les traceurs à état. Un document préchargé qui définit des identifiants, hydrate une session ou écrit dans le stockage le fait de manière spéculative — pour une visite qui pourrait être abandonnée. Nettoyer cela, dédupliquer par rapport à l'activation réelle éventuelle et réconcilier l'identité entre les pages devient une véritable source d'erreur et de risque pour la vie privée.
Monoid contourne toute cette catégorie de problèmes. Nous ne stockons rien sur l'appareil — pas de cookies, pas de localStorage, pas d'empreinte. Il n'y a aucune session spéculative à créer puis à défaire. La mesure est un signal unique et sans état, que nous n'émettons qu'une fois la page devenue réelle. Comme la collecte s'exécute à la périphérie de Cloudflare, l'agrégation porte sur des données qui reflètent déjà des navigations réelles et activées, plutôt que les suppositions optimistes d'un navigateur.
C'est la minimisation des données qui joue en votre faveur. Lorsque vous ne collectez rien qui ait besoin d'être nettoyé, le rendu spéculatif ne crée pas d'enregistrements d'identité orphelins ni de profils en double. Cela signifie simplement que vous attendez prerenderingchange avant de compter.
Une check-list pour une analytique compatible avec le prerender
- Conditionnez l'émission de la vue de page à
document.prerenderinget à l'événementprerenderingchange. - Calculez le LCP, le FCP et l'INP par rapport à
activationStart, ou utilisez une bibliothèque qui le fait déjà. - Traitez les journaux de requêtes serveur comme un sur-ensemble des visites réelles, et non comme un substitut de celles-ci.
- Vérifiez que votre Content-Security-Policy autorise votre endpoint de mesure à être atteint depuis un document activé ; testez dans le panneau prerender des Chrome DevTools.
- Évitez toute écriture spéculative dans le stockage de l'appareil — la façon la plus propre d'être correct vis-à-vis du prerender est de ne conserver aucun état client.
Le point plus général
Chaque nouvelle primitive de performance — bfcache, navigations douces, et maintenant les speculation rules — brise discrètement l'ancienne hypothèse selon laquelle un chargement de page équivaut à une visite humaine. L'analytique qui s'appuie sur les cookies et les sessions à état doit greffer toujours plus de logique de réconciliation. L'analytique qui mesure un événement sans état au moment de la visibilité réelle n'a qu'à respecter les événements de cycle de vie de la plateforme. Des pages plus rapides et des chiffres honnêtes ne sont pas incompatibles ; il suffit de compter au bon moment.
Comments
Loading comments…