Long Frames y INP – Entendiendo el Rendimiento Post Carga

Hola a todos. Bienvenidos a mi charla sobre long frames e INP, entendiendo el rendimiento posterior a la carga. Mi nombre es Vinicius. Trabajo como líder técnico para Gillian y he trabajado para Volvo, Spotify y Kleiner antes.

He trabajado con rendimiento durante unos seis años y ves algunas similitudes en cada empresa para la que trabajas cuando trabajas en rendimiento durante tanto tiempo. Todos estamos algo familiarizados con al menos alguna forma de depuración de rendimiento y eso puede ser Lighthouse o DevTools. También estamos algo familiarizados con las métricas de rendimiento y a veces con algunas métricas más que con otras. Así que estamos familiarizados con Barbados. Pero la mayoría de las veces cuando hablamos de rendimiento, estamos sesgados hacia el tiempo de carga y ha sido así durante mucho tiempo. Nos enfocamos en ofrecer una buena experiencia de carga y hay una buena razón para eso. Las aplicaciones o sitios web que cargan lentamente y tienen una mala experiencia de carga pueden llevar a la frustración y altas tasas de rebote. Pero olvidar la parte posterior a la carga es algo que también puede suceder y es donde la mayoría de nuestros usuarios pasan la mayor parte de su tiempo.

Y durante mucho tiempo, incluso las métricas de capacidad de respuesta estaban algo vinculadas al tiempo de carga. Entonces, ¿cuánto tiempo tarda la aplicación o la página en ser interactiva? ¿Cuánto tiempo tarda el navegador en responder a la primera entrada del usuario? ¿O cuánto tiempo bloqueó el paso de JavaScript el hilo principal durante el tiempo de carga? Todos esos están muy enfocados en la experiencia de carga. Es por eso que ahora tenemos métricas como INP y NAPI como long animation frame. Y nos ayudan a descifrar y mejorar la interactividad. Pero me estoy adelantando un poco. Para apreciar verdaderamente esas increíbles adiciones a nuestro conjunto de herramientas, necesitamos recibir una pequeña lección de historia sobre cómo llegaron aquí las métricas de rendimiento, por qué evolucionaron de la manera en que lo hicieron y cómo llegamos aquí en este largo viaje. Solo puedes conectar los puntos mirando hacia atrás. Y un poco de contexto puede dar una gran perspectiva sobre las razones por las que los usuarios, por qué usamos las métricas de la manera en que lo hacemos y por qué las técnicas se moldearon de la manera en que lo hicieron hoy en día. Así que echemos un vistazo a esos primeros días y veamos cómo era el panorama. Por qué herramientas como el modelo rail se moldearon de la manera en que lo hicieron y cómo ayudaron a allanar el camino para que llegaran las métricas de interactividad. Todo el camino hasta INP y long animation frames.

Primero, echemos un vistazo al modelo rail. Fue introducido en 2015 y significa respuesta, animación, inactividad y carga. Respuesta siendo capacidad de respuesta, no respuesta HTTP. Es un paso significativo hacia adelante en cómo pensamos sobre la percepción e interacciones de los usuarios. Cada parte del modelo rail viene con un conjunto de recomendaciones. Así que centrémonos en lo que tenemos para respuesta. Así que nuevamente significa capacidad de respuesta y comenzó a hacer más popular un conjunto de tiempos de referencia sobre cómo dividimos el trabajo en el hilo principal y cómo deberíamos pensar y organizar nuestro trabajo de JavaScript en torno a la entrada del usuario y cuánto tiempo deberíamos tardar en responder a la entrada del usuario y por qué.

Así que el modelo rail, de alguna manera dicta esta ventana de 100 milisegundos como la cantidad total de tiempo para procesar una entrada de usuario y enviar el siguiente frame. Pero dado que el procesamiento también implica la cola del bucle de eventos para la entrada del usuario y el despacho de los listeners, las tareas se quedaron con un presupuesto de 50 milisegundos para responder dentro de una ventana de frame que podría servir una experiencia de 60 frames por segundo. Cualquier tarea que exceda ese presupuesto puede incurrir en un salto visual y retrasar la actualización visual, resultando en una interacción de usuario frustrante que nos lleva a los primeros días de las métricas de interactividad.

Aunque esas métricas estaban casi enteramente enfocadas y sesgadas hacia la experiencia de carga, fue un gran punto de partida. Con métricas como FCP, o first contentful paint. Con métricas como FMP, first meaningful paint, y LCP, largest contentful paint, nos ayudó a medir la completitud visual y métricas que gravitaban alrededor de la inactividad del CPU después de los tiempos de carga, como first interactive y first consistently interactive, que luego se nombró como CPU idle, a first CPU idle, perdón, y tiempo hasta interactivo. Pero carecíamos de buenas maneras de medir y entender problemas de rendimiento en torno a las interacciones del usuario. Nuestras primeras métricas para evaluar la interactividad todavía se medían alrededor de eventos que ocurrieron durante o justo después del tiempo de carga de la página. Evaluando cuánto tiempo tomó para que el navegador descargara y pausara los assets y pudiera comenzar a responder a las entradas del usuario.

Métricas como tiempo hasta interactivo o TTI, que intentan evaluar precisamente eso y first input delayed, que evalúa cuánto tiempo, cuánto retraso, perdón, una entrada de usuario incurriría durante ese tiempo. Hubo otra métrica que también surgió alrededor de ese tiempo, después de esas, llamada total blocking time. Y aunque era una métrica de laboratorio y las herramientas de laboratorio principalmente la evaluaban en correlación con el tiempo hasta interactivo, fue un paso en la dirección correcta al intentar crear una métrica en torno al impacto de tareas largas en la capacidad de respuesta de la página. Así que echemos un vistazo más de cerca a cómo se calcularon esas métricas y entendamos algunas de sus deficiencias. Miremos TTI o tiempo hasta interactivo nuevamente. Así que fue concebido primero como first consistently interactive, intenta evaluar cuándo el navegador es capaz de responder a las interacciones de manera confiable.

Creo que el nombre original transmite muy bien el concepto, pero no tiene un acrónimo pegajoso. Así que el gráfico tomado de los Google Docs originales sobre la métrica en el estudio de caso para la métrica, muestra una serie de eventos que el navegador tomaría para poder calcular el time to interactive. Y también podemos usar el gráfico oficial tomado del artículo de web.dev sobre first input delay para ver cómo están conectados el time to interactive y el first input delay.

Entonces, el time to interactive mide hacia atrás el tiempo total que el navegador tomó desde el inicio de la respuesta hasta cuando el navegador tiene una ventana de cinco segundos de ventana tranquila de cinco segundos. Y para evaluar y medir cómo el navegador es capaz de responder de manera confiable a las interacciones del usuario. First input delay mide la primera interacción y evalúa cualquier retraso en el manejo de la entrada. La métrica de first input delay fue un buen comienzo. En un intento de evaluar la interrupción y el jank al servir la primera interacción, te da un número en milisegundos sobre cuánto tiempo se retrasó la respuesta de esa interacción con la métrica de first input delay vino con algunos ojos y la métrica también vino con algunas recomendaciones sobre cómo evitar interacciones lentas. Con eso, también obtuvimos total blocking time como una métrica de laboratorio para ayudarnos a medir el impacto total en tareas largas.

Así que esta métrica no está necesariamente conectada a las interacciones del usuario, sino que mide cuánto trabajo se está realizando en el hilo principal, lo que puede impactar las interacciones del usuario y las actualizaciones visuales que necesitan ocurrir durante ese tiempo. Esta métrica, aunque utilizada por herramientas de laboratorio como Lighthouse para medir el impacto en tareas largas durante el tiempo de carga no es necesariamente una métrica de tiempo de carga, sino que mide una medición de tareas largas bloqueando el hilo principal a lo largo del tiempo. Desde la creación del modelo rail, intentamos entender el impacto de un hilo principal ocupado en la experiencia de nuestros usuarios con acrónimos elegantes y modelos mentales para ayudarnos a dividir el trabajo y comprender mejor el impacto de las tareas largas al intentar mantener una experiencia de usuario receptiva y agradable como resultado clave. Hablando de tareas largas, la API de long task es otro hito importante. Si total blocking time es el tiempo total de bloqueo durante un período de tiempo, la API de long task nos proporciona acceso granular a todas las tareas largas que ocurrieron durante dicho período de tiempo, dándote alguna forma de enumeración y modelo de atribución básico sobre esas entradas. Aunque fue un paso en la dirección correcta, no resolvió nuestros problemas. El modelo de atribución básico nos da más granularidad y algo de información sobre cada tarea larga, pero no nos da una visión adecuada sobre qué script o función podría haber sido atribuida, dándote no mucho más que una marca de tiempo y una duración total de bloqueo. Esta cita en realidad proviene del artículo sobre long animation frames sobre las deficiencias de la API de long task, que es otro punto a otro punto es que si solo consideras las tareas largas 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, que también ocuparán el hilo principal impidiendo que el navegador responda a las interacciones y ralentizando la producción de nuevos frames.

Y así, con ese conocimiento, el equipo de Chrome comenzó a investigar cómo podrían crear una mejor métrica de capacidad de respuesta centrada en el usuario, una que pudiera observar no solo el tiempo de carga, sino también el tiempo posterior a la carga, como parte de la experiencia del usuario. Y también abarca todas las partes que podrían estar causando interacciones lentas. Esta imagen está tomada del artículo hacia una mejor métricas de capacidad de respuesta que precede al anuncio de INP. Y ya puedes ver mucha semejanza en cómo INP como métrica funciona e identificar algunas de sus partes. Puedes ver la sección de retraso de entrada, la sección de tiempo de procesamiento, y el siguiente frame siendo formado como un recuento completo de la duración de la interacción. Esto también se representa en DevTools, al menos hoy en día. En la pista de interacciones en el panel de rendimiento, ves el retraso de entrada y el retraso de presentación como bigotes en cada lado del evento de entrada. Y el tiempo de procesamiento como la barra sólida, representando la totalidad de la duración de la interacción. Así que todas esas tres partes cuentan para la interacción. Y con todos los marcos de llamada dentro de la pila siendo mostrados debajo en la pista del hilo principal, lo que ahora nos lleva de vuelta a INP y long animation frames. Así que comencemos con INP. INP, como un Core Web Vitals, intenta evaluar la capacidad de respuesta general de la página dándote una puntuación basada en la interacción más larga observada. INP, similar a CLS, es una métrica a nivel de sesión.

Y reemplazó first input delay como un Core Web Vital en marzo de 2024. Una advertencia importante es que para no penalizar sitios web y aplicaciones altamente interactivas, la interacción más alta de cada 50ª interacción durante la duración de la sesión será descartada. Así que esto es para evitar fallos aleatorios, tareas largas aleatorias en la duración total de la sesión que se contabilicen para tu interacción con NextPaint. Aquí, tenemos una gran visualización sobre INP proveniente del artículo en web.dev que muestra lo que se considera una interacción y muestra todas las diferentes partes de la interacción a la puntuación de NextPaint como un tiempo. Cada parte de la duración de la interacción puede ser contabilizada como el modelo de atribución para la puntuación de INP. Así que puedes ver el retraso de entrada, puedes ver el tiempo de procesamiento, y el retraso de presentación contabilizando todas las partes de la entrada o la interacción.

Lo que nos lleva a la API de long animation frame. Nos introduce al concepto de un animation frame, que es similar a la métrica INP cambia nuestra percepción de cómo seccionamos porciones de trabajo en el hilo principal. Podemos usar el mismo modelo del artículo de INP para entender qué es un animation frame. Al igual que la métrica INP, pasa de centrarse únicamente en la parte de JavaScript a centrarse en todo el trabajo necesario para enviar un nuevo frame. Desde cualquier retraso en la ejecución causado por una tarea anterior, hasta el tiempo de ejecución de la tarea durante el animation frame, hasta cualquier retraso causado por el estilo y el diseño. Esto nos ayuda a entender mejor cualquier problema que pueda llevar a interacciones lentas o jank. Ya que se centra en cómo el usuario percibe el rendimiento. Conectando actualizaciones visuales y capacidad de respuesta a un único modelo de atribución.

También es importante notar que los long frames, pueden ocurrir en cualquier momento. Ya que la ejecución de scripts proviene de muchas fuentes diferentes y desencadena diferentes efectos secundarios, incluidas actualizaciones visuales sin entrada directa del usuario. Así que los animation frames son realmente útiles para ayudarnos a identificar todo tipo de diferentes problemas conectados a la capacidad de respuesta. Y como modelo, el animation frame nos ayuda a seccionar mejor partes de porciones de trabajo en el hilo principal, teniendo en cuenta todas las cosas que podrían estar retrasando el siguiente frame. Lo que significa que la API de long animation frame y los animation frames como una unidad de trabajo es un modelo de atribución mucho mejor para trabajar. Mejora donde nos proporciona datos mucho, mucho más ricos como un modelo de atribución también. Similar a la API de long task, tenemos una marca de tiempo y una duración. Pero también tenemos un desglose de todos los segmentos del animation frame como una unidad de trabajo. Así que puedes ver que tenemos el tiempo de inicio y la duración. Tenemos el inicio de renderizado y el estilo y el inicio de diseño y la duración de bloqueo también. Junto con cualquier entrada que pueda haber ocurrido durante el animation frame. Con esos datos proporcionados por la entrada del animation frame, podemos seccionar todas las unidades de trabajo que ocurrieron durante ese intervalo o animation frame y entender dónde se gastó más tiempo. Así que tienes el tiempo de inicio y el tiempo de finalización que se pueden calcular fácilmente, pero también la duración total del trabajo, que es el tiempo de ejecución de JavaScript, la duración de renderizado, duración de pre-diseño y duración de estilo y diseño. Así que esto realmente te ayudará a identificar problemas durante ese animation frame de manera muy consistente. También proporciona una mejor atribución cuando se trata de cualquier posible script que podría haber resultado en un tiempo de ejecución prolongado. Dándote tiempos separados por fuente y detalles como qué script y función lo llamó.

Así que puedes ver que tenemos las diferentes secciones sobre quién llamó y datos de tiempo separados fuente para una mejor atribución y también detalles de la fuente.

Aquí hay un ejemplo rápido de cómo se ve el datos de atribución cuando lo juntas todo en una entrada de animation frame. Es importante notar que la entrada de interacción hasta el siguiente paint podría tener más de una entrada de long animation frame. Dado que el modelo de atribución de retraso de entrada también estaría conectado a su propia entrada de long animation frame. También es importante recordar que las entradas de long animation frame podrían tener múltiples scripts atribuidos a su tiempo de ejecución.

Aquí tenemos dos ejemplos de cómo puedes visualizar la interacción hasta el siguiente paint en el entorno. A la izquierda tienes la barra de herramientas de Vercel mostrando una colección de entradas de inp en modo de desarrollo y muestra todas las diferentes partes de cada interacción como un desglose con los tiempos. Así que te ayuda a entender y visualizar durante el tiempo de desarrollo todas las interacciones que podrían haber ocurrido en tiempo real mientras interactúas con la página. Y a la derecha tienes el visor de trazas en una herramienta que estoy creando llamada PerfLab. Puedes ver la entrada de interacción hasta el siguiente paint resaltada en la traza mostrada arriba y junto a ella puedes ver tarjetas de informe con diferentes tiempos para la misma traza. Esta es otra traza visualizada en PerfLab. Y quería mostrar los animation frames que pueden ocurrir en cualquier momento dado. Así que esta entrada de long animation frame no está directamente vinculada a ninguna interacción, por lo tanto, no cuenta para ningún inp. Como esta traza se realizó sobre una traza de tiempo de carga que quería evaluar el impacto de diferentes terceros en la duración total de carga para una sesión de traza. Pero los long animation frames pueden ayudarte a identificar tareas largas y también long frames que ocurren en cualquier momento.

Así que podemos entender mejor el impacto y las diferentes cosas que suceden en cualquier momento. Pero es importante entender que los long animation frames también tienen sus limitaciones. Donde una gran adición como es, no está libre de algunas cosas que es muy importante recordar. Así que aquí podemos ver todos los scripts que ocurrieron durante la línea de tiempo porque esta es una traza que capturé y estoy resaltando la entrada en sí que capturé como un long animation frame o como una entrada de animation frame dentro de la traza que capturé. Pero una cosa importante a recordar, que si estás capturando animation frames o métricas de inp en el entorno sin una traza, es importante recordar algunas cosas. Que la atribución de scripts solo puede provenir de scripts que se ejecutan en el hilo principal de la página. Eso incluye iFrames del mismo origen. Como los long animation frames también pueden ser causados por scripts de terceros ejecutados en tu sitio web o incluso extensiones de Chrome, puede impactar tu atribución de animation frame y atribución de inp al tener un tiempo de ejecución más largo pero una atribución de script faltante.

También hay un problema al momento de escribir esta presentación al menos, donde los scripts sin información de origen como callbacks de manejadores de eventos y scripts en línea también carecerán de datos de atribución dentro del modelo de atribución, al menos por el momento. Así que aquí puedes visualizar todo en la traza porque es una traza capturada y las entradas de animation frame se contabilizan junto con todos los call frames. Pero al capturarlo por separado en el entorno es importante recordar. Hemos llegado tan lejos desde los primeros días de herramientas de rendimiento y métricas y ahora tenemos herramientas tan increíbles a nuestra disposición para ayudarnos a entender mejor y mejorar las experiencias en la web. Es un viaje realmente increíble con INP y long animation frame como las últimas incorporaciones al conjunto de herramientas y finalmente podemos tener una mejor comprensión de las interacciones de los usuarios y ofrecer mejores experiencias post-carga a nuestros usuarios. Muchas gracias.