En marzo de 2024 Google hizo un cambio silencioso pero profundo en sus Core Web Vitals: jubiló FID (First Input Delay) y lo reemplazó por INP (Interaction to Next Paint). El anuncio pasó sin mucho ruido fuera del mundillo SEO, pero las implicaciones son enormes: muchos sitios que tenían FID en verde despertaron en naranja o rojo con INP, sin haber tocado una línea de código. Esta guía explica qué cambió, por qué Google hizo el cambio y cómo bajar tu INP por debajo del umbral aceptable.
Qué mide INP y en qué se diferencia de FID
FID solo medía la latencia de la primera interacción del usuario con la página. Era una métrica fácil de aprobar porque la mayoría de los sitios sí responden rápido al primer clic; el problema venía después, cuando el JavaScript empezaba a ejecutarse pesado.
INP es más realista. Mide la latencia de todas las interacciones del usuario durante la sesión (clics, taps, pulsaciones de tecla) y reporta el peor caso, o el percentil 98 si hay muchas. Es el tiempo entre que el usuario hace algo y la página le responde visualmente con un cambio en pantalla. Si abres un menú y se demora 600 ms en aparecer, INP lo registra. Si haces clic en un botón y el spinner tarda en cambiar de estado, también.
Los umbrales son más estrictos de lo que muchos esperan:
- Bueno: ≤ 200 milisegundos
- Necesita mejorar: entre 200 y 500 ms
- Pobre: > 500 ms
Por contexto: 200 ms es muy poco. Un sitio con sliders, formularios complejos, builders visuales y varios píxeles de tracking lo supera con facilidad sin que el usuario perciba un problema dramático.
Por qué Google hizo el cambio
La razón oficial es que FID no reflejaba la experiencia real. La razón práctica es que Google quería forzar a la industria a tomarse en serio el rendimiento del JavaScript durante toda la sesión, no solo en el primer segundo. Con FID, muchos sitios optimizaban solo lo above-the-fold y dejaban el resto en condiciones lamentables. INP cierra ese hueco.
El efecto en el mundo real fue claro: según datos de campo de Chrome, alrededor del 40% de los sitios que estaban en verde con FID pasaron a naranja o rojo con INP. Si nunca revisaste tu INP, hay una probabilidad alta de que estés en ese grupo.
Cómo medir tu INP (sin laboratorio engañoso)
PageSpeed Insights muestra INP en la sección de datos de campo (la parte superior con el grafiquito de barras). Search Console también lo reporta en la sección de Experiencia, separado por dispositivo.
Para diagnosticar dónde se origina el problema, las herramientas útiles son:
- Web Vitals Extension (Chrome): visualiza INP en vivo mientras navegas.
- DevTools de Chrome, pestaña Performance: graba una sesión interactuando con la página y revisa el «long task summary».
- WebPageTest con la opción de capturar interacciones.
El diagnóstico clave es identificar qué interacciones específicas están tardando. INP no es un número abstracto: es una respuesta lenta a un clic concreto en un botón concreto.
Las 5 causas más comunes de un INP alto
1. JavaScript pesado en el hilo principal
Si el main thread está ocupado ejecutando código cuando el usuario hace clic, el clic tiene que esperar. Esto se ve mucho en sitios con builders visuales o tracking pesado en la home.
2. Scripts de terceros
Píxeles de Meta, Google Tag Manager con 30 tags activos, chats tipo Intercom, A/B testing tools. Cada uno suma. La regla pragmática: si no aporta valor medible al negocio, fuera.
3. Event listeners sin debouncing
Eventos de scroll o resize que disparan funciones pesadas en cada milisegundo de movimiento. Solución estándar: debouncing o throttling.
4. Renderizado costoso del DOM
Cambios masivos en el DOM por interacción (filtros que repintan toda una lista de 500 productos, por ejemplo) bloquean el hilo durante cientos de milisegundos. Solución: virtualización de listas o renderizado incremental.
5. CSS complejo con muchas animaciones
Layouts que dependen de propiedades costosas como box-shadow animado, filter: blur o transiciones de altura sobre listas grandes pueden generar layout thrashing y disparar INP.
El plan para mejorar tu INP
- Identifica las interacciones más lentas. Abre tu sitio en Chrome con DevTools, graba una sesión real y ordena las long tasks por duración.
- Audita scripts de terceros. Lista todo lo que carga GTM. Quita lo que no genere reporte directo a una métrica de negocio.
- Difiere JavaScript no crítico. Todo lo que no se necesita above-the-fold puede esperar al requestIdleCallback.
- Divide bundles grandes. Code splitting por ruta. No envíes a la home el JS del checkout.
- Optimiza event listeners. Debouncing, throttling, delegación de eventos cuando aplica.
- Re-mide en 28 días. CrUX promedia 28 días de datos.
INP y WordPress: una mención especial
WordPress es particularmente vulnerable a problemas de INP por la combinación de themes pesados, page builders y plugins que ejecutan JavaScript adicional. Si usas Elementor, WPBakery o Divi, revisa que estás usando la versión actualizada (ambos han hecho trabajo serio en performance) y considera desactivar funcionalidades que no uses.
Esta métrica complementa a las otras dos que Google evalúa: revisa también cómo optimizar LCP y cómo arreglar el CLS si quieres tener tu sitio en verde en las tres.
INP es la métrica que más sitios están reprobando hoy. Trabajarla a fondo no solo te da rankings: te da una experiencia más fluida que se nota en conversión, especialmente en móvil.
Ingresa a https://seoinspector.pro/
Redactor SEO y experto en marketing digital con más de 8 años de experiencia tanto en publicidad pagada como crecimiento orgánico.