Comprende cómo la nueva métrica INP afecta la experiencia de los sitios creados con frameworks y bibliotecas de JavaScript.
Recientemente, Chrome presentó una nueva métrica experimental de capacidad de respuesta en el informe Chrome UX Report. Esta métrica, que ahora conocemos como Interaction to Next Paint (INP), mide la capacidad de respuesta general a las interacciones del usuario en la página. Hoy queremos compartir estadísticas sobre dónde se encuentran los sitios web creados con frameworks modernos de JavaScript en relación con esta métrica. Queremos analizar por qué INP es relevante para los frameworks y cómo funcionan Aurora y los frameworks para optimizar la capacidad de respuesta.
Información general
Chrome usa el retraso de primera entrada (FID) como parte de las Métricas web esenciales (CWV) para medir la capacidad de respuesta de carga de los sitios web. FID mide el tiempo de espera desde la primera interacción del usuario hasta el momento en que el navegador puede procesar los controladores de eventos conectados a la interacción. No incluye el tiempo para procesar los controladores de eventos, procesar interacciones posteriores en la misma página o pintar el siguiente fotograma después de que se ejecutan las devoluciones de llamada de eventos. Sin embargo, la capacidad de respuesta es crucial para la experiencia del usuario a lo largo del ciclo de vida de la página, ya que los usuarios pasan aproximadamente el 90% del tiempo en una página después de que se carga.
INP mide el tiempo que tarda una página web en responder a las interacciones del usuario desde que este inicia la interacción hasta el momento en que se pinta el siguiente fotograma en la pantalla. Con INP, esperamos habilitar una medición agregada de la latencia percibida en todas las interacciones en el ciclo de vida de la página. Creemos que INP proporcionará un cálculo más preciso de la cantidad de páginas web y la capacidad de respuesta del entorno de ejecución.
Dado que FID mide solo el retraso de entrada de la primera interacción, es probable que los desarrolladores web no hayan optimizado de forma proactiva las interacciones posteriores como parte de su proceso de mejora de CWV. Por lo tanto, los sitios, en especial aquellos con un alto grado de interactividad, tendrían que empezar a trabajar duro para tener un buen rendimiento con esta métrica.
El rol de los frameworks
Debido a que muchos sitios web dependen de JavaScript para proporcionar interactividad, la puntuación de INP se vería afectada principalmente por la cantidad de JavaScript procesado en el subproceso principal. Los frameworks de JavaScript son una parte esencial del desarrollo web moderno de frontend y les proporcionan a los desarrolladores abstracciones valiosas para el enrutamiento, el control de eventos y la compartimentación del código JavaScript. Por lo tanto, desempeñan un papel fundamental en la optimización de la capacidad de respuesta y la experiencia del usuario de los sitios web que los utilizan.
Es posible que los frameworks hayan tomado medidas para lograr una mejor capacidad de respuesta, ya que mejoraron el FID de los sitios web de forma anticipada. Sin embargo, ahora tendrían que analizar los datos disponibles de la métrica de capacidad de respuesta y trabajar para abordar las brechas identificadas. En general, el INP suele tener tasas de aprobación más bajas, y la diferencia en el proceso de medición requiere una optimización adicional del código. En la siguiente tabla, se resumen los motivos.
El equipo de Aurora en Chrome trabaja con frameworks web de código abierto para ayudar a los desarrolladores a mejorar diferentes aspectos de la experiencia del usuario, incluidos el rendimiento y las métricas de CWV. Con la introducción de INP, queremos estar preparados para el cambio en las métricas de CWV en los sitios web basados en frameworks. Recopilamos datos en función de la métrica experimental de capacidad de respuesta en los informes de CrUX. Compartiremos estadísticas y elementos de acción para facilitar la transición a la métrica INP para los sitios web basados en marcos de trabajo.
Datos de métricas de capacidad de respuesta experimental
Un INP inferior o igual a 200 milisegundos indica una buena capacidad de respuesta. Los datos del informe de CrUX y el CWV Technology Report de junio de 2023 nos proporcionan la siguiente información sobre la capacidad de respuesta de los frameworks populares de JavaScript.
En la tabla, se muestra el porcentaje de orígenes en cada framework con una buena puntuación de capacidad de respuesta. Las cifras son alentadoras, pero nos dicen que hay mucho que mejorar.
¿Cómo afecta JavaScript al INP?
Los valores del INP en el campo se correlacionan bien con el tiempo de bloqueo total (TBT) observado en el lab. Esto podría implicar que cualquier secuencia de comandos que bloquee el subproceso principal durante un largo tiempo sería malo para INP. La ejecución intensa de JavaScript después de cualquier interacción podría bloquear el subproceso principal por un período prolongado y retrasar la respuesta a esa interacción. Algunas de las causas comunes que provocan el bloqueo de las secuencias de comandos son las siguientes:
JavaScript no optimizado: El código redundante o las estrategias de carga y división de código deficientes pueden causar sobredimensionamiento de JavaScript y bloquear el subproceso principal durante períodos prolongados. La división de código, la carga progresiva y la separación de tareas largas pueden mejorar considerablemente los tiempos de respuesta.
Secuencias de comandos de terceros: Las secuencias de comandos de terceros, que a veces no se requieren para procesar una interacción (por ejemplo, secuencias de comandos de anuncios), pueden bloquear la conversación principal y causar demoras innecesarias. Priorizar las secuencias de comandos esenciales puede ayudar a reducir el impacto negativo de las secuencias de comandos de terceros.
Varios controladores de eventos: Varios controladores de eventos asociados con cada interacción, cada uno de los cuales ejecuta una secuencia de comandos diferente, podrían interferir entre sí y sumarse para causar demoras prolongadas. Es posible que algunas de estas tareas no sean esenciales y se puedan programar para que lo haga un trabajador web o cuando el navegador esté inactivo.
Sobrecarga del framework en el control de eventos: Los frameworks pueden tener funciones o sintaxis adicionales para controlar los eventos. Por ejemplo, Vue usa v-on para adjuntar objetos de escucha de eventos a los elementos, mientras que Angular une los controladores de eventos del usuario. La implementación de estas funciones requiere código de framework adicional por encima de JavaScript convencional.
Hidratación: Cuando se usa un framework de JavaScript, es común que un servidor genere el HTML inicial de una página, que luego necesita aumentarse con controladores de eventos y estados de la aplicación para que pueda ser interactivo en un navegador web. A este proceso lo llamamos hidratación. Este puede ser un proceso pesado durante la carga, según el tiempo que demore JavaScript en cargar y de que se complete la hidratación. También puede llevar a que las páginas parezcan interactivas cuando no lo son. A menudo, la hidratación ocurre automáticamente durante la carga de la página o de forma diferida (por ejemplo, cuando se interactúa con el usuario) y puede afectar el INP o el tiempo de procesamiento debido a la programación de tareas. En bibliotecas como React, puedes aprovechar
useTransitionpara que parte de la renderización de un componente esté en el siguiente fotograma y los efectos secundarios más costosos se dejan para los fotogramas futuros. Debido a esto, las actualizaciones en una transición que producen actualizaciones más urgentes, como los clics, pueden ser un patrón que puede ser bueno para el INP.Carga previa: La carga previa agresiva de los recursos necesarios para navegaciones posteriores puede ser una ventaja de rendimiento si se hace correctamente. Sin embargo, si cargas previamente y renderizas rutas SPA de forma síncrona, puedes terminar afectando negativamente al INP, ya que toda esta costosa renderización intenta completarse en un solo fotograma. Compara esto con no cargar previamente tu ruta y, en su lugar, iniciar el trabajo necesario (por ejemplo,
fetch()) y desbloquear la pintura. Te recomendamos que vuelvas a examinar si el enfoque de tu framework para la carga previa genera una UX óptima y cómo (si corresponde) esto puede afectar al INP.
A partir de ahora, para obtener una buena puntuación de INP, los desarrolladores tendrán que enfocarse en revisar el código que se ejecuta después de cada interacción en la página y optimizar sus estrategias de fragmentación, rehidratación, carga y el tamaño de cada actualización de render() para secuencias de comandos propias y de terceros.
¿Cómo están Aurora y los frameworks abordan los problemas de INP?
Aurora trabaja con frameworks e incorpora prácticas recomendadas para brindar soluciones integradas a los problemas comunes. Trabajamos con Next.js, Nuxt.js, Gatsby y Angular en soluciones que ofrecen valores predeterminados sólidos dentro del framework para optimizar el rendimiento. A continuación, se muestran los aspectos más destacados de nuestro trabajo en este contexto:
React y Next.js: El componente de la secuencia de comandos de Next.js ayuda a abordar los problemas causados por la carga ineficiente de secuencias de comandos de terceros. La fragmentación granular se introdujo en Next.js para permitir los bloques más pequeños para el código compartido. Esto ayuda a reducir la cantidad de código común sin usar que se descarga en todas las páginas. También estamos trabajando con Next.js para que los datos de INP estén disponibles como parte de su servicio de Analytics.
Angular: Aurora se asocia con el equipo de Angular para explorar las mejoras en la renderización y la hidratación del servidor. También planeamos investigar mejoras en el manejo de eventos y la detección de cambios para mejorar la INP.
Vue y Nuxt.js: Estamos explorando métodos de colaboración, principalmente en relación con la carga y el procesamiento de las secuencias de comandos.
¿Cómo piensan los frameworks sobre mejorar el INP?
React y Next.js
La segmentación de tiempo de React.js, implementada a través de startTransition y Suspense, te permite habilitar la hidratación selectiva o progresiva. Esto significa que la hidratación no es un bloque síncrono. Se realiza en secciones pequeñas que se pueden interrumpir en cualquier momento.
Esto debería ayudar a mejorar el INP y permitirte responder más rápidamente a las pulsaciones de teclas, los efectos de colocar el cursor sobre el cursor durante la transición y los clics. También ayuda a que las apps de React sean responsivas, incluso en transiciones grandes, como la función de autocompletar.
Next.js implementó un nuevo framework de enrutamiento que usa startTransition de forma predeterminada para las transiciones de rutas. Esto permite a los propietarios de sitios de Next.js adoptar la fragmentación de tiempo de React y mejorar la capacidad de respuesta de las transiciones de rutas.
Angular
El equipo de Angular está explorando varias ideas que también deberían ayudar con INP:
- Sin zona: Reduce el tamaño inicial del paquete y el código obligatorio que se debe cargar para que una app pueda renderizar algo.
- Hidratación: Hidratación al estilo de una isla para limitar la cantidad de actividad de la app que se debe activar para interactuar.
- Reduce la sobrecarga de la CD: Por ejemplo, haz que la detección de cambios sea menos costosa, busca maneras de verificar menos aspectos de la app y aprovecha las señales reactivas sobre los cambios.
- División de código más detallada: Haz que el paquete inicial sea más pequeño.
- Mejor compatibilidad con indicadores de carga: Por ejemplo, durante la rerenderización de SSR, durante la navegación de ruta y en las operaciones de carga diferida.
- Herramientas de creación de perfiles: Son mejores herramientas de desarrollo para comprender el costo de las interacciones, en particular en lo que respecta a la detección de cambios en interacciones específicas.
A través de estas mejoras, podemos abordar diferentes problemas que conducen a una respuesta y experiencia del usuario deficientes, y también impulsar las métricas de CWV y la nueva métrica INP para los sitios web basados en frameworks.
Conclusión
Esperamos que la puntuación de INP proporcione una mejor brújula para que los sitios web mejoren la capacidad de respuesta y el rendimiento en el futuro. Aprovecharemos nuestra guía de INP existente para brindar más sugerencias prácticas a los desarrolladores de frameworks en 2023. Esperamos conseguirlo de las siguientes maneras:
- Creación de canales para facilitar el acceso a datos de campo sobre INP para frameworks y desarrolladores web.
- Trabaja con frameworks para crear funciones que mejoren el INP de forma predeterminada.
Apreciamos los comentarios de los usuarios del framework cuando comienzan sus recorridos de optimización de INP.