INP
Interaction to Next Paint
El INP mide el tiempo de respuesta de la página a las interacciones del usuario —clicks, taps en mobile y pulsaciones de teclado. Reemplazó al FID (First Input Delay) como métrica CWV oficial en marzo 2024. A diferencia del FID, el INP evalúa todas las interacciones durante la sesión, no solo la primera.
El valor de INP reportado es el percentil 75 de todas las interacciones medidas. Esto significa que el 75% de las interacciones del usuario deben resolverse dentro del umbral — las lentas pesan, pero no es el máximo absoluto.
Por qué Google reemplazó FID con INP
El FID tenía una limitación fundamental: solo medía la latencia de la primera interacción. Una página podía tener buen FID pero responder lento a todas las interacciones posteriores — formularios, filtros, menús, carritos. INP corrige eso midiendo durante toda la sesión.
| Aspecto | FID (retirado) | INP (vigente) |
|---|---|---|
| Qué mide | Latencia de la primera interacción del usuario (primer click o tecla) | Latencia de TODAS las interacciones durante la sesión completa |
| Valor reportado | Latencia de una sola interacción: la primera | Percentil 75 de todas las interacciones registradas en la sesión |
| Qué ignora | Todo lo que pasa después de la primera interacción | El 25% de interacciones con mayor latencia (percentil 75, no máximo) |
| Por qué cambió | FID ignoraba páginas con interacciones complejas post-carga (formularios, SPAs, carousels) | INP captura la experiencia real durante toda la sesión, no solo el arranque |
| Vigencia | Retirado en marzo 2024 | CWV oficial desde marzo 2024 |
Causas comunes de INP alto y cómo corregirlas
Long tasks en el main thread
Las long tasks son tareas de JavaScript que bloquean el main thread por más de 50ms. Durante una long task, el navegador no puede procesar interacciones del usuario —las encola hasta que la tarea termina.
Fix
Identificar long tasks con el Performance tab de Chrome DevTools. Fragmentar tareas con scheduler.postTask() o setTimeout(fn, 0) para ceder el control al navegador entre chunks de trabajo.
Event handlers pesados
Funciones en event listeners (onClick, onInput, onChange) que hacen trabajo sincrónico intenso —consultas al DOM, cálculos complejos o actualizaciones de estado que desencadenan re-renders masivos.
Fix
Aplicar debounce o throttle en handlers de alta frecuencia (scroll, resize, input). Delegar trabajo pesado a Web Workers para no bloquear el main thread. Minimizar el trabajo hecho durante el handler.
Hidratación síncrona en React/Next.js
Durante la hidratación de una SPA o SSR app, React toma el HTML estático del servidor y adjunta los event listeners. En páginas con mucho JavaScript, este proceso puede bloquear el main thread varios segundos.
Fix
Implementar selective hydration con React.lazy y Suspense. En Next.js App Router, usar React Server Components para evitar enviar JavaScript innecesario al cliente. Explorar Partial Prerendering.
Renderizado no priorizado
Actualizaciones de estado que desencadenan re-renders grandes y no urgentes bloquean updates urgentes. Por ejemplo, filtrar una lista grande en el mismo tick que actualizar el UI feedback del click.
Fix
Usar React.startTransition para marcar updates no urgentes. useDeferredValue para diferir valores que desencadenan renders costosos. Esto permite que React priorice el feedback visual inmediato.
Terceros con scripts bloqueantes
Scripts de analytics, chat widgets, ad networks u otros terceros que ejecutan código pesado en el main thread durante interacciones del usuario. Son especialmente difíciles de controlar.
Fix
Cargar scripts de terceros con async o defer. Usar la Partytown library para ejecutar scripts de terceros en un Web Worker separado. Auditar qué terceros tienen mayor impacto en el Performance tab.
Cómo diagnosticar INP alto
Chrome DevTools — Performance tab
Graba una sesión de interacción y muestra todas las long tasks, el tiempo de procesamiento de cada event handler y el tiempo hasta el siguiente paint. La herramienta más detallada para diagnosticar INP.
Long Animation Frames API (LoAF)
API web nativa (Chrome 116+) que expone información sobre frames de animación que tardaron más de 50ms. Más granular que las Long Tasks API para diagnosticar INP específicamente.
PerformanceObserver con event timing
Permite instrumentar la página en producción para capturar tiempos de interacción reales de usuarios. Útil para páginas con patrones de interacción que no se pueden reproducir fácilmente en laboratorio.
PageSpeed Insights — datos de campo
Muestra el INP del percentil 75 de usuarios reales (CrUX) para la URL especificada. Primer lugar para verificar si el problema existe en datos reales antes de investigar en laboratorio.
Continuar con LCP o CLS
¿Tu sitio responde lento a clicks y formularios?
Un INP alto suele tener causa raíz en JavaScript —long tasks, hidratación pesada o third-party scripts fuera de control. Lo diagnosticamos con datos de campo reales y DevTools, no con suposiciones.
Última actualización: 2026-06-22 · Sistema: ATLAS D01-SEO · Autor: Andrés Castrejón