Lighthouse de Google no utiliza la métrica de Interacción con la siguiente pintura (INP) en sus pruebas estándar, a pesar de que INP es uno de los Core Web Vitals.
Barry Pollard, defensor de los desarrolladores de rendimiento web en Google Chrome, explicó el razonamiento detrás de esto y ofreció información sobre cómo medir el INP.
Lighthouse mide las cargas de páginas, no las interacciones
Lighthouse mide la carga de una página simple y captura varias características durante ese proceso.
Puede estimar la pintura con contenido más grande (LCP) y el cambio de diseño acumulativo (CLS) en condiciones de carga específicas, identificar problemas y asesorar sobre cómo mejorar estas métricas.
Sin embargo, INP es diferente ya que depende de las interacciones del usuario.
Pollard explicó:
“El problema es que Lighthouse, como muchas herramientas de rendimiento web, normalmente simplemente carga la página y no interactúa con ella. Sin interacciones = ¡No hay INP que medir!”
Los flujos de usuario personalizados permiten la medición de INP
Si bien Lighthouse no puede medir el INP, conocer los recorridos comunes de los usuarios le permite utilizar «flujos de usuarios» para medir el INP.
Pollard añadió:
«Si usted, como propietario de un sitio, conoce los recorridos habituales de los usuarios, puede medirlos en Lighthouse utilizando ‘flujos de usuarios’ que luego medirán el INP».
Estos recorridos comunes de los usuarios se pueden automatizar en un entorno de integración continua, lo que permite a los desarrolladores probar INP en cada confirmación y detectar posibles regresiones.
Tiempo total de bloqueo como proxy INP
Aunque Lighthouse no puede medir INP sin interacciones, puede medir causas probables, particularmente tareas largas de bloqueo de JavaScript.
Aquí es donde entra en juego la métrica del Tiempo total de bloqueo (TBT).
Según Pollard:
“TBT (Tiempo total de bloqueo) mide el tiempo total de todas las tareas superiores a 50 ms. La teoría es:
- Muchas tareas largas y bloqueantes = ¡alto riesgo de INP!
- Pocas tareas largas y bloqueantes = ¡bajo riesgo de INP!”
Limitaciones del TBT como sustituto del INP
El TBT tiene limitaciones como sustituto del INP.
Pollard señaló:
“Si no interactúa durante tareas largas, es posible que no tenga ningún problema de INP. Además, las interacciones pueden cargar MÁS JavaScript que Lighthouse no mide”.
Él agrega:
«Así que es una pista, pero no un sustituto de la medición real del INP».
Optimización de las puntuaciones de Lighthouse frente a la experiencia del usuario
Algunos desarrolladores optimizan las puntuaciones de Lighthouse sin considerar el impacto en el usuario.
Pollard advierte contra esto y afirma:
“Un patrón común que veo es retrasar TODOS los JS hasta que el usuario interactúe con una página: ¡excelente para las puntuaciones de Lighthouse! A menudo terrible para los usuarios 😢:
- A veces nada se carga hasta que mueves el mouse.
- A menudo, tu primera interacción sufre un retraso mayor”.
Publicación completa de Pollard
Por qué esto importa
Es necesario comprender las relaciones de Lighthouse, INP y TBT para optimizar la experiencia del usuario.
Reconocer las limitaciones en la medición del INP ayuda a evitar optimizaciones equivocadas.
El consejo de Pollard para medir INP es centrarse en las interacciones reales del usuario para garantizar que las mejoras en el rendimiento mejoren la UX.
Dado que INP sigue siendo un Core Web Vital, comprender sus matices es esencial para mantenerlo dentro de un umbral aceptable.
Aplicaciones prácticas
Para monitorear el rendimiento del sitio y el INP:
- Utilice los “flujos de usuarios” de Lighthouse para medir el INP en viajes comunes.
- Automatice los flujos de usuarios en CI para monitorear INP y capturar regresiones.
- Utilice TBT como proxy INP, pero comprenda sus limitaciones.
- Priorice las mediciones de campo para obtener datos INP precisos.
- Equilibre las optimizaciones del rendimiento con consideraciones de UX.
Imagen de portada: Ye Liew/Shutterstock
