Qué mide el INP y por qué es clave para tus clientes

Tu cliente te escribe enfadado: “la web va a tirones”. Abres PageSpeed Insights esperando un desastre y te encuentras un 92 en escritorio. El LCP, perfecto. Y aun así, cuando abres el menú o pulsas “añadir al carrito” en el móvil, hay medio segundo de nada. Pulsas, y la web piensa. Ese hueco tiene nombre desde 2024, y tiene una métrica que lo mide.

Saber qué mide el INP se ha vuelto básico para cualquier agencia que gestione webs de clientes. No es una métrica más del informe: el INP (Interaction to Next Paint) es el Core Web Vital que pone número a esa sensación de “web que no responde”, la que tus clientes notan aunque no sepan explicarla. Y desde que sustituyó al antiguo FID, suspende webs que antes pasaban de sobra.

Qué mide el INP, en una frase

El INP mide cuánto tarda una web en responder visualmente a una interacción del usuario. Pulsas un botón, tocas un menú, marcas una casilla: el INP cuenta los milisegundos que pasan desde ese gesto hasta que la pantalla pinta el siguiente fotograma con una respuesta.

Es la diferencia entre una web que “obedece al instante” y una que se queda pensando un momento antes de reaccionar. No mide cuánto tarda en cargar. Mide cuánto tarda en hacerte caso una vez ya está cargada.

Y aquí está la clave que muchos pasan por alto: el INP no mira una sola interacción. Observa todas las que hace el usuario durante la visita —clics, toques, pulsaciones de teclado— y reporta, en la práctica, la peor. Una sola interacción lenta de toda la sesión puede arruinar el resultado. Por eso es tan honesto: refleja lo que de verdad se siente al usar la web, no un momento elegido con suerte.

Cómo se descompone una interacción

Cuando alguien pulsa un botón, ese “tiempo de respuesta” no es un bloque único. Son tres tramos, y entender cuál falla es media reparación:

1. Retraso de entrada (input delay). El tiempo que el navegador tarda en empezar a atender el gesto, normalmente porque está ocupado ejecutando otro código. El usuario ya ha pulsado; el navegador todavía no ha podido ni mirar.
2. Tiempo de procesamiento (processing time). Lo que tardan en ejecutarse los manejadores de eventos asociados a esa interacción: la lógica que decide qué pasa al pulsar.
3. Retraso de presentación (presentation delay). El tiempo hasta que el navegador calcula y pinta el siguiente fotograma con el cambio visual.

El INP es la suma de los tres. Si tienes un INP malo, no basta con “optimizar JavaScript” a ciegas: conviene saber en qué tramo se va el tiempo. Casi siempre es el primero —el hilo principal bloqueado—, pero no siempre.

Los umbrales que tienes que reportar

Google fija tres rangos, y aquí no hay margen de interpretación:

• Bueno: 200 ms o menos. La web se siente instantánea.
• Necesita mejorar: entre 200 y 500 ms. Empieza a notarse ese arrastre.
• Pobre: más de 500 ms. El usuario percibe que la web va lenta, aunque no sepa por qué.

Un matiz importante para no llevarte sustos: el umbral se mide en el percentil 75 de las visitas reales. No es la media. Significa que el 75% de tus usuarios debe estar por debajo de ese número. Basta con que una porción de la audiencia use móviles modestos o conexiones flojas para que el percentil 75 se dispare, aunque en tu portátil todo vaya fino. Esa es, casi siempre, la razón de la discrepancia entre “a mí me va bien” y el cliente quejándose.

Por qué el INP sustituyó al FID (y por qué te afecta)

Hasta marzo de 2024, el Core Web Vital de interactividad era el FID (First Input Delay). El FID tenía un problema grave: solo medía la primera interacción de la visita, y de esa primera interacción solo el retraso inicial, no toda la respuesta. Era un examen fácil. Casi cualquier web lo aprobaba.

El FID medía si la web te dejaba empezar. El INP mide si la web responde bien durante toda la visita. Es un salto de exigencia, no un retoque.

El INP cambia las reglas: todas las interacciones, la duración completa hasta el repintado. Resultado práctico para tu agencia: webs de clientes que con el FID sacaban verde llevan desde 2024 en ámbar o rojo, sin que nadie haya tocado nada. No es que la web haya empeorado. Es que ahora se mide lo que antes se ignoraba. Si gestionas webs con mucho JavaScript —tiendas, paneles, themes de WordPress cargados de plugins—, es muy probable que tengas trabajo de INP esperándote.

Por qué va mal el INP: las causas reales

Un INP pobre casi siempre apunta al mismo culpable: el hilo principal del navegador está saturado. El navegador hace una cosa a la vez, y si está ocupado, tu clic espera turno. Las causas habituales:

• JavaScript pesado o mal troceado. Tareas largas que bloquean el hilo principal durante cientos de milisegundos. Mientras se ejecutan, ninguna interacción puede atenderse.
• Scripts de terceros. Chats, píxeles de seguimiento, mapas de calor, widgets de reseñas. Cada uno mete su propio código en la cola. Una agencia que apila herramientas de marketing en la web del cliente está, sin saberlo, empeorando el INP.
• Manejadores de eventos costosos. Lógica que hace demasiado en cada clic: recalcular, reordenar, pedir datos de forma síncrona.
• DOM enorme. Páginas con decenas de miles de elementos hacen que cada repintado sea caro, alargando el tercer tramo de la interacción.

La buena noticia: estos problemas se diagnostican y se corrigen sobre la web actual, sin rehacerla. Lo mismo que pasa con el resto de Core Web Vitals en WordPress cuando heredas un theme que no elegiste.

Cómo medir el INP de la web de un cliente

Tienes dos formas, y conviene usar las dos:

Datos de campo (usuarios reales). Es lo que cuenta para Google. PageSpeed Insights te muestra el INP real de los últimos 28 días si la web tiene tráfico suficiente, sacado del informe CrUX. Es el número que de verdad afecta al SEO y el que debes llevar al informe del cliente.

Datos de laboratorio (tu diagnóstico). Para saber por qué va mal, abre el panel de Rendimiento de las DevTools de Chrome, interactúa con la página y mira qué tareas largas bloquean el hilo principal. Ahí ves el tramo culpable y el script concreto que lo causa. Es la herramienta para pasar de “el INP es 480 ms” a “este widget de reseñas se come 300 ms en cada clic”.

Mide siempre pensando en móvil. El INP se sufre mucho más en un teléfono de gama media que en tu equipo de trabajo, y ahí está la mayoría del tráfico de tus clientes.

Qué hacer con un INP malo

Sin entrar en cada técnica, el orden de ataque que mejor funciona:

1. Quita lo que no se usa. Scripts de terceros olvidados, plugins que nadie echa de menos. Es el arreglo de mayor impacto y menor riesgo.
2. Trocea las tareas largas. Partir el JavaScript pesado en trozos pequeños deja huecos para que el navegador atienda los clics. El usuario nota la web “despierta”.
3. Aligera los manejadores de eventos. Que cada interacción haga lo justo y aplace lo demás.
4. Reduce la complejidad del DOM en las páginas más interactivas.

Un principio resume todo: lo que no se ejecuta en el momento del clic no estorba. Cada milisegundo que el hilo principal pasa ocupado es un milisegundo que tu usuario espera.

Conclusiones clave

• El INP mide la capacidad de respuesta de una web: cuánto tarda en reaccionar visualmente a clics, toques y pulsaciones, durante toda la visita.
• Buen INP: 200 ms o menos, medido en el percentil 75 de usuarios reales en móvil.
• Sustituyó al FID en marzo de 2024 y es mucho más exigente: webs que aprobaban antes ahora suspenden sin haber cambiado.
• La causa casi siempre es el hilo principal saturado por JavaScript y scripts de terceros. Se arregla sobre la web actual.

¿Un cliente con la web “que va a tirones”?

El INP es de esos problemas que el cliente siente pero no sabe nombrar, y que un informe de PageSpeed deja en evidencia. Tenerlo en verde es base para el SEO y para que la web no espante a quien ya está dentro —de poco sirve acelerar la carga si luego la web no responde al primer clic—.

Trabajo como socio técnico white-label para tu agencia: diagnostico y arreglo los Core Web Vitals de las webs de tus clientes —INP incluido—, bajo tu marca y con un informe antes/después listo para reportar. Si quieres saber con quién hablas, te dejo un poco sobre mí.

¿Tienes un cliente con una web que reacciona tarde? Escríbeme y la miramos juntos —te digo qué interacción la frena y qué merece la pena arreglar primero—.

Preguntas frecuentes

¿Qué mide exactamente el INP?

El INP (Interaction to Next Paint) mide cuánto tarda la web en responder visualmente a una interacción del usuario: desde que hace clic, toca o pulsa una tecla hasta que la pantalla pinta el siguiente fotograma. Recoge todas las interacciones de la visita y reporta prácticamente la peor, así que refleja la capacidad de respuesta real durante toda la sesión, no un único momento.

¿Cuál es un buen valor de INP?

Google considera bueno un INP de 200 milisegundos o menos. Entre 200 y 500 ms está en "necesita mejorar", y por encima de 500 ms es "pobre". El umbral se mide en el percentil 75 de las visitas, es decir, lo que experimentan el 75% de tus usuarios o mejor.

¿En qué se diferencia el INP del antiguo FID?

El FID (First Input Delay) solo medía el retraso de la primera interacción y solo la parte de espera, no toda la respuesta. El INP mide todas las interacciones de la página y la duración completa, hasta que se repinta la pantalla. Por eso es mucho más estricto y representativo: una web podía tener un FID excelente y aun así sentirse lenta al usarla.

¿El INP afecta al posicionamiento en Google?

Sí. Desde marzo de 2024 el INP es uno de los tres Core Web Vitals y, por tanto, un factor de la señal de experiencia de página de Google. Un mal INP puede frenar el SEO de la web de tu cliente, además de degradar la experiencia de uso y la conversión.