Medir INP y mejorar la respuesta del sitio con INP Scanner

Esta guía explica INP y cómo usar INP Scanner Milten para investigar interacciones lentas. INP sustituyó a FID en Core Web Vitals en marzo de 2024. Una prueba de laboratorio cubre las acciones realizadas, no la experiencia de todos los visitantes.

¿Qué es Interaction to Next Paint (INP)?

INP evalúa la respuesta a clics, toques y entradas de teclado durante una visita. La latencia incluye la espera antes de procesar la entrada, la ejecución de los controladores y la espera hasta el siguiente repintado. FID medía solo el retraso de la primera entrada; INP considera las interacciones válidas de toda la visita. No mide la duración completa de una respuesta de red asíncrona posterior.

Características clave del INP:

• Agregación: INP no es un promedio. Por lo general refleja la interacción más lenta, excluyendo valores atípicos en visitas con muchas interacciones.
• Umbrales: bueno hasta 200 ms; necesita mejorar por encima de 200 ms y hasta 500 ms; deficiente por encima de 500 ms. En datos reales se evalúa el percentil 75, separando móvil y escritorio.
• Acciones incluidas: clics, toques y teclado. El desplazamiento y el movimiento del puntero no cuentan por sí solos como interacciones INP.

¿Por qué es importante el INP para usted?

1. Experiencia de usuario (UX)

Una respuesta visual lenta puede hacer que un botón parezca inactivo y provocar clics repetidos. Mida la interacción concreta y su resultado. Las estadísticas sobre carga de páginas no demuestran un efecto de INP en la tasa de rebote de su sitio.

2. SEO y clasificaciones de búsqueda

INP forma parte de Core Web Vitals, que utilizan los sistemas de clasificación de Google. Una buena puntuación no garantiza una posición superior y una mala no demuestra una penalización fija. Evalúe la respuesta junto con la relevancia del contenido y otros aspectos de la experiencia de página.

3. La velocidad como ventaja competitiva

La respuesta visual inmediata ayuda a entender que la acción se ha recibido. Compare las tareas relevantes para su audiencia: una misma demora puede tener efectos distintos según la tarea.

Cómo trabajar con INP Scanner de Milten

INP Scanner ayuda a investigar la respuesta en una prueba controlada del navegador. Revise las acciones ejecutadas y las limitaciones antes de generalizar los resultados.

1. Compruebe las interacciones probadas

Elija un recorrido representativo y confirme qué acciones realizó la prueba:

• Clics en botones y enlaces.
• Entrada de teclado en los campos pertinentes.
• Desplazamiento necesario para llegar a un elemento; el desplazamiento en sí no es una interacción INP.

Una prueba controlada es un escenario reproducible, no una medición en los dispositivos de todos los visitantes. Registre el navegador, el perfil de dispositivo y las condiciones reales de la prueba. Añada pruebas manuales para los recorridos importantes que no se hayan cubierto.

2. Interprete los tiempos

INP se mide con datos de Event Timing. PerformanceObserver puede observar las entradas event compatibles; no existe un tipo general render para este propósito. Una biblioteca como web-vitals agrupa las interacciones y calcula INP.

• Distinga la espera de entrada, la ejecución del controlador y la demora de presentación.
• Investigue las tareas largas de JavaScript en el hilo principal.
• Examine la fluidez de las animaciones como una cuestión relacionada, pero distinta.

3. Investigue las observaciones

Utilice los datos que realmente figuran en el informe:

• Identifique las interacciones registradas y sus elementos de destino.
• Investigue una acción lenta, como un botón «Comprar» de ejemplo que tarda 600 ms; no es una medición de un cliente.
• Compruebe la causa posible en una grabación de rendimiento del navegador y pruebe un cambio limitado del código.

Límites de una prueba automática

• Consulte las condiciones actuales del servicio y los campos disponibles en el informe.
• Una prueba en el navegador no demuestra que se hayan usado dispositivos físicos de los visitantes.
• Las acciones no ejecutadas y los datos ausentes siguen sin verificar. Complete el análisis con datos reales cuando estén disponibles.

Causas frecuentes de interacciones lentas

1. Controladores de eventos largos

Ejemplo ilustrativo; las funciones y los datos deben estar definidos en la aplicación:

button.addEventListener('click', () => {
	// Synchronous processing of 10,000 data rows
	const result = heavyCalculation(data)
	updateUI(result)
})

Problema: el trabajo síncrono de heavyCalculation ocupa el hilo principal y puede retrasar el siguiente repintado. Solución: reduzca o divida el trabajo, o traslade los cálculos adecuados a un Web Worker. Un solo setTimeout únicamente programa la misma tarea pesada para más tarde; no la saca del hilo principal.

2. CSS/JS de bloqueo de renderizado

Ejemplo:

<link rel="stylesheet" href="large-styles.css" />
<script src="analytics.js" defer></script>

Problema: una hoja de estilos bloqueante y una ejecución costosa de scripts pueden retrasar la visualización o la entrada. defer cambia la planificación, pero no elimina el trabajo. La hoja del ejemplo se aplica a la pantalla; usar solo media="print" dejaría esos estilos sin aplicar en pantalla. Posibles mejoras:

• Incluya en línea solo el CSS realmente crítico y mida el efecto.
• Elimine estilos sin uso tras comprobar clases dinámicas y estados de la interfaz; PurgeCSS necesita una configuración adecuada.
• Aplace los scripts no críticos y reduzca su coste de ejecución.

3. Animaciones lentas

Ejemplo:

@keyframes fade {
	from {
		opacity: 0;
		transform: translateX(-100px);
	}
	to {
		opacity: 1;
		transform: translateX(0);
	}
}

Problema: las animaciones de opacity y transform suelen ser eficientes, pero muchas animaciones simultáneas pueden provocar tirones. Posibles mejoras:

• Simplifique las animaciones y reduzca los elementos animados a la vez.
• Use will-change: transform solo cuando sea necesario y poco antes del cambio. Es una indicación, no una garantía de aceleración GPU; su uso excesivo consume recursos. Mida el resultado.

4. Recálculos forzados repetidos del diseño (layout thrashing)

Ejemplo:

for (let i = 0; i < 100; i++) {
	element.style.height = `${i}px`
	console.log(element.offsetHeight) // Forces layout recalculation
}

Problema: alternar escrituras de estilos y lecturas geométricas como offsetHeight puede forzar recálculos repetidos. Calcular el diseño no es lo mismo que pintar. Solución:

• Agrupe las lecturas geométricas antes de las escrituras cuando sea posible.
• Use requestAnimationFrame para cambios visuales cuando corresponda, pero no espere resolver el problema colocando dentro el mismo bucle de lecturas y escrituras.

Cómo mejorar el INP: 5 consejos prácticos

1. Optimizar controladores de eventos

• Divida las tareas largas y ceda el control al navegador entre bloques mediante un mecanismo adecuado, como setTimeout.
• queueMicrotask no da al navegador una oportunidad de pintar: una cadena de microtareas puede mantener la página bloqueada.
• Reduzca el trabajo inmediato del controlador y muestre una respuesta rápida.

2. Reducir el tamaño del paquete de JavaScript

• Elimine las bibliotecas no utilizadas (por ejemplo, utilizando Webpack Bundle Analyzer).
• Aplique la división de código para cargar módulos dinámicamente.

3. Use debounce y throttle

Aplique debounce o throttle al trabajo costoso si la tarea lo permite. El ejemplo requiere definir o importar debounce. Mantenga inmediata la respuesta visual del campo; los 300 ms son una decisión ilustrativa de planificación, no un objetivo de INP:

const debouncedSearch = debounce((query) => {
	fetchResults(query)
}, 300)

4. Optimizar renderizado

• Reduzca la complejidad innecesaria del DOM.
• Mida los costes de estilos y diseño sin atribuirlos de antemano a los selectores.
• Considere content-visibility: auto para secciones fuera de pantalla y compruebe diseño, foco y accesibilidad.

5. Prueba en dispositivos de gama baja

Pruebe dispositivos de gama baja representativos cuando sea posible. Las herramientas del navegador permiten emular CPU y redes más lentas, por ejemplo una ralentización de CPU de 4× y una conexión móvil limitada. Son condiciones ilustrativas, no un perfil 3G fijo del servicio ni pruebas en equipos físicos.

Verifique el resultado

Repita la misma interacción después de publicar el cambio y en condiciones comparables. Compruebe el tiempo y la corrección de la tarea: un carrito más rápido debe seguir conteniendo el producto adecuado.

Use INP Scanner de Milten como parte de la investigación:

• Registre las acciones probadas y los datos que faltan.
• Compare el mismo recorrido antes y después.
• Evalúe las visitas reales con sus propios datos; un buen resultado de laboratorio no demuestra un buen INP para todos los usuarios.

Elija una interacción importante, identifique una causa posible y pruebe una corrección limitada. Distinga las comprobaciones superadas, fallidas y no ejecutadas.

Consulte la guía de medición de INP y la guía de optimización de INP.