Dimension CoreDash : LOAF

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

Essai gratuit

Trusted by market leaders · Client results

workivafotocasanina carekpnharvardebaymy work featured on web.devvpnperionnestlehappyhorizonadevintasaturnwhowhatwearaleteiadpg mediaerasmusmcsnvmarktplaatsmonarchcompareloopearplugs

Dimension : Long Animation Frames (lurl)

La dimension LOAF met en évidence les URL des scripts qui ont causé des Long Animation Frames pendant les sessions de vos utilisateurs. Chaque valeur est une URL de script : un bundle interne, une balise d'analyse tierce, un widget de chat, un gestionnaire de consentement, ou tout autre élément qui s'est exécuté suffisamment longtemps pour bloquer le rendu. Il s'agit d'une attribution au niveau de la source, et non d'une simple trace d'appels que vous devez reconstruire dans les DevTools.

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

coredash loaf scripts

Pourquoi Long Tasks n'était pas suffisant

L'API Long Tasks (disponible depuis 2017) signalait toute tâche du thread principal dépassant 50 ms, mais elle ne fournissait presque aucune attribution. Vous pouviez voir qu'un blocage s'était produit ; vous ne pouviez pas voir ce qui l'avait causé. Les développeurs passaient des heures à corréler les horodatages des tâches avec les cascades réseau (network waterfalls), en devinant quel script en était responsable.

L'API LoAF change la donne. Elle renvoie des objets PerformanceLongAnimationFrameEntry, contenant chacun un tableau scripts. Chaque entrée de ce tableau possède un invokerType, une sourceURL et une duration. CoreDash lit la sourceURL de chaque script exécuté pendant une longue frame et la stocke en tant que valeur de la dimension LOAF. Le résultat est une liste classée d'URL de scripts triée 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 longue frame d'animation, CoreDash enregistre les URL des scripts contributeurs aux côtés de l'observation INP. Cela signifie que vous pouvez filtrer vos données INP par URL LOAF et voir quel script est responsable de vos pires interactions. La dimension regroupe par URL, vous voyez donc le nombre de sessions impliquant ce script dans la création d'une longue frame.

Entrées typiques que vous verrez 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 d'application)
  • https://connect.facebook.net/en_US/fbevents.js (Pixel Meta)

Dans les données CoreDash, les scripts tiers sont responsables des Long Animation Frames sur environ 60 à 70 % des sites. Les gestionnaires de balises contribuent à eux seuls aux frames longues sur environ 45 % des propriétés surveillées. Les bundles internes dominent le reste, généralement en raison de rendus 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 comme « nécessite une amélioration ». Les données LoAF vous indiquent quel script s'est exécuté pendant cet écart. Un INP de 280 ms dont 210 ms remontent à un script de gestionnaire de consentement est un problème complètement différent d'un INP de 280 ms dont 190 ms remontent à votre propre gestionnaire de paiement. Le correctif est différent. L'équipe responsable est différente. L'urgence est différente.

Sans l'attribution LoAF, les deux semblent identiques dans votre histogramme INP. Avec elle, vous pouvez acheminer le problème directement à la bonne personne.

Flux de travail de débogage

  1. Ouvrez la dimension LOAF dans CoreDash : Triez par fréquence (combien de sessions ont vu cette URL dans une frame longue). La première entrée est votre cible la plus prioritaire.
  2. Filtrez de manière croisée avec l'INP : Appliquez le filtre LOAF à votre vue de métrique INP. Vérifiez si le p75 de l'INP change lorsque vous isolez les sessions où ce script s'est exécuté. Une augmentation de plus de 30 ms confirme que le script contribue à la dégradation de l'INP en production.
  3. Classez comme interne ou tiers : Si votre propre domaine est dans l'URL, cela signifie que vous contrôlez le correctif. Une URL de CDN tiers signifie que vous devez supprimer, retarder ou remplacer le script du fournisseur.
  4. Appliquez le correctif et vérifiez : Pour les scripts tiers, différez le chargement jusqu'à après la première interaction de l'utilisateur à l'aide d'une façade ou d'une initialisation différée. Pour le code interne, profilez la fonction spécifique dans les Chrome DevTools avec la limitation du processeur (CPU throttling) définie sur 4x. Déployez la modification et observez la mise à jour de la dimension LOAF dans les 24 à 48 heures de trafic utilisateur réel.

Règle empirique 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 taux, elle affecte une portion mesurable d'utilisateurs réels tout au long du mois.
  • Les scripts tiers ne doivent pas s'exécuter pendant les gestionnaires d'interaction. Si un gestionnaire de balises se déclenche de manière synchrone sur un événement de clic, c'est un problème de configuration, pas 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 signale la durée par script à l'intérieur 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 internes dans la liste LOAF pointent souvent vers la surcharge du framework (framework overhead). React, Vue et Angular peuvent tous produire des frames longues lors des mises à jour d'état. L'URL LoAF sera votre propre bundle. Profilez l'arborescence des composants, et 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 dans le monde réel. Filtrez par elle, croisez avec vos données INP, et vous obtenez une liste priorisée de ce qu'il faut exactement corriger, et dans quel ordre.