La API de Long Animation Frames (Lo-Af se pronuncia LoAF) es una actualización de la API de Long Tasks para proporcionar una mejor comprensión de las actualizaciones lentas de la interfaz de usuario (IU). Esto puede ser útil para identificar fotogramas de animación lentos que probablemente afecten la métrica principal de Métricas web esenciales de Interaction to Next Paint (INP), que mide la capacidad de respuesta, o bien para identificar otros bloqueos de la IU que afectan la suavidad.
Estado de la API
Después de una prueba de origen de Chrome 116 a Chrome 122, la API de LoAF se envió desde Chrome 123.
Segundo plano: La API de Long Tasks
La API de Long Animation Frames es una alternativa a la API de Long Tasks, que ha estado disponible en Chrome desde hace algún tiempo (a partir de Chrome 58). Como su nombre lo sugiere, la API de Long Task te permite supervisar tareas largas, que son tareas que ocupan el subproceso principal durante 50 milisegundos o más. Las tareas largas se pueden supervisar a través de la interfaz PerformanceLongTaskTiming, con un PeformanceObserver:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'longtask', buffered: true });
Es probable que las tareas largas generen problemas de capacidad de respuesta. Si un usuario intenta interactuar con una página (por ejemplo, hace clic en un botón o abre un menú), pero el subproceso principal ya procesa una tarea larga, la interacción del usuario se retrasa a la espera de que se complete esa tarea.
Para mejorar la capacidad de respuesta, a menudo se recomienda dividir las tareas largas. Si cada tarea larga se divide en una serie de varias tareas más pequeñas, puede permitir que se ejecuten tareas más importantes entre ellas para evitar retrasos significativos en la respuesta a las interacciones.
Por lo tanto, cuando se intenta mejorar la capacidad de respuesta, el primer esfuerzo suele ser ejecutar un registro del rendimiento y observar las tareas largas. Esto puede ocurrir mediante una herramienta de auditoría basada en labs, como Lighthouse (que tiene la auditoría para Evitar tareas largas del subproceso principal) o observando tareas largas en Herramientas para desarrolladores de Chrome.
Las pruebas basadas en labs suelen ser un punto de partida deficiente para identificar problemas de capacidad de respuesta, ya que es posible que estas herramientas no incluyan interacciones. Cuando lo hacen, son un pequeño subconjunto de interacciones probables. Lo ideal sería medir las causas de las interacciones lentas en el campo.
Deficiencias de la API de Long Tasks
Medir las tareas extensas en el campo con un Observador de rendimiento solo es algo útil. En realidad, no proporciona tanta información más allá del hecho de que se produjo una tarea larga y del tiempo que tomó.
Las herramientas de supervisión de usuarios reales (RUM) suelen usar esta función para ver la tendencia de la cantidad o la duración de las tareas largas o identificar en qué páginas ocurren, pero sin los detalles subyacentes de lo que causó la tarea larga, esto es solo de uso limitado. La API de Long Tasks solo tiene un modelo de atribución básico que, en el mejor de los casos, solo te indica el contenedor en el que se llevó a cabo la tarea larga (el documento de nivel superior o un <iframe>), pero no la secuencia de comandos o la función que la llamó, como se muestra en una entrada típica:
{
"name": "unknown",
"entryType": "longtask",
"startTime": 31.799999997019768,
"duration": 136,
"attribution": [
{
"name": "unknown",
"entryType": "taskattribution",
"startTime": 0,
"duration": 0,
"containerType": "window",
"containerSrc": "",
"containerId": "",
"containerName": ""
}
]
}
La API de Long Tasks también es una vista incompleta, ya que también puede excluir algunas tareas importantes. Algunas actualizaciones, como la renderización, suceden en tareas separadas que idealmente deben incluirse junto con la ejecución anterior que hizo que esa actualización midiera con precisión el “trabajo total” de esa interacción. Para obtener más detalles sobre las limitaciones de depender de las tareas, consulta la sección de la explicación “En qué casos se necesitan las tareas largas”.
El último problema es que la medición de tareas largas solo informa sobre las tareas individuales que tardan más que el límite de 50 milisegundos. Un fotograma de animación podría estar formado por varias tareas inferiores a este límite de 50 milisegundos y, aun así, bloquear colectivamente la capacidad de procesamiento del navegador.
API de Long Animation Frames
La API de Long Animation Frames (LoAF) es una nueva API que busca abordar algunas de las deficiencias de la API de Long Tasks para permitir que los desarrolladores obtengan estadísticas más prácticas que ayuden a abordar problemas de capacidad de respuesta y mejorar INP.
Una buena capacidad de respuesta significa que una página responde rápidamente a las interacciones realizadas con ella. Eso implica poder pintar las actualizaciones que necesita el usuario de manera oportuna y evitar bloquear estas actualizaciones. Para INP, se recomienda responder en 200 milisegundos o menos, pero para otras actualizaciones (por ejemplo, animaciones), incluso que pueden ser demasiado largas.
La API de Long Animation Frames es un enfoque alternativo para medir el trabajo de bloqueo. En lugar de medir las tareas individuales, la API de Long Animation Frames, como su nombre lo indica, mide los fotogramas de animación largos. Un fotograma de animación largo ocurre cuando una actualización de renderización se retrasa más de 50 milisegundos (al igual que el umbral de la API de Long Tasks).
Los fotogramas de animación largos se pueden observar de manera similar a las tareas largas con un PerformanceObserver, pero, en su lugar, analizan el tipo long-animation-frame:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Los fotogramas de animación largos anteriores también se pueden consultar desde el cronograma de rendimiento de la siguiente manera:
const loafs = performance.getEntriesByType('long-animation-frame');
Sin embargo, hay un maxBufferSize para las entradas de rendimiento después del cual se descartan las entradas más recientes, por lo que se recomienda el enfoque de PerformanceObserver. El tamaño del búfer long-animation-frame se establece en 200, al igual que en long-tasks.
Ventajas de mirar marcos en lugar de tareas
La ventaja clave de observar esto desde la perspectiva de un fotograma en lugar de una de tareas es que una animación larga puede contener cualquier cantidad de tareas que, de manera acumulativa, dan como resultado un fotograma de animación largo. Esto aborda el punto final mencionado anteriormente, en el que es posible que la API de Long Tasks no muestre la suma de muchas tareas más pequeñas que bloquean la renderización antes de un fotograma de animación.
Una ventaja adicional de esta vista alternativa sobre las tareas largas es la capacidad de proporcionar desgloses de tiempo de todo el fotograma. En lugar de solo incluir un startTime y un duration, como la API de Long Tasks, LoAF incluye un desglose mucho más detallado de las diferentes partes de la duración del fotograma, entre las que se incluye lo siguiente:
startTime: Es la hora de inicio del fotograma de animación largo en relación con la hora de inicio de la navegación.duration: Es la duración del fotograma de animación largo (sin incluir el tiempo de presentación).renderStart: Es la hora de inicio del ciclo de renderización, que incluye las devoluciones de llamadarequestAnimationFrame, el cálculo del estilo y el diseño, el cambio de tamaño del observador y las devoluciones de llamada de Intersección observador.styleAndLayoutStart: Es el comienzo del período dedicado a los cálculos de estilo y diseño.firstUIEventTimestamp: Es la hora del primer evento de la IU (mouse/teclado, etc.) que se controlará durante este fotograma.blockingDuration: Es la duración en milisegundos durante el cual se bloqueó el fotograma de animación.
Estas marcas de tiempo permiten que el fotograma de animación largo se divida en tiempos:
| Tiempos | Cálculo |
|---|---|
| Hora de inicio | startTime |
| Hora de finalización | startTime + duration |
| Duración del trabajo | renderStart ? renderStart - startTime : duration |
| Duración del procesamiento | renderStart ? (startTime + duration) - renderStart: 0 |
| Renderización: Duración del diseño previo | styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0 |
| Renderización: Duración del estilo y el diseño | styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0 |
Para obtener más detalles sobre estos tiempos individuales, consulta la explicación, que proporciona información detallada sobre qué actividad contribuye a un fotograma de animación largo.
Mejor atribución
El tipo de entrada long-animation-frame incluye mejores datos de atribución de cada secuencia de comandos que contribuyó a un fotograma de animación largo.
De manera similar a la API de Long Tasks, esto se proporcionará en un array de entradas de atribución, cada una de las cuales detalla lo siguiente:
- Tanto
namecomoEntryTypemostraránscript. - Es un
invokersignificativo que indica cómo se llamó a la secuencia de comandos (por ejemplo,'IMG#id.onload','Window.requestAnimationFrame'o'Response.json.then'). - El
invokerTypedel punto de entrada de la secuencia de comandos:user-callback: Es una devolución de llamada conocida registrada desde una API de plataforma web (por ejemplo,setTimeout,requestAnimationFrame).event-listener: Es un objeto de escucha de un evento de plataforma (por ejemplo,click,load,keyup).resolve-promise: Controlador de una promesa de la plataforma (por ejemplo,fetch(). Ten en cuenta que, en el caso de las promesas, todos los controladores de las mismas se mezclan como una sola “secuencia de comandos”..reject-promise: De acuerdo conresolve-promise, pero para el rechazo.classic-script: Evaluación de la secuencia de comandos (por ejemplo,<script>oimport())module-script: Igual queclassic-script, pero para secuencias de comandos de módulos.
- Separar los datos de tiempo para esa secuencia de comandos:
startTime: Hora en que se invocó la función de entrada.duration: Es la duración entrestartTimey cuando se terminó de procesar la lista de microtareas en cola posterior.executionStart: El tiempo después de la compilación.forcedStyleAndLayoutDuration: Es el tiempo total dedicado al procesamiento de diseño y estilo forzados dentro de esta función (consulta paginación excesiva).pauseDuration: Es el tiempo total dedicado a “pausar” operaciones síncronas (alerta, XHR síncrona).
- Detalles de la fuente de la secuencia de comandos:
sourceURL: Es el nombre del recurso de la secuencia de comandos cuando está disponible (o vacío si no se encuentra).sourceFunctionName: Es el nombre de la función de secuencia de comandos cuando está disponible (o vacío si no se encuentra).sourceCharPosition: Es la posición del carácter de la secuencia de comandos cuando está disponible (o -1 si no se encuentra).
windowAttribution: Es el contenedor (el documento de nivel superior o una<iframe>) en el que se produjo el fotograma de animación larga.window: Es una referencia a la ventana del mismo origen.
Cuando se proporcionan, las entradas de origen permiten a los desarrolladores saber exactamente cómo se llamó a cada secuencia de comandos en el fotograma de animación largo, hasta la posición de los caracteres en la secuencia de comandos de llamada. Esto proporciona la ubicación exacta en un recurso de JavaScript que dio como resultado un fotograma de animación largo.
Ejemplo de una entrada de rendimiento de long-animation-frame
Este es un ejemplo completo de una entrada de rendimiento de long-animation-frame, que contiene una sola secuencia de comandos:
{
"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
}
Como se puede ver, esto proporciona una cantidad de datos sin precedentes para que los sitios web puedan comprender la causa de las actualizaciones de procesamiento retrasadas.
Usa la API de Long Animation Frames en el campo
Las herramientas como las Herramientas para desarrolladores de Chrome y Lighthouse, si bien son útiles para descubrir y reproducir problemas, son herramientas de lab que pueden pasar por alto aspectos importantes de la experiencia del usuario que solo pueden proporcionar los datos de campo.
La API de Long Animation Frames está diseñada para usarse en el campo con el objetivo de recopilar datos contextuales importantes para las interacciones del usuario que la API de Long Tasks no pudo. Esto puede ayudarte a identificar y reproducir problemas con la interactividad que de otro modo no habrías descubierto.
Compatibilidad de la detección de funciones con la API de Long Animation Frames
Puedes usar el siguiente código para probar si se admite la API:
if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
// Monitor LoAFs
}
Vínculo a la interacción de INP más larga
El caso de uso más evidente de la API de Long Animation Frames es ayudar a diagnosticar y corregir problemas de Interaction to Next Paint (INP), y ese fue uno de los principales motivos por los que el equipo de Chrome desarrolló esta API. Un INP correcto es aquel en el que todas las interacciones se responden en 200 milisegundos o menos desde la interacción hasta que se pinta el fotograma. Dado que la API de Long Animation Frames mide todos los fotogramas que tardan 50 ms o más, la mayoría de los INP problemáticos deben incluir datos de LoAF para ayudarte a diagnosticar esas interacciones.
La “LoAF de INP” es la LoAF que incluye la interacción de INP, como se muestra en el siguiente diagrama:
En algunos casos, es posible que un evento INP abarque dos LoAF, por lo general, si la interacción ocurre después de que el fotograma comienza la parte de renderización del fotograma anterior, y de ese modo el controlador de eventos lo procesó en el fotograma siguiente:
Incluso es posible que abarque más de dos LoAF en algunas circunstancias excepcionales.
Registrar los datos de las LoAF asociados con la interacción del INP te permite obtener mucha más información sobre esta interacción para ayudar a diagnosticarla. Esto es muy útil para comprender el retraso de entrada, ya que puedes ver qué otras secuencias de comandos se ejecutaban en ese marco.
También puede ser útil comprender la duración del procesamiento y la demora en la presentación inexplicables si tus controladores de eventos no reproducen los valores que se observan, ya que es posible que se estén ejecutando otras secuencias de comandos para tus usuarios, que podrían no estar incluidas en tus propias pruebas.
No existe una API directa para vincular una entrada de INP con su entrada o entradas de LoAF relacionadas, aunque es posible hacerlo en el código comparando las horas de inicio y finalización de cada una (consulta la secuencia de comandos de ejemplo WhyNp).
La biblioteca web-vitals incluye todos los LoAF con intersección en la propiedad longAnimationFramesEntries de la interfaz de atribución INP de la versión 4.
Una vez que hayas vinculado las entradas de LoAF, puedes incluir información con la atribución INP. El objeto scripts contiene parte de la información más valiosa, ya que puede mostrar qué más se estaba ejecutando en esos fotogramas, por lo que, si envías esos datos a tu servicio de estadísticas, podrás comprender mejor por qué las interacciones fueron lentas.
Informar los LoAF de la interacción del INP es una buena manera de encontrar cuáles son los problemas de interactividad más urgentes en tu página. Cada usuario puede interactuar de manera diferente con tu página y, si hay un volumen suficiente de datos de atribución de INP, se incluirán algunos problemas potenciales en los datos de atribución de INP. Esto te permite ordenar las secuencias de comandos por volumen para ver cuáles se correlacionan con INP lento.
Informa más datos de animaciones largas en un extremo de Analytics
Una de las desventajas de analizar únicamente las LOAF de INP es que es posible que se pasen por alto otras áreas potenciales de mejora que podrían causar problemas futuros de INP. Esto puede llevar a la sensación de perseguir el éxito cuando solucionas un problema de INP y esperas ver una gran mejora, solo que descubres que la siguiente interacción más lenta es solo una pequeña cantidad, por lo que tu INP no mejora mucho.
Por lo tanto, en lugar de destacar solo la LOAF de INP, te recomendamos considerar todas las LoAF a lo largo del ciclo de vida de la página:
Sin embargo, cada entrada de LoAF contiene datos considerables, por lo que es probable que no quieras volver a emitirlo. En su lugar, te conviene restringir tu análisis a algunos LoAF o algunos datos.
Estos son algunos de los patrones sugeridos:
- Cómo observar fotogramas de animación largos con interacciones
- Cómo observar fotogramas de animación más largos que un umbral determinado
- Cómo observar los peores fotogramas de animación largos
- Identificar patrones comunes en fotogramas de animación largos
Cuál de estos patrones funciona mejor para ti depende de qué tan lejos estés en tu recorrido de optimización y qué tan comunes sean los fotogramas de animación largos. En el caso de un sitio que nunca antes se optimizó en cuanto a la capacidad de respuesta, es posible que haya muchas LoAF que podrías limitar a solo LoAF con interacciones, establecer un umbral alto o mirar solo los peores. A medida que resuelves tus problemas comunes de capacidad de respuesta, puedes ampliar esto no limitando solo a las interacciones y disminuyendo los umbrales, o buscando patrones particulares.
Cómo observar fotogramas de animación largos con interacciones
Para obtener estadísticas más allá del fotograma de animación largo de INP, puedes observar todas las LoAF con interacciones (que se pueden detectar por la presencia de un valor firstUIEventTimestamp).
Esto también puede ser un método más sencillo para supervisar los LoAF de INP en lugar de intentar correlacionar ambos, lo que puede ser más complejo. En la mayoría de los casos, esto incluirá el LOAF de INP para una visita determinada y, en casos excepcionales, cuando no lo hace, igualmente se muestran interacciones largas que es importante corregir, ya que pueden ser la interacción de INP con otros usuarios.
El siguiente código registra todas las entradas de LoAF de más de 150 milisegundos en las que ocurrió una interacción durante la trama. Aquí se elige el valor de 150 porque es un poco menor que el umbral de INP “bueno” de 200 milisegundos. Puedes elegir un valor mayor o menor según tus necesidades.
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 });
Cómo observar fotogramas de animación más largos que un umbral determinado
Otra estrategia sería supervisar todos los LoAF y enviar los que superan un cierto umbral de vuelta a un extremo de análisis para su posterior análisis:
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 });
Como las entradas de fotogramas de animación extensas pueden ser bastante grandes, los desarrolladores deben decidir qué datos de la entrada se deben enviar a Analytics. Por ejemplo, los tiempos de resumen de la entrada y tal vez los nombres de las secuencias de comandos, o algún otro conjunto mínimo de otros datos contextuales que puedan considerarse necesarios.
Observar los peores fotogramas de animación largos
En lugar de tener un umbral establecido, es posible que los sitios quieran recopilar datos en el fotograma (o marcos de animación) más largos, para reducir el volumen de datos que deben balizarse. Por lo tanto, independientemente de la cantidad de fotogramas de animación largos que haya experiencias en una página, solo se reenvían los datos del peor, los cinco o la cantidad de fotogramas de animación largos que sean absolutamente necesarios.
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 });
Estas estrategias también se pueden combinar. Observa solo las 10 peores LoAF, con interacciones de más de 150 milisegundos.
En el momento adecuado (idealmente, en el evento visibilitychange), vuelve a las estadísticas. Para realizar pruebas locales, puedes usar console.table de forma periódica:
console.table(longestBlockingLoAFs);
Identificar patrones comunes en fotogramas de animación largos
Una estrategia alternativa sería observar las secuencias de comandos comunes que aparecen más en entradas de marcos de animación largos. Se podrían enviar datos a nivel de la posición de los personajes y del guion para identificar a los infractores reincidentes.
Esto puede funcionar especialmente bien para plataformas personalizables en las que los temas o complementos que causan problemas de rendimiento podrían identificarse en varios sitios.
El tiempo de ejecución de secuencias de comandos comunes (u orígenes de terceros) en largos fotogramas de animación podría resumirse e informarse para identificar los factores más comunes de los largos fotogramas de animación en un sitio o un conjunto de sitios. Por ejemplo, para observar las URLs:
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});
Un ejemplo de este resultado es el siguiente:
(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 |
Usar la API de Long Animation Frames en las herramientas
La API también permite usar herramientas adicionales para desarrolladores para la depuración local. Si bien algunas herramientas, como Lighthouse y las Herramientas para desarrolladores de Chrome, pudieron recopilar gran parte de estos datos usando detalles de seguimiento de nivel inferior, tener esta API de nivel superior podría permitir que otras herramientas accedan a estos datos.
Muestra datos de fotogramas de animación largos en Herramientas para desarrolladores
Puedes mostrar fotogramas de animación largos en Herramientas para desarrolladores con la API de performance.measure(), que luego se muestran en el seguimiento de tiempos del usuario de Herramientas para desarrolladores en los registros de rendimiento para mostrar dónde enfocar tus esfuerzos para mejorar el rendimiento:
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 });
A largo plazo, es probable que se incorpore a Herramientas para desarrolladores, pero el fragmento de código anterior permite que aparezca allí mientras tanto.
Cómo usar datos de fotogramas de animación largos en otras herramientas para desarrolladores
La extensión de Métricas web esenciales mostró el valor en la información de depuración del resumen de registros para diagnosticar problemas de rendimiento.
Ahora también muestra datos de fotogramas de animación extensos para cada devolución de llamada de INP y cada interacción:
Usar datos de fotogramas de animación largos en herramientas de prueba automatizadas
De manera similar, las herramientas de prueba automatizadas en las canalizaciones de CI/CD pueden mostrar detalles sobre posibles problemas de rendimiento midiendo fotogramas de animación largos mientras ejecutan varios paquetes de pruebas.
Preguntas frecuentes
Estas son algunas de las preguntas frecuentes sobre esta API:
¿Por qué no extender o iterar la API de Long Tasks?
Esta es una perspectiva alternativa para informar una medición similar, pero en última instancia diferente, de los posibles problemas de respuesta. Es importante garantizar que sigan funcionando los sitios que dependen de la API de Long Tasks existente para evitar interrumpir los casos de uso existentes.
Si bien la API de Long Tasks puede beneficiarse de algunas de las funciones de LoAF (como un mejor modelo de atribución), creemos que enfocarse en los fotogramas en lugar de las tareas ofrece muchos beneficios que la convierten en una API fundamentalmente diferente a la API existente de Long Tasks.
¿Esta función reemplazará a la API de Long Tasks?
Si bien creemos que la API de Long Animation Frames es mejor y más completa para medir tareas largas, por el momento, no hay planes para dar de baja la API de Long Tasks.
Quiero recibir comentarios
Puedes enviar comentarios en la lista de problemas de GitHub o informar los errores en la implementación de la API por parte de Chrome en la Herramienta de seguimiento de errores de Chrome.
Conclusión
La API de Long Animation Frames es una nueva y emocionante, con muchas ventajas potenciales en comparación con la API de Long Tasks anterior.
De esta forma, está demostrando ser una herramienta clave para abordar los problemas de capacidad de respuesta, según las mediciones del INP. INP es una métrica difícil de optimizar, y esta API es una de las formas en las que el equipo de Chrome busca facilitar a los desarrolladores la identificación y el manejo de problemas.
Sin embargo, el alcance de la API de Long Animation Frames se extiende más allá de INP y puede ayudar a identificar otras causas de actualizaciones lentas que pueden afectar la fluidez general de la experiencia del usuario de un sitio web.