INP: la métrica que está reescribiendo el ranking en 2026

INP (Interaction to Next Paint) es la métrica de interactividad de Core Web Vitals: mide cuánto tarda tu sitio en responder a cada clic o tap del usuario. Un INP malo daña la experiencia y, desde marzo de 2024, tu ranking en Google. Es la métrica donde más PyMEs están fallando hoy en móvil.

Imagínate esta escena. Estás en una tienda online, buscando un producto. Lo agregas al carrito. Haces clic en “Comprar”. Y nada pasa.

Pasan dos segundos. Vuelves a hacer clic. Tres segundos. Cuatro. La página finalmente reacciona, pero ya hiciste clic cuatro veces. Tu pedido se duplicó. Te enojas. Te vas.

Eso es INP malo. Y Google lo está midiendo desde marzo de 2024.

Si estás llegando aquí sin contexto previo de Core Web Vitals, conviene partir por el pillar Mide tu sitio antes de invertir, donde explicamos las tres métricas juntas (LCP, INP, CLS) y cómo medir tu baseline. Acá vamos a profundizar específicamente en INP.

Qué es INP (y por qué reemplazó a FID)

INP significa Interaction to Next Paint. Mide el tiempo entre que el usuario hace algo (clic, tap, scroll, escribir) y el momento en que la página responde visualmente.

Hasta marzo de 2024, Google medía algo parecido pero más limitado: FID (First Input Delay). FID solo evaluaba la primera interacción del usuario en la página. INP cambió eso: ahora se mide cada interacción durante toda la sesión.

¿Por qué importa el cambio? Porque la mayoría de los problemas de responsividad no están en la primera interacción. Están en las décimas o vigésimas: cuando el JavaScript ya se cargó pero sigue trabajando en segundo plano, cuando un script de chat o analytics se ejecuta tarde, cuando una imagen pesada se descarga y bloquea el render.

INP captura todo eso. Es más estricto, más realista y más fiel a lo que siente el usuario.

Los umbrales: dónde estás y dónde deberías estar

El INP se mide en milisegundos:

• Bueno: menos de 200ms
• Necesita mejorar: entre 200 y 500ms
• Pobre: más de 500ms

Para que te quede dimensionado: 200ms es lo que tarda un ojo humano en parpadear. Si tu sitio responde más rápido que un parpadeo, el usuario lo percibe como instantáneo. Si tarda más de medio segundo, lo percibe como pesado o lento.

Según el reporte de Core Web Vitals de HTTPArchive de noviembre de 2025, cerca del 67% de los sitios pasa INP en desktop. En móvil, ese número baja al 49%. La diferencia importa: el 70% del tráfico web hoy es móvil. Y si miramos las tres métricas Core Web Vitals juntas (LCP, INP, CLS), el porcentaje de sitios que pasa las tres en simultáneo cae a cerca del 55%, como repasamos en Mide tu sitio antes de invertir.

Si tu sitio está construido sobre WordPress con plugins acumulados, sobre Shopify con apps de marketing instaladas, sobre cualquier stack que cargue muchos scripts de terceros, hay alta probabilidad de que estés en ese 51% que falla INP en móvil. Vale la pena mencionar que muchos de esos mismos scripts también degradan tu LCP, así que las dos métricas se atacan en paralelo: el patrón completo para LCP está en El patrón que reduce tu LCP 4 veces sin reescribir tu sitio.

Las tres causas reales de un INP malo

INP malo casi nunca es un problema único. Es la suma de tres patrones.

1. JavaScript de terceros bloqueando el main thread

Cada vez que instalas un chat (Tawk, Intercom, Crisp), un analytics (GA4, Mixpanel, Hotjar), un tag de Ads (Google Tag Manager, Meta Pixel) o un plugin de redes sociales, agregas JavaScript que se ejecuta en el navegador del visitante.

Cuando el navegador está ejecutando ese JavaScript, no puede responder a los clics del usuario. El usuario hace tap, el navegador ve el tap pero no puede procesarlo hasta que el script termine. Eso son los milisegundos que se acumulan en tu INP.

El problema típico: empiezas con un solo script. Sumas el chat. Después el pixel de Facebook. Después un widget de testimonios. Después un script de pop-up de descuento. Cada uno suma 50 a 150ms. La acumulación es lo que rompe el INP.

2. Hydration costosa en sitios JavaScript-first

Si tu sitio está hecho con React, Vue, Next.js, Nuxt o cualquier framework JS-first sin optimización específica, el navegador tiene que hidratar el HTML estático con JavaScript antes de que sea interactivo.

Para una landing simple, esto puede tomar 800ms a 2 segundos en móvil de gama media. Durante ese tiempo, el sitio se ve pero no responde a clics. Eso destruye INP.

Las arquitecturas modernas (islands en Astro, partial hydration en Qwik, RSC en Next 14+) atacan exactamente este problema. Pero requieren refactor del sitio, no son flags que se prendan. Si no quieres meterte en ese refactor por tu cuenta, los servicios de presencia digital gestionada de Lopia parten de un stack liviano que cuida INP desde el primer día.

3. Animaciones y efectos que se calculan en el main thread

Animaciones hechas con setTimeout, setInterval o JavaScript de scroll personalizado bloquean el thread principal. Cada frame de la animación es trabajo del navegador que compite con tus interacciones.

Las animaciones que sí funcionan bien son las que usan transform y opacity en CSS, o requestAnimationFrame correctamente. Si tu sitio tiene scrolls que se sienten trabados o efectos parallax que cuelgan, ahí está tu problema.

Cómo identificar tu problema de INP en 5 minutos

Hay tres herramientas para diagnosticar INP. Cada una te da una capa de información distinta.

Primero, el auto-diagnóstico de Lopia. Pega tu URL en lopia.cl/diagnostico y mira el número de INP en mobile. Si es rojo, ya sabes que tienes un problema. El reporte te da las oportunidades priorizadas: cuáles scripts pesan más, qué optimizaciones aplicar primero.

Segundo, Chrome DevTools en modo Performance. Para análisis técnico profundo. Abres tu sitio en Chrome, abres DevTools, vas a la pestaña Performance, presionas grabar, interactúas con el sitio, y obtienes un timeline detallado de qué script bloqueó qué interacción.

Tercero, Search Console > Core Web Vitals. Te muestra el INP real de tus visitantes (datos de campo), no de un test sintético. Es la métrica que Google usa para decidir tu ranking. Si Search Console te dice que tienes URLs con INP pobre, esas son las que tienes que arreglar primero.

Cuándo INP es prioridad para tu negocio

Como cualquier métrica, INP no se arregla en abstracto. Se arregla cuando tiene impacto en tu negocio.

Vale la pena trabajarlo si:

• Tu sitio tiene formularios, carrito de compra o cualquier flujo interactivo crítico
• Recibes más de 3 mil visitas al mes en móvil
• Tu tasa de abandono en mobile es mayor que en desktop (signo de UX con falencias)
• Estás compitiendo por keywords donde Google premia mobile UX

Probablemente no es prioridad si:

• Tu sitio es informativo puro, sin interacciones críticas
• Tu audiencia es mayoritariamente desktop con conexión rápida (B2B corporativo)
• Tienes problemas más graves sin resolver: contenido confuso, sitio no responsive, propuesta de valor poco clara

La regla simple: si el usuario se va antes de hacer la primera interacción importante (clic en CTA, llenar formulario), INP no es tu cuello de botella. Si el usuario llega hasta el formulario pero lo abandona a medio llenar, INP probablemente sí lo es.

El camino corto: priorización en tres pasos

Si decides atacarlo, no intentes arreglar todo de una vez. Aplica este orden:

Paso 1, auditar scripts de terceros. Revisa qué scripts tienes instalados. Para cada uno, pregunta: ¿está dando valor que justifique su costo en performance? Si no lo sabes, prueba quitarlo por 7 días y mide. Habitualmente, hay 2 o 3 scripts que se pueden eliminar sin pérdida real de funcionalidad.

Paso 2, defer + async. De los scripts que sí necesitas, configura los que se puedan con atributo defer o async. Esto le dice al navegador que no bloquee el render mientras los carga. La diferencia en INP puede ser del 30% al 40%.

Paso 3, lazy-load lo no crítico. Chat widgets, analytics secundarios, pixels de campañas que no están corriendo: carga todo eso después de la primera interacción del usuario, no antes. Eso baja INP drásticamente sin perder funcionalidad.

Estos tres pasos resuelven el 70% de los problemas de INP en sitios PyME chilenos. El resto requiere análisis más profundo, pero típicamente ya estás en zona verde con esto. Mantener ese rendimiento en el tiempo es justamente lo que cubren los productos de presencia gestionada de Lopia, donde el monitoreo del stack es continuo y no algo que revisas una sola vez.

Lo que cambió en 2026 y por qué importa más que antes

A partir de 2025, INP pasó a tener mayor peso relativo dentro del scoring de experiencia de página que Google usa para evaluar sitios. Esto significa que un INP pobre baja más posiciones que antes por el mismo problema.

Al mismo tiempo, los crawlers de IA (ChatGPT, Perplexity, Claude) que evalúan sitios para citarlos en respuestas están privilegiando sitios con buen INP, porque es un proxy de la calidad técnica general del sitio. Un INP malo es señal de un sitio con muchos plugins acumulados, baja optimización y poco mantenimiento. Las IAs prefieren citar sitios bien gestionados.

Para una PyME, esto se traduce en dos cosas: pierdes ranking en Google, y empiezas a aparecer menos cuando los usuarios buscan con IA. Ambas tendencias se aceleraron en 2025 y 2026.

Antes de cualquier otra optimización

Si te preguntas por dónde empezar este mes para mejorar tu posicionamiento, mide tu INP primero. No tu LCP, no tu CLS, no tu Core Web Vitals general. Tu INP en mobile.

Es la métrica donde más PyMEs están fallando, donde más fácil es ver el impacto de los cambios, y la que Google está privilegiando más en 2026.

Pega tu URL en el auto-diagnóstico, anota el número, y decide desde ahí.

Preguntas frecuentes

¿INP es lo mismo que velocidad de carga?

No. La velocidad de carga (LCP) mide cuánto tarda en aparecer tu contenido. INP mide cuánto tarda tu sitio en responder a interacciones del usuario una vez que ya cargó. Son problemas distintos y se arreglan con técnicas distintas. Un sitio puede cargar rápido pero responder lento (típico de WordPress con muchos plugins), o cargar lento pero responder bien una vez cargado.

¿Por qué Google reemplazó FID por INP?

Porque FID solo medía la primera interacción del usuario. Eso ocultaba problemas que aparecen después: cuando se carga el chat, cuando se ejecuta el analytics, cuando hidrata el framework JS. INP captura todas las interacciones, no solo la primera. Refleja mejor la experiencia real de uso.

¿Qué INP debería tener mi sitio para ser competitivo en SEO?

Por debajo de 200ms en mobile. Esa es la zona verde según Google. Si estás entre 200 y 500ms, tienes margen de mejora pero no estás siendo penalizado de forma agresiva. Si estás sobre 500ms, hay alta probabilidad de que estés perdiendo posicionamiento contra competidores con sitios más livianos.

¿Cuánto tiempo toma arreglar un INP malo?

Depende de la causa. Si son scripts de terceros acumulados, 2 a 4 horas de trabajo te lleva a zona verde. Si es hidratación de framework JS, puede ser un refactor de varias semanas. Por eso conviene diagnosticar primero antes de invertir en cambios.

¿Mi sitio en WordPress puede tener buen INP?

Sí, pero requiere disciplina. Limitar plugins, usar un theme liviano, configurar caching server-side, y diferir scripts no críticos. Hay sitios WordPress con INP excelente, pero son los que mantienen su stack controlado activamente.