L'API Long Animation Frames (LoAF, prononcé Lo-Af) est une mise à jour de l'API Long Tasks pour vous aider à mieux comprendre les mises à jour lentes de l'interface utilisateur (UI). Cela peut être utile pour identifier les images d'animation lentes susceptibles d'affecter la métrique Core Web Vitals Interaction to Next Paint (INP), qui mesure la réactivité, ou pour identifier d'autres à-coups de l'interface utilisateur qui affectent la lissage.
État de l'API
Navigateurs pris en charge
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
Après une phase d'évaluation de Chrome 116 à Chrome 122, l'API LoAF est expédiée depuis Chrome 123.
Contexte: API Long Tasks
Navigateurs pris en charge
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
L'API Long Animation Frames est une alternative à l'API Long Tasks, disponible dans Chrome depuis un certain temps (depuis Chrome 58). Comme son nom l'indique, l'API Long Task vous permet de surveiller les longues tâches, c'est-à-dire celles qui occupent le thread principal pendant au moins 50 millisecondes. Les tâches longues peuvent être surveillées à l'aide de l'interface PerformanceLongTaskTiming
, avec un PeformanceObserver
:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'longtask', buffered: true });
Les tâches longues sont susceptibles de provoquer des problèmes de réactivité. Si un utilisateur tente d'interagir avec une page (par exemple, en cliquant sur un bouton ou en ouvrir un menu), mais que le thread principal traite déjà une longue tâche, l'interaction de l'utilisateur est retardée en attendant la fin de cette tâche.
Pour améliorer la réactivité, il est souvent conseillé de séparer les tâches longues. Si chaque tâche longue est divisée en une série de plusieurs tâches plus petites, cela peut permettre l'exécution de tâches plus importantes entre elles pour éviter des retards importants de réponse aux interactions.
Ainsi, lorsque vous essayez d'améliorer la réactivité, la première chose à faire consiste souvent à exécuter une trace des performances et à examiner les tâches longues. Pour ce faire, vous pouvez utiliser un outil d'audit basé sur des ateliers comme Lighthouse (qui propose l'audit Éviter les longues tâches du thread principal) ou examiner les longues tâches dans les outils pour les développeurs Chrome.
Les tests en laboratoire sont souvent un mauvais point de départ pour identifier les problèmes de réactivité, car ces outils peuvent ne pas inclure les interactions. Dans ce cas, il s'agit d'un petit sous-ensemble d'interactions probables. Idéalement, vous mesureriez les causes des interactions lentes sur le terrain.
Limites de l'API Long Tasks
Mesurer les longues tâches sur le terrain à l'aide d'un observateur de performances n'est que quelque peu utile. En réalité, elle ne fournit pas beaucoup d'informations au-delà du fait qu'une longue tâche s'est produite et du temps qu'elle a pris.
Les outils de surveillance des utilisateurs réels s'en servent souvent pour déterminer le nombre ou la durée des longues tâches, ou pour identifier les pages sur lesquelles ils se produisent. Toutefois, sans les détails sous-jacents sur les causes de ces longues tâches, leur utilité est limitée. L'API Long Tasks ne dispose que d'un modèle d'attribution de base, qui ne vous indique, au mieux, que le conteneur dans lequel la tâche longue s'est produite (le document de premier niveau ou <iframe>
), mais pas le script ou la fonction qui l'a appelée, comme le montre une entrée type:
{
"name": "unknown",
"entryType": "longtask",
"startTime": 31.799999997019768,
"duration": 136,
"attribution": [
{
"name": "unknown",
"entryType": "taskattribution",
"startTime": 0,
"duration": 0,
"containerType": "window",
"containerSrc": "",
"containerId": "",
"containerName": ""
}
]
}
L'API Long Tasks est également incomplète, car elle peut également exclure certaines tâches importantes. Certaines mises à jour, telles que le rendu, se produisent dans des tâches distinctes qui, idéalement, doivent être incluses en même temps que l'exécution précédente, qui a permis à cette mise à jour de mesurer avec précision le "travail total". pour cette interaction. Pour en savoir plus sur les limites liées aux tâches, consultez la section de la vidéo explicative.
Le dernier problème est que la mesure des longues tâches ne génère des rapports que sur les tâches individuelles qui dépassent la limite de 50 millisecondes. Une image d'animation peut être composée de plusieurs tâches d'une taille inférieure à cette limite de 50 millisecondes, tout en bloquant collectivement l'affichage du navigateur.
API Long Animation Frames
Navigateurs pris en charge
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
L'API Long Animation Frames (LoAF) est une nouvelle API qui vise à combler certaines des lacunes de l'API Long Tasks. Elle permet aux développeurs d'obtenir des insights plus exploitables afin de résoudre les problèmes de réactivité et d'améliorer INP.
Une bonne réactivité signifie qu'une page réagit rapidement aux interactions effectuées avec elle. Cela implique de pouvoir peindre toutes les mises à jour dont l'utilisateur a besoin en temps opportun et d'éviter de bloquer ces mises à jour. Pour INP, il est recommandé de répondre en 200 millisecondes ou moins, mais pour les autres mises à jour (par exemple, les animations), même celles qui peuvent être trop longues.
L'API Long Animation Frames est une approche alternative à la mesure du travail de blocage. Au lieu de mesurer les tâches individuelles, l'API Long Animation Frames, comme son nom l'indique, mesure les longues frames d'animation. On parle de longue image d'animation lorsqu'une mise à jour de rendu est retardée au-delà de 50 millisecondes (le même seuil que pour l'API Long Tasks).
Les longues frames d'animation peuvent être observées de la même manière que les tâches longues avec un PerformanceObserver
, mais en examinant le type long-animation-frame
à la place:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Vous pouvez également interroger les longues images d'animation précédentes depuis la chronologie des performances, comme suit:
const loafs = performance.getEntriesByType('long-animation-frame');
Cependant, il existe une maxBufferSize
pour les entrées de performances, après quoi les entrées plus récentes sont supprimées. L'approche PerformanceObserver est donc recommandée. La taille de la mémoire tampon long-animation-frame
est définie sur 200, comme pour long-tasks
.
Avantages de regarder des cadres plutôt que des tâches
Le principal avantage d'examiner cela du point de vue d'une image plutôt que du point de vue des tâches est qu'une longue animation peut être composée de n'importe quel nombre de tâches ayant entraîné une longue image d'animation. Cela concerne le dernier point mentionné précédemment, où la somme des nombreuses tâches plus petites qui bloquent l'affichage avant une image d'animation peut ne pas être révélée par l'API Long Tasks.
Un autre avantage de cette autre vue pour les longues tâches est la possibilité de fournir des répartitions temporelles de l'ensemble du frame. Au lieu d'inclure simplement un startTime
et un duration
, comme l'API Long Tasks, le LoAF inclut une répartition beaucoup plus détaillée des différentes parties de la durée de frame, y compris:
startTime
: heure de début de la longue image d'animation par rapport à l'heure de début de la navigation.duration
: durée de l'image d'animation longue (sans tenir compte de la durée de présentation).renderStart
: heure de début du cycle de rendu, qui inclut les rappelsrequestAnimationFrame
, le calcul du style et de la mise en page, ainsi que les rappels de l'observateur de redimensionnement et d'intersection.styleAndLayoutStart
: début de la période consacrée aux calculs de style et de mise en page.firstUIEventTimestamp
: heure du premier événement d'interface utilisateur (souris/clavier, etc.) à gérer au cours de ce frame.blockingDuration
: durée, en millisecondes, pendant laquelle l'image d'animation était bloquée.
Ces codes temporels permettent de diviser la longue image de l'animation en codes temporels:
Durée | Calcul |
---|---|
Heure de début | startTime |
Heure de fin | startTime + duration |
Durée du travail | renderStart ? renderStart - startTime : duration |
Durée du rendu | renderStart ? (startTime + duration) - renderStart: 0 |
Rendu: durée de la pré-mise en page | styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0 |
Rendu: durée du style et de la mise en page | styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0 |
Pour en savoir plus sur ces différentes durées, consultez la vidéo explicative qui indique avec précision les activités qui contribuent à une longue image d'animation.
Amélioration de l'attribution
Le type d'entrée long-animation-frame
inclut de meilleures données d'attribution pour chaque script qui a contribué à une longue image d'animation.
Comme pour l'API Long Tasks, ces données seront fournies dans un tableau d'entrées d'attribution, chacune contenant les informations suivantes:
name
etEntryType
renvoient tous deuxscript
.- Un
invoker
significatif indiquant la façon dont le script a été appelé (par exemple,'IMG#id.onload'
,'Window.requestAnimationFrame'
ou'Response.json.then'
). invokerType
du point d'entrée du script: <ph type="x-smartling-placeholder">- </ph>
user-callback
: rappel connu enregistré à partir d'une API de plate-forme Web (par exemple,setTimeout
ourequestAnimationFrame
).event-listener
: écouteur d'un événement de plate-forme (par exemple,click
,load
,keyup
).resolve-promise
: gestionnaire d'une promesse de plate-forme (par exemple,fetch()
). Notez que dans le cas de promesses, tous les gestionnaires des mêmes promesses sont mélangés sous la forme d'un "script"..
reject-promise
: conformément àresolve-promise
, mais pour le refus.classic-script
: évaluation du script (par exemple,<script>
ouimport()
)module-script
: identique àclassic-script
, mais pour les scripts de module.
- Séparez les données temporelles de ce script:
startTime
: heure à laquelle la fonction d'entrée a été appelée.duration
: durée entrestartTime
et le moment où la file d'attente de microtâches suivante a terminé le traitement.executionStart
: temps après la compilation.forcedStyleAndLayoutDuration
: temps total passé à traiter la mise en page et le style forcés dans cette fonction (voir thrashing).pauseDuration
: temps total passé en "mise en veille" les opérations synchrones (alerte, XHR synchrone).
- Détails de la source du script:
sourceURL
: nom de la ressource de script, le cas échéant (ou vide s'il est introuvable).sourceFunctionName
: nom de la fonction de script, le cas échéant (ou vide dans le cas contraire).sourceCharPosition
: position du caractère du script, le cas échéant (ou "-1" s'il est introuvable).
windowAttribution
: conteneur (document de premier niveau ou<iframe>
) dans lequel se trouve le long frame d'animation.window
: référence à la fenêtre d'origine commune.
Lorsqu'elles sont fournies, les entrées sources permettent aux développeurs de savoir exactement comment chaque script de la longue image d'animation a été appelé, jusqu'à la position du personnage dans le script appelant. Vous obtenez ainsi l'emplacement exact d'une ressource JavaScript ayant généré la longue image d'animation.
Exemple d'entrée associée aux performances de long-animation-frame
Voici un exemple complet d'entrée de performance long-animation-frame
contenant un seul script:
{
"blockingDuration": 0,
"duration": 60,
"entryType": "long-animation-frame",
"firstUIEventTimestamp": 11801.099999999627,
"name": "long-animation-frame",
"renderStart": 11858.800000000745,
"scripts": [
{
"duration": 45,
"entryType": "script",
"executionStart": 11803.199999999255,
"forcedStyleAndLayoutDuration": 0,
"invoker": "DOMWindow.onclick",
"invokerType": "event-listener",
"name": "script",
"pauseDuration": 0,
"sourceURL": "https://web.dev/js/index-ffde4443.js",
"sourceFunctionName": "myClickHandler",
"sourceCharPosition": 17796,
"startTime": 11803.199999999255,
"window": [Window object],
"windowAttribution": "self"
}
],
"startTime": 11802.400000000373,
"styleAndLayoutStart": 11858.800000000745
}
Comme vous pouvez le constater, cela fournit une quantité sans précédent de données pour permettre aux sites Web de comprendre la cause des mises à jour retardées de l'affichage.
Utiliser l'API Long Animation Frames dans le champ
Bien qu'utiles pour détecter et reproduire des problèmes, des outils comme les outils pour les développeurs Chrome et Lighthouse sont des outils d'atelier qui peuvent passer à côté d'aspects importants de l'expérience utilisateur que seules les données réelles peuvent fournir.
L'API Long Animation Frames est conçue pour être utilisée sur le terrain afin de collecter des données contextuelles importantes concernant les interactions utilisateur, ce qui n'est pas le cas de l'API Long Tasks. Cela peut vous aider à identifier et à reproduire des problèmes d'interactivité que vous n'auriez peut-être pas découverts autrement.
Prise en charge de la détection de fonctionnalités pour les cadres d'animation longs
Vous pouvez utiliser le code suivant pour vérifier si l'API est compatible:
if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
// Monitor LoAFs
}
Lien vers la plus longue interaction INP
Le cas d'utilisation le plus évident de l'API Long Animation Frames consiste à aider à diagnostiquer et à résoudre les problèmes d'Interaction to Next Paint (INP). C'est l'une des principales raisons pour lesquelles l'équipe Chrome a développé cette API. Pour un INP bon, on parle de réponse à toutes les interactions en 200 millisecondes ou moins entre l'interaction et le cadre. Étant donné que l'API Long Animation Frames mesure tous les frames qui prennent 50 ms ou plus, les INP les plus problématiques doivent inclure des données LoAF pour vous aider à diagnostiquer ces interactions.
Le « LoAF INP » est le LoAF qui inclut l'interaction INP, comme illustré dans le diagramme suivant:
![Exemples de longues images d'animation sur une page, avec le LoAF INP mis en évidence.](https://developer.chrome.google.cn/static/docs/web-platform/long-animation-frames/image/loaf-inp.png?authuser=6&hl=fr)
Dans certains cas, il est possible qu'un événement INP couvre deux LOAF, généralement si l'interaction se produit après que l'image a lancé la partie de rendu du frame précédent, et que le gestionnaire d'événements l'a donc traité dans l'image suivante:
![Exemples de longues images d'animation sur une page, avec le LoAF INP mis en évidence.](https://developer.chrome.google.cn/static/docs/web-platform/long-animation-frames/image/loaf-inp-two-frames.png?authuser=6&hl=fr)
Dans de rares cas, il est même possible qu'il couvre plus de deux LOAF.
L'enregistrement des données LoAF associées à l'interaction INP vous permet d'obtenir beaucoup plus d'informations sur cette interaction pour faciliter son diagnostic. Cela est particulièrement utile pour comprendre le délai d'entrée, car vous pouvez voir quels autres scripts étaient exécutés dans ce frame.
Il peut également être utile de comprendre la durée du traitement et le délai de présentation inexpliqués si vos gestionnaires d'événements ne reproduisent pas les valeurs observées, car d'autres scripts peuvent être en cours d'exécution pour vos utilisateurs et ne sont peut-être pas inclus dans vos propres tests.
Il n'existe aucune API directe permettant d'associer une entrée INP aux entrées ou entrées LoAF correspondantes, bien qu'il soit possible de le faire dans le code en comparant les heures de début et de fin de chaque entrée (voir l'exemple de script WhyNp).
La bibliothèque web-vitals
inclut tous les LoAF qui se croisent dans la propriété longAnimationFramesEntries
de l'interface d'attribution INP à partir de la version 4.
Une fois que vous avez associé la ou les entrées LoAF, vous pouvez inclure des informations avec l'attribution INP. L'objet scripts
contient certaines des informations les plus précieuses, car il peut montrer ce qui était en cours d'exécution dans ces frames. Le balisage de ces données dans votre service d'analyse vous permettra de comprendre pourquoi les interactions étaient lentes.
Signaler les LOAF pour l'interaction INP est un bon moyen de trouver les problèmes d'interactivité les plus urgents sur votre page. Chaque utilisateur peut interagir différemment avec votre page. S'il dispose d'un volume suffisant de données d'attribution INP, un certain nombre de problèmes potentiels seront inclus dans les données d'attribution INP. Cela vous permet de trier les scripts par volume pour voir ceux qui sont en corrélation avec l'INP lent.
Transmettre des données d'animation plus longues à un point de terminaison d'analyse
L'inconvénient de ne tenir compte que des LOAF INP est que vous pouvez passer à côté d'autres domaines potentiels d'amélioration susceptibles de causer de futurs problèmes INP. Cela peut donner l'impression d'être à la poursuite de votre pile, ce qui vous permet de corriger un problème INP en espérant une amélioration considérable, pour que la prochaine interaction la plus lente ne soit que légèrement supérieure, et votre INP ne s'améliore donc pas beaucoup.
Ainsi, au lieu de mettre en avant uniquement le LOAF INP, vous pouvez examiner tous les LOAF tout au long de la durée de vie de la page:
![Page avec de nombreux LOAF, dont certains se produisent lors d'interactions, même en dehors de l'interaction INP.](https://developer.chrome.google.cn/static/docs/web-platform/long-animation-frames/image/all-loafs.png?authuser=6&hl=fr)
Cependant, chaque entrée LoAF contient une quantité considérable de données, vous ne voudrez donc probablement pas les baliser toutes. Au lieu de cela, vous pouvez limiter votre analyse à quelques LOAF ou à certaines données.
Voici quelques suggestions:
- Observer de longues frames d'animation lors des interactions
- Observer les images d'animation dépassant un certain seuil
- Observer les pires images d'animation longues
- Identifier les tendances courantes dans les longues images d'animation
Le modèle qui vous convient le mieux dépend de l'avancée de votre parcours d'optimisation et de la fréquence des images d'animation longues. Pour un site qui n'a jamais été optimisé pour la réactivité auparavant, il peut y avoir de nombreux LOAF. Vous voudrez peut-être les limiter uniquement aux manchots à faible valeur d'interaction avec les interactions, définir un seuil élevé ou n'examiner que les médiocres. Au fur et à mesure que vous résolvez les problèmes courants de réactivité, vous pouvez développer ce phénomène en ne vous limitant pas aux seules interactions et en baissant les seuils, ou en recherchant des tendances particulières.
Observer les longues images d'animation avec des interactions
Pour obtenir des insights au-delà de la longue image d'animation INP, vous pouvez examiner tous les LOAF avec des interactions (qui peuvent être détectées par la présence d'une valeur firstUIEventTimestamp
).
Il peut également s'agir d'une méthode plus simple pour surveiller les LOAF de l'INP plutôt que d'essayer de les corréler, ce qui peut être plus complexe. Dans la plupart des cas, cela inclura le niveau de précision de l'INP pour une visite donnée. Dans de rares cas, il présente toujours de longues interactions qu'il est important de corriger, car il peut s'agir de l'interaction INP pour d'autres utilisateurs.
Le code suivant consigne toutes les entrées LoAF de plus de 150 millisecondes où une interaction s'est produite pendant le frame. La valeur 150 est choisie ici, car elle est légèrement inférieure aux 200 millisecondes de "bonne" Seuil INP. Vous pouvez choisir une valeur supérieure ou inférieure en fonction de vos besoins.
const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.duration > REPORTING_THRESHOLD_MS &&
entry.firstUIEventTimestamp > 0
) {
// Example here logs to console, but could also report back to analytics
console.log(entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Observer les images d'animation dont la durée dépasse un certain seuil
Une autre stratégie consisterait à surveiller tous les LOAF et à baliser ceux qui dépassent un certain seuil vers un point de terminaison d'analyse pour une analyse ultérieure:
const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.duration > REPORTING_THRESHOLD_MS) {
// Example here logs to console, but could also report back to analytics
console.log(entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Étant donné que les longues entrées de frame d'animation peuvent être assez volumineuses, les développeurs doivent décider quelles données de l'entrée doivent être envoyées à l'analyse. Par exemple, les heures de résumé de l'entrée et éventuellement les noms des scripts, ou tout autre ensemble minimal d'autres données contextuelles qui peuvent être jugées nécessaires.
Identifier les pires images d'animation longues
Plutôt que d'avoir un seuil défini, les sites peuvent vouloir collecter des données sur la ou les trames d'animation les plus longues afin de réduire le volume de données à baliser. Par conséquent, quel que soit le nombre de longues images d'animation sur une page, seules les données des moins bonnes (une, cinq ou le nombre de longues animations absolument nécessaires) sont renvoyées.
MAX_LOAFS_TO_CONSIDER = 10;
let longestBlockingLoAFs = [];
const observer = new PerformanceObserver(list => {
longestBlockingLoAFs = longestBlockingLoAFs.concat(list.getEntries()).sort(
(a, b) => b.blockingDuration - a.blockingDuration
).slice(0, MAX_LOAFS_TO_CONSIDER);
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Ces stratégies peuvent également être combinées : vous ne pouvez examiner que les 10 manchots de faible niveau d'engagement les plus faibles, avec des interactions de plus de 150 millisecondes.
Au moment opportun (idéalement lors de l'événement visibilitychange
), renvoyez les données aux données analytiques. Pour les tests en local, vous pouvez utiliser régulièrement console.table
:
console.table(longestBlockingLoAFs);
Identifier les tendances communes dans les longues images d'animation
Une autre stratégie consiste à examiner les scripts courants qui apparaissent le plus dans les longues entrées d'images d'animation. Les données peuvent être rapportées au niveau du script et de la position des personnages afin d'identifier les responsables d'infractions répétées.
Cela peut s'avérer particulièrement efficace pour les plates-formes personnalisables où les thèmes ou plug-ins à l'origine de problèmes de performances peuvent être identifiés sur un certain nombre de sites.
Le temps d'exécution des scripts courants (ou origines tierces) des longues frames d'animation peut être additionné et rapporté afin d'identifier les contributeurs communs aux longues images d'animation sur un site ou un ensemble de sites. Par exemple, pour examiner les URL:
const observer = new PerformanceObserver(list => {
const allScripts = list.getEntries().flatMap(entry => entry.scripts);
const scriptSource = [...new Set(allScripts.map(script => script.sourceURL))];
const scriptsBySource= scriptSource.map(sourceURL => ([sourceURL,
allScripts.filter(script => script.sourceURL === sourceURL)
]));
const processedScripts = scriptsBySource.map(([sourceURL, scripts]) => ({
sourceURL,
count: scripts.length,
totalDuration: scripts.reduce((subtotal, script) => subtotal + script.duration, 0)
}));
processedScripts.sort((a, b) => b.totalDuration - a.totalDuration);
// Example here logs to console, but could also report back to analytics
console.table(processedScripts);
});
observer.observe({type: 'long-animation-frame', buffered: true});
Voici un exemple de résultat:
(index) |
sourceURL |
count |
totalDuration |
---|---|---|---|
0 |
'https://example.consent.com/consent.js' |
1 |
840 |
1 |
'https://example.com/js/analytics.js' |
7 |
628 |
2 |
'https://example.chatapp.com/web-chat.js' |
1 |
5 |
Utiliser l'API Long Animation Frames dans les outils
L'API permet également d'utiliser des outils de développement supplémentaires pour le débogage local. Certains outils tels que Lighthouse et Chrome DevTools ont pu collecter une grande partie de ces données à l'aide de détails de traçage de niveau inférieur, mais cette API de niveau supérieur pourrait permettre à d'autres outils d'accéder à ces données.
Afficher les données des longues frames d'animation dans les outils de développement
Vous pouvez afficher de longues images d'animation dans les outils de développement à l'aide de l'API performance.measure()
. Elles s'affichent ensuite dans la piste de temps utilisateur des outils de développement dans les traces des performances pour vous indiquer où concentrer vos efforts pour améliorer les performances:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
performance.measure('LoAF', {
start: entry.startTime,
end: entry.startTime + entry.duration,
});
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
À plus long terme, il sera probablement intégré aux outils de développement lui-même, mais l'extrait de code précédent permet d'y figurer en attendant.
Utiliser les données des longues cadres d'animation dans d'autres outils du développeur
L'extension Web Vitals a indiqué la valeur dans l'enregistrement des informations de débogage du récapitulatif afin de diagnostiquer les problèmes de performances.
Désormais, il affiche également de longues données d'images d'animation pour chaque rappel INP et chaque interaction:
![Journalisation de la console de l'extension Web Vitals.](https://developer.chrome.google.cn/static/docs/web-platform/long-animation-frames/image/loaf-web-vitals-extension.png?authuser=6&hl=fr)
Utiliser les données des longues cadres d'animation dans les outils de test automatisés
De même, les outils de test automatisés des pipelines CI/CD peuvent révéler des détails sur d'éventuels problèmes de performances en mesurant de longues frames d'animation lors de l'exécution de différentes suites de tests.
Questions fréquentes
Voici quelques-unes des questions fréquentes concernant cette API:
Pourquoi ne pas simplement étendre ou itérer l'API Long Tasks ?
Il s'agit d'une autre façon de signaler des problèmes de réactivité potentiels similaires, mais finalement différents. Il est important de s'assurer que les sites qui s'appuient sur l'API Long Tasks existante continuent de fonctionner pour éviter de perturber les cas d'utilisation existants.
Bien que l'API Long Tasks puisse bénéficier de certaines des fonctionnalités de LoAF (comme un meilleur modèle d'attribution), nous pensons que se concentrer sur les frames plutôt que sur les tâches offre de nombreux avantages qui en font une API fondamentalement différente de l'API Long Tasks existante.
Pourquoi n'ai-je pas d'entrées de script ?
Cela peut indiquer que le long frame d'animation n'était pas dû à JavaScript, mais à un gros travail de rendu.
Cela peut également se produire lorsque le long frame d'animation est dû à JavaScript, mais que l'attribution du script ne peut pas être fournie pour différentes raisons de confidentialité, comme indiqué précédemment (principalement parce que le code JavaScript n'appartient pas à la page).
Pourquoi des entrées de script sont-elles présentes, mais pas d'informations sur la source, ou des informations limitées ?
Cela peut se produire pour plusieurs raisons. Par exemple, il n'y a pas de source fiable vers laquelle renvoyer.
Les informations concernant les scripts no-cors cross-origin
seront également limitées, mais vous pouvez résoudre ce problème en récupérant ces scripts à l'aide de CORS en ajoutant crossOrigin = "anonymous"
à l'appel <script>
.
Par exemple, voici le script Google Tag Manager par défaut à ajouter à la page:
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->
Il peut être amélioré pour ajouter des j.crossOrigin = "anonymous"
afin de permettre de fournir tous les détails de l'attribution pour GTM.
Cela va-t-il remplacer l'API Long Tasks ?
Nous pensons que l'API Long Animation Frames est une API plus performante et plus complète pour mesurer les longues tâches. Toutefois, nous ne prévoyons pas d'abandonner l'API Long Tasks pour le moment.
Commentaires souhaités
Vous pouvez envoyer vos commentaires dans la liste GitHub des problèmes ou signaler les bugs liés à l'implémentation de l'API dans Chrome dans l'outil de suivi des problèmes de Chrome.
Conclusion
L'API Long Animation Frames est une nouvelle API intéressante qui offre de nombreux avantages potentiels par rapport à l'API Long Tasks précédent.
Il s'avère qu'il s'agit d'un outil clé pour résoudre les problèmes de réactivité tels que mesurés par INP. INP est une métrique difficile à optimiser, et cette API est un moyen pour l'équipe Chrome de faciliter l'identification et la résolution des problèmes pour les développeurs.
Toutefois, le champ d'application de l'API Long Animation Frames s'étend au-delà de l'INP et peut aider à identifier d'autres causes de lenteur des mises à jour susceptibles d'affecter la fluidité globale de l'expérience utilisateur d'un site Web.