El INP (Interaction to Next Paint) es el Core Web Vital que mide la capacidad de respuesta de tu página: el tiempo que pasa desde que un usuario hace clic, toca la pantalla o presiona una tecla hasta que el navegador muestra el siguiente frame visual como respuesta. Cuanto más bajo, mejor.
Desde marzo de 2024 el INP reemplazó oficialmente al FID (First Input Delay) como métrica de interactividad en los Core Web Vitals de Google. A diferencia del FID, el INP evalúa todas las interacciones durante la sesión, no solo la primera.
INP vs FID: ¿por qué cambiaron la métrica?
El FID solo medía el retraso antes de que el navegador procesara la primera interacción. Era útil como señal de carga inicial, pero ignoraba todo lo que ocurría después: los clics en menús, los envíos de formularios, las búsquedas internas. Muchos sitios tenían un FID excelente y aun así respondían lento durante la navegación normal.
El INP corrige ese punto ciego midiendo la interacción con mayor latencia de toda la sesión. Así refleja mejor la experiencia real del usuario a lo largo de toda su visita.
¿Qué interacciones cuenta el INP?
- Clics con el ratón
- Toques en pantalla táctil
- Pulsaciones de teclado
El desplazamiento con scroll y el hover no cuentan para el INP, ya que no generan "frames de respuesta" de la misma manera.
Cómo se calcula el INP
Para cada interacción que cuenta, el navegador mide tres fases:
- Input delay: el tiempo desde la interacción hasta que el main thread queda libre para procesarla.
- Processing time: el tiempo que tardan los event handlers de JavaScript en ejecutarse.
- Presentation delay: el tiempo desde que los handlers terminan hasta que el navegador pinta el siguiente frame.
La suma de las tres fases es la latencia de esa interacción. El INP final es la latencia de la peor interacción de la sesión (con un pequeño margen estadístico para ignorar valores atípicos extremos en sesiones con muchas interacciones).
Umbrales de Google
| Puntuación INP | Valoración |
|---|---|
| 200 ms o menos | Bueno |
| Entre 200 ms y 500 ms | Necesita mejora |
| Más de 500 ms | Malo |
El objetivo es un INP de 200 ms o menos. Por encima de 500 ms el usuario percibe la página como claramente lenta e irresponsiva.
¿Qué provoca un INP alto?
La causa raíz casi siempre es el main thread bloqueado. Cuando JavaScript está ocupado ejecutando tareas largas, las interacciones del usuario se quedan en cola esperando su turno.
Tareas largas de JavaScript
Cualquier tarea que ocupe el main thread más de 50 ms se considera "larga" (long task). Scripts de terceros —analytics, chats, publicidad, redes sociales— son los principales culpables. También el código propio mal optimizado: bucles pesados, renderizado ineficiente o cálculos síncronos costosos.
Event handlers pesados
Hacer demasiado trabajo dentro de un handler de clic o de teclado retrasa directamente el "processing time". Si un clic en un botón desencadena una llamada a API síncrona, un recálculo de layout completo o la manipulación de cientos de nodos del DOM, el INP sube.
Presentation delay elevado
Aunque los handlers terminen rápido, si el navegador tiene que calcular un layout complejo o renderizar muchos elementos nuevos antes de pintar el siguiente frame, el presentation delay se dispara. Reducir la cantidad de elementos afectados por cada interacción ayuda aquí.
Cómo diagnosticar tu INP
Necesitas datos de usuarios reales para diagnosticar correctamente el INP:
- PageSpeed Insights — muestra el INP del percentil 75 de tus usuarios reales (datos CrUX). Es el punto de partida.
- Search Console → Core Web Vitals — agrupa las URLs de tu sitio por su estado en INP con datos reales.
- Chrome DevTools → Performance — graba una sesión de interacción. Cada interacción aparece como un bloque en la timeline. Busca los bloques más largos y expande para ver en qué fase se pierde tiempo.
- PerformanceObserver API — implementa
new PerformanceObserver()con el tipo'event'para registrar las latencias de interacción de tus usuarios reales en producción.
El panel de Performance de Chrome también muestra las "long tasks" en rojo sobre el main thread — ahí es donde debes empezar a investigar.
Cómo mejorar el INP
Mejorar el INP significa liberar el main thread para que pueda responder a las interacciones más rápido. Estas son las estrategias más efectivas:
1. Rompe las tareas largas
Divide el trabajo pesado en tareas más pequeñas usando setTimeout(fn, 0) o la API scheduler.yield() (cuando esté disponible). Esto da al navegador la oportunidad de procesar interacciones pendientes entre tarea y tarea.
2. Carga diferida de scripts de terceros
Los scripts de analytics, publicidad y social suelen ser la fuente número uno de long tasks. Cárgalos con defer o async, o mejor aún, atrásalos hasta después del primer clic del usuario con la técnica de "facade" (un elemento placeholder que carga el script real solo cuando el usuario interactúa).
3. Optimiza tus event handlers
Mueve el trabajo pesado fuera del handler principal. Si necesitas procesar datos después de un clic, usa requestAnimationFrame para el trabajo visual y relega el resto a un Web Worker. Evita manipular el DOM masivamente dentro de un handler.
4. Reduce el DOM size
Un DOM de miles de nodos hace que cada recálculo de layout sea más lento. Apunta a menos de 1.500 nodos en total y usa virtualización para listas largas (renderizar solo los elementos visibles).
5. Usa CSS para animaciones y transiciones
Las transiciones CSS se ejecutan en el hilo del compositor, no en el main thread, por lo que no afectan al INP. Siempre que sea posible, delega las animaciones a CSS en lugar de JavaScript.
Si tu sitio tiene un INP problemático y no sabes por dónde empezar, un equipo especializado en rendimiento web puede identificar las long tasks concretas que están afectando tu puntuación.
Consulta también nuestra guía completa de rendimiento web para ver todas las métricas en contexto.
INP y el impacto en SEO y conversión
Con el reemplazo del FID en marzo de 2024, el INP ya es una señal de ranking activa en Google. Un INP malo en un nicho competitivo puede costar posiciones frente a competidores con mejor experiencia de usuario.
El impacto en conversión es aún más directo: si un usuario hace clic en "Agregar al carrito" y la página tarda 800 ms en reaccionar visualmente, la sensación de que "algo no funcionó" aumenta el abandono. Los estudios de Google muestran que sitios con buen INP tienen tasas de conversión significativamente superiores a los que tienen un INP malo.
Conclusiones clave
- El INP mide la latencia de la peor interacción de la sesión; el objetivo es 200 ms o menos.
- Reemplazó al FID en marzo de 2024 porque evalúa toda la sesión, no solo la primera interacción.
- La causa raíz más frecuente es el main thread bloqueado por tareas largas de JavaScript.
- Los scripts de terceros (analytics, ads, social) son los sospechosos habituales.
- Para mejorar el INP: rompe las tareas largas, carga scripts de terceros diferidamente y optimiza tus event handlers.
¿Tu INP está por encima de 200 ms? Contáctanos en elenlace.com y realizamos una auditoría de rendimiento para identificar exactamente qué está bloqueando tu main thread.
Preguntas frecuentes
¿El INP afecta a todos los tipos de sitio web?
Sí, pero impacta más a sitios con mucha interactividad: e-commerce, formularios complejos, aplicaciones web tipo SPA (Single Page App) y medios con barras de búsqueda o filtros. Un blog estático con poco JavaScript rara vez tiene problemas de INP.
¿Por qué mi INP en laboratorio es bueno pero en campo es malo?
Las herramientas de laboratorio (Lighthouse, DevTools) simulan condiciones controladas con pocos scripts activos. Los datos de campo reflejan usuarios reales con extensiones del navegador, conexiones variables y sesiones largas donde el JavaScript acumula trabajo. Siempre prioriza los datos de campo para el INP.
¿Un INP de 200 ms se puede alcanzar en sitios con mucho JavaScript?
Sí, con las técnicas correctas. Los sitios más exigentes del mundo (Gmail, YouTube, Amazon) mantienen un INP aceptable dividiendo el trabajo en tareas pequeñas, usando Web Workers para cómputo pesado y cargando scripts de terceros de forma diferida.
¿El INP mide solo el tiempo de respuesta visual o también el procesamiento interno?
El INP mide el tiempo total desde la interacción hasta el siguiente frame pintado, que incluye el input delay, el processing time y el presentation delay. No mide lo que ocurre después de ese primer frame (por ejemplo, una animación posterior), solo la respuesta visual inmediata.
Recursos útiles
Otros proveedores y guías que vale la pena comparar:
