Tu web pasa el test de velocidad. El LCP está en verde. El CLS no da problemas. Pero desde que Google actualizó los Core Web Vitals en marzo de 2024, hay una tercera métrica que probablemente esté en amarillo o en rojo: el INP.
El INP —Interaction to Next Paint— mide algo diferente a lo que medían las métricas anteriores. No mide cuánto tarda en cargar tu página. Mide cuánto tarda en responder cuando el usuario hace algo: pulsa un botón, abre un menú, filtra un resultado. Y esa diferencia lo hace mucho más difícil de mejorar que cualquier optimización de carga que hayas hecho hasta ahora.
En este artículo: qué mide el INP exactamente, por qué las webs fallan en él aunque tengan buen rendimiento de carga, y qué se puede hacer cuando el número es demasiado alto.
Qué mide el INP y en qué se diferencia del FID
El First Input Delay (FID) medía el tiempo hasta que el navegador podía empezar a procesar la primera interacción del usuario. Era una métrica parcial: solo medía la primera, y solo medía el retraso en el inicio del procesamiento, no el tiempo hasta que el usuario veía alguna respuesta visual.
El Interaction to Next Paint (INP) mide el tiempo completo de respuesta de cualquier interacción durante toda la sesión del usuario: desde que pulsa hasta que el navegador actualiza la pantalla. Y toma el percentil 98 de todas las interacciones de la sesión, no la primera. Eso significa que una sola interacción lenta en un flujo complejo puede arrastrar el INP de toda la página.
| Criterio | FID (retirado) | INP (actual) |
|---|---|---|
| Qué mide | Retraso en el inicio del procesamiento | Tiempo completo de respuesta visual |
| Qué interacciones | Solo la primera interacción | Todas las interacciones de la sesión |
| Umbral «bueno» | Menos de 100ms | Menos de 200ms |
| Umbral «necesita mejora» | 100–300ms | 200–500ms |
| Dónde fallaban webs | Scripts de terceros bloqueando el hilo | JavaScript pesado en respuesta a interacciones |
| Impacto en ranking | Factor de ranking desde 2021 | Factor de ranking desde marzo de 2024 |
Por qué el INP es más difícil de mejorar que el LCP
El LCP —Largest Contentful Paint— mide cuándo se renderiza el elemento más grande visible. Las optimizaciones son relativamente directas: comprimir imágenes, usar CDN, eliminar recursos bloqueantes, preconectar a orígenes críticos. Hay un playbook establecido.
El INP no tiene un playbook único porque el problema puede estar en cualquier interacción de cualquier flujo. Un desplegable de navegación lento, un filtro de catálogo que bloquea el hilo, un formulario que tarda en validar: cualquiera de ellos puede ser el punto de falla. Identificar cuál de todas las interacciones de tu web está generando el peor INP requiere datos de usuario real (CrUX) o herramientas de profiling en el navegador, no solo PageSpeed Insights.
Otra razón: las causas del INP alto suelen estar en el JavaScript de la aplicación, no en los recursos externos. Y el JavaScript de la aplicación es código propio que hay que refactorizar. No se resuelve cambiando un parámetro de configuración. Requiere entender qué hace el hilo principal cuando el usuario interactúa y por qué tarda más de 200ms en liberar control.
Las causas más frecuentes de un INP alto
Tareas largas en el hilo principal. JavaScript que se ejecuta en bloques de más de 50ms sin ceder el control al navegador. Cuando el hilo está ocupado procesando una tarea larga, no puede responder a las interacciones del usuario. El resultado es una interfaz que se siente congelada aunque el diseño sea correcto.
Manipulación del DOM excesiva en respuesta a eventos. Cuando un clic en un botón desencadena recalcular estilos, relayoutar y repintar una porción grande del DOM, el tiempo hasta el siguiente paint sube. Reducir el alcance del DOM que se modifica en cada interacción es una de las optimizaciones con más impacto en el INP.
Renderizado síncrono en frameworks JavaScript. Frameworks como React, Angular o Vue pueden generar actualizaciones de estado que bloquean el hilo hasta completar el renderizado. Las APIs de renderizado concurrente (como Concurrent Mode en React 18) dividen el trabajo en fragmentos más pequeños que no bloquean el hilo principal.
Scripts de terceros que se ejecutan en el hilo principal. Analytics, chat, mapas, herramientas de personalización: cualquier script de tercero que se ejecute en el hilo principal compite con tus propias interacciones. Identificar cuáles contribuyen al INP y moverlos a Web Workers cuando sea posible es una mejora con alto impacto.
Tip técnico: usar isInputPending() para ceder el hilo en tareas largas
La API navigator.scheduling.isInputPending() permite que una tarea larga de JavaScript compruebe si hay interacciones pendientes del usuario y, si las hay, ceda el control al hilo principal antes de continuar. Es una técnica de yielding que permite dividir el trabajo sin usar setTimeout(0) de forma ciega. El patrón es: ejecutar un bloque de trabajo, comprobar si hay input pendiente, ceder el hilo si lo hay, retomar el trabajo. Compatible con Chrome y Edge. Combinado con el scheduler.yield() de la Scheduler API, es el enfoque más moderno para optimizar INP en aplicaciones con JavaScript intensivo.
Cómo medir el INP real de tu web
PageSpeed Insights muestra el INP del laboratorio (Lighthouse) y el INP de campo (CrUX, datos reales). El dato relevante para el ranking de Google es el de campo. Si tu web tiene poco tráfico, puede no haber datos suficientes en CrUX y la métrica aparecerá como «sin datos».
Para medir el INP de forma más granular, la librería web-vitals de Google permite instrumentar el INP en tu propio código y enviarlo a Analytics o a cualquier sistema de monitorización. La función onINP() reporta el valor del INP junto con la interacción que lo causó (elemento, tipo de evento, tiempo de procesamiento). Es la forma más directa de saber exactamente dónde está el problema.
Si trabajas con un proyecto de desarrollo web a medida, añadir esta instrumentación es trabajo de horas. Si tu web está en un CMS con código no accesible, las opciones de diagnóstico granular son más limitadas. Puede ser otro argumento para el análisis de deuda técnica que mencionábamos en otro artículo.
Preguntas frecuentes sobre INP y Core Web Vitals
¿El INP afecta directamente al posicionamiento en Google?
Sí, desde marzo de 2024. Google incluye los Core Web Vitals —LCP, INP y CLS— como señales de la experiencia de página en el algoritmo de ranking. Un INP en rojo (más de 500ms) es una señal negativa. No es el único factor, pero compite con el resto de factores SEO en queries donde la intención y el contenido son equivalentes entre competidores.
¿Cómo sé cuánto está afectando el INP a mi ranking actual?
No hay una correlación directa visible. Google Search Console muestra el estado de los Core Web Vitals (bueno, necesita mejora, deficiente) pero no el impacto específico en posiciones. La forma de estimarlo es comparar el rendimiento de posicionamiento de páginas con INP bueno vs páginas con INP deficiente dentro del mismo sitio, controlando el resto de variables.
¿Qué es más prioritario, mejorar el LCP o el INP?
Depende de cuál está en peor estado. Si los dos están en rojo, empieza por el LCP porque sus soluciones son más directas y tienen impacto en la percepción de velocidad al cargar. Si el LCP está en verde y el INP no, el INP es la prioridad. Si los dos están en verde, el siguiente nivel es el INP porque es el más difícil de mantener en verde a medida que el proyecto crece en complejidad.
