API Long Animation Frames

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

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

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, devraient être incluses avec 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 au fait de s'appuyer sur les tâches, consultez la section Cas où les longues tâches sont à court d'exercices dans le message explicatif.

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

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 rappels requestAnimationFrame, 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 et EntryType renvoient tous deux script.
• 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 :
  • user-callback: rappel connu enregistré à partir d'une API de plate-forme Web (par exemple, setTimeout ou requestAnimationFrame).
  • 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 en un seul "script"..
  • reject-promise: conformément à resolve-promise, mais pour le refus.
  • classic-script: évaluation du script (par exemple, <script> ou import())
  • 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 entre startTime 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é à mettre en veille les opérations synchrones (alerte, XHR synchrone).
• Informations sur 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 comprend l'interaction INP, comme illustré dans le diagramme suivant:

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:

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 pour lier une entrée INP à ses entrées ou entrées LoAF associées, 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:

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 au seuil INP "satisfaisant" de 200 millisecondes. 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 manches de fournir des données les plus médiocres, 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é une 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:

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.

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.

Remerciements

Vignette de Henry Be sur Unsplash.