El INP mide cuánto tarda una web en responder después de que alguien haga clic, toque un botón o rellene un campo, y desde 2024 forma parte de las tres métricas de Core Web Vitals que Google usa para valorar la experiencia de una página. Para una empresa que capta clientes por internet, un INP alto no es un detalle técnico: es un formulario de contacto que se queda colgado un instante, un menú que no despliega a la primera y una persona que abandona antes de dejar sus datos. Esta guía explica qué significa cada umbral, dónde suele fallar una web corporativa y qué revisar primero antes de perder leads por un problema de rendimiento.
Qué es el INP y por qué importa
El INP (Interaction to Next Paint) sustituyó al First Input Delay (FID) como métrica oficial de Core Web Vitals el 12 de marzo de 2024. La diferencia es de fondo: FID solo medía el retraso antes de la primera interacción, mientras que el INP observa todas las interacciones de la visita -clics, toques y pulsaciones de teclado- y se queda con la que peor responde. Una web puede cargar rápido y aun así fallar en INP si el botón de «solicitar presupuesto» tarda en reaccionar.
El INP es la métrica que evalúa la capacidad de una página para responder con rapidez a las interacciones del usuario a lo largo de toda la visita, no solo en el primer clic.
Google lo calcula sobre el percentil 75 de las visitas, separando móvil y escritorio: para aprobar, al menos tres de cada cuatro interacciones reales de los visitantes tienen que entrar dentro del umbral bueno. No basta con que la web «se sienta rápida» en una prueba interna; el dato sale del tráfico real registrado en el Chrome User Experience Report.
Los tres umbrales de Interaction to Next Paint
Google clasifica el INP en tres franjas, medidas en milisegundos:
| Valoración | Rango | Qué significa |
|---|---|---|
| Bueno | 200 ms o menos | La interacción se siente instantánea |
| Necesita mejora | Entre 200 y 500 ms | Hay un retraso perceptible |
| Malo | Más de 500 ms | El usuario nota que la web «no responde» |
Más de cuatro de cada diez webs siguen sin bajar de los 200 ms en 2026, lo que convierte al INP en la métrica de Core Web Vitals que más suspensos reparte, por delante de LCP (velocidad de carga) y CLS (estabilidad visual). Para una empresa con un ciclo de venta largo, cada interacción torpe en la web es una razón más para que un decisor cierre la pestaña antes de rellenar el formulario de contacto.
El umbral no es un capricho de Google: sale de estudios de percepción que sitúan en torno a los 100 ms el punto en que una respuesta se siente instantánea, y en los 300-500 ms el punto en que el usuario empieza a dudar de si su clic se ha registrado. Una landing de captación con el INP en la franja roja pierde a los visitantes más impacientes justo en el paso que más interesa: el clic en «enviar».
Herramientas para auditar tus Core Web Vitals
Medir el INP de una web no exige presupuesto adicional: Google pone las herramientas a disposición de cualquiera de forma gratuita.
- PageSpeed Insights: da el INP real de los últimos 28 días si la web tiene tráfico suficiente, además de una simulación de laboratorio.
- Chrome UX Report (CrUX): expone el histórico de Core Web Vitals de millones de dominios, incluido el propio si tiene visitas de Chrome.
- Search Console: agrupa las URL por estado -bueno, mejorable, malo- dentro del informe de Core Web Vitals.
- Librería web-vitals: se instala en la propia web para registrar el INP de cada visitante real y enviarlo a GA4 u otra herramienta de analítica.
La cifra de laboratorio de una auditoría puntual sirve para diagnosticar, pero la que cuenta de cara a Google es la de campo: la que dejan los visitantes reales navegando desde su móvil, con su conexión y su dispositivo, no el ordenador de la oficina con fibra simétrica.
Errores de JavaScript que disparan el INP
El origen casi siempre está en JavaScript que bloquea el hilo principal justo cuando el visitante interactúa. Los casos más frecuentes en webs corporativas son animaciones mal optimizadas, librerías pesadas cargadas de golpe y, sobre todo, código de terceros que la propia empresa no controla.
Scripts de terceros: chats, píxeles y widgets
Un chat en directo, el píxel de conversión de LinkedIn Ads, un vídeo incrustado y un widget de reseñas pueden sumar, cada uno, decenas de milisegundos al INP porque compiten por el mismo hilo del navegador justo en el momento en que alguien hace clic. La solución no es eliminarlos -muchos son necesarios para captar leads- sino cargarlos en diferido o tras la primera interacción del usuario, y auditar cada trimestre cuáles siguen generando tráfico real y cuáles quedaron instalados por inercia desde una campaña que ya terminó.
Formularios y menús: los puntos críticos de INP
En una web pensada para captar clientes, las interacciones que más importan no son las que más ocurren, sino las que están a un clic de convertir: enviar el formulario de contacto, abrir el desplegable de servicios o filtrar el catálogo. Ahí es donde un INP alto duele más, porque el abandono ocurre justo antes de dejar el dato de contacto.
Validación de formularios en tiempo real
Muchos formularios de contacto validan cada campo con JavaScript mientras el usuario escribe, comprobando el formato del correo o del teléfono a cada pulsación. Si esa validación no está optimizada, el campo se queda «atascado» una fracción de segundo en cada tecla, y esa latencia repetida es justo lo que mide el INP. Cambiar la validación para que se dispare al salir del campo en lugar de en cada tecla, y mover el envío a segundo plano con una respuesta visual inmediata, suele bajar el INP del formulario sin tocar el diseño.
Qué hacer si tu web no cumple el umbral
Bajar el INP no es un ajuste de una tarde: exige perfilar el código con las herramientas del navegador, identificar qué script concreto bloquea cada interacción y decidir si se optimiza, se difiere o se elimina. En una web corporativa con años de plugins y campañas acumuladas, ese diagnóstico suele encontrar más de un culpable a la vez.
Antes de rehacer nada, conviene partir de una auditoría web que mida el INP real de las páginas con más tráfico -normalmente la home, la de contacto y las de servicio- y priorice por impacto en conversión, no por facilidad técnica. Si el problema viene del propio gestor de contenidos, migrar las páginas críticas a un desarrollo a medida suele dar más margen que seguir parcheando una plantilla genérica. Y como el rendimiento se degrada solo con el tiempo -cada plugin y cada script nuevo suma milisegundos-, conviene revisarlo dentro del mantenimiento web periódico, no solo cuando ya hay un problema visible.
Preguntas frecuentes sobre el INP
¿Qué diferencia hay entre INP y velocidad de carga?
La velocidad de carga (LCP) mide cuánto tarda en verse el contenido principal la primera vez que se abre la página. El INP mide algo distinto: cuánto tarda la web en reaccionar cuando el usuario ya está dentro y hace clic en algo. Una web puede cargar en un segundo y aun así tener un INP malo si el JavaScript bloquea los clics posteriores.
¿Cuánto tarda en notarse una mejora de INP?
Depende de la causa. Diferir un script de terceros o corregir una validación de formulario puede notarse en la siguiente medición de PageSpeed Insights, en minutos. Pero el dato que Google usa para clasificar la web es el de campo, acumulado sobre 28 días, así que confirmar la mejora real tarda ese mismo periodo.
¿El INP afecta al posicionamiento en Google?
Sí, es uno de los factores de la señal de experiencia de página, aunque con menos peso que la relevancia del contenido o los enlaces. Su efecto es mayor de forma indirecta: una web que responde mal a los clics pierde leads aunque posicione bien, porque el usuario abandona antes de convertir.
Fuente: web.dev (Google)