Comprende cómo la nueva métrica del INP afecta la experiencia de los sitios creados con bibliotecas y frameworks de JavaScript.
Recientemente, Chrome presentó una nueva métrica de capacidad de respuesta experimental en el informe Informe de UX de Chrome. Esta métrica, que ahora conocemos como Interacción a la siguiente pintura (INP), mide la capacidad de respuesta general a las interacciones del usuario en la página. Hoy queremos compartir estadísticas sobre la ubicación de los sitios web creados con frameworks modernos de JavaScript en relación con esta métrica. Queremos analizar por qué el INP es relevante para los frameworks y cómo Aurora y los marcos están trabajando 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 la 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 la ejecución de las devoluciones de llamada del evento. Sin embargo, la capacidad de respuesta es fundamental para la experiencia del usuario a lo largo del ciclo de vida de la página, ya que los usuarios pasan alrededor del 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 esta comienza la interacción hasta que se pinta el siguiente fotograma en la pantalla. Con el 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 INP proporcionará una estimación más precisa de la carga de las páginas web y la capacidad de respuesta del tiempo de ejecución.
Dado que FID solo mide el retraso de entrada de la primera interacción, es probable que los desarrolladores web no hayan optimizado proactivamente las interacciones posteriores como parte de su proceso de mejora de Métricas web esenciales. Por lo tanto, los sitios, especialmente aquellos con un alto grado de interactividad, tendrán que empezar a trabajar arduamente para lograr un buen rendimiento en 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á afectada principalmente por la cantidad de JavaScript procesado en el subproceso principal. Los marcos de trabajo de JavaScript son una parte esencial del desarrollo web de frontend moderno y proporcionan a los desarrolladores abstracciones valiosas para el enrutamiento, el manejo de eventos y la compartimentación del código JavaScript. Por lo tanto, desempeñan un papel central 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 mejorar la capacidad de respuesta a través de la mejora anticipada de FID para los sitios web. Sin embargo, ahora tendrían que analizar los datos de las métricas de capacidad de respuesta disponibles y trabajar para abordar las brechas que se identificaron. En general, el INP tiende a tener porcentajes de aprobación más bajos 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 Métricas web esenciales. Con la introducción del INP, queremos estar preparados para el cambio en las métricas de Métricas web esenciales para los sitios web basados en marcos. Recopilamos datos en función de la métrica de capacidad de respuesta experimental de los informes de CrUX. Compartiremos estadísticas y elementos de acción para facilitar la transición a la métrica de INP para sitios web basados en marcos de trabajo.
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 de CrUX y el Informe de tecnología de CWV de junio de 2023 brindan la siguiente información sobre la capacidad de respuesta de los frameworks populares de JavaScript.
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 dicen que podemos mejorar.
¿Cómo afecta JavaScript a 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 largo período sería malo para INP. Una 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. A continuación, se indican algunas de las causas comunes que provocan el bloqueo de secuencias de comandos:
JavaScript no optimizado: El código redundante o las estrategias deficientes de división y carga de código pueden provocar un sobredimensionamiento de JavaScript y bloquear el subproceso principal durante períodos prolongados. La división de código, la carga progresiva y la división de las tareas largas pueden mejorar considerablemente los tiempos de respuesta.
Secuencias de comandos de terceros: Las secuencias de comandos de terceros, que a veces no son necesarias para procesar una interacción (por ejemplo, las 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.
Múltiples controladores de eventos: Varios controladores de eventos asociados con cada interacción, cada uno de los cuales ejecuta una secuencia de comandos diferente, pueden interferir unos con otros y generar retrasos largos. Algunas de estas tareas pueden no ser esenciales y se podrían programar en un trabajador web o cuando el navegador esté inactivo.
Sobrecarga de 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 los elementos, mientras que Angular une los controladores de eventos de usuario. La implementación de estas funciones requiere un código de framework adicional superior al código normal de JavaScript.
Hidratación: cuando se usa un framework de JavaScript, es común que un servidor genere el código HTML inicial para una página, que luego necesita aumentarse con controladores de eventos y el estado 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 cargarse y la hidratación en completarse. 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, durante la interacción del 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 la parte de la renderización de un componente esté en el siguiente fotograma y cualquier efecto secundario más costoso que se aplique a los fotogramas futuros. Por lo tanto, las actualizaciones en una transición que generan actualizaciones más urgentes, como los clics, pueden ser un patrón útil para el INP.Carga previa: La carga previa agresiva de los recursos necesarios para navegaciones posteriores puede mejorar el rendimiento cuando se hace bien. Sin embargo, si realizas una carga previa y procesas rutas SPA de forma síncrona, puedes terminar teniendo un impacto negativo en el INP ya que toda esta renderización costosa intenta completarse en un solo fotograma. Compara esto con no realizar una 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 esto podría afectar (si es posible) el INP.
De ahora en adelante, para obtener una buena puntuación de INP, los desarrolladores se deberán enfocar en revisar el código que se ejecuta después de cada interacción en la página y optimizar las 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 abordando Aurora y los frameworks los problemas del INP?
Aurora trabaja 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 configuraciones predeterminadas sólidas dentro del marco de trabajo 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 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 detallada se introdujo en Next.js para permitir 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 de hidratación y renderización del servidor. También planeamos buscar refinamientos en el manejo de eventos y la detección de cambios para mejorar el INP.
Vue y Nuxt.js: Estamos explorando vías de colaboración, principalmente en relación con la carga y el procesamiento de secuencias de comandos.
¿Cómo están pensando los frameworks en mejorar el INP?
React y Next.js
La segmentación de tiempo de React.js, implementada mediante 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 porciones pequeñas que se pueden interrumpir en cualquier momento.
Esto ayudará a mejorar el INP y te permitirá responder más rápidamente 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 rutas. Esto permite a los propietarios del sitio de Next.js adoptar la segmentación 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 INP:
- Sin zonas: Reduce el tamaño inicial del paquete y el código obligatorio que se debe cargar para que una app pueda renderizar lo que sea.
- Hidratación: Hidratación isleña para limitar cuánto se debe despertar la app 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 datos de la app y aprovecha los indicadores reactivos sobre los cambios.
- División de código más detallada: Reduce el tamaño del paquete inicial.
- 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 generación de perfiles: Son mejores herramientas de desarrollo para comprender el costo de interacción, particularmente en torno al costo de detección de cambios en interacciones específicas.
A través de estas mejoras, podemos abordar diferentes problemas que afectan la capacidad de respuesta y la experiencia del usuario, además de impulsar las métricas de Métricas web esenciales y la nueva métrica de INP para sitios web basados en marcos de trabajo.
Conclusión
Esperamos que la puntuación de INP proporcione una mejor guía para que los sitios web mejoren la capacidad de respuesta y el rendimiento en el futuro. Nos basaremos en nuestra guía de INP existente para brindar más sugerencias prácticas a los desarrolladores de frameworks en 2023. Para lograrlo, esperamos lo siguiente:
- Creación de canales para un fácil acceso a datos de campo en INP para frameworks y desarrolladores web.
- Trabaja con frameworks para compilar funciones que mejorarán INP de forma predeterminada.
Agradecemos los comentarios de los usuarios del framework cuando inicien sus recorridos de optimización de INP.