¿Qué es un AnimationFrame y qué puede decirte?

Hoy, voy a hablar sobre animation frames y lo que pueden decirte, y también sobre la API de long animation frame, LOAF, aunque muy amablemente, muchos dicen que es LOAF, ¿verdad? ¿Por qué no? Sí, mi nombre es Vinicius, y soy un ingeniero principal en PlusOne, también construyendo PerfLab y PerfAgent. Y las aplicaciones web modernas necesitan ser responsivas y fluidas, proporcionando a los usuarios una retroalimentación inmediata para sus interacciones. Así que para entender cómo funcionan nuestras aplicaciones, necesitamos entender cómo los navegadores procesan y renderizan contenido. Queremos tratar bien a nuestros usuarios y ofrecer nuevas experiencias emocionantes sin interrupciones ni frustraciones.

Así que construir aplicaciones puede ser muy difícil, y lanzar experiencias que sean fluidas y responsivas puede ser muy complicado. Por eso el equipo de Chrome lanzó INP como una métrica y long animation frames como una API, para ayudarnos a entender mejor y hacer un seguimiento de la experiencia de nuestros usuarios. Hablaremos sobre algunos conceptos básicos de los internos del navegador y las APIs. Así que para ponerte al día sobre cómo funciona el event loop y algunos de esos conceptos, hay un muy buen video de Lydia Haley llamado JavaScript Visualized que explica en gran profundidad, explicándolos de una manera muy accesible. Pero tomemos un poco de tiempo para conocer los conceptos básicos sobre las long tasks y por qué tenemos un presupuesto de 50 milisegundos para las tareas que se ejecutan en el hilo principal.

Hace unos 10 años, en 2015, el equipo Rail popularizó un conjunto de tiempos y nos dio directrices para mantenernos, para ayudarnos y mantener las interacciones del usuario fluidas y responsivas. Así que la ventana de 100 milisegundos que ves en la imagen, representa la cantidad total de tiempo que el navegador tiene para procesar cualquier entrada dada. Pero dado que el procesamiento también involucra la cola del event loop y la entrada y despacho de los event listeners, las tareas tienen un presupuesto de 50 milisegundos para ejecutarse en el nuevo hilo principal para permitir que los navegadores envíen el siguiente frame y ofrezcan una experiencia de 60 frames por segundo. Cualquier tarea que exceda este presupuesto puede incurrir en interrupciones visuales, retrasando las actualizaciones visuales para el usuario.

Para obtener más antecedentes sobre la historia detrás de las métricas de interactividad, puedes consultar otra de mis charlas llamada Long Frames and INP, Understanding the Postload Performance. Así que ahora, volviendo a las long tasks. Aunque el modelo Rail nos introdujo al concepto de una long task, la API de long task tiene un problema importante. Aunque nos permite recopilar long tasks que ocurrieron durante un período de tiempo, su modelo de atribución no nos da una visión adecuada sobre de qué scripts o funciones pueden provenir esas tareas, dándonos no mucho más que la marca de tiempo y la duración del bloqueo. Así que realmente no tenemos una buena manera de entender por qué ocurrieron esas long tasks y de dónde provienen esos cuellos de botella. Así que esta cita está tomada del artículo de Google sobre la Long Animation Frame API, explicando exactamente ese problema de la long task.

Otro punto importante es que si solo consideras las long tasks como una fuente de problemas de interactividad, estás eliminando toda una clase de problemas de rendimiento que tiene que ver con el estilo y el diseño. Así que esos también pueden impedir que el navegador responda a las interacciones y ralentizar la producción de nuevos frames. Así que esta interacción aquí en la imagen, tiene un tiempo de procesamiento largo, pero principalmente proviene de diseños forzados y estilo. Así que esto también puede incurrir en jank visual. Por eso ahora tenemos los animation frames como el modelo base que impulsa INP y los long animation frames. Así que en esta charla, estaremos revisando el concepto sobre cómo el navegador procesa diferentes eventos y cómo esos eventos afectan diferentes partes del animation frame, impactando la experiencia de los usuarios y la puntuación URNP.

Un animation frame representa el ciclo completo que el navegador realiza para procesar eventos y presentar nuevos frames en la pantalla. Este proceso puede incluir trabajos como la cola y el procesamiento de posibles entradas de usuario, la ejecución de código, tareas o micro-tareas, el procesamiento de estilo y diseño, y finalmente, la composición y renderización de un nuevo frame. Así que piensa en un animation frame como una instantánea de todo el trabajo necesario para generar actualizaciones visuales para tus usuarios. El trabajo realizado en un animation frame se utiliza como atribución para las tres partes de la puntuación INP, que son el retraso de entrada, el tiempo de procesamiento y el retraso de presentación. Pero desde la perspectiva de un animation frame, este trabajo puede medirse y clasificarse más granularmente dentro de su modelo de atribución, y veremos más sobre eso más adelante. Los animation frames están presentes en toda la sesión y, aunque se utiliza como modelo base para la atribución hacia INP, no requiere una interacción. Simplemente mide diferentes tipos de trabajo que ocurren antes de que el navegador pueda enviar el siguiente frame, recopilando marcas de tiempo y separándolas en diferentes tipos de trabajo. Debido a eso, puede considerarse como un buen candidato para una abstracción cuando se trata de cómo los navegadores procesan el trabajo y cómo los usuarios perciben su experiencia.

Desde la perspectiva de un animation frame, el trabajo se divide en diferentes categorías. Así que cuando tienes tiempos, esas categorías se dividen en la compilación de scripts, ejecución de scripts, estilos de diseño, trabajo y trabajo de renderizado. Así que cada uno de ellos se agrega en su propia parte del modelo de atribución del animation frame.

Volvamos a esta interacción. No puedes decir inmediatamente por qué estamos gastando tanto tiempo en el trabajo de diseño y por qué estamos gastando tanto de este tiempo de procesamiento en el trabajo de renderizado. Y dado que esa es la causa principal de por qué el tiempo de procesamiento es tan largo, tendríamos que profundizar más en el gráfico de llamas para encontrar la fuente del problema.

Ahora mira esta imagen. Utiliza el poder de las anotaciones del panel de rendimiento para resaltar un animation frame en la sección superior de él.

Y debajo de él, muestra el mismo segmento, pero resaltando las diferentes secciones de trabajo ejecutado en ese animation frame. Primero, puede notar que tenemos múltiples eventos en un solo animation frame. Volveré a eso más adelante. Pero tenga en cuenta que un animation frame y, posteriormente, la métrica IMP y las entradas de long animation frame no están limitadas a un evento por interacción. Así que puedo, de hecho, déjame ver si puedo tener esto. Ahí lo tienes. Así que aquí está el mismo tipo de segmento dentro de la pestaña de rendimiento. Y puedes ver para este rastro en particular, tienes diferentes animation frames aquí, ¿verdad? Así que dentro de eso, podemos verificar, por ejemplo, si desplazo para este animation frame en particular, tengo diferentes tipos de trabajo ejecutados dentro de un animation frame. Y no siempre es solo scripting.

Ahora de vuelta a la presentación. También es importante notar que parte del modelo de atribución puede no estar presente en algún animation frame, como las ranuras de atribución faltantes que tienes en la imagen allí. Eso podría deberse a diferentes limitaciones que actualmente enfrenta la plataforma para inferir con precisión o seguridad la información, como el tiempo de ejecución proveniente de scripts de terceros o extensiones de Chrome. Así que ahora echemos un vistazo a diferentes atributos del modelo de atribución de animation frame, pero cómo está presente en la métrica IMP. Puede que hayas visto uno de estos pequeños dentro de la pista de interacción en el panel de rendimiento, donde a la izquierda y a la derecha los bigotes son los inputs y el retraso de presentación. La barra sólida en el medio es el tiempo de procesamiento.

Comencemos con el primer evento de UI, timestamp. Esto es parte del modelo de atribución dentro de animation frames, proveniente de la Long Animation Frame API. Pero también se conoce como el retraso de input. Este es el timestamp para el primer evento, el primer evento de interacción que se procesa dentro de un animation frame dado. Este timestamp representa la creación del evento de interacción y podría haber ocurrido en cualquier momento dentro del animation frame actual o anterior, dependiendo si hubo un retraso entre el evento siendo creado y el evento siendo procesado. Este atributo proporciona los datos utilizados para calcular el retraso de input para animation frames que están conectados al evento IMP. El tiempo de procesamiento abarca el trabajo en el main thread relacionado con tareas o microtareas que se ejecutan durante el animation frame. Si se inspecciona en el profiler, este grupo de trabajo será representado en el gráfico de llamas por trabajos como la compilación de scripts, diferentes llamadas a funciones y callbacks, ejecución de promesas, funciones de callback de temporizador, y también estilos forzados y layouts.

La última sección de trabajo antes de que el navegador pueda producir un envío en el siguiente frame es el retraso de presentación. Consiste en cualquier trabajo relacionado con el procesamiento de actualizaciones visuales necesarias después de que el main thread ha terminado de ejecutar todas las tareas del animation frame. Este tipo de trabajo se compone de diferentes partes como estilo y layout. Pero el estilo y layout no son el único tipo de trabajo que se procesa en esta etapa. Otras diferentes APIs se ejecutan entre la ejecución de una tarea y el frame siendo presentado en la pantalla. Trabajos como la evaluación de selectores CSS y el cálculo de estilos, callbacks de observadores precisos, promesas de transición de vista, y callbacks de request animation frame. El trabajo ejecutado en esta etapa corre mucho más cerca de las partes del animation frame que involucran presentar un nuevo frame, pero también pueden contribuir a retrasos antes de que el nuevo frame pueda ser presentado, ya que algunas de esas APIs también pueden generar sus propias microtareas, por lo tanto, el trabajo ejecutado en esta etapa también puede llevar a problemas de IMP.

Entonces, ¿por qué deberíamos pensar en términos de animation frames? En 2021, para potenciar la próxima métrica de interactividad y mejorar el modelo de atribución para nuestros datos de campo, el equipo de Chrome comenzó la investigación y desarrollo en torno a una nueva forma estándar de medir el trabajo en torno a las interacciones del usuario. Un año después, IMP se convirtió en una métrica experimental, y en marzo de 2024, reemplazó el first input delay, FID. Junto con INP, también obtuvimos los long animation frames, que es cómo comenzamos a agregar las fases de INP en un nuevo modelo de atribución. Así que, en forma de animation frames, las entradas se expusieron como parte de las performance APIs a través de la long animation frames API, o LOAF.

Similar a la long task, veamos cómo se ve el contraste en este. Bien, creo que es lo suficientemente bueno. Así que, similar a cómo funciona la long task API, la long animation frame API expone entradas de animation frames que están por encima de los umbrales de 50 milisegundos, permitiendo a los desarrolladores centrarse en recopilar datos que podrían señalar cuellos de botella en sus aplicaciones. Así que, usando nuevamente el poder de las anotaciones del performance panel, estoy mostrando aquí un segmento de un trace y cada animation frame contabilizado para ese segmento. Esto muestra cómo podemos conectar mejor el trabajo ejecutado en el main thread con cómo las actualizaciones visuales realmente se envían y producen al usuario, ya que podemos visualizar mejor cómo el navegador procesa el trabajo y produce frames.

Usando tales conceptos, he construido una forma de Instagram dentro de PerfLab para mostrar la distribución de animation frames según estadísticas tomadas de su modelo de atribución, permitiendo cierta exploración sobre cómo exponer rápidamente posibles cuellos de botella dentro de su aplicación en un alcance de sesión completa. Así que, en lugar de centrarse en un punto singular en el tiempo basado en su interacción INP, usted obtiene una mejor comprensión de, o más bien una comprensión holística de cómo su código se ejecuta y qué tipos de diferentes problemas podrían estar ocurriendo durante toda la sesión. Así que, veamos. Tengo que localizar mi rastreador. Bien, ahí lo tienes.

Entonces, volvamos aquí a esta pequeña demo. Así que, desde este pequeño histograma aquí, una forma de histograma, puedo ver cuánto script y layout estoy teniendo ejecutado a lo largo de diferentes secciones de tiempo. Así que, de alguna manera dividí toda la línea de tiempo en diferentes porciones iguales de trabajo y puedo saltar rápidamente a diferentes partes que podrían parecer problemáticas y obtener una mejor comprensión de lo que está sucediendo. Así que, esto no está necesariamente conectado a ninguna métrica en particular. Es solo cómo va mi sesión en general. Así que, puedo ver aquí que tengo un animation frame muy largo ocurriendo aquí y puedo intentar saltar al trace y obtener una mejor comprensión de esto.

Ahora, volvamos aquí. Así que, desde el lado de la API, el equipo detrás de Web Vitals lanzó una actualización recientemente que enriquece el modelo de atribución de INP con buckets. Así que, estos buckets incluyen el tiempo total dedicado a diferentes tipos de trabajo realizado por INP, la interacción INP. Así que, tendrías una mejor comprensión de cuánto tiempo se está dedicando a tu animation frame viniendo directamente de la Web Vitals API. Así que, como hemos establecido hasta ahora, el animation frame puede ocurrir durante toda la sesión y son una gran abstracción que podemos usar para medir y clasificar el trabajo necesario para presentar un frame. Así que, ahora echemos un vistazo a cómo las interacciones pueden influir en los animation frames. Así que, las interacciones de usuario pueden iniciarse en cualquier momento durante un animation frame, teniendo en cuenta que los animation frames son slots que ocurren durante toda la sesión. Así que, si la creación del evento ocurre durante la sección de tiempo de procesamiento de un animation frame, el evento de interacción podría ser encolado y permitido seguir su event handler. Así que, las tareas durante eso...

Así que, no estará dentro del mismo animation frame, lo que representaría el input delay que ves en la imagen aquí. Pero también es importante separar el concepto de interacción y event handlers. Ya que una interacción podría incluir múltiples event handlers, como los eventos de key down, key press, y key up en una sola instancia de pulsación de tecla. Cada uno puede tener sus propias tareas de event handler para ser procesadas. Y en algunos casos, cada evento puede incluso ser procesado en un animation frame diferente, lo que significa que cada event handler podría ser parte del input delay o tiempo de procesamiento desde una perspectiva de animation frame. Es por eso que nuestro evento NP podría incurrir en múltiples entradas de long animation frame. También es importante recordar que cada entrada de long animation frame podría tener múltiples scripts atribuidos a su tiempo de ejecución, ya que el código de la aplicación y del framework puede estar conectado a la misma tarea que se está ejecutando. Las interacciones de usuario son solo una parte de un contexto más amplio cuando se trata de cómo nuestros usuarios perciben su experiencia. Los problemas de rendimiento pueden tener cualquier combinación de factores por los cuales las cosas podrían ser lentas. Pero entender la perspectiva de nuestro usuario, para eso, necesitamos un contexto más amplio. Y eso a menudo se pierde si solo piensas en las piezas individuales.

Es por eso que los animation frames pueden ser un gran candidato para ayudar a crear una discusión más productiva sobre problemas de rendimiento, consolidando todos los diferentes tipos de trabajo en un modelo que mejor representa la percepción de los usuarios, y ayudando a los equipos de desarrollo a obtener más confianza y un mejor flujo de trabajo en torno a sus tareas de rendimiento. Los animation frames también son realmente, realmente buenos, cuando se trata del modelo de atribución, para dárselo a modelos de IA.

Así que esta es la parte de PerfLab. También he creado este pequeño, que es una forma de chat bot, se podría decir, donde puedes extraer. Tengo que echar un vistazo al tamaño de estos chicos. Veamos este. Es un chat bot, en cierto modo, donde puedes ayudar a identificar problemas de rendimiento. Donde PerfLab era más un panel de control per se, este es el subconjunto más pequeño de lo que una herramienta de desarrollo puede parecer. Y está construido sobre los mismos internos de Google Chrome, las herramientas de desarrollador.

Así que extraje eso, y generé la biblioteca estándar que me ayuda a visualizar el trace, y también extraer eso de los traces. Así que todavía tienes INP aquí, y por supuesto tienes animation frames ocurriendo. El mismo tipo de concepto del histograma. Así que me da una distribución de cómo se ven los frames, y destacando diferentes áreas problemáticas. Pero también, puedo preguntar, ¿puedes... Esto es difícil de escribir. ¿Puedes ayudarme a entender mi puntuación INP en este trace? Así que los datos ricos que tienes en los datos de animation frame, datos de atribución, puedes entregárselos a un modelo, a un modelo de lenguaje grande, y ayudarte a entender mejor tus problemas de rendimiento también.

Entonces, basado en los datos que tengo del archivo de trace, usando los mismos internos que Google Chrome utiliza dentro de las herramientas de desarrollo, donde también están interactuando archivos de trace y gráficos de llama, es a través de diferentes modelos para ayudarte a detectar problemas. Es el mismo concepto aquí. Extraigo los mismos internos, y luego genero un informe muy detallado basado en esa interacción que ocurre. Puedes extraer el tiempo específico en que ocurrió, puedes ayudarte a visualizar la interacción, y también visualizar el gráfico de llama, para que puedas entender mejor lo que está sucediendo. Y darte un análisis basado en eso, y ayudarte a entender los problemas que estás enfrentando. Y todo esto está impulsado por los mismos datos del modelo de atribución de animation frame. Así que el rico modelo de atribución que tenemos, realmente, realmente nos ayuda tanto a nosotros, como por supuesto a los dioses de las máquinas para darnos insights.

Así que esta charla está basada en un escrito que tengo. Así que este es el código QR para el escrito que hice el año pasado para el Perf Calendar. Te doy un momento para capturarlo. Y eso es todo por mi parte. Gracias a todos. Así que nuestra primera pregunta. Sí. ¿Qué tipo de herramientas existen para analizar el rendimiento relacionado con tareas en interfaces web? Bueno, una realmente buena que tienes... Así que si estás hablando de APIs, tienes, por supuesto, la Long Animation Frame API. Tendrás los Web Vitals. Así que Web Vitals, los Core Web Vitals, y los Web Vitals Scripts. Realmente te ayuda a recopilar información de tu aplicación desde la perspectiva de Rome, monitoreo real del usuario. Es realmente, realmente importante obtener esos datos reales del usuario. Así que ya sea a través de tus propios scripts, leyendo directamente desde las entradas de rendimiento, tus datos de Long Animation Frame o por los Web Vitals es una buena manera de hacerlo. O capturando traces también. Tenemos las APIs de auto-perfilado, donde puedes capturar traces para hacerlo. Genial. Sí. Parece algo bastante complicado de desglosar. Lo es, sí. De hecho, entonces, ¿cómo... ¿Qué consejo darías a alguien que mira un gráfico de llama como ese por primera vez para intentar averiguar dónde están las cosas mal? Esa es una buena pregunta. Correcto.

Entonces, el equipo de Chrome ha estado en una racha absoluta cuando se trata de ayudar a los desarrolladores de todo tipo de experiencia a entender mejor los traces. Así que dentro del archivo de trace, dentro de la pestaña de rendimiento, tienes la solicitud de IA. Así que puedes seleccionar un frame y puedes tener el panel de IA apareciendo en la consola y puedes preguntar a la IA en los tableros de Chrome diferentes preguntas sobre el trace. Estoy construyendo uno yo mismo. Creo que eso es muy genial. Poder hacer preguntas al respecto es uno de los superpoderes de los modelos de IA y su capacidad para mirar un gran conjunto de JSON y destacar realmente lo interesante... Sí.

El gráfico de llama puede ser muy intimidante al principio. Y lo que para los profesionales en el campo del rendimiento, especialmente, es información. Para muchas personas, es ruido. Y romper esa barrera es difícil. Por eso comencé a crear el agente. Y por eso Google Chrome también está imbuyendo la pestaña de rendimiento con IA. Eso es muy genial.

OK. Tenemos algunas más preguntas que han llegado. Excelente. OK. Esta es una buena. ¿Cómo motivarías a un equipo de desarrollo para trabajar en mejorar el rendimiento y utilizar herramientas como INP? Y voy a seguir llamándolo LOAF. Long animation frame. LOAF. Es una buena manera de llamarlo. Tengo otro artículo en otra masterclass solo sobre eso. Así que es por qué tu trabajo de rendimiento no se ve.

Y yo diría que el TLDR es trabajar con métricas que son importantes para tu producto. Así que las métricas de rendimiento, son el enfoque general. Son cómo, en general, deberías intentar arreglar el rendimiento. Y también tienes umbrales que te ayudarán a entender mejor diferentes partes del rendimiento. O en general, te ayudarán a crear una experiencia más fluida. Pero en última instancia, depende mucho de lo que importa a tu producto. Así que si tienes una página web más estática, INP no es necesariamente el mejor rendimiento para intentar arreglar. Así que considera cómo tu producto... ¿Cuál es la naturaleza de tu producto? ¿Qué métricas importan más? Y ahí es donde empiezas. Iba a decir, es mejor vincularlo a métricas de negocio reales. Exactamente. Correcto, correcto, correcto. Sí. Así que si INP es importante para tu negocio, si las personas que usan e interactúan con tus aplicaciones es importante, eso es lo que importa. Sí. Genial.

OK. Dado tu conocimiento sobre el análisis de rendimiento, si encuentras un problema de rendimiento, uno de esos grandes long animation frames, ¿hay algunos pasos típicos que seguirías para averiguar la causa? Sí. Así que normalmente es simplemente profundizar directamente. Depende del tipo de datos que tengas. Así que si proviene de tu herramienta Rome, algunas herramientas Rome tienen... Si Sentry, uno de los patrocinadores, tienen trazas reales. Así que eso es significativamente útil. Pero si estás más limitado solo a métricas, entonces lo primero sería intentar perfilar primero. Cuando solo tienes métricas, números, te dicen que hay un problema, pero no dónde está el problema. Así que necesitas más datos. Así que eso solo puede venir a través de un archivo de trace. Genial. OK.

Esto podría ser rápido o más fácil. ¿Cómo se ve el soporte entre navegadores para long animation frames? Así que los long animation frames actualmente están disponibles en Chrome. Barry está justo frente a mí. No estoy seguro si es ampliamente compatible todavía. No lo he comprobado para ser honesto contigo. Pensé que Barry podría saber eso, pero está negando con la cabeza que no lo sabe. Lo puse en un aprieto ahí. Pero sí, está disponible en Chrome. Sé que... He leído que Safari también está trabajando en lanzarlo. Así que está ampliamente disponible. Supongo que estar en Chrome significa que también está en Edge. Sí, exactamente. También está en Edge. Así que cualquier navegador Chromium lo tiene. Así que es una porción bastante significativa de usuarios. Genial.

Tenemos una pequeña interludio en tu chatbot agente. Y alguien quisiera saber qué LLM se utiliza para el agente. Gemini. Gemini. Muy bien, ahí lo tienes. Son diferentes agentes. Estoy orquestando con diferentes agentes porque los datos para un archivo de perfil son ricos y muy, muy grandes. Así que hay diferentes expertos, agentes que estoy construyendo. Uno solo para NP, uno solo para LCP. Y luego, a partir de eso, simplemente entrego diferentes porciones de la traza a cada agente especializado. Sí, muy genial. Muy genial. Pero es Gemini.

Es Gemini. Es Gemini de principio a fin. Genial. ¿Probaste algunos para encontrar el adecuado? Sí. Sí, lo hice. Pero quiero decir, como estoy muy profundamente incrustado en el código fuente de DevTools y ellos usan Gemini y pude ver cómo se elaboran las indicaciones, pensé que el entrenamiento de Gemini probablemente también habría leído más sobre las métricas que me interesan. Así que mi indicación del sistema está más adaptada a eso y tratando de enfocar al agente para responder preguntas relacionadas con el rendimiento. Y funcionó muy bien desde el principio.

Genial. Y lo que voy a hacer, una última pregunta más porque estamos quedándonos sin tiempo aquí. Pero creo que esto es interesante. ¿Este marco de long animation frame ayuda a entender problemas de rendimiento en WebGPU así como en la web en general? Ayudaría un poco. Así que el código de WebGPU no se ejecuta en el hilo principal. El WebGPU se ejecuta en su propio hilo separado. Así que te ayudaría a entender cuándo ese código interactuaría con el hilo principal. Y también, si produjo algún tipo de retraso de presentación durante la parte de renderizado, entonces también podrías visualizar los diferentes tiempos. Pero en cuanto a la atribución dentro del animation frame, diría que no tanto. De acuerdo. Sí. Justo. Sí, el hecho de que se esté transfiriendo a otra cosa, tiene sentido. Sí. De acuerdo. Bueno, voy a cortar ahí. Pero quiero que todos den otro agradecimiento a Vinicius. Gracias.

Ahora hay una sección de preguntas y respuestas. Te diriges abajo para responder preguntas y respuestas.