Google reemplazó FID por INP en marzo 2024. Sitios con INP > 200ms están perdiendo CTR y conversión sin saberlo. Y el costo es real: cada milisegundo extra es un peso más de CAC.
La mayoría de los equipos de marketing B2B en LATAM siguen mirando el reporte de Core Web Vitals de hace dos años: LCP, FID y CLS, todo en verde, problema resuelto. Eso ya no es cierto. Desde marzo 2024 Google reemplazó FID (First Input Delay) por INP (Interaction to Next Paint), y la diferencia entre las dos métricas no es cosmética: es estructural. INP es más exigente, mide más superficies de la página, y afecta directamente el ranking en Google y el comportamiento del usuario en tu sitio.
Esta pieza es la lectura técnica desde el lado MM: qué cambió puntualmente, por qué muchos sitios B2B chilenos con CWV en verde el año pasado están hoy en ámbar o rojo, las 5 palancas que más mueven INP en sitios B2B en 2026, y cómo se traduce esto en CAC concreto.
FID medía una cosa, INP mide muchas
FID medía solamente la primera interacción del usuario con la página: el tiempo entre el primer clic, tap o tecla, y la respuesta del navegador. Esa métrica era fácil de pasar porque casi todos los sitios tienen una primera interacción rápida (la home carga, el usuario hace scroll o tap, y la respuesta es inmediata).
INP mide TODAS las interacciones que el usuario hace durante la sesión y reporta el percentil 98. Esto significa que un sitio con FID excelente (< 100ms) puede tener INP terrible si tiene un componente pesado en cualquier parte: un menú que se demora en abrir, un formulario con validación síncrona pesada, un widget de chat que bloquea el main thread cuando se inicializa, una imagen lazy-loaded que reflowa media página al aparecer.
El umbral de Google: INP < 200ms es bueno, 200-500ms es ámbar, > 500ms es rojo. La realidad de los sitios B2B chilenos que auditamos en MorgansMedia: el 60% está en ámbar y el 25% en rojo. Solo el 15% está en verde. Y la mayoría no lo sabe porque sus equipos siguen mirando los reportes con FID antiguos.
Por qué INP afecta tu CAC
La cadena causal es directa: INP más alto → percepción de sitio lento → más rebote → menor tasa de conversión → mayor CAC para el mismo gasto en Ads.
En medidas internas en cuentas de clientes MM 2025-2026, comparando sitios antes y después de optimizar INP, observamos:
- Tasa de rebote en mobile cae entre 8% y 22% cuando INP pasa de ámbar a verde.
- Tasa de conversión en formularios sube entre 12% y 30% cuando INP del formulario específico está bajo 150ms.
- CTR orgánico desde Google sube entre 5% y 14% al pasar la pieza completa Core Web Vitals a verde (Google premia explicitamente CWV en ranking).
Estos números son agregados de auditorías reales. La traducción a CAC es directa: si tu Google Ads gasta USD 4.000/mes con conversión del 2,5% y subes la conversión a 3%, el CAC baja proporcionalmente. Optimizar INP suele ser más barato que aumentar el presupuesto de Ads y rinde más.
Las 5 palancas que más mueven INP en B2B
En auditorías de sitios B2B en 2026, los problemas de INP convergen en cinco causas. Atacar las cinco lleva la mayoría de sitios de ámbar a verde sin rebuild completo.
1. Defer en scripts third-party
Los chat widgets (Intercom, Drift, Crisp), los pixels de marketing (Meta Pixel, GA4, LinkedIn Insight Tag), los heatmaps (Hotjar, Microsoft Clarity) y los popups (Optinmonster, Sumo) bloquean el main thread cuando se cargan. Si están en <head> sin defer o async, el navegador no puede responder a ninguna interacción hasta que terminan.
La solución es marcarlos defer o cargarlos después del evento load con un setTimeout corto. Para chat widgets, cargar después del primer scroll o después de 3 segundos es el patrón estándar. Esto solo suele bajar INP entre 80 y 150ms.
2. Lazy loading agresivo de imágenes y iframes
Imágenes que cargan al inicio y están debajo del fold consumen banda y main thread. Iframes embebidos (YouTube, Calendly, Loom) son peores: cada iframe es esencialmente un sitio dentro de tu sitio.
Patrón correcto: loading="lazy" en todas las imágenes debajo del fold, e iframes substituidos por un placeholder estático (thumbnail + botón play) que carga el iframe real solo al click. Para Calendly recomendamos popup en lugar de inline embed.
3. Reducir JavaScript bundle size
El JS de un sitio B2B promedio en LATAM pesa entre 500KB y 2MB. La mayoría de ese peso es librerías que se podrían tree-shakear: lodash entero cuando solo se usa una función, jQuery completo para un toggle de menú, momentjs para formatear una fecha.
En proyectos MM con WordPress, el patrón incluye: optimización con WP Rocket o LiteSpeed Cache, dequeueing de scripts en páginas donde no aplican, y reemplazo de plugins pesados por equivalentes ligeros. En proyectos Next.js, dynamic imports para componentes pesados y revisión del bundle con next-bundle-analyzer.
4. Eliminar componentes con re-renders innecesarios
Específico de React mal optimizado: componentes que se re-renderizan en cada cambio de estado del padre, listas grandes sin key o sin React.memo, contextos demasiado grandes que disparan re-renders en cascada.
La auditoría con React DevTools Profiler suele mostrar 2-3 componentes que consumen el 80% del tiempo de render. Memoizarlos con useMemo, useCallback y React.memo cuando aplica baja INP entre 50 y 100ms en sitios complejos.
5. Cachear respuestas de API en el cliente
Llamadas API que se repiten en cada navegación entre páginas (login state, perfil de usuario, menú de categorías) son el caso de uso obvio para cache cliente. Sin cache, cada interacción bloquea hasta recibir respuesta de red.
Patrón: SWR o React Query en frontend, con staleTime configurado según el dato. Resultados que cambian poco (menú, perfil) pueden cachearse 5-10 minutos. Resultados dinámicos (notificaciones, carrito) se mantienen frescos pero con keepPreviousData para no flickear.
Mobile CTR vs Desktop CTR: el gap silencioso
Un dato propio de MM relevante: nuestro propio sitio mide hoy CTR mobile de 2,15% vs CTR desktop de 4,33%. Es un gap de más del doble. La causa principal en nuestro caso fue INP en mobile entre 280 y 450ms, mientras que en desktop estaba bajo 150ms. Mobile tiene CPU más lento, conexión más variable, y main thread más congestionado por scripts third-party.
La mayoría de los reportes ejecutivos de marketing miran CTR promedio sin segmentar por device. Eso oculta el problema. La revisión correcta es CTR mobile vs desktop separados, comparados contra benchmark del nicho.
Cómo se mide INP en el field
Dos formas: lab data (Lighthouse, PageSpeed Insights) y field data (Chrome User Experience Report, web-vitals.js en el sitio en vivo).
Lab data es útil para debug pero no representa al usuario real. Field data es lo que Google usa para ranking. La pieza correcta a mirar es la sección “Field Data” de PageSpeed Insights y el reporte CrUX en Search Console.
Para captura propia recomendamos web-vitals.js (~1KB) que reporta INP a tu sistema de analytics. Así cap.tu el INP real de tus usuarios reales y puedes ver dónde duele.
Checklist de auditoría rápida
Lo que en MM revisamos en una auditoría inicial de INP:
- Field data en PageSpeed Insights (mobile y desktop) y URL específicas que más tráfico tienen.
- Chrome DevTools Performance tab grabando una sesión de 30s navegando, con CPU throttling 4x para simular mobile.
- Listado de scripts third-party con su tamaño y posición (head vs body, defer vs async vs nada).
- Bundle analyzer si es Next.js o React, con foco en libraries > 50KB.
- Reporte de plugins activos si es WordPress, ordenados por impacto en página (P3 Plugin Profiler).
De esa auditoría salen las 5-10 acciones priorizadas por impacto. La mayoría de los sitios B2B chilenos llegan a verde con 6-8 semanas de trabajo dedicado, sin rebuild.
Cierre
Tu sitio es la cara comercial de tu empresa. Si carga lento o responde lento, le estás dando ventaja a tu competencia gratis. INP no es una métrica que se pase con un plugin de cache: es el resultado de decisiones técnicas acumuladas. Hacer la auditoría y atacar las 5 palancas paga: más conversión, mejor ranking, menor CAC.
Si tu sitio está en ámbar o rojo en INP y tu equipo no sabe por dónde empezar, agenda un DMC. En el diagnóstico revisamos field data, identificamos los 3 cuellos de botella más caros, y dejamos hoja de ruta de optimización con timeline y costo estimado.
Matías Guiñez Gebhardt es CTO en MorgansMedia. Tech lead en desarrollo, integraciones, plugins y widgets a medida.
