La optimización INP es el proceso de reducir cuánto tarda tu página en responder visualmente después de que un usuario hace clic, toca o pulsa una tecla. Interaction to Next Paint mide esa latencia durante toda la visita y reporta un valor cercano al peor, así que aprobarlo significa que cada interacción importante —no solo la media— tiene que sentirse rápida. Si tu informe de Core Web Vitals muestra un INP en rojo o ámbar, esta guía recorre cómo diagnosticar las interacciones lentas y arreglarlas de raíz.
INP es el Core Web Vital que más sitios suspenden, y el que más equipos malinterpretan. No es una métrica de carga. Mide la capacidad de respuesta en tiempo de ejecución —lo que pasa cuando alguien usa la página de verdad—, lo que lo hace más difícil de falsear y más difícil de arreglar que las métricas que lo acompañan. Acertar con la optimización INP ya es lo mínimo exigible en SEO técnico para cualquier sitio interactivo.
Qué mide INP realmente
Google sustituyó First Input Delay por Interaction to Next Paint como Core Web Vital el 12 de marzo de 2024, según la documentación de web.dev de Google. El cambio importa porque FID solo contaba el retraso antes de que el navegador empezara a gestionar tu primera interacción. Ignoraba todo lo que venía después. Una página podía sacar un FID perfecto y aun así congelarse un segundo entero cada vez que alguien tocaba un filtro.
INP cierra ese hueco. Observa casi todas las interacciones a lo largo de la vida de la página y reporta un único valor cercano al peor. Cada interacción se divide en tres partes:
- Input delay — tiempo desde el toque o clic hasta que arranca el event handler, normalmente esperando a que el hilo principal se libere.
- Tiempo de procesamiento — cuánto tardan en ejecutarse tus event handlers.
- Presentation delay — tiempo que tarda el navegador en recalcular el layout y pintar el siguiente frame.
Una interacción se siente lenta cuando cualquiera de esas tres fases se alarga. La mayoría de los problemas reales de INP viven en la primera y la tercera fase: un hilo principal ocupado que no puede arrancar tu handler, o un re-render costoso que retrasa el pintado. El tiempo de procesamiento del medio suele ser menor de lo que la gente supone.
El umbral no perdona. Un buen INP es de 200 milisegundos o menos en el percentil 75 de los datos de campo, según la guía de INP de web.dev. Entre 200 y 500 milisegundos necesita mejora; por encima de 500 milisegundos es malo. Como Google usa el percentil 75, tu cuarto de interacciones más lento decide el resultado. Tu mediana puede ser excelente y aun así suspendes.
Por qué INP es una preocupación real de posicionamiento
Los Core Web Vitals alimentan las señales de experiencia de página de Google, que sus sistemas usan para separar páginas de relevancia comparable. La documentación de Google Search Central es explícita en que son un criterio de desempate, no un factor primario. La optimización INP no rescatará un contenido pobre ni un perfil de enlaces débil.
Pero ese marco de “desempate” se queda corto en móvil. Las interacciones en el teléfono son más lentas —CPUs más débiles, más throttling térmico, scripts de anuncios y etiquetas más pesados—, así que el INP móvil es donde los sitios sangran. Si tu posicionamiento es fuerte pero tu CTR y tu engagement flojean en móvil, un INP malo suele ser parte de la historia. Este es el tipo de brecha que una auditoría de SEO técnico en condiciones está pensada para detectar antes de que aparezca como ingresos perdidos.
Hay una segunda razón, más silenciosa, para preocuparse. INP se correlaciona con cómo se siente la página, y una página que se siente lenta pierde conversiones sin importar dónde posicione. Estás optimizando lo mismo que Google: usuarios que no abandonan.
El proceso de depuración de INP en cinco pasos
Uso la misma secuencia en cada proyecto. Va de la evidencia real a la causa raíz y a la solución, en ese orden, porque el mayor error de los equipos es optimizar interacciones que nunca fueron lentas para los usuarios reales.
Paso 1 — Confirma el problema en datos de campo. Abre el informe de Core Web Vitals en Google Search Console o pasa la URL por PageSpeed Insights. Ambos usan datos del Chrome UX Report —usuarios reales de Chrome, no una prueba sintética de laboratorio—. Si el INP de campo está en verde, para. No tienes un problema de INP que merezca la pena perseguir, diga lo que diga tu puntuación de laboratorio.
Paso 2 — Identifica qué interacciones son lentas. Los datos de campo te dicen que la página tiene un problema, no qué botón lo causa. Usa la librería JavaScript web-vitals o una herramienta de monitorización de usuarios reales para atribuir el INP a elementos y tipos de evento concretos. En la mayoría de los sitios, dos o tres interacciones —un menú, un filtro, un añadir al carrito— concentran casi todo el daño.
Paso 3 — Reprodúcelo en el laboratorio. Abre Chrome DevTools, limita la CPU con un throttling de 4x para simular un móvil de gama media y graba la interacción lenta en el panel Performance. Buscas la long task en el hilo principal que bloquea la respuesta. Las long tasks —cualquier cosa que supere los 50 milisegundos— son la materia prima de un INP malo.
Paso 4 — Atribuye el coste. Lee el flame chart. ¿El retraso está antes de que corra tu handler (input delay por un hilo principal bloqueado), dentro del handler (trabajo síncrono pesado), o después (un re-render costoso o layout thrashing)? La fase decide la solución. Aquí es donde el Total Blocking Time de tus informes de laboratorio se vuelve útil: un TBT alto casi siempre predice un INP malo, porque ambos los provocan las long tasks del hilo principal.
Paso 5 — Arregla y vuelve a medir en campo. Despliega la corrección y espera. Los datos de campo son una ventana móvil de 28 días, así que una mejora real tarda semanas en aparecer del todo en Search Console. No juzgues la corrección solo por el número de laboratorio.
Las correcciones que de verdad mueven el INP
Una vez que conoces la fase, los remedios son concretos.
Divide las long tasks. La corrección de mayor impacto. Cualquier script que corra más de 50 milisegundos bloquea toda interacción que caiga durante ese tiempo. Parte el trabajo largo en trozos más pequeños y devuelve el control al navegador entre ellos —scheduler.yield() donde esté soportado, o patrones con setTimeout y await como alternativa—. Ceder el control permite gestionar un clic pendiente entre trozos en vez de después de todos.
Recorta y aplaza el JavaScript. Menos código en el hilo principal es menos riesgo de INP. Audita los scripts de terceros sin piedad: widgets de chat, herramientas de test A/B, analítica y gestores de etiquetas son infractores habituales porque corren en cada interacción. Aplaza o carga en diferido todo lo que no haga falta para la primera interacción. En mi experiencia auditando sitios, los scripts de terceros son la causa de INP que los equipos más pasan por alto, precisamente porque los añadió marketing, no ingeniería, y nadie asume su coste de rendimiento.
Saca trabajo del camino crítico. Si un event handler hace un cálculo costoso, haz lo mínimo para dar feedback visual primero —actualiza la UI— y luego ejecuta el trabajo pesado, idealmente en un web worker o después del siguiente pintado. El usuario ve una respuesta inmediata aunque el resultado completo tarde más.
Reduce el coste de renderizado y de DOM. El presentation delay crece con el tamaño del DOM y la complejidad del layout. Árboles DOM grandes, componentes muy anidados y CSS que fuerza layout síncrono ralentizan el pintado tras una interacción. Simplifica el DOM, evita el layout thrashing y usa content-visibility en CSS para saltarte el renderizado del contenido fuera de pantalla.
Arregla la hidratación en sitios con framework. En React, Vue y stacks similares, la hidratación puede bloquear el hilo principal justo en la ventana en que los usuarios intentan interactuar por primera vez. Plantéate hidratación progresiva o selectiva, server components o arquitectura de islas para que la página se vuelva interactiva por partes en lugar de toda de golpe.
Un checklist de optimización INP
Repásalo antes de dar una interacción por arreglada:
- El INP de campo está confirmado en rojo o ámbar en Search Console: arreglas un problema real
- Las interacciones lentas concretas están identificadas por elemento y tipo de evento
- La interacción lenta se reproduce en DevTools con throttling de CPU de 4x
- La long task que bloquea está identificada en el flame chart de Performance
- La fase del retraso está atribuida (input delay, procesamiento o presentation)
- Las long tasks de más de 50 ms se dividen cediendo el control
- Los scripts de terceros no esenciales están aplazados o eliminados
- El trabajo pesado del handler corre después del feedback visual, no antes
- El tamaño del DOM y el coste de layout se reducen donde retrasan el pintado
- La corrección se verifica en datos de campo tras la ventana de 28 días
Trabaja de arriba abajo. Saltarte los pasos de datos de campo es como los equipos gastan un sprint optimizando una interacción que nunca fue lenta para los usuarios reales.
Dónde encaja la optimización INP en tu estrategia
INP es una palanca, y vive dentro de la experiencia de página, que vive dentro de un panorama de posicionamiento mucho más amplio. Arréglalo porque una página rápida y receptiva convierte mejor y te protege en las decisiones ajustadas de ranking, no porque esperes que sea lo que te suba de la página dos a la uno. Rara vez funcionan así los Core Web Vitals.
Si tus datos de campo muestran un fallo persistente de INP y tu equipo no encuentra la causa raíz, suele ser señal de que el problema es arquitectónico: demasiado JavaScript, demasiadas etiquetas, una estrategia de renderizado que pelea contra el hilo principal. Eso merece traer una mirada externa. Un proyecto de SEO técnico enfocado o una auditoría puntual encontrarán las tareas bloqueantes más rápido que un equipo depurando su propio código, y si quieres entender cómo trabajo antes de comprometerte, la página de consultor freelance lo explica. La buena optimización INP es poco glamurosa, medible y permanente una vez hecha: exactamente el tipo de trabajo técnico que compone en silencio.
Preguntas frecuentes
¿Qué es un buen valor de INP?
Un buen Interaction to Next Paint es de 200 milisegundos o menos en el percentil 75 de tus datos de campo, tanto en móvil como en escritorio. Entre 200 y 500 milisegundos necesita mejora, y por encima de 500 milisegundos es malo. Google mide en el percentil 75, así que tu cuarto de interacciones más lento determina si la página aprueba.
¿Es INP un factor de posicionamiento de Google?
Sí, indirectamente. INP es uno de los tres Core Web Vitals, y los Core Web Vitals alimentan las señales de experiencia de página de Google, que actúan como criterio de desempate entre páginas de relevancia similar. Un INP malo no hunde por sí solo un buen contenido, pero puede costarte las decisiones ajustadas, sobre todo en móvil.
¿Cuál es la diferencia entre INP y FID?
First Input Delay solo medía el retraso antes de que el navegador empezara a gestionar tu primera interacción. INP mide la latencia completa —input delay, tiempo de procesamiento y presentation delay— de casi todas las interacciones de la visita y reporta un valor cercano al peor. Eso hace INP mucho más difícil de aprobar, y por eso Google sustituyó FID por él en marzo de 2024.
¿Cómo mido el INP de mi sitio?
Empieza por los datos de campo: el informe de Core Web Vitals en Google Search Console, o PageSpeed Insights para una sola URL, ambos con datos del Chrome UX Report. Cuando confirmes un problema real, reproduce la interacción lenta en el panel Performance de Chrome DevTools con throttling de CPU para encontrar la long task que bloquea la respuesta.
¿Los frameworks de JavaScript pueden causar mal INP?
Con frecuencia. La hidratación pesada, los scripts de terceros y los event handlers costosos se ejecutan en el hilo principal y bloquean la respuesta del navegador. Los frameworks no son el problema en sí —lo es enviar demasiado JavaScript y hacer demasiado trabajo síncrono en los callbacks—, pero ese patrón es común en sitios React y Vue.
