En marzo de 2024, Google reemplazó FID (First Input Delay) por INP (Interaction to Next Paint) como Core Web Vital oficial. La diferencia importa: INP mide TODAS las interacciones del usuario, no solo la primera. Si tu sitio se siente "trabado" en cualquier click después del initial load, INP lo detecta y Google te penaliza.

Qué mide exactamente INP

INP es el tiempo más largo entre una interacción (click, tap, key) y el próximo paint visual. Es decir: cuánto tarda tu sitio en mostrar feedback visible después de que el usuario hizo algo.

Zonas oficiales:

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

Para que entiendas la sensación: 200ms es el límite humano para que algo se sienta "instantáneo". Por encima de eso, el cerebro detecta latencia.

Verificá el INP de tu sitio en nuestro test de velocidad y comparalo con el real de tus usuarios en Search Console → Core Web Vitals.

Por qué INP es más exigente que FID

FID solo medía el delay antes de procesar el primer click. INP mide el ciclo completo: input → procesamiento → paint final. Y lo hace con TODAS las interacciones, no solo la primera.

Esto descubre problemas que FID nunca mostraba:

  • Apertura lenta de un menú dropdown
  • Filtros que tardan en aplicarse en un ecommerce
  • Modal que demora en aparecer al click
  • Botón "Agregar al carrito" que se siente trabado

Las 6 causas más comunes de INP alto

1. Tareas largas en el main thread

JavaScript es single-threaded. Si una función tarda 300ms procesando, el navegador no puede responder a clicks durante esos 300ms. Las culpables más comunes:

  • Bibliotecas pesadas cargadas sync (jQuery + 10 plugins, Moment.js, lodash entero)
  • Cálculos pesados en cada scroll/resize
  • Hidratación de SPAs con muchos componentes
  • Loops grandes sin throttling

Solución: code splitting, lazy load de features no críticas, mover cálculos pesados a Web Workers.

2. Event handlers pesados

Un onClick que ejecuta 100ms de lógica antes de actualizar UI = INP malo. Mejor:

// Mal: bloquea hasta terminar
button.addEventListener('click', () => {
  doExpensiveStuff();   // 200ms
  updateUI();
});

// Bien: actualiza UI primero, después el trabajo pesado
button.addEventListener('click', () => {
  updateUI();           // sincrónico, rápido
  requestIdleCallback(() => doExpensiveStuff());
});

3. Tracking pixels y widgets de terceros

El #1 enemigo del INP en sitios reales. Google Analytics, Meta Pixel, Hotjar, Intercom, chat widgets... cada uno suma overhead. Soluciones:

  • Cargá los tracking pixels con defer o después del load event
  • Usá Google Tag Manager para condicionar tags
  • Evaluá si TODOS son necesarios (¿usás Hotjar mensualmente?)
  • Mové chat widgets a requestIdleCallback

4. Re-renders innecesarios en frameworks

Si usás React/Vue, cada setState dispara reconciliación. Si tu componente re-renderiza un árbol grande en cada keystroke, INP se cae:

  • Usá React.memo, useMemo, useCallback con cabeza
  • Considerá React Concurrent Mode / useTransition para updates no urgentes
  • Virtualizá listas largas (react-window, virtua)

5. CSS pesado en el path crítico

CSS complejo (selectores costosos, animations sin will-change, layout thrashing) puede causar reflows que congelen el render. El estilo más caro: :has() mal usado.

6. Plugins de WordPress mal codeados

El 80% de sitios WordPress con INP malo es por plugins. Identificá con Query Monitor o el panel de DevTools → Performance. Desactivá uno por uno y medí.

Cómo medir INP correctamente

INP es difícil de capturar con tests simulados porque depende del comportamiento real del usuario. Las herramientas:

  • Search Console → Core Web Vitals: la verdad real. Datos de Chrome de usuarios reales (CrUX).
  • PageSpeed Insights: incluye estimación INP en lab + datos CrUX.
  • Web Vitals extension: medí en tu navegación real, identificá qué interacción es la culpable.
  • Chrome DevTools → Performance → Interactions: cada interacción con su INP exacto.

Importante: en CrUX, INP es el percentil 75. Es decir: 25% de tus usuarios tienen INP peor del que ves. Apuntá a mejor que 200ms para que la mayoría esté en verde.

Checklist de optimización INP

  1. Auditá tu bundle JS: ¿qué pesa más, qué podés sacar?
  2. Defer todos los scripts no críticos
  3. Lazy load de chat, tracking, social embeds
  4. Code splitting por ruta
  5. Memoization en componentes React/Vue
  6. Virtualizá listas con muchos items
  7. Web Workers para cálculos pesados
  8. Updaeá UI primero, lógica pesada después
  9. Eliminá plugins WordPress mal codeados
  10. Monitor continuo en Search Console
INP no se mide con un test único. Se monitorea con datos reales mes a mes. Si tu sitio depende de Google, INP en verde es no opcional desde 2024.

Si estás armando un sistema

Cuando desarrollamos sistemas a medida en Jumpweb, INP es parte del checklist desde el día uno: virtualización de tablas grandes, debounce en filtros, optimistic UI updates, code splitting agresivo. Si tenés un dashboard interno o un panel admin que se siente lento, hablemos: ofrecemos desarrollo de sistemas web optimizados.

Próximos pasos