Comprende cómo la nueva métrica de 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 de UX de Chrome. Esta métrica, que ahora conocemos como Interaction to Next Paint (INP), mide la capacidad de respuesta general ante las interacciones del usuario en la página. Hoy queremos compartir estadísticas sobre la posición de los sitios web creados con frameworks de JavaScript modernos en relación con esta métrica. Queremos analizar por qué el INP es relevante para los frameworks y cómo Aurora y los frameworks trabajan para optimizar la capacidad de respuesta.
Contexto
Chrome usa el retraso de la primera entrada (FID) como parte de las Métricas web esenciales (CWV) para medir la capacidad de respuesta de carga de los sitios web. El 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 ni pintar el siguiente fotograma después de que se ejecutan las devoluciones de llamada de eventos. Sin embargo, la capacidad de respuesta es fundamental para la experiencia del usuario durante todo el 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 medida agregada para la latencia percibida de todas las interacciones en el ciclo de vida de la página. Creemos que el INP proporcionará una estimación más precisa de la carga y la capacidad de respuesta del tiempo de ejecución de las páginas web.
Dado que el FID solo mide la demora 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 la CWV. Por lo tanto, los sitios, especialmente aquellos con un alto grado de interactividad, deberán comenzar a trabajar arduamente para obtener buenos resultados en esta métrica.
El rol de los frameworks
Dado 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 que se procesa en el subproceso principal. Los frameworks de JavaScript son una parte esencial del desarrollo web moderno de frontend y proporcionan a los desarrolladores abstracciones valiosas para el enrutamiento, el manejo de eventos y la compartimentación del código de JavaScript. Por lo tanto, tienen un papel central en la optimización de la capacidad de respuesta y la experiencia del usuario de los sitios web que los usan.
Es posible que los frameworks hayan tomado medidas para mejorar la capacidad de respuesta mejorando el FID de los sitios web con anterioridad. Sin embargo, ahora tendrían que analizar los datos de métricas de capacidad de respuesta disponibles y trabajar para abordar las brechas identificadas. En general, la INP tiende a 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 resume el motivo.
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 las Métricas web esenciales. Con la introducción de INP, queremos prepararnos para el cambio en las métricas de CWV para los sitios web basados en frameworks. Recopilamos datos basados en la métrica de capacidad de respuesta experimental en los informes de CrUX. Compartiremos estadísticas y medidas para facilitar la transición a la métrica de INP para los sitios web basados en frameworks.
Datos de la métrica de capacidad de respuesta experimental
Un INP inferior o igual a 200 milisegundos indica una buena capacidad de respuesta. Los datos del informe CrUX y el Informe de tecnología de las Métricas web esenciales de junio de 2023 nos proporcionan la siguiente información sobre la capacidad de respuesta de los frameworks de JavaScript populares.
La tabla muestra el porcentaje de orígenes en cada framework con una buena puntuación de capacidad de respuesta. Las cifras son alentadoras, pero nos indican que hay mucho margen para mejorar.
¿Cómo afecta JavaScript a la INP?
Los valores de 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 período prolongado sería perjudicial para la INP. La ejecución intensiva de JavaScript después de cualquier interacción podría bloquear el subproceso principal durante un período prolongado y retrasar la respuesta a esa interacción. Estas son algunas de las causas comunes que llevan al bloqueo de secuencias de comandos:
JavaScript no optimizado: El código redundante o las estrategias de carga y división de código deficientes pueden hacer que JavaScript se agrande y bloquee el subproceso principal durante largos períodos. La división de código, la carga progresiva y la división de tareas largas pueden mejorar los tiempos de respuesta de forma considerable.
Secuencias de comandos de terceros: Las secuencias de comandos de terceros, que a veces no son necesarias para procesar una interacción (por ejemplo, secuencias de comandos de anuncios), pueden bloquear el subproceso 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 ejecutando una secuencia de comandos diferente, podrían interferir entre sí y acumularse para causar demoras prolongadas. Es posible que algunas de estas tareas no sean esenciales y se puedan programar en 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 el control de eventos. Por ejemplo, Vue usa v-on para adjuntar objetos de escucha de eventos a elementos, mientras que Angular une los controladores de eventos del usuario. La implementación de estas funciones requiere código de framework adicional además de JavaScript vanilla.
Hidratación: Cuando se usa un framework de JavaScript, no es raro que un servidor genere el HTML inicial de una página que, luego, debe complementarse con controladores de eventos y el estado de la aplicación para que pueda ser interactiva en un navegador web. Llamamos a este proceso hidratación. Este puede ser un proceso pesado durante la carga, según el tiempo que tarde JavaScript en cargarse y que finalice la hidratación. También puede hacer que las páginas parezcan interactivas cuando no lo son. A menudo, la hidratación se produce automáticamente durante la carga de la página o de forma diferida (por ejemplo, en la interacción del usuario) y puede afectar la 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 dejen para fotogramas futuros. Teniendo en cuenta esto, las actualizaciones en una transición que generan actualizaciones más urgentes, como los clics, pueden ser un patrón que puede ser bueno para la INP.Precarga: La precarga agresiva de los recursos necesarios para las navegaciones posteriores puede ser una ventaja de rendimiento si se hace correctamente. Sin embargo, si precargas y renderizas rutas de SPA de forma síncrona, puedes afectar negativamente la INP, ya que toda esta renderización costosa intenta completarse en un solo fotograma. Compara esto con no realizar la carga previa de 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 proporciona la UX óptima y cómo (si es que lo hace) esto puede afectar a la INP.
A partir de ahora, para obtener una buena puntuación de INP, los desarrolladores deberán 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, hidratación y carga, así como el tamaño de cada actualización de render() para las secuencias de comandos propias y de terceros.
¿Cómo abordan Aurora y los frameworks los problemas de INP?
Aurora funciona con frameworks mediante la incorporación de prácticas recomendadas para proporcionar soluciones integradas a problemas comunes. Trabajamos con Next.js, Nuxt.js, Gatsby y Angular en soluciones que ofrecen parámetros predeterminados sólidos dentro del framework para optimizar el rendimiento. A continuación, se incluyen los aspectos más destacados de nuestro trabajo en este contexto:
React y Next.js: El componente de secuencia de comandos de Next.js ayuda a abordar los problemas causados por la carga ineficiente de secuencias de comandos de terceros. El fragmento detallado se introdujo en Next.js para permitir fragmentos de tamaño más pequeño 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 asociará con el equipo de Angular para explorar mejoras en la renderización del servidor y la hidratación. También planeamos analizar la posibilidad de definir mejor el control de eventos y la detección de cambios para mejorar la INP.
Vue y Nuxt.js: Estamos explorando vías de colaboración, principalmente en relación con la carga y renderización de secuencias de comandos.
¿Cómo piensan los frameworks mejorar la INP?
React y Next.js
El corte de tiempo de React.js, implementado 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 pequeñas porciones que se pueden interrumpir en cualquier momento.
Esto debería ayudar a mejorar la INP y permitirte responder más rápido a las pulsaciones de teclas, los efectos de desplazamiento durante la transición y los clics. También ayuda a mantener la capacidad de respuesta de las apps de React, incluso para 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 ruta. Esto permite a los propietarios de sitios de Next.js adoptar el corte de tiempo de React y mejorar la capacidad de respuesta de las transiciones de ruta.
Angular
El equipo de Angular está explorando varias ideas que también deberían ayudar con la INP:
- Sin zona: Reduce el tamaño del paquete inicial y el código obligatorio que se debe cargar antes de que una app pueda renderizar contenido.
- Hidratación: Hidratación de estilo de isla para limitar la cantidad de la app que se debe activar para la interacción.
- Reduce la sobrecarga de la CD: Por ejemplo, haz que la detección de cambios sea menos costosa, encuentra formas de verificar menos la app y aprovecha los indicadores reactivos sobre lo que cambió.
- División de código más detallada: Haz que el paquete inicial sea más pequeño.
- Mejor compatibilidad con los indicadores de carga: Por ejemplo, durante la nueva renderizació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 interacción, en particular, el costo de detección de cambios para interacciones específicas.
Gracias a estas mejoras, podemos abordar diferentes problemas que generan una baja capacidad de respuesta y una experiencia del usuario deficiente, y mejorar las métricas de CWV y la nueva métrica de INP para los sitios web basados en frameworks.
Conclusión
Esperamos que la puntuación de INP proporcione un mejor punto de referencia para que los sitios web mejoren la capacidad de respuesta y el rendimiento en el futuro. En 2023, nos basaremos en nuestra guía de INP existente para proporcionar más sugerencias prácticas a los desarrolladores de frameworks. Para lograrlo, esperamos hacer lo siguiente:
- Creación de canales para facilitar el acceso a los datos de campo en INP para frameworks y desarrolladores web.
- Trabaja con frameworks para crear funciones que mejoren la INP de forma predeterminada.
Agradecemos los comentarios de los usuarios del framework cuando comienzan sus recorridos de optimización de INP.