¿Qué es el INP?

El Interaction to Next Paint mide cuánto tarda una página en mostrar que ha entendido lo que el usuario acaba de hacer. El reloj arranca con el clic, el toque o la pulsación de tecla, y se detiene en el primer fotograma que refleja el resultado. No mide cuánto tarda la acción en completarse, sino cuánto tarda en verse que algo pasa.

Esa distinción es la clave de la métrica. Un botón que abre un menú puede necesitar medio segundo para cargar su contenido, y aun así tener buen INP si el menú aparece vacío de inmediato y se rellena después. Al revés, un botón que hace muy poco trabajo puntúa mal si el navegador estaba ocupado con otra cosa cuando el usuario lo pulsó.

Solo cuentan tres tipos de interacción: clic o toque, pulsación de tecla, y las interacciones con el teclado sobre elementos enfocables. Desplazarse por la página o pasar el ratón por encima no cuenta, aunque un desplazamiento con tirones se perciba igual de mal. Para eso hay otras señales dentro de las Core Web Vitals.

Ese detalle explica por qué el INP no se puede falsear con trucos de carga. Una página puede llegar entera en medio segundo y responder pésimo al primer clic, porque el navegador sigue ocupado ejecutando el JavaScript que llegó con ella. Velocidad de entrega y capacidad de respuesta son cosas distintas, y el usuario nota antes la segunda: espera que la página tarde en aparecer, no que se quede muda cuando ya la está usando.

Por eso conviene pensar el page speed como dos preguntas separadas. Cuánto tarda en verse algo la responde el LCP; cuánto tarda en reaccionar, el INP. Optimizar solo la primera deja páginas que parecen rápidas y se sienten pesadas, y ese desajuste aparece en la tasa de rebote antes que en cualquier informe técnico.

Cada interacción medida se descompone en tres fases consecutivas, y la suma es lo que se compara con los umbrales. Google considera bueno un INP de hasta 200 milisegundos, mejorable hasta 500, y deficiente por encima. Como en el resto de métricas de campo, la evaluación se hace sobre el percentil 75 de las visitas reales, así que un valor bueno en el portátil del equipo no dice nada.

Saber qué fase pesa más cambia por completo dónde se trabaja. Si domina la espera de entrada, el problema son tareas largas que ya estaban corriendo, y la solución vive en el gestor de etiquetas y en los scripts de terceros. Si domina la presentación, el problema es el tamaño del documento, y eso se arregla en la plantilla del CMS.

Hay una asimetría entre las tres fases que conviene tener presente. La espera de entrada y la presentación dependen del estado general de la página: cuántos scripts corren, qué tamaño tiene el documento, qué más está pasando en ese instante. El procesamiento, en cambio, depende del código concreto del botón que se pulsó. La primera clase de problema se arregla una vez y mejora todas las interacciones; la segunda hay que arreglarla elemento por elemento.

En una auditoría de SEO técnico esa diferencia decide el orden de trabajo. Merece la pena empezar por lo que afecta a toda la plantilla, porque una sola corrección ahí mueve el percentil de golpe, mientras que optimizar un botón concreto solo mejora las visitas que lo pulsan.

Hasta marzo de 2024 la métrica de interactividad era el First Input Delay, y el cambio no fue cosmético. El FID medía solo la primera interacción de la visita y solo su fase de espera, sin contar ni el procesamiento ni el pintado. El resultado era una métrica fácil de aprobar: casi todas las páginas la pasaban aunque se sintieran lentas al usarlas.

El INP mide todas las interacciones y las tres fases completas, y se queda con la peor. Por eso muchos sitios que tenían el semáforo en verde con el FID lo vieron pasar a ámbar sin haber cambiado nada. No empeoraron: la regla anterior no medía lo que decía medir.

Esa historia deja una lección aplicable más allá de la velocidad. Una métrica que casi todo el mundo aprueba no está describiendo la realidad, está describiendo su propio umbral, y lo mismo vale para cualquier KPI de un panel de analítica web.

El cambio tuvo además una consecuencia práctica en la manera de informar. Muchos paneles de cliente seguían mostrando el FID meses después de su retirada, porque la métrica estaba cableada en la plantilla del informe y nadie la revisó. El resultado eran presentaciones con un semáforo verde que ya no correspondía a ninguna evaluación real de Google.

Vale la pena revisar cualquier KPI heredado con el mismo criterio: si nadie recuerda cuándo se definió el umbral, probablemente describe una situación que ya no existe. Eso vale para la velocidad y también para métricas de negocio como la conversión por canal en un panel de analítica web que nadie ha tocado en dos años.

El primer paso no es optimizar, es identificar qué interacción concreta arrastra el valor. Las herramientas de campo señalan el elemento culpable, y muy a menudo resulta ser uno solo: un filtro de catálogo, un selector de variantes en una ficha de e-commerce, un menú desplegable con demasiados niveles.

A partir de ahí las palancas son pocas y conocidas. Partir las tareas largas de JavaScript para que el navegador pueda atender al usuario entre trozo y trozo. Sacar del manejador de evento todo lo que no haga falta para la respuesta inmediata. Reducir el tamaño del documento, porque cada nodo extra encarece el recálculo del diseño. Y revisar qué scripts de terceros se cargan en el Google Tag Manager, que suele ser donde crece el problema sin que nadie lo decida.

La comprobación posterior sigue las mismas reglas que el resto de métricas de campo: los datos de Search Console tardan semanas en moverse, así que medir al día siguiente no dice nada. Y como el INP toca directamente lo que el usuario siente, vale la pena cruzarlo con tasa de rebote y con la conversión de la página afectada.

Un caso frecuente merece mención aparte, porque se resuelve sin tocar código. Muchos sitios cargan por gestor de etiquetas scripts que ya no usa nadie: una herramienta de mapas de calor que se probó una vez, un chat que se sustituyó, un píxel de una campaña terminada. Cada uno compite por el hilo principal en cada visita. Revisar esa lista y borrar lo muerto suele dar la mejora más barata de toda la lista.

La segunda medida barata es mirar qué se ejecuta al cargar y qué podría esperar. Un mapa de calor o una herramienta de sesión no necesitan arrancar en el primer segundo; retrasarlos hasta después de la primera interacción no cambia lo que miden y libera justo el momento que el INP vigila.

• Optimizar la página de inicio cuando el problema está en una plantilla de producto o de filtro que nadie mide.
• Confundir el INP con el tiempo total de la acción: lo que cuenta es cuándo se ve la respuesta, no cuándo termina el trabajo.
• Probar solo en escritorio, cuando el índice mobile-first decide y los móviles antiguos tardan varias veces más en la misma tarea.
• Añadir una animación de carga y dar el problema por resuelto: la animación mejora la percepción, no la métrica.
• Tratar los umbrales como un aprobado. Bajar de 480 a 320 milisegundos mejora la experiencia real aunque el rótulo siga en ámbar, igual que ocurre con el LCP.