Qué es el INP (Interaction to Next Paint)
El INP mide cuánto tarda una página en responder visualmente después de que el usuario interactúa con ella: un clic del ratón, un toque en la pantalla o una pulsación de tecla. En concreto, cronometra el tiempo desde que ocurre la interacción hasta que el navegador dibuja el siguiente fotograma que refleja el resultado. Su umbral de buena experiencia es de 200 milisegundos o menos, medido en el percentil 75 de las visitas reales.
La diferencia con el LCP es fundamental: el LCP mide carga (qué tan rápido aparece el contenido), mientras que el INP mide capacidad de respuesta (qué tan rápido reacciona la página una vez cargada). Una página puede cargar en 1,5 segundos y aun así sentirse pesada cada vez que tocas algo, porque son dos cosas distintas.
El INP no mira una sola interacción, sino todas las que ocurren durante la visita, y reporta prácticamente la más lenta. Esto es deliberado: mide la peor experiencia que tuvo el usuario, no el promedio, porque un único botón que tarda un segundo es lo que la persona recuerda. Por eso el INP es un reflejo honesto de cómo se siente usar tu sitio de verdad.
Por qué INP reemplazó a FID el 12 de marzo de 2024
El 12 de marzo de 2024, INP reemplazó oficialmente a FID (First Input Delay) como métrica estable de Core Web Vitals (web.dev, Google). Google anunció el cambio con casi un año de antelación para dar tiempo a los desarrolladores, y a partir de septiembre de 2024 sus herramientas dejaron de garantizar los datos de FID. Fue el primer cambio de fondo en las Core Web Vitals desde su lanzamiento en 2021.
El motivo del cambio es que FID medía muy poco. FID (First Input Delay, "retraso de la primera entrada") solo cronometraba el retraso de la primera interacción de la visita, y solo la parte de "retraso de entrada", no el procesamiento ni el dibujado. En la práctica esto daba aprobados engañosos: si el primer clic era rápido pero todos los siguientes se arrastraban, FID reportaba un valor excelente que no correspondía a la experiencia real.
INP corrige eso midiendo dos cosas más:
- Todas las interacciones, no solo la primera, y reportando prácticamente la peor.
- El ciclo completo de cada interacción: el retraso de entrada, el tiempo que tarda el JavaScript en procesar la respuesta, y el retraso hasta que el navegador dibuja el resultado en pantalla.
El resultado es una métrica bastante más difícil de aprobar. Muchos sitios que sacaban un FID perfecto descubrieron un INP en amarillo o rojo, no porque hubieran empeorado, sino porque INP por fin medía lo que FID ignoraba.
FID vs INP: la comparación
La forma más rápida de entender el cambio es ver las dos métricas lado a lado. Ambas miden interactividad, pero INP es mucho más completa, y por eso una web puede pasar de "todo verde" con FID a necesitar trabajo con INP sin haber cambiado una línea de código.
| Aspecto | FID (retirado) | INP (actual) |
|---|---|---|
| Qué interacciones mide | Solo la primera de la visita | Todas las de la visita (reporta casi la peor) |
| Qué parte del retraso mide | Solo el retraso de entrada inicial | Ciclo completo: entrada + procesamiento + presentación |
| Umbral "bueno" | ≤ 100 ms | ≤ 200 ms |
| Umbral "pobre" | > 300 ms | > 500 ms |
| Vigencia | Hasta el 12 de marzo de 2024 | Desde el 12 de marzo de 2024 |
Los umbrales de INP parecen más laxos (200 ms frente a 100 ms), pero no lo son: como INP mide el ciclo completo y todas las interacciones, un valor de 200 ms en INP representa mucho más trabajo del navegador que 100 ms en FID. La comparación de números entre ambas métricas es engañosa; lo que importa es que INP es la que cuenta hoy.
El umbral de 200 ms y sus tres rangos
Un buen INP es de 200 milisegundos o menos en el percentil 75 de las visitas. Esto significa que al menos el 75 % de las interacciones de la página deben completarse en 200 ms o menos para aprobar; si una de cada cuatro se arrastra por encima de ese valor, el sitio no pasa. Los tres rangos oficiales de Google son estos:
| Rango de INP | Clasificación | Qué percibe el usuario |
|---|---|---|
| ≤ 200 ms | Bueno | La página responde al instante |
| 200 ms – 500 ms | Necesita mejora | Se nota un pequeño retraso al interactuar |
| > 500 ms | Pobre | La página se siente trabada y lenta |
El límite de 200 ms tiene una base perceptiva: por debajo de ese tiempo, el cerebro humano interpreta la respuesta como inmediata y ligada a la acción que la provocó. Por encima, empieza a percibirse un desfase entre lo que se hace y lo que ocurre, y esa sensación de "va lento" es la que castiga tanto la experiencia como, indirectamente, el posicionamiento.
Cómo reducir el INP: el JavaScript es el culpable
El INP mejora reduciendo el trabajo de JavaScript que bloquea el hilo principal del navegador. El hilo principal es la única cola donde el navegador procesa tanto las interacciones del usuario como la ejecución de scripts; si una tarea larga de JavaScript la ocupa, el clic del usuario espera su turno, y ese tiempo de espera es justo lo que INP mide. Bajar el INP consiste en despejar esa cola. Estas son las acciones más efectivas:
- Reduce y divide el JavaScript. Elimina scripts que no usas —plugins abandonados, librerías cargadas "por si acaso"— y divide el código para que cada trozo se cargue solo cuando hace falta (code splitting). Menos JavaScript ejecutándose es menos hilo principal bloqueado.
- Difiere lo que no es urgente. La analítica, el chat de soporte o la publicidad no necesitan ejecutarse durante la carga inicial. Cargarlos con
defero después del evento de carga libera el hilo justo cuando el usuario empieza a interactuar. - Fragmenta las tareas largas. Una función que tarda 300 ms bloquea cualquier interacción durante ese tiempo. Partirla en tareas cortas y ceder el control al navegador entre ellas —con
setTimeouto con la APIscheduler.yield()— permite que un clic se atienda en medio. - Optimiza los event handlers. Un manejador de eventos que hace mucho trabajo síncrono en cada clic o cada tecla dispara el INP. Deja en el handler solo lo mínimo para actualizar la interfaz y mueve el trabajo pesado a después del siguiente pintado, para que el usuario vea una respuesta inmediata.
- Quita scripts de terceros que no aporten. Cada widget externo —un mapa embebido, un feed de redes, un contador— trae su propio JavaScript que corre en tu hilo principal. Los que no generan valor real son deuda de rendimiento pura.
Por qué el hosting casi no mejora el INP
El INP es, de las tres Core Web Vitals, la que menos depende del hosting. La razón es directa: el INP se juega en el navegador del visitante, ejecutando el JavaScript de tu tema y tus plugins, no en el servidor. Cambiar a un servidor más rápido no arregla un INP malo causado por una plantilla con 300 KB de scripts, porque ese código se ejecuta en el teléfono del usuario, no en tu máquina.
Esto contrasta con el LCP, que sí mejora mucho con un buen servidor porque incluye el TTFB (el tiempo de respuesta del servidor). Si tu problema es el INP, el trabajo está en el frontend: aligerar el tema, reducir plugins, diferir scripts. Decirlo con honestidad importa, porque migrar de hosting para arreglar un INP malo es gastar dinero en el lugar equivocado.
Dicho esto, el INP no vive solo. Forma parte de un conjunto de tres métricas, y para verlo en contexto junto al LCP y el CLS conviene leer la guía completa de Core Web Vitals, donde se explica cuándo el problema es el servidor y cuándo es el código, y en qué orden atacar cada métrica.
El INP (Interaction to Next Paint) mide qué tan rápido responde tu página cuando el usuario la toca, y desde el 12 de marzo de 2024 reemplazó a FID como una de las tres Core Web Vitals de Google. Su umbral es de 200 milisegundos o menos en el percentil 75, y es más difícil de aprobar que FID porque mide todas las interacciones y su ciclo completo, no solo el primer clic. La buena noticia es que casi siempre está en tus manos: el INP se arregla en el código —reduciendo, dividiendo y difiriendo JavaScript—, no en el servidor. Mide tu web en PageSpeed Insights, revisa si tu INP está en amarillo o rojo y, si lo está, empieza por eliminar el JavaScript que no aporta: ese suele ser el 80 % del problema.
Hosting con LiteSpeed, NVMe y soporte 24/7 desde $3/mes.