Dimension Core/Dash : LOAF

Trouvez les URL exactes des scripts qui bloquent votre main thread et dégradent l'INP en attribuant les Long Animation Frames à leur source.

Essai gratuit

Trusted by market leaders · Client results

ebayloopearplugscomparewhowhatwearworkivavpnsaturnnina caredpg mediaharvardsnvmonarchadevintamy work featured on web.devkpnmarktplaatsperionaleteiahappyhorizonnestlefotocasaerasmusmc

Dimension : Long Animation Frames (lurl)

La dimension LOAF remonte les URL des scripts qui ont causé des Long Animation Frames durant les sessions de vos utilisateurs. Chaque valeur est une URL de script : un bundle first-party, un tag analytique tiers, un widget de chat, un gestionnaire de consentement ou tout autre élément ayant fonctionné assez longtemps pour bloquer le rendu. Il s'agit d'une attribution au niveau de la source, et non d'une simple stack trace à reconstruire dans les DevTools.

CoreDash collecte ces données à l'aide de l'Long Animation Frames API (LoAF), que Chrome intègre en remplacement de l'ancienne API Long Tasks. Là où Long Tasks indiquait qu'une frame était trop longue, LoAF précise quels scripts ont été exécutés dans cette frame et quelles étaient leurs URL. C'est cette distinction qui rend cette dimension utile en production.

Pourquoi Long Tasks ne suffisait pas

L'API Long Tasks (disponible depuis 2017) signalait toute tâche du main thread dépassant 50 ms, mais ne fournissait quasiment aucune attribution. Vous pouviez constater le blocage, mais pas en identifier la cause. Les développeurs passaient des heures à corréler les horodatages des tâches avec les cascades réseau pour deviner quel script était responsable.

L'API LoAF change la donne. Elle remonte des objets PerformanceLongAnimationFrameEntry, contenant chacun un tableau scripts. Chaque entrée de ce tableau possède un invokerType, une sourceURL et une duration. CoreDash li la sourceURL de chaque script exécuté durant une frame longue et la stocke comme valeur de la dimension LOAF. Le résultat est un classement des URL de scripts ordonné par leur fréquence d'apparition dans les frames longues de vos utilisateurs.

Comment CoreDash utilise les données LoAF

Chaque fois qu'une interaction utilisateur déclenche une frame d'animation longue, CoreDash enregistre les URL des scripts concernés en parallèle de la mesure de l'INP. Vous pouvez ainsi filtrer vos données INP par URL LOAF et identifier le script responsable de vos pires interactions. La dimension effectue un regroupement par URL, affichant ainsi le nombre de sessions où ce script a provoqué une frame longue.

Exemples d'entrées types dans la dimension LOAF :

  • https://www.googletagmanager.com/gtm.js (conteneur Google Tag Manager)
  • https://cdn.cookielaw.org/consent/... (OneTrust ou plateforme de consentement similaire)
  • https://js.intercomcdn.com/... (widget de chat)
  • /static/js/app.bundle.js (votre propre code applicatif)
  • https://connect.facebook.net/en_US/fbevents.js (Pixel Meta)

Selon les données de CoreDash, les scripts tiers causent des frames d'animation longues sur environ 60 à 70 % des sites. Les tag managers contribuent à eux seuls aux frames longues sur environ 45 % des propriétés surveillées. Les bundles first-party dominent le reste, généralement à cause de re-renders React ou de gestionnaires d'événements non optimisés.

Attribution de l'INP via LoAF

L'INP mesure le temps écoulé entre l'interaction de l'utilisateur et l'affichage de la frame suivante. Si cet écart dépasse 200 ms, Google classe l'expérience dans la catégorie « amélioration nécessaire ». Les données LoAF révèlent quel script s'est exécuté durant cet intervalle. Un INP de 280 ms dont 210 ms proviennent d'un script de gestionnaire de consentement est un problème totalement différent d'un INP de 280 ms dont 190 ms proviennent de votre propre gestionnaire de checkout. La correction est différente. L'équipe responsable est différente. L'urgence est différente.

Sans attribution LoAF, ces deux cas semblent identiques dans votre histogramme INP. Avec elle, vous pouvez immédiatement orienter le problème vers la bonne personne.

Workflow de débogage

  1. Ouvrez la dimension LOAF dans CoreDash : triez par fréquence (le nombre de sessions ayant rencontré cette URL dans une frame longue). La première entrée est votre cible prioritaire.
  2. Croisez avec l'INP : appliquez le filtre LOAF à votre vue de la métrique INP. Vérifiez si le p75 de l'INP varie lorsque vous isolez les sessions où ce script s'est exécuté. Une hausse de plus de 30 ms confirme que le script contribue à la dégradation de l'INP en production.
  3. Classez le script en first-party ou tiers : la présence de votre propre domaine dans l'URL signifie que vous maîtrisez la correction. Une URL de CDN tiers implique que vous devez supprimer, retarder ou remplacer le script du fournisseur.
  4. Appliquez la correction et vérifiez : pour les scripts tiers, différez le chargement après la première interaction utilisateur en utilisant une façade ou une initialisation retardée. Pour le code first-party, profilez la fonction spécifique dans Chrome DevTools avec un CPU throttling à 4x. Déployez la modification et observez la mise à jour de la dimension LOAF sous 24 à 48 heures de trafic utilisateur réel.

Règles empiriques d'ingénierie

  • Toute URL de script unique apparaissant dans des frames longues pour plus de 5 % des sessions mérite d'être étudiée. À ce rythme, elle impacte une part mesurable d'utilisateurs réels sur le mois.
  • Les scripts tiers ne doivent pas s'exécuter pendant les gestionnaires d'interactions. Si un tag manager se déclenche de manière synchrone sur un événement de clic, il s'agit d'un problème de configuration, pas d'une limitation du navigateur.
  • Une durée de frame longue supérieure à 200 ms pour un seul script est un signal clair. L'API LoAF indique la durée par script au sein de la frame. Tout script consommant 200 ms ou plus d'une frame est la cause principale de l'INP qui en découle.
  • Les scripts first-party de la liste LOAF signalent souvent la surcharge (overhead) d'un framework. React, Vue et Angular peuvent tous générer des frames longues lors des mises à jour d'état. L'URL LOAF correspondra à votre propre bundle. Profilez l'arbre des composants, pas seulement le réseau.

La dimension LOAF vous apporte ce qu'aucun test synthétique ne peut fournir : la preuve des scripts qui bloquent les utilisateurs réels en production, classés par fréquence réelle. Filtrez par cette dimension, croisez avec vos données INP, et vous obtiendrez une liste ordonnée des priorités de correction.