FID solo medía la primera interacción. INP mide la peor interacción durante toda la sesión del usuario, lo cual es mucho más representativo. Una página puede cargar rápido y ser lenta al hacer clic, y eso es lo que INP captura.
Clasificación
- Bueno: ≤ 200 ms
- Necesita mejora: entre 200 y 500 ms
- Malo: > 500 ms
Qué mide exactamente
INP es el tiempo desde que el usuario hace una acción hasta que el siguiente frame se pinta. Incluye:
- Tiempo de procesamiento del evento (JavaScript)
- Tiempo de bloqueo del main thread
- Tiempo de renderizado del nuevo frame
Causas de mal INP
- Listeners de eventos con lógica pesada (handlers que ejecutan mucho código)
- Librerías gigantes en main thread (jQuery viejo, bundles de 2 MB)
- Third-party scripts (Tag Manager con decenas de tags, widgets de chat pesados)
- React re-renders masivos por no optimizar
- Layout thrashing (lecturas y escrituras al DOM intercaladas)
Soluciones
- Code splitting: dividir el bundle para que no se cargue todo el JS de golpe
- Debounce y throttle en eventos frecuentes (scroll, resize, input)
- Web Workers para lógica pesada fuera del main thread
- requestIdleCallback para tareas no urgentes
- Virtualización de listas largas (react-window, react-virtual)
- Eliminar o diferir third-party no crítico
- useMemo / useCallback en React para evitar renders innecesarios
Medir INP
- PageSpeed Insights (datos de campo)
- Web Vitals extension de Chrome
- Lighthouse en sesión simulada
- RUM (Real User Monitoring) con librerías como web-vitals.js
Errores comunes
- Optimizar LCP y olvidar INP (dos métricas distintas)
- Probar solo en móvil de gama alta (el INP se dispara en móviles gama media/baja)
- No medir en condiciones reales (usuarios con red 3G-4G, CPU limitada)
Auditamos INP y el resto de Core Web Vitals en cada proyecto. Pide tu auditoría.