INP a 200ms: Por Qué Esta Métrica Está Matando tus Conversiones (Y Cómo Arreglarla)

Basado en auditorías reales de sitios en producción, no en simulaciones de Lighthouse.

Hay una métrica que la mayoría de los sitios están fallando y no lo saben. No es LCP — ese se discute en cada reunión de SEO. Es INP: Interaction to Next Paint. Y el 43% de los sitios evaluados por el Chrome User Experience Report en 2026 no pasan el umbral de 200ms, según datos recopilados por JAM Creative y respaldados por análisis de HTTP Archive.

FID (First Input Delay) solo medía el tiempo antes de que el navegador empezara a procesar un clic. INP mide el recorrido completo — desde que el usuario toca la pantalla o hace clic hasta que el navegador pinta la respuesta visual. Eso incluye el tiempo de procesamiento del manejador de eventos, las tareas largas que bloquean el hilo principal y cualquier trabajo JavaScript que se interponga entre la interacción y el feedback visual.

Si tu sitio carga rápido pero se siente "pegajoso" al hacer clic — botones que tardan en responder, menús que no se abren al primer toque, formularios que congelan medio segundo al enviarse — estás perdiendo conversiones por INP y probablemente no lo has medido correctamente.

Por Qué el INP es Más Peligroso que el FID

La diferencia clave: FID era fácil de pasar. Solo necesitabas que el hilo principal estuviera libre en el momento del primer clic del usuario. Las interacciones posteriores — las que realmente importan para la conversión — no contaban.

INP captura todas las interacciones durante el ciclo de vida de la página: clics en botones de CTA, toques en campos de formulario, interacciones con carruseles de productos, apertura del menú móvil, envío de formularios. La peor interacción (el percentil 75) es la que determina tu puntuación.

Esto tiene una consecuencia directa: un sitio puede tener una carga ultrarrápida (LCP de 1.2s) y una estabilidad visual perfecta (CLS de 0.02), pero si un script de analítica bloquea el hilo principal cuando el usuario intenta hacer clic en "Comprar", la puntuación INP se dispara a 400ms y Google lo penaliza como experiencia "Poor".

Lo Que la Actualización de Marzo 2026 Cambió

Google ajustó tres cosas en su actualización de Core Web Vitals de marzo 2026 que hicieron que INP pasara de ser una métrica secundaria a un factor de ranking crítico:

1. Datos de campo como señal principal. Antes Google combinaba datos de laboratorio (Lighthouse) con datos de campo (CrUX). Desde marzo 2026, el peso se desplazó casi completamente a CrUX. Tu puntuación de Lighthouse importa menos que cómo los usuarios reales experimentan tu sitio en dispositivos reales con conexiones reales.

2. El umbral de URLs "Poor" se endureció. Antes podías tener hasta el 25% de tus URLs en categoría Poor y aún aprobar. La actualización redujo ese umbral al 15%. Si más del 15% de tus páginas fallan INP, todo el sitio se ve afectado en ranking.

3. Interacciones con scroll ahora cuentan. Las interacciones que ocurren durante eventos de scroll — donde el usuario intenta tocar un elemento mientras el navegador está procesando desplazamiento — ahora se incluyen en la medición. Esto ha reducido drásticamente las tasas de aprobación en páginas con mucho contenido.

El resultado práctico: un sitio que monitoreamos pasó del 72% de aprobación de INP al 44% después de la actualización. Su código no había cambiado. Google cambió lo que contaba.

El Framework de Diagnóstico de INP de Mintec

Después de auditar docenas de sitios, hemos identificado tres causas raíz que explican el 80% de los fracasos de INP. Este es el orden en que las atacamos:

1. Scripts de Terceros (El Asesino #1)

Un sitio típico carga de 8 a 12 scripts de terceros por página: Google Analytics (o GA4), Facebook Pixel, widget de chat en vivo, consentimiento de cookies, mapas embebidos, reproductores de video, dashboards de A/B testing. Cada uno compite por tiempo en el hilo principal.

La solución no es eliminarlos todos — algunos son esenciales para el negocio. Es categorizarlos y aplicar una estrategia de carga diferida:

• Críticos para la interacción: Los que el usuario necesita para completar una acción (chat, formularios). Estos deben cargarse temprano pero optimizados.
• Críticos para analítica: GA4, Meta Pixel. Se cargan después de la primera interacción del usuario, no en cada carga de página.
• No críticos: Widgets de soporte, mapas, reproductores. Se cargan condicionalmente cuando el usuario los solicita.

Usamos requestIdleCallback para diferir scripts no críticos y async o defer para todo lo demás. La regla: si un script no es necesario para la primera interacción del usuario, no debería ejecutarse antes de esa interacción.

2. Tareas Largas que Bloquean el Hilo Principal

Cualquier operación JavaScript que tome más de 50 milisegundos bloquea el hilo principal. Un bucle de renderizado de React, una rehidratación costosa, un cálculo de estado complejo — todo contribuye a INP alto.

Las correcciones que funcionan en sitios reales:

• yield al hilo principal: Dividir tareas largas usando setTimeout o la nueva API scheduler.yield(). Un proceso que toma 200ms se divide en 4 chunks de 50ms, permitiendo que el navegador maneje interacciones entre ellos.
• Web Workers para cómputo pesado: Mover procesamiento de datos, transformaciones y análisis a un worker en un hilo separado.
• Content-visibility: auto: Esta propiedad CSS difiere el renderizado de elementos fuera de la pantalla hasta que el usuario se desplaza cerca de ellos. Reduce el trabajo del hilo principal durante la carga entre un 30% y un 50%.

3. Hidratación de Frameworks JavaScript

Este problema es específico de sitios construidos con frameworks JavaScript pesados (React, Next.js, Vue). La hidratación — el proceso de adjuntar manejadores de eventos al HTML renderado en servidor — puede tomar cientos de milisegundos.

Astro resuelve esto con el patrón de "islas": cero JavaScript por defecto, interactividad solo donde se necesita. Los componentes interactivos se aíslan y no bloquean el resto de la página. En nuestras migraciones de sitios React a Astro, hemos visto INP mejorar entre 40% y 60% sin cambiar la funcionalidad.

INP y Conversiones: La Conexión que Pocos Miden

Hay una razón por la que INP es tan letal para las conversiones: ocurre exactamente en el momento en que el usuario está listo para actuar.

Un estudio de caso documentado por varios equipos de rendimiento muestra que sitios de e-commerce que optimizaron INP por debajo de 200ms vieron incrementos de conversión del 12% al 30%. No es correlación: cuando reduces el tiempo entre el clic y la respuesta visual, el usuario percibe el sitio como más confiable y es más probable que complete la acción.

El razonamiento es psicológico: cada milisegundo de retraso entre una intención (clic en "Comprar") y su ejecución (cambio visual que confirma la acción) introduce fricción. En 200ms, la fricción es imperceptible. En 500ms, el usuario duda. En 800ms, el usuario asume que algo falló y hace clic de nuevo — o peor, abandona.

Medición Correcta: No Confíes Solo en Lighthouse

Lighthouse te da una estimación. CrUX te da la realidad. La brecha entre ambas puede ser de 100ms o más, especialmente en dispositivos móviles de gama media que representan la mayoría del tráfico web global.

Para medir INP correctamente:

1. Usa la API de CrUX para obtener datos de usuarios reales de tus URLs. Se actualiza mensualmente con un retraso de 28 días.
2. Implementa RUM (Real User Monitoring) con herramientas como SpeedVitals o Request Metrics para obtener datos diarios.
3. Configura alertas cuando el p75 de INP supere los 200ms. No esperes al informe mensual.

Si no estás midiendo INP desde la perspectiva del usuario real, no sabes si tu sitio está fallando. Y lo más probable: está fallando.

Conclusión

INP no es una moda pasajera. Es la métrica que Google ha elegido para representar la calidad de interacción del usuario con tu sitio, y cada actualización la hace más difícil de pasar. La buena noticia: las soluciones existen y son implementables.

En Mintec, abordamos INP con un proceso estructurado: auditamos el sitio con datos de campo reales, identificamos los scripts de terceros y tareas largas que están bloqueando el hilo principal, y aplicamos optimizaciones quirúrgicas que respetan la funcionalidad existente.

Artículos relacionados:

• Core Web Vitals: Qué Cambió y Qué Sigue Importando para el SEO
• CMS Headless: Por Qué el Desarrollo Web Moderno Va Hacia la Arquitectura
• El Desarrollo Multimedia Enriquece Los Sitios Web
• Por Qué las Marcas de Alto Crecimiento Abandonan los Temas Estándar de Shopify por Headless

Explora nuestros servicios de desarrollo web →

Fuentes

• Google, "Interaction to Next Paint (INP)" — web.dev
• JAM Creative, "43% of Sites Fail INP" — jamcreative.co/blog/inp-failing-pagespeed-insights-wont-tell-you
• CrUX / HTTP Archive, "Web Almanac 2025 — Performance"
• backlynk.io, "Core Web Vitals INP 2026: Real User Data and the 200ms Threshold"
• Digital Applied, "Core Web Vitals 2026: INP, LCP & CLS Optimization Guide"