INP (Interaction to Next Paint): cómo mejorar la métrica de Core Web Vitals que mide la respuesta de tu web

INP (Interaction to Next Paint) es la métrica de Core Web Vitals que mide cuánto tarda tu web en responder a cada clic, toque o tecla. Reemplazó a FID en marzo de 2024 y hoy es la que más sitios suspenden. Aquí tienes cómo medirla, por qué se dispara y cómo bajarla de 200 ms.

Qué es INP y por qué Google lo eligió como métrica de respuesta

INP observa la latencia de todas las interacciones que ocurren durante la visita completa a una página: cada clic, cada toque y cada tecla. No reporta una media, sino la respuesta más lenta que vio el usuario. Una web puede cargar rápido y aun así sentirse lenta en cuanto alguien intenta usarla.

La guía oficial de web.dev sobre INP la define como la métrica que evalúa la capacidad de respuesta general de la página observando la latencia de las interacciones de clic, toque y teclado durante toda la visita. Y añade el dato que justifica el cambio: según Chrome, el 90% del tiempo que un usuario pasa en una página ocurre después de que cargue. La experiencia real está en la interacción, no en la carga.

La limitación de FID: solo medía la primera interacción

First Input Delay (FID) medía una sola cosa: el retraso entre el primer clic y el momento en que el navegador podía empezar a procesarlo. Una web podía pasar FID con nota y tardar 800 ms en abrir un menú cinco minutos después. Google reconoció esa limitación durante años: INP se anunció como métrica experimental y luego se comprometió a reemplazar a FID. Desde el 12 de marzo de 2024 es la métrica estable de responsividad, así que no compares informes antiguos de FID con INP como si midieran lo mismo.

Qué interacciones cuenta INP y cuáles no

Cuenta clics, toques y pulsaciones de teclado. No cuenta el scroll, el hover ni el zoom, porque no bloquean la respuesta a una acción del usuario de la misma forma. Una interacción es un grupo de eventos del mismo gesto lógico (pointerdown, pointerup y click), y su latencia va desde que empieza ese grupo hasta que el navegador puede pintar el siguiente frame. También entran las interacciones dentro de iframes.

Cómo se calcula INP y qué es un buen resultado

INP toma la interacción más lenta de la visita con una excepción: descarta una de cada 50 interacciones para no castigar la página por un pico aislado. Lo que se reporta en CrUX, PageSpeed Insights y Search Console es el percentil 75 de todas las visitas, segmentado por móvil y escritorio.

Umbrales oficiales: 200 ms, 500 ms y percentil 75

• 200 ms o menos: bueno.
• Más de 200 y hasta 500 ms: necesita mejorar.
• Más de 500 ms: pobre.

Google recomienda mantener el INP en 200 ms o menos al percentil 75, en móvil y escritorio. El móvil suele ir peor por CPU y red: si tu informe separa dispositivos, empieza por ahí.

INP vs FID: por qué tu web puede haber empeorado sin tocar nada

Muchos sitios en verde con FID aparecieron en ámbar o rojo al llegar INP. No es una regresión: es un cambio de vara. FID medía solo el retraso de entrada de la primera interacción; INP mide la latencia completa (entrada, procesamiento y pintado) de todas. Ese matiz evita pánicos: toca optimizar, no rehacer el sitio.

Cómo medir tu INP: datos de campo y de laboratorio

El orden importa: primero datos de campo, que son los que Google usa; después laboratorio, que es donde se diagnostica la causa.

Datos de campo: CrUX, Search Console y RUM

PageSpeed Insights muestra el bloque de datos de campo de CrUX con el INP del percentil 75 y su distribución. El informe de Core Web Vitals de Search Console agrupa URLs por estado y deja ver qué plantillas fallan. Si puedes medir por tu cuenta, la librería web-vitals envía el INP real de cada visita a tu analítica y lo cruza con página, país o dispositivo.

Datos de laboratorio: simular interacciones reales

En Chrome DevTools, el panel Performance con la CPU limitada a 4x o 6x permite grabar un flujo real (abrir el menú, filtrar un listado, enviar un formulario) y ver qué tareas largas coinciden con la interacción lenta. Medir sin límite de CPU da verde y no representa al usuario de móvil.

Las tres partes de una interacción

Toda latencia se descompone en tres tramos: input delay (lo que espera el evento hasta que el hilo principal está libre), processing duration (lo que tardan tus manejadores) y presentation delay (lo que tarda el navegador en calcular estilos, layout y pintar el siguiente frame). Saber en qué tramo se va el tiempo decide la técnica; optimizar a ciegas mueve el problema de sitio.

Causas típicas de un INP alto

• Tareas largas en el hilo principal: un script que ocupa el hilo 300 ms bloquea los clics que lleguen en ese momento.
• JavaScript de terceros: analítica, widgets de chat, gestores de consentimiento y etiquetas de marketing compiten por el mismo hilo.
• DOM enorme: cada cambio fuerza recálculos de estilo y layout, y el coste se multiplica con miles de nodos.
• Trabajo repetido: manejadores que leen y escriben el DOM en bucle (layout thrashing) o recalculan lo mismo en cada evento.

Cómo mejorar tu INP: técnicas prácticas

La guía de optimización de INP de web.dev propone un método claro: partir de datos de campo, reproducir en laboratorio y atacar las tareas largas. Estas son las palancas que más mueven la aguja.

Reducir y dividir tareas largas: yielding

Si una tarea necesita más de 50 ms, pártela y devuelve el control al navegador entre trozos, para que pueda atender los clics que lleguen. El patrón clásico usa setTimeout; hoy hay APIs mejores, como scheduler.yield.

async function procesar(items) {
  for (let i = 0; i < items.length; i++) {
    trabajoPesado(items[i]);
    // devolver el control cada 50 elementos
    if (i % 50 === 0) {
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

Si el navegador lo soporta, scheduler.yield() cede el hilo con mejor prioridad, y navigator.scheduling.isInputPending() permite ceder justo cuando hay una entrada esperando. Así el clic deja de hacer cola detrás de un bucle que no tiene prisa.

Sacar trabajo del hilo principal con web workers

Parsear JSON grandes, ordenar listas, calcular totales o procesar texto no necesitan tocar el DOM. Un web worker lo hace en otro hilo y devuelve el resultado por mensaje. El hilo principal queda libre para responder, que es exactamente lo que mide INP.

Optimizar manejadores y recortar terceros

En cada manejador haz lo mínimo para el siguiente frame y difiere el resto. Audita los terceros con el panel Coverage: lo que no aporta se difiere o se elimina. Y simplifica el DOM de las plantillas con peor INP: menos nodos, menos coste.

INP y SEO: qué dice Google exactamente

Google lo dice con todas las letras en el anuncio de INP como Core Web Vital: tener buenos datos en el informe de Core Web Vitals no garantiza buenos rankings. Los Core Web Vitals son parte de la experiencia de página, una señal entre muchas, no un atajo. Prometer posiciones por bajar el INP es vender humo; lo honesto es que una web que responde rápido retiene y convierte mejor, y ese beneficio sí se puede medir.

En Search Console, el informe de Core Web Vitals dejó de mostrar FID y evalúa INP desde marzo de 2024. Si vienes de una auditoría antigua, comprueba que tus métricas de responsividad sean INP y no FID heredado. Y sitúalo donde corresponde: junto a LCP (velocidad de carga) y CLS (estabilidad visual), que explico en la guía de qué son las Core Web Vitals. Si tu problema está en la carga, empieza por las fuentes web y el LCP; si está en la respuesta, este artículo.

Plan de acción: de medir a mejorar en una semana

1. Mira el INP de campo en PageSpeed Insights para tus 3 a 5 plantillas principales y anota en qué rango estás.
2. Abre el informe de Core Web Vitals de Search Console y agrupa las URLs que fallan por plantilla, no una por una.
3. Reproduce en laboratorio el flujo con más interacciones (menú, carrito, formulario, filtros) con CPU limitada.
4. Identifica el tramo donde se va el tiempo: input delay, processing o presentation. Ese dato elige la técnica.
5. Aplica una palanca por semana: yielding en la tarea más larga, un worker para el cálculo pesado o el recorte de un tercero inútil.
6. Vuelve a medir a los 7 y a los 28 días. Los datos de campo tardan en moverse; no cambies el rumbo por un día malo.

Bajar de 200 ms no requiere reescribir la web: requiere saber qué interacción duele, en qué tramo se va el tiempo y atacar esa tarea concreta. Si ordenas además la medición en Search Console, tienes la foto completa: para eso está la guía de cómo usar Google Search Console.