Interaction to Next Paint ha sustituido a First Input Delay como Core Web Vital

Desarrolladores web, el 12 de marzo es la fecha en que Interaction to Next Paint (INP) se convirtió en un Core Web Vital, sustituyendo a First Input Delay (FID). Tanto INP como FID pretenden ayudar a los desarrolladores a tener una medida de la rapidez con la que su sitio responde a la interacción del usuario.

Read this post aloud for me
7:50

Core web vitals from Google with Interaction to next paint circled.

Todas las Core Web Vitals son métricas diferentes que evalúan lo mismo

Las principales variables web evalúan una cosa: ¿su página resulta lenta para los visitantes? Las propias mediciones se centran en los aspectos que Google considera que tienen un mayor impacto en la lentitud percibida.

La puntuación bruta de segundos/milisegundos y de estabilidad visual que obtienes no cambia con el tiempo, sin embargo, como lo que se determina como bueno/malo se basa en un percentil de sitios y esos datos se actualizan con el tiempo, tu puntuación debería empeorar sistemáticamente con el tiempo si no haces nada para seguir actualizando el rendimiento de tu sitio.

Si eso no tiene sentido, piénsalo de esta manera: estás en una carrera con millones de personas, no hay línea de meta, no te cansas y necesitas un descanso. Todos controláis vuestra velocidad relativa con respecto a los demás. Estar entre el 25% de los mejores corredores en cuanto a velocidad es lo que todos consideran bueno. La gente que está muy por detrás empieza a mejorar su velocidad para entrar en ese 25%, muchos lo consiguen, otros sólo logran mejoras marginales. Los que ya están en ese 25% siguen optimizando y ajustando para mejorar las pequeñas cosas que hacen para conseguir un poco más a cada paso que dan. Como todos intentan estar en ese 25%, con el tiempo se hace cada vez más difícil conseguirlo, porque cada vez más gente que antes era lenta ahora acelera, y todos los que eran rápidos siguen haciendo pequeñas mejoras de velocidad. Las mph/kph que se necesitaban para estar en el 25% superior cuando se empezó serán inferiores a las mph/kph necesarias para estar en el 25% superior en cualquier momento posterior.

¿Por qué es una carrera sin final y con objetivos móviles?

El propósito de core web vitals no es sobre usted, no es sobre su sitio, es sobre todos los sitios web en Internet. Sirve para motivar a todo el mundo a crear sitios web que no sean lentos. A medida que los sitios empiezan a parecer menos lentos, desgraciadamente también cambian las expectativas de los usuarios sobre la velocidad a la que deben funcionar. No existe la fórmula mágica de "una vez que mis métricas estén dentro de este umbral, se sentirá rápido para siempre".

¿Qué es Interaction to Next Paint y por qué es mejor que First Input Delay?

Interaction to Next Paint como medida es una mejora sobre First Input Delay porque en lugar de medir sólo la primera interacción, tiene en cuenta todas las interacciones, los manejadores de eventos y el retraso en la presentación del siguiente fotograma. Este es un enfoque más integral para validar que la UI/UX de su sitio se siente consistentemente rápida.

Optimizar para INP es similar pero más holístico que FID.

Ejemplos de cosas que hay que evitar

  • Renderizar grandes trozos de HTML en respuesta a una interacción del usuario. En su lugar, utilizar css para mostrar/ocultar grandes bloques de html en lugar de crear y eliminar elementos cuando sea posible.
  • Actualizar estilos CSS usando JavaScript en respuesta a las interacciones del usuario. (ej: aplicar una clase css es más rápido que aplicar toneladas de estilos individuales usando JavaScript).
  • Omitir los atributos de altura y anchura de las imágenes que aparecen en respuesta a la interacción de un usuario. Si incluyes atributos de anchura y altura el navegador puede realizar los cálculos de diseño más rápido.
  • Hacer muchas devoluciones de llamada de oyentes de eventos. Mantenlo tan simple como sea posible, separa las respuestas críticas y no críticas a la interacción del usuario, puedes usar setTimeout() y opcionalmente requestAnimationFrame() para envolver todo el código no crítico. Para decidir qué es crítico, decide qué cosas tienen que mostrarse al usuario inmediatamente, y qué cosas estaría bien mostrar, calcular o hacer un poco más tarde.

Un arma secreta que requiere algo de práctica

Hay algo que puedes hacer que ayuda a mitigar gran parte de los problemas de rendimiento relacionados con el diseño y el estilo, pero requiere que entiendas lo que estás haciendo.

Me refiero a la propiedad CSS content-visibility. Los valores que puedes proporcionar son auto, style, layout y paint. La mayoría de las veces auto estará bien. El reto, sin embargo, es que su CSS para el elemento en el que está utilizando esto debe:

  • Asegurar que el elemento no necesitará cambiar de tamaño basado en cualquier elemento dentro de él.
  • Los elementos dentro de este elemento padre no deben afectar a los elementos fuera del elemento padre.
  • Los Estilos CSS de los elementos hijos no deben escapar de los límites del elemento padre.

Si lo haces correctamente los hijos del elemento padre pueden ser renderizados perezosamente por el navegador mejorando el rendimiento. Para la gente preocupada por la accesibilidad - esto no tiene ningún impacto en la capacidad de la tecnología de asistencia para ver el contenido. No funciona de la misma manera que la propiedad de visibilidad en CSS.

Aunque la visibilidad del contenido es excelente para el rendimiento general del sitio web, afecta específicamente a INP cuando la página hace visible el HTML en respuesta a la interacción del usuario.

¿Cómo se prueban y diagnostican los problemas de INP?

Utilice la herramienta Page Speed Insights de Google en la web, así como la herramienta de las herramientas para desarrolladores de su navegador, para determinar en primer lugar si su puntuación INP es baja. Si su INP ya es buena, intentar mejorarla puede rayar en la microoptimización y no mejorar mucho.

Interaction to next paint - a range bar showing green (good) orange (needs improvement) and red (bad) ranges for INP, the value in orange is 431 ms

Probar y diagnosticar esto en el laboratorio (un entorno que controlas totalmente) es un poco diferente de diagnosticar otros problemas de rendimiento en los que Google Page Speed Insights, por ejemplo, puede decirte directamente cuáles son los problemas.

Tendrá que identificar cuáles son los flujos de usuario principales de su sitio. Por ejemplo, registrarse para obtener una nueva cuenta, realizar una compra, iniciar sesión. A continuación, pruebe manualmente el uso de la Web Vitals Chrome Extension abriendo su sitio, haga clic derecho en la extensión, elija opciones, a continuación, active la casilla de registro de la consola, y pulse guardar.

Ahora, con la consola abierta, puedes hacer clic en tu página y ver datos que te ayudarán a evaluar la rapidez con la que tu página responde a interacciones específicas. Dicho esto, la herramienta no te da mucho para diagnosticar dónde está la raíz del problema. Para ello, puedes utilizar la herramienta de perfiles de rendimiento de Chrome, pero ten en cuenta que puede resultar un poco difícil obtener información.

¿Cómo debe abordar la solución de INP?

Optimice su sitio de forma iterativa en lugar de hacerlo de una sola vez. Tratar de resolver todos los problemas a la vez hará que sobre-ingeniería, sobre-refactor o simplemente perder el tiempo. INP va a requerir más optimización centrada en JavaScript, ya que la mayor parte de la interacción se maneja con JavaScript, así que concentre su tiempo allí.

Haz pequeños cambios, mide, recoge datos de campo si puedes, repite hasta que estés en verde.

En general, no temas el cambio, sí, es algo nuevo, sí, requiere algunas habilidades técnicas, pero dudo que convertirse en un factor de clasificación de búsqueda se hunda el rango de un sitio de la noche a la mañana. A Google le importa más el contenido que la velocidad de carga. La basura de carga rápida sigue siendo basura, mientras que el contenido de calidad de carga lenta sigue siendo contenido de calidad. También creo que vamos a empezar a ver frameworks de JavaScript haciendo cosas para ayudar a que sea aún más fácil.

¿Quieres aprender más acerca de la optimización de su sitio para la velocidad?

Yo mismo, otros expertos en CMS de HubSpot, y entusiastas del rendimiento de sitios web en HubSpot elaboramos una guía bastante buena sobre la velocidad. Sinceramente, es ideal para cualquier persona, independientemente de si utiliza el CMS de HubSpot - porque el rendimiento del sitio web se evalúa de la misma manera independientemente de la plataforma que utilice. Dicho esto, si utilizas HubSpot encontrarás algunas optimizaciones específicas de HubSpot realmente útiles que también puedes hacer.