Durante años, FID (First Input Delay) fue la métrica de interactividad que determinaba si una web cumplía con los Core Web Vitals de Google. Era una métrica “amable”: medía solo el primer input del usuario y las webs pasaban el umbral con relativa facilidad.
En marzo de 2024, Google reemplazó FID por INP (Interaction to Next Paint). El cambio no fue cosmético: INP mide cosas distintas, es mucho más exigente y ha dejado a muchas webs en rojo que antes pasaban en verde.
Los datos hablan claro: el 40% de las webs que pasaban FID no pasan INP. Si tu web no ha ajustado su performance al nuevo estándar en los últimos 24 meses, probablemente tengas un problema silencioso que está afectando tu SEO sin que lo sepas.
Qué mide INP y por qué es más exigente que FID
FID medía el retraso entre el primer input del usuario (click, tap, tecla) y el momento en que el navegador empezaba a procesar ese input. Solo el primer input. Solo el retraso inicial. Solo el inicio del procesamiento.
INP mide el peor caso de interactividad de toda la sesión del usuario. Todos los inputs, no solo el primero. La latencia completa desde que el usuario interactúa hasta que la pantalla se actualiza. El “peor caso” (p98, no la media).
Esto es un cambio de criterio. FID podía ser bueno aunque tu web tuviera un botón que tardara 2 segundos en responder, siempre que el primer click fuera rápido. INP detecta ese botón problemático y lo refleja en la métrica.
Los umbrales actuales de Google:
- INP bueno: menor a 200 ms.
- INP a mejorar: entre 200 ms y 500 ms.
- INP malo: más de 500 ms.
Muchas webs con JavaScript pesado (frameworks frontend modernos, muchos tags de tracking, librerías de analytics agresivas) se sitúan fácilmente por encima de 200 ms en interacciones típicas. Y ni lo saben.
Los 3 problemas técnicos que más dañan INP
JavaScript bloqueante en el hilo principal
El hilo principal del navegador procesa tanto JavaScript como las actualizaciones visuales. Cuando JavaScript ocupa el hilo más de 50 ms, el navegador no puede responder a inputs del usuario durante ese tiempo.
Los culpables típicos:
- Librerías de tracking agresivas (GA4 con muchas configuraciones, Segment, Hotjar, scripts de personalización).
- Hydration de frameworks frontend en páginas con muchos componentes.
- Third-party scripts de ads, recomendadores, chatbots.
- Event handlers pesados que hacen cálculos complejos al click.
La solución no es eliminar JavaScript. Es auditar qué ejecuta el hilo principal en cada momento y mover lo que se pueda a Web Workers, lazy-loading o ejecución diferida.
Tareas largas en el click
Cuando el usuario hace click en un botón y el click handler ejecuta una función pesada (llamada API, procesamiento de datos, actualización de estado compleja en React/Vue), INP mide todo ese tiempo.
El patrón correcto: el click handler debe actualizar el UI visual inmediatamente (mostrar spinner, cambiar estado del botón) y mover el trabajo pesado a un setTimeout o requestIdleCallback.
Estilo y layout trashing
Cuando el usuario interactúa y la interacción dispara recálculos masivos de layout (muchos elementos se redimensionan, se reposicionan, cambian estilos), el tiempo entre input y next paint se dispara.
Causas típicas:
- Animaciones CSS que modifican propiedades que fuerzan recálculo de layout (width, height, margin, padding en lugar de transform/opacity).
- JavaScript que lee y escribe en el DOM intercaladamente sin usar requestAnimationFrame.
- Componentes que se remontan al hacer cualquier interacción simple.
Cómo diagnosticar INP en tu web hoy mismo
Paso 1: Datos reales de CrUX
Los datos que Google usa para evaluar tu sitio vienen de Chrome UX Report (CrUX), que recopila métricas anónimas de usuarios reales. Estas son las métricas que cuentan para SEO, no las simuladas de Lighthouse.
Accede a PageSpeed Insights y mira la sección “Descubre qué están experimentando los usuarios reales”. Si INP aparece en rojo o amarillo para mobile y/o desktop, tienes un problema que afecta a tu SEO.
Si no aparece (el sitio tiene poco tráfico y CrUX no tiene datos), usa Lighthouse en modo “user flow” simulando interacciones reales.
Paso 2: Identificar las interacciones problemáticas
Chrome DevTools incluye un panel de Performance específico. Activa el registro, usa la web como usuario normal (scroll, click, formularios), para el registro.
El panel muestra cada long task que ha ocupado el hilo principal. Las tareas de 200+ ms son candidatas a problemas INP. Las de 500+ ms son problemas seguros.
Para cada long task, DevTools muestra qué código la causó. Si es código propio, tienes que refactorizar. Si es código de terceros (tags, analytics, widgets), tienes que decidir si el valor que aporta justifica el coste en performance.
Paso 3: Priorizar por frecuencia de interacción
No todas las interacciones son iguales. Un click en un enlace que el 90% de usuarios hace es crítico. Un click en un menú secundario que el 5% usa es menos urgente.
Cruza los datos de INP con Google Analytics: qué interacciones son las más frecuentes. Prioriza la corrección de las que afectan a más usuarios.
Por qué esto cambia las prioridades de SEO técnico
INP no se arregla optimizando imágenes o mejorando el servidor (eso afecta a LCP, otra métrica distinta). INP se arregla auditando el JavaScript que ejecuta tu web.
Esto mueve el centro de gravedad del SEO técnico. Durante años, la optimización técnica se enfocaba mucho en el lado servidor (compresión, CDN, caching, tiempos de respuesta). INP traslada el foco al frontend: qué JavaScript se ejecuta, cuándo se ejecuta, cómo se ejecuta.
Las webs con más problemas INP suelen ser las construidas con frameworks pesados sin optimización (Next.js/Nuxt con muchos componentes sin lazy-loading), webs con muchos tags de marketing (Google Tag Manager con 30+ tags activos), o sitios con personalización dinámica agresiva.
Qué hacer esta semana si INP es un problema
-
Audita en PageSpeed Insights las 10 URLs más importantes de tu web. Si INP está en rojo en alguna, tienes trabajo.
-
Identifica el JavaScript más pesado: entra en DevTools → Performance → Coverage. Verás qué archivos JS se cargan y cuánto se usa realmente.
-
Pregunta a tu equipo técnico qué tags de marketing están activos y cuáles aportan valor real. Es habitual encontrar 10-15 tags acumulados durante años que ya no se usan y siguen ejecutándose en cada página.
-
Revisa librerías frontend: si usas React/Vue/Angular, ¿haces code-splitting? ¿Tus componentes son lazy? ¿Estás hidratando componentes que podrían ser islas estáticas?
-
Mide semanalmente: crea un dashboard simple en Looker Studio con INP de las páginas principales. Lo que no se mide no mejora.
La oportunidad dentro del problema
El 40% de webs no pasa INP. Eso significa que si optimizas bien este aspecto, tienes ventaja competitiva directa frente a la mayoría de tu sector.
Y a diferencia de otras métricas SEO, INP es muy accionable: las mejoras son técnicas, tienen roadmap claro y los resultados son medibles en 4-6 semanas.
Si tu web tiene problemas de INP y no tienes claro por dónde empezar, contacta con nosotros para un diagnóstico técnico. Llevamos 25 años optimizando performance y Core Web Vitals en proyectos grandes y sabemos qué mueve la aguja en cada caso.
