INP: qué es, qué mide de verdad y por qué suspende gente que no cambió nada

Cuando INP sustituyó a FID en marzo de 2024, miles de sitios pasaron de aprobar a suspender sin haber tocado una línea de código. No fue un endurecimiento del umbral: es que FID medía la parte fácil y INP mide todo lo demás. Entender exactamente qué mide, qué no mide y en cuál de sus tres fases se pierde el tiempo es la diferencia entre atacar el JavaScript correcto y desmontar medio sitio sin que el número se mueva.

Respuesta rápida

• El umbral es 200 milisegundos en el percentil 75 de las visitas reales.
• Mide clic, toque y tecla. Desplazarse, pasar el ratón y hacer zoom no cuentan.
• Se descompone en tres fases, y solo una suele ser el problema.
• No es exactamente la peor interacción: se descarta una alta por cada 50.

¿Qué es INP y qué mide?

Interaction to Next Paint mide cuánto tarda una página en mostrar la respuesta visual a una interacción del usuario. Registra clics de ratón, toques en pantalla y pulsaciones de tecla, se evalúa en el percentil 75 de las visitas reales, y Google considera buena una respuesta de 200 milisegundos o menos.

Qué tipo de métrica es esta

Las otras dos métricas de la experiencia de carga miran cómo llega la página. Esta mira cómo se comporta cuando alguien la usa, y eso cambia dónde está el problema.

FID, su antecesora, medía solo el retraso de la primera interacción: cuánto tardaba el navegador en empezar a atender el primer toque. Era la parte más fácil de aprobar, porque no incluía ni lo que tardaba el código en ejecutarse ni lo que costaba pintar el resultado.

INP mide la interacción completa, de principio a fin, y a lo largo de toda la visita, no solo al principio. Por eso los sitios que se apoyaban en cargar mucho JavaScript después del primer segundo pasaron a suspender: ese código nunca había entrado en la cuenta y ahora entra.

Las tres fases, y cuál es la tuya

1. Retraso de entrada

Del momento del toque a que el navegador empieza a ejecutar el manejador correspondiente. Si es largo, el hilo principal estaba ocupado con otra cosa: una tarea larga, un script de terceros arrancando, un gestor de etiquetas cargando.

El arreglo no está en el manejador sino en lo que se estaba ejecutando cuando llegó el toque: partir las tareas largas, retrasar lo que no hace falta al principio, y quitar lo que no aporta.

2. Duración de procesado

Lo que tarda el código en ejecutarse. Si es la fase larga, el manejador hace demasiado trabajo de golpe.

Suele arreglarse haciendo lo mínimo para responder al usuario y aplazando el resto: mostrar el cambio primero y enviar la analítica, calcular o pedir datos después.

3. Retraso de presentación

De que acaba el código a que el usuario ve el resultado. Si domina, el problema es de pintado: cambios que obligan al navegador a recalcular el diseño entero, listas enormes que se vuelven a dibujar, animaciones caras.

Y hay un caso que engaña: la respuesta puede ser instantánea y sentirse lenta porque el cambio visual llega tarde. Es la fase que más se ignora porque el código parece rápido.

Lo que INP no mide

Conviene tenerlo claro porque ahorra diagnósticos falsos.

No mide el desplazamiento. Bajar por la página no es una interacción a efectos de esta métrica, aunque vaya a tirones, y por eso una queja de "se desplaza mal" no va a aparecer en el informe de Google Search Console por mucho que se busque.

No mide pasar el ratón por encima ni el zoom. Un menú desplegable que tarda en abrirse al pasar por encima no puntúa; el mismo menú abierto con clic, sí. La consecuencia práctica es que una interfaz puede sentirse pesada y aprobar sin problema, y al revés.

Y no es literalmente la peor interacción. En páginas con muchas interacciones se descarta una alta por cada cincuenta, precisamente para que un tropiezo puntual no defina la nota de una página que va bien. En páginas con pocas interacciones, en cambio, la peor sí manda.

Por dónde empezar

Primero, el dato de campo, que es el que Google evalúa y el que aparece en el informe, con la ventana y el percentil que describe Core Web Vitals.

Después, identificar qué interacción es la mala. No es lo mismo el buscador del menú que un botón de aceptar cookies, y solo una está pesando. Es el paso que más gente se salta, y sin él las tres fases no significan nada: se acaba mirando el desglose de una interacción que nadie usa mientras la que pesa está en otro sitio de la página. Un cuaderno con dos columnas, qué se tocó y cuánto tardó, resuelve esto antes que cualquier herramienta.

Después, ver en qué fase se va el tiempo, con las herramientas de rendimiento del navegador y con el móvil simulado, porque en un equipo de escritorio potente casi nada se reproduce. Es la misma trampa que con el resto de estas métricas: se prueba donde mejor va y se decide con ese dato, mientras el informe mide lo que le pasa a la gente.

Y por último, atacar solo esa fase. La mayoría de las guías proponen las tres soluciones a la vez, que es cómo se acaba desmontando código que no era el problema. El contexto de qué hace el JavaScript por debajo está en JavaScript y SEO.

Cuándo INP no es la prioridad

Cuando la página es estática y casi no tiene interacciones. Sin clics ni toques, no hay casi nada que medir, y ese es el caso de la mayoría de los artículos de un blog.

Cuando ya estás por debajo de 200 ms en campo. El umbral es un umbral.

Cuando el LCP está en rojo. Se llega antes a la carga que a la interacción, y el orden de trabajo lo dice el propio recorrido del usuario.

Cuando la mala nota viene de una funcionalidad que casi nadie usa. Vale la pena mirar cuántas visitas la tocan antes de reescribirla.

INP y TBT no son la misma cosa, y media primera página las junta

Comprobado el 13 de agosto de 2026, varias de las páginas que ocupan esta consulta tratan el INP y el Total Blocking Time como el mismo problema con dos nombres. Una llega a titular la guía con las dos siglas juntas.

Se parecen en la causa, que es el JavaScript, y no se parecen en nada más. El TBT se mide en laboratorio y durante la carga: una simulación abre la página, suma cuánto tiempo estuvo el hilo principal bloqueado y devuelve un número al instante. El INP se mide en visitas reales y a lo largo de toda la sesión, y se queda con la peor interacción de todas.

De ahí sale un caso que desconcierta a mucha gente y que es perfectamente normal: el TBT baja a la mitad y el INP no se mueve. Suele significar que la interacción que decide tu nota no ocurre en la carga, sino tres clics más adentro, en un desplegable, un filtro o un formulario que ningún análisis de laboratorio llega a tocar porque nadie los pulsa en una simulación.

El TBT sirve, y sirve exactamente para lo que es: una señal temprana y barata mientras se desarrolla. Lo que no es es un sustituto, y usarlo como tal explica bastantes meses de trabajo sin resultado en el informe que de verdad cuenta.

Errores que se repiten

• Tratar INP como FID con otro nombre. Mide tres veces más cosas.
• Optimizar el manejador cuando el problema es el retraso de entrada. Es otro código.
• Probar en un portátil potente. El campo se mide sobre móviles reales.
• Quitar JavaScript a ciegas. Sin saber la fase, se quita lo que no era.
• Contar el desplazamiento como interacción. No entra en la métrica.
• Perseguir la peor interacción registrada. Se descarta una alta por cada 50.

Las otras dos, que no se arreglan aquí

El INP es una de las tres y la única que depende de lo que pasa después de la carga. La de carga tiene sus cuatro tramos y su propio orden en mejorar el LCP, donde el enemigo suele estar en el servidor o en el orden de descubrimiento de los recursos más que en el código que se ejecuta. Conviene tenerlo presente porque el reflejo habitual ante un informe en rojo es tocar el JavaScript, y en dos de las tres métricas eso no es por donde se empieza. La estabilidad visual, por su parte, no comparte ni causa ni solución con ninguna de las otras dos y se arregla con reservas de espacio en el CSS: cómo arreglar el CLS.

Datos y transparencia

Que varias de las páginas mejor posicionadas para esta consulta presentan el INP y el Total Blocking Time como el mismo problema es una observación propia del 13 de agosto de 2026 y se recoge como confusión circulante, no como fuente.

Que un INP de 200 milisegundos o menos es bueno, que entre 200 y 500 es mejorable y por encima de 500 deficiente, la evaluación en el percentil 75, las tres fases de una interacción con sus definiciones, que la métrica registra clics de ratón, toques en pantalla y pulsaciones de tecla, que no observa desplazamiento, paso del ratón ni zoom, y que en páginas con muchas interacciones se descarta una interacción alta por cada cincuenta, proceden de la documentación pública de Google sobre INP, comprobada el 12 de agosto de 2026. Que INP sustituyó a FID en marzo de 2024 procede de la misma fuente. No aparece aquí ninguna cifra sobre cuántos sitios pasaron de aprobar a suspender con el cambio: Google no publica ese dato y las estimaciones que circulan proceden de muestras de herramientas de terceros no comparables entre sí; la frase sobre miles de sitios describe un efecto conocido del cambio de definición, no una medición propia. El orden de diagnóstico es juicio operativo de trabajo sobre una cartera que registra más de 300 millones de impresiones anuales en Search Console. Verificado en agosto de 2026.

Fuentes primarias, abiertas el 13 de agosto de 2026: la documentación de Interaction to Next Paint.

Lo que esto cambia

El cambio de FID a INP ilustra algo que conviene tener presente al leer cualquier métrica: la definición decide el resultado, y la definición cambia.

Nadie mejoró ni empeoró su sitio en marzo de 2024. Cambió qué se contaba, y con ello cambió quién aprobaba. La lectura útil no es que Google apretara, sino que la nota anterior medía menos de lo que la gente creía. Cuando una métrica se sustituye por otra más completa, lo que se descubre no es una regresión: es lo que ya estaba y no se estaba mirando.

Preguntas frecuentes