A partir de marzo de 2024, Interaction to Next Paint sustituirá formalmente a First Input Delay como métrica de Core Web Vitals. Descubra en qué se diferencian las dos métricas, por qué necesitábamos una nueva forma de medir la capacidad de respuesta de la interacción y cómo puede empezar a optimizar el rendimiento de su sitio ahora para una transición sin problemas a la última métrica Core Web Vital.
Se avecina un cambio en la línea de Core Web Vitals. Si estás leyendo esto antes de marzo de 2024 y enciendes tu herramienta de monitorización del rendimiento favorita, obtendrás un informe de Core Web Vitals como este extraído de PageSpeed Insights:
Un momento, pero ¿Qué son las Core Web Vitals? Las Métricas web Core Web Vitals son una iniciativa de Google que ofrece orientación sobre los indicadores de calidad, que son esenciales para ofrecer una excelente experiencia del usuario en la Web.
El objetivo de la iniciativa de Métricas web es simplificar el panorama y ayudar a los sitios a enfocarse en las métricas más importantes, las Métricas web esenciales.
Seguimos,
Probablemente estés acostumbrado a ver la mayoría de estas métricas. Pero hay una buena razón para el pequeño icono azul que aparece junto a la segunda métrica de la segunda fila, Interaction to Next Paint (INP). Se trata de la métrica más reciente y está previsto que se convierta oficialmente en un factor de clasificación en los resultados de búsqueda de Google a partir de marzo de 2024.
Y hay una buena razón para que INP se sitúe inmediatamente debajo de First Input Delay (FID) en ese gráfico. El INP sustituirá oficialmente al FID cuando se convierta en una métrica oficial de Core Web Vitals.
El hecho de que la INP ya esté disponible en los informes de resultados significa que tenemos la oportunidad de familiarizarnos con ella hoy, antes de su lanzamiento. De eso trata este artículo. En lugar de aplazar el INP hasta que empiece a influir en la forma en que medimos el rendimiento de los sitios, dediquemos unos minutos a comprender mejor qué es y por qué está diseñado para sustituir al FID. De este modo, no sólo dispondrá de la información necesaria para leer sus informes de rendimiento en marzo de 2024, sino que podrá preparar su sitio web de forma proactiva para el cambio.
Contenido de la página
“No veo esas métricas en mis informes”
Lo más probable es que estés consultando Lighthouse o algún otro informe basado en datos de lab. Y con esto me refiero a datos que no proceden del terreno en forma de usuarios “reales”. Se configura la prueba aplicando algún tipo de simulación y se empiezan a ver los resultados. En otras palabras, los datos no se refieren al tráfico web real, sino a un entorno simulado que ofrece una visión aproximada del tráfico cuando se dan determinadas condiciones.
Digo todo esto porque es importante recordar que no todos los datos de rendimiento son iguales, y algunas métricas son simplemente imposibles de medir con ciertos tipos de datos. El INP y el FID resultan ser un par de métricas en las que los datos simulados no son adecuados para obtener resultados significativos, y eso se debe a que tanto el INP como el FID son mediciones de las interacciones de los usuarios. Puede que el nombre “Retraso en la primera entrada” no lo haya hecho evidente, pero está más claro que el agua cuando empezamos a hablar de “Interacción con la siguiente pintura”: ¡está ahí, en el nombre!
Los datos lab simulados, como los que se utilizan en los informes Lighthouse, no interactúan con la página. Eso significa que no hay forma de evaluar la primera entrada que hace un usuario ni ninguna otra interacción en la página.
Por lo tanto, es por eso que usted no está viendo INP o FID en sus informes. Si desea estas métricas, entonces usted querrá utilizar una herramienta de rendimiento que es capaz de utilizar los datos de usuario real, como DebugBear, que puede controlar su tráfico real de forma continua en tiempo real, o PageSpeed Insights que basa su hallazgo en Google “Chrome User Experience Report” (comúnmente conocido como CrUX). La diferencia entre la monitorización de usuarios en tiempo real y la medición del rendimiento en función de los datos CrUX es muy importante.
La INP mejora la forma de medir las interacciones en las páginas
Bien, ya sabemos que tanto el INP como el FID se refieren a las interacciones de la página. En concreto, se trata de medir el tiempo que transcurre entre que un usuario interactúa con la página y la página responde a esa interacción.
Entonces, ¿cuál es la diferencia entre las dos métricas? La respuesta es doble. En primer lugar, el FID es una medida del tiempo que tarda la página en empezar a procesar una interacción o el retardo de entrada. Eso suena bien a primera vista: queremos saber cuánto tarda un usuario en iniciar una interacción y optimizarla si podemos. Sin embargo, el problema es que la página sólo tarda una parte del tiempo en responder completamente a una interacción.
Una imagen más completa considera el retardo de entrada además de otros dos componentes: el tiempo de procesamiento y el retardo de presentación. En otras palabras, también debemos tener en cuenta el tiempo que se tarda en procesar la interacción y el tiempo que tarda la página en mostrar la interfaz de usuario como respuesta. Como ya habrás adivinado, INP tiene en cuenta los tres retardos, mientras que FID sólo tiene en cuenta el retardo de entrada.
La segunda diferencia entre INP y FID es qué interacciones se evalúan. FID no es tímido sobre qué interacción mide: la primera, como en el retardo de entrada de la primera interacción en la página. Podemos pensar en INP como una representación más completa y precisa de la rapidez con la que la página responde a las interacciones del usuario, ya que analiza todas y cada una de las interacciones de la página. Probablemente es raro que una página sólo tenga una interacción, y las interacciones que haya después de la primera probablemente estén situadas muy abajo en la página y se produzcan después de que ésta se haya cargado completamente.
Así, mientras que la FID examina la primera interacción -y sólo el retardo de entrada de esa interacción-, la INP considera todo el ciclo de vida de todas las interacciones.
Medición de la interacción con la siguiente pintura
Tanto el FID como el INP se miden en milisegundos. No te preocupes demasiado si ves que el tiempo INP es mayor que el FID. Eso suele ocurrir cuando se evalúan todas las interacciones de la página en lugar de sólo la primera interacción.
La orientación de Google es mantener un FID por debajo de 100ms. Y recuerda, el FID no tiene en cuenta el tiempo que tarda el evento en procesarse, ni el tiempo que tarda la página en actualizarse tras el evento. Sólo tiene en cuenta el retraso del proceso del evento.
Y como el INP tiene en cuenta esos tres factores (el retraso de entrada, el tiempo de procesamiento y el retraso de presentación), la guía de Google para medir el INP es intrínsecamente mayor que el FID: menos de 200 ms para un resultado “bueno” y entre 200 y 500 ms para un resultado de aprobado. Cualquier interacción que suponga un retraso superior a 500 ms es un claro cuello de botella.
El objetivo es detectar las interacciones lentas y optimizarlas para que la experiencia del usuario sea más fluida. ¿Cómo se identifican exactamente esos problemas? Eso es lo que vamos a ver a continuación.
Identificación de interacciones lentas
Ya hay muchas cosas que puede hacer ahora mismo para optimizar su sitio para INP antes de que se convierta en un Core Web Vital oficial en marzo de 2024. Recorramos el proceso.
Por supuesto, estamos hablando de que el usuario haga algo en la página, es decir, una acción como un clic o el foco del teclado. Eso podría ser la expansión de un panel en un componente de acordeón o tal vez la activación de un modal o un indicador de cualquier cambio en un estado en el que la interfaz de usuario se actualiza en respuesta.
Tu página puede consistir en poco más que contenido e imágenes, con muy pocas interacciones, si es que hay alguna. También podría ser una especie de interfaz de usuario basada en un juego con miles de interacciones. INP puede dar mucho trabajo, pero todo depende del número de interacciones.
Ya hemos hablado de la diferencia entre los datos de campo y los de laboratorio simulado, y de cómo los datos de laboratorio son incapaces de medir con precisión las interacciones de las páginas. Esto significa que tendrá que basarse en los datos de campo cuando elabore informes INP para identificar cuellos de botella. Y cuando hablamos de datos de campo, nos referimos a dos tipos diferentes:
- Datos del informe CrUX que se basan en los resultados de usuarios reales de Chrome. Estos datos están disponibles en PageSpeed Insights y Google Search Console. Si utilizas cualquiera de las dos herramientas de Google, ten en cuenta que sus métodos de simulación recopilan métricas en una conexión rápida y, a continuación, estiman la velocidad que tendría la página en una conexión más lenta.
- Monitorizar el tráfico en tiempo real de tu sitio web, lo que requerirá añadir un fragmento a tu código fuente que envíe los datos de tráfico a un servicio. Puedes aprovechar los datos históricos de CrUX integrados con BigQuery para obtener una vista histórica de tus resultados que se remonta hasta 2017 con nuevos datos que llegan mensualmente, lo que no es exactamente una monitorización “en tiempo real” de tu tráfico real, pero ciertamente es útil.
Obtendrá el máximo rendimiento de su inversión con una supervisión en tiempo real que mantenga un registro histórico de datos que pueda utilizar para evaluar los resultados del INP a lo largo del tiempo.
Optimización de las interacciones lentas
Este es el objetivo final, ¿verdad? Una vez identificadas las interacciones lentas -ya sea mediante una prueba rápida con datos CrUX o una solución de monitorización en tiempo real-, tenemos que optimizarlas para que sus retrasos sean al menos inferiores a 500 ms, pero idealmente inferiores a 200 ms.
Al final, la optimización de INP se reduce a la actividad de la CPU. Pero como ahora sabemos, INP mide dos componentes adicionales de las interacciones que FID no mide para un total de tres componentes: retardo de entrada, tiempo de procesamiento y retardo de presentación. Cada uno de ellos es una oportunidad para optimizar la interacción, así que vamos a desglosarlos.
Reducir el retardo de entrada
Esto es de lo que se ocupa exclusivamente el FID, y es el tiempo que transcurre entre la entrada del usuario, como un clic, y el inicio de la interacción.
Aquí es donde la métrica del Tiempo Total de Bloqueo (TBT) es buena porque mira la actividad de la CPU que ocurre en el hilo principal, lo que añade tiempo para que la página sea capaz de responder a la interacción de un usuario. El TBT no cuenta para las clasificaciones de búsqueda de Google, pero el FID y el INP sí, y ambos están directamente influidos por el TBT. Por lo tanto, es bastante importante.
Usted querrá auditar qué tareas se están ejecutando en el hilo principal para mejorar su TBT y, como resultado, su INP. Específicamente, querrás vigilar las tareas largas en el hilo principal, que son aquellas que tardan más de 50ms en ejecutarse. Puedes obtener una visualización decente de las tareas en el hilo principal en DevTools:
La función “Timelines” de Safari DevTools registra la carga de la página y produce una línea de tiempo de la actividad que puede desglosarse por peticiones de red, diseño y renderizado, JavaScript y eventos, y CPU. Chrome y Firefox ofrecen las mismas funciones, pero pueden tener un aspecto algo diferente, como suelen hacer los navegadores.
En resumen: Optimiza las tareas largas. Hay muchos enfoques que puedes adoptar en función de tu aplicación. No todas las secuencias de comandos son iguales, en el sentido de que una puede ejecutar una función básica mientras que otra es simplemente un “nice-to-have”. Tendrás que preguntarte:
- ¿A quién sirve el script?
- ¿Cuándo se sirve?
- ¿Desde dónde se sirve?
- ¿Para qué sirve?
Luego, en función de tus respuestas, tienes muchas opciones para optimizar tus tareas largas:
- Utiliza Web Workers para establecer hilos separados para tareas para sacar los scripts del hilo principal.
- Divida los paquetes de JavaScript en piezas individuales para cargas útiles más pequeñas.
- Scripts asíncronos o diferidos que pueden ejecutarse más tarde sin afectar a la carga inicial de la página.
- Preconectar las conexiones de red, para que los navegadores tengan una pista de otros dominios a los que podrían tener que conectarse. (Cabe señalar que esto podría revelar la dirección IP del usuario y entrar en conflicto con el cumplimiento de la GDPR).
O elimine los scripts que ya no necesite.
Reducir el tiempo de procesamiento
Digamos que la entrada del usuario desencadena una tarea pesada, y usted necesita servir un montón de JavaScript en respuesta – lo suficientemente pesado que usted sabe que uno o dos segundos son necesarios para que la aplicación procese completamente la actualización.
- Intenta crear un estado de carga que se active inmediatamente y realiza el trabajo en un callback setTimeout() porque es una forma mucho más rápida de responder a la interacción del usuario que esperar a la actualización completa.
- Si estás trabajando en React, asegúrate de que estás evitando que tus componentes se vuelvan a renderizar innecesariamente.
- Recuerde que alert(), confirm() y prompt() son capaces de aumentar el tiempo total de procesamiento, ya que se ejecutan de forma sincrónica y bloquean el hilo principal. Dicho esto, parece que podría haber planes para cambiar ese comportamiento antes de que INP se convierta en un Core Web Vital formal.
Reducir el retraso en la presentación
Reducir el tiempo que tarda la presentación consiste realmente en reducir el tiempo que tarda el navegador en mostrar las actualizaciones de la interfaz de usuario, pintar los estilos y hacer todos los cálculos necesarios para producir la presentación.
Por supuesto, esto depende totalmente de la complejidad de la página. Dicho esto, hay algunas cosas a tener en cuenta para ayudar a disminuir la brecha entre el momento en que las devoluciones de llamada de una interacción han terminado de ejecutarse y cuando el navegador es capaz de pintar los cambios visuales resultantes.
Una cosa es tener en cuenta el tamaño total del DOM. Cuanto mayor sea el DOM, más HTML habrá que procesar. Al menos eso es cierto en general, aunque la relación entre el tamaño del DOM y la renderización no es exactamente 1:1; el navegador aún tiene que trabajar más para renderizar un DOM más grande en la carga inicial de la página y cuando hay un cambio en la página. Ese enlace te llevará a una explicación en profundidad de lo que contribuye al tamaño del DOM, cómo medirlo y enfoques para reducirlo. Lo esencial, sin embargo, es intentar mantener una estructura plana (es decir, limitar los niveles de elementos anidados). Además, revisar tu CSS en busca de selectores demasiado complejos es otra fruta madura para ayudar a avanzar.
Ya que estamos hablando de CSS, podrías considerar la propiedad de visibilidad del contenido y cómo podría ayudar a reducir el retardo de la presentación. Viene con un montón de consideraciones, pero si se utiliza con eficacia, puede proporcionar el navegador con una pista en cuanto a qué elementos aplazar totalmente la representación. La idea es que podemos renderizar la contención del diseño de un elemento pero saltarnos la pintura hasta que se hayan cargado otros recursos.
Y recuerda, si estás generando HTML desde JavaScript, ese JavaScript tendrá que cargarse para que el HTML se renderice. Ese es un coste potencial que viene con muchos frameworks de aplicaciones de una sola página.
Obtenga información sobre su desglose INP de usuario real
Las herramientas que hemos visto hasta ahora pueden ayudarle a observar interacciones específicas, especialmente cuando las prueba en su propio ordenador. Pero, ¿hasta qué punto se parece eso a lo que experimentan sus visitantes reales?
La monitorización de usuarios reales (RUM) le permite comprobar la capacidad de respuesta de su sitio web en el mundo real:
- ¿Qué páginas tienen el INP más lento?
- ¿Qué componentes de la INP tienen mayor impacto en la vida real?
- ¿Con qué elementos de la página interactúan más a menudo los usuarios?
- ¿Cuál es la velocidad media de interacción de un elemento determinado?
- ¿Es nuestro sitio web menos receptivo para los usuarios de distintos países?
- ¿Nuestras puntuaciones INP mejoran o empeoran con el tiempo?
Conclusión
Cuando Interaction to Next Paint haga su debut oficial como Core Web Vital en marzo de 2024, dispondremos de una forma mejor de medir la capacidad de respuesta de una página a las interacciones del usuario, que sustituirá a la métrica First Input Delay.
En lugar de fijarnos en el retardo de entrada de la primera interacción de la página, obtenemos una evaluación de alta definición del componente con menor capacidad de respuesta de la página -incluidos el retardo de entrada, el tiempo de procesamiento y el retardo de presentación-, tanto si se trata de la primera interacción como de otra situada muy abajo en la página. En otras palabras, INP es una forma más clara y precisa de medir la velocidad de las interacciones de los usuarios.
¿Estará tu aplicación preparada para el cambio en marzo de 2024? Ahora dispone de una hoja de ruta que le ayudará a optimizar sus interacciones con el usuario y a prepararse con antelación. Este es el momento de ponerse manos a la obra; de lo contrario, podría encontrarse con interacciones no identificadas que superen el umbral de 500 ms para una puntuación INP “aceptable”, lo que repercutiría negativamente en su posicionamiento en los motores de búsqueda, dado que merma la experiencia de los usuarios.
