Google reemplazó FID (First Input Delay) por INP (Interaction to Next Paint) en marzo de 2024. Dos años después, en 2026, INP está mostrando ser más exigente de lo que muchos esperaban, y mobile lo sufre más que desktop. Para sitios B2B LATAM con frontends pesados (typical Next.js sin optimizar, WordPress con plugins acumulados, Shopify con apps de terceros), INP es la métrica que está quemando rankings sin que el equipo de marketing lo note.
Este post documenta qué cambió con INP, cómo se mide bien, qué patrones están quebrando sitios B2B LATAM y los quick wins técnicos que rinden más con menos esfuerzo.
La diferencia entre FID e INP
FID medía el tiempo entre la primera interacción del usuario (click, tap, key press) y el momento en que el browser empezaba a procesarla. Una sola medición por carga de página. Indulgente con bugs que ocurrían después.
INP mide la latencia de TODAS las interacciones durante la sesión y reporta la peor (sobre el percentil 75). No es una métrica de "primera impresión" sino de "experiencia completa". Si tu página responde rápido al primer click pero queda lenta después, FID te perdonaba; INP te castiga.
Umbrales actuales de Google:
- INP bueno: menos de 200ms
- INP necesita mejora: 200-500ms
- INP malo: más de 500ms
La diferencia operativa: muchos sitios que pasaban FID cómodos ahora están en la zona "necesita mejora" con INP. Especialmente sitios con apps SPA pesadas, third-party scripts (chat widgets, analytics, ad networks, cookie banners) y handlers de evento mal optimizados.
Por qué mobile sufre más
Tres razones técnicas:
Una. CPU mobile más lenta. Hardware móvil promedio tiene CPU sustancialmente menos potente que desktop. Lo que ejecuta en 50ms en una laptop puede tomar 200ms en un Android medio. INP penaliza al mobile en escenarios idénticos a desktop.
Dos. Networks mobile más ruidosas. 4G/5G LATAM tienen jitter y latencia variable. Si tu página hace request a un endpoint propio al click, el tiempo de respuesta varía mucho. Desktop con WiFi típicamente más estable.
Tres. Third-party scripts más costosos en mobile. Chat widgets como Tawk.to o Intercom, cookie banners de Cookiebot, ads de Google, pixels de Meta. En desktop apenas se notan. En mobile pueden bloquear el main thread durante 300-500ms en momentos críticos.
La combinación hace que el INP mobile B2B LATAM esté típicamente entre 280ms y 450ms, en "necesita mejora" o "malo". Y eso afecta ranking orgánico desde 2024 pero con peso creciente.
Lo que está ocurriendo con AI Mode
Google AI Mode (la versión más reciente del AI Overview con interacción conversacional) introduce nueva variable: las páginas referenciadas en respuestas pueden recibir interacciones del usuario directamente desde SERP, sin que el usuario "navegue" al sitio formalmente.
Eso significa que tu página necesita responder rápido no solo a cargas iniciales sino a interacciones en contextos no controlados (SERP embebida, AI Overview cards interactivas, vistas previas de Discover). Si tu INP en esos contextos es malo, el usuario queda con mala experiencia que ni siquiera registras en tu GA4.
Esto eleva el peso práctico de INP. Antes era métrica de ranking. Ahora es métrica de experiencia que Google usa para decidir si te referencia en AI Mode o no.
Cómo se mide INP correctamente
Las tres formas de medirlo:
PageSpeed Insights: métrica field data sobre los últimos 28 días de visitas reales. Ideal para tener número oficial. Limitación: solo agrega data si el sitio tiene tráfico suficiente.
Search Console - Core Web Vitals report: métrica field data agregada por página. Permite identificar qué páginas específicas tienen problema INP.
Chrome DevTools - Performance Insights: métrica lab para debug en desarrollo. Te muestra qué evento bloquea el main thread y por cuánto tiempo.
Para debug práctico, recomiendo usar el web-vitals library de Google en producción para enviar métricas INP a tu GA4 con custom event. Eso te permite segmentar por página, por device, por geografía y por tiempo. Sin esa segmentación, el debug es ciego.
Los 5 problemas más comunes en B2B LATAM
Después de auditar 23 sitios B2B LATAM en lo que va del año, los patrones recurrentes:
Problema 1: Event handlers pesados. Un onclick que ejecuta validaciones complejas, formatea data, actualiza state global y dispara analytics events sincrónicamente. Cada paso suma latencia. Si el handler total tarda 250ms, INP está en zona mala.
Solución: dividir el handler en parts. Lo crítico (UI feedback) ejecuta inmediato. El resto (analytics, validations no urgentes) se deja a setTimeout o useEffect.
Problema 2: Third-party scripts bloqueando interacciones. Chat widget, cookie banner, tag manager, múltiples pixels. Todos compitiendo por el main thread durante los primeros 5-8 segundos de la página.
Solución: cargar third-party scripts con strategy=lazyOnload en Next.js, defer en HTML estático, o usar Google Tag Manager Server-Side para mover el peso al servidor. En MM hemos reducido INP 40-60% en clientes con esta sola optimización.
Problema 3: React re-renders en cascada al click. Pattern común en SPAs Next.js mal arquitectadas: un click dispara update en context global, todos los components se re-renderizan, performance cae. INP se dispara.
Solución: arquitectura con context segmentado, memoization con useMemo y useCallback en components que reciben props complejos, y considerar zustand o Jotai en lugar de Context para state que cambia frecuentemente.
Problema 4: Formularios con validation síncrona pesada. Cada keystroke ejecuta validaciones complejas que bloquean el input. Para forms de 9 campos (los que recomendamos en B2B con ticket alto), esto se nota fuerte.
Solución: validation debounced (esperar 300ms después del último keystroke), validation asíncrona para validaciones de servidor, separation entre validation visual (instant) y validation funcional (debounced).
Problema 5: Imágenes sin lazy loading o sin format moderno. Cada imagen pesada que carga durante interacción compite con el handler en el main thread.
Solución: Next.js Image component con automatic format conversion (AVIF/WebP), lazy loading nativo en HTML estático (loading="lazy"), y CDN con on-the-fly optimization (Cloudflare Images, Cloudinary).
Los quick wins por orden de ROI
Para CTO B2B LATAM con presupuesto limitado de horas, este es el orden de quick wins por hora invertida vs mejora INP esperada:
Quick win 1 (1-2 horas, mejora INP 20-40%): defer / lazyOnload de todos los third-party scripts. Es el más rentable porque toma poco tiempo y rinde mucho.
Quick win 2 (4-8 horas, mejora INP 15-30%): debounce de validations en forms. Aplica especialmente a sitios con formularios pesados.
Quick win 3 (8-16 horas, mejora INP 20-40%): refactor de event handlers pesados separando UI crítico de analytics secundario. Requiere conocer el codebase.
Quick win 4 (8-12 horas, mejora INP 10-25%): optimización de re-renders con memo/callback en components críticos. Requiere auditoría detallada.
Quick win 5 (variable, mejora INP 10-20%): migration de imágenes a Next.js Image o equivalente con AVIF/WebP. Variable según el sitio.
Una implementación combinada de los 5 quick wins típicamente lleva un sitio B2B LATAM de INP mobile 400ms a INP mobile 180ms en 30-50 horas de trabajo. ROI inmediato en ranking orgánico y en experiencia del usuario.
Lo que aplicamos en MorgansMedia
Nuestro INP mobile actual en morgansmedia.cl está entre 140ms y 170ms (zona buena). Para llegar ahí aplicamos:
Una. Cloudflare como CDN con auto-optim de imágenes y Workers para edge logic.
Dos. Astro con islands architecture: JavaScript mínimo en el shipping inicial, hidratación selectiva por component.
Tres. Third-party scripts diferidos: el chat widget carga 6 segundos después del onload de la página, no antes.
Cuatro. GTM Server-Side para mover el peso de tracking al servidor.
Cinco. Formulario DMC con validation client-side debounced + validation server-side via Edge Function.
Resultado: posición promedio en GSC subió 13 → 8 en 8 meses, INP estable bajo 180ms, branded search lift +35%. La performance técnica está detrás del SEO/GEO que MM logra.
Preguntas frecuentes
¿Mi sitio está en WordPress con muchos plugins. ¿Puedo optimizar INP sin migrar?
Sí. Las palancas: caching agresivo con WP Rocket o LiteSpeed Cache, lazy loading de plugins no críticos, defer de scripts, deshabilitar emojis nativos de WordPress (cargan script innecesario), optimizar el theme para reducir DOM. Mejora típica: INP 450ms → 250ms con 8-16 horas de trabajo.
¿Shopify permite optimizar INP o estoy atado a su platform?
Limitado pero posible. Las palancas: theme custom optimizado, eliminación de apps de terceros no esenciales (cada app suele inyectar script), Shopify Online Store 2.0 features (mejor que 1.0 para performance). En general, sitios B2B serios sobre Shopify tienen INP en zona "necesita mejora" sin migrar a Hydrogen.
¿Cuánto tiempo toma ver mejora en ranking después de optimizar INP?
Google recalibra Core Web Vitals con field data de 28 días. Las primeras mejoras de ranking aparecen 4-8 semanas después del fix. Resultados materiales en 8-16 semanas. No es cambio inmediato pero es consistente.
El cierre
INP en 2026 es la métrica de Core Web Vitals que más diferencia sitios B2B LATAM exitosos de los que se estancan. Con AI Mode introduciendo interacciones en SERP, su peso práctico es mayor que el ranking orgánico tradicional. Los sitios mobile-first con INP bueno tienen ventaja material que se acumula con el tiempo.
Los quick wins documentados son accionables en 30-50 horas de trabajo técnico. La inversión se recupera en 2-4 meses de mejora de ranking + mejora de experiencia del usuario + capacidad de aparecer más seguido en AI Mode. No es trabajo glamoroso pero es trabajo rentable.
El DMC (Diagnóstico de Madurez de Crecimiento) de MorgansMedia incluye auditoría completa de Core Web Vitals del sitio del cliente con segmentación por página y device. Identifica los 3-5 quick wins de mayor impacto y propone roadmap específico para tu stack. No es checklist genérico. Es plan dirigido al INP real de tu sitio en field data.
