INP: qué es Interaction to Next Paint y cómo mejorarlo | Ighenatt

El 12 de marzo de 2024, aproximadamente 600.000 webs que antes aprobaban todos los Core Web Vitals empezaron a suspender uno. No porque hubieran empeorado: Google reemplazó el FID por el INP, un baremo mucho más estricto de interactividad. La transición reveló algo que los datos de campo ya sabían desde hacía meses: muchos sitios son rápidos en cargar pero lentos en responder.

INP (Interaction to Next Paint) mide cuánto tarda tu página en responder visualmente a lo que el usuario hace. No solo a la primera acción, como hacía FID, sino a cada clic, cada tap y cada pulsación de teclado durante toda la sesión. Un usuario que rellena un formulario, filtra resultados o navega por un menú desplegable genera decenas de interacciones. INP reporta la peor de ellas.

El umbral es concreto: 200ms o menos para considerarse bueno. En ese margen, el navegador tiene que recibir el input, ejecutar todos los handlers de eventos, hacer cualquier recálculo de DOM necesario, y pintar el siguiente frame en pantalla. En muchos sitios con JavaScript intensivo, ese ciclo se extiende hasta los 800ms o más.

Cómo funciona INP: las tres fases de una interacción

Para optimizar INP hay que entender qué mide exactamente. Cada interacción registrada por el navegador se divide en tres fases:

1. Retraso de entrada (Input delay)

El tiempo que transcurre desde que el usuario hace clic o pulsa hasta que el navegador puede empezar a ejecutar los handlers de ese evento. Si el hilo principal está ocupado con otra tarea — una petición en vuelo que procesa datos, un timer que ejecuta código, el parsing de un script — el evento se queda en cola. Ese tiempo en cola es el input delay.

Un input delay alto suele indicar tareas largas bloqueando el hilo principal. La referencia estándar es que ninguna tarea debería durar más de 50ms en el hilo principal para garantizar capacidad de respuesta inmediata.

2. Duración de procesamiento (Processing duration)

El tiempo que tarda en ejecutarse todo el código de los event callbacks asociados a esa interacción. Si un clic en un botón dispara tres handlers que actualizan el estado de React, hacen una llamada a una API y re-renderizan un componente complejo, toda esa ejecución se suma aquí.

Este es el componente donde más se puede intervenir con cambios en el código.

3. Retraso de presentación (Presentation delay)

El tiempo desde que los callbacks terminan hasta que el navegador renderiza el siguiente frame con los cambios aplicados. Incluye el recálculo de estilos, el layout y la composición. Un DOM muy grande, cambios de estilo que fuerzan reflow o transformaciones CSS no-compositor pueden inflar este número.

La suma de las tres fases es el INP de esa interacción. El INP de la página es el valor más alto (o cercano al máximo) de todas las interacciones registradas en la sesión.

El estado real del INP en 2025: quién suspende y por qué

Los datos del Chrome UX Report procesados por DebugBear en 2025 muestran la foto actual del INP global. En desktop, el 97% de los webs consiguen un INP bueno (≤200ms). En móvil, ese porcentaje baja al 77%. Esa brecha de 20 puntos porcentuales no se explica principalmente por código mal optimizado: se explica por los dispositivos.

En Estados Unidos, Alemania o Japón, la mediana de INP en móvil es de 100ms — dentro del umbral bueno. En Filipinas, el percentil 90 de los sitios más lentos alcanza los 600ms. En Lesoto o Angola, incluso webs medianas superan los 300ms. Los 23 puntos porcentuales de webs móviles que suspenden INP son, en buena medida, usuarios en países con dispositivos de gama baja y conexiones inestables procesando el mismo JavaScript que otros usuarios ejecutan en un iPhone reciente.

La Web Almanac de HTTP Archive de 2025 confirma que los 1.000 sitios más visitados del mundo mejoraron del 53% al 63% de páginas con INP bueno en ese año — una ganancia de 10 puntos en 12 meses. Pero en el total de la web, el margen de mejora sigue siendo significativo.

Los sectores con peor INP de forma consistente son e-commerce (mucha lógica de filtros, carrito, validaciones en tiempo real) y medios de comunicación (scripts de publicidad programática, trackers de analytics con handlers costosos). Los sitios estáticos o con poco JavaScript son los que más fácilmente consiguen INP en el rango bueno.

Por qué INP importa para el negocio: el caso redBus

Las métricas de rendimiento tienen sentido cuando se traducen en resultados concretos. El caso de redBus — la plataforma de reserva de autobuses más grande de India — es el benchmark de referencia para el impacto de INP en negocio.

redBus tenía problemas de INP específicamente en campos de búsqueda y filtros. Sus interacciones más críticas llegaban a duraciones de entre 870 y 900ms — cuatro veces el umbral bueno de Google. El equipo identificó tres fuentes de latencia:

Scroll event handler sin debouncear: El handler de scroll se ejecutaba en cada pixel de movimiento, saturando el hilo principal. La solución fue añadir debounce al handler y usar requestAnimationFrame para priorizar el trabajo de renderizado antes del siguiente frame.

Carga lazy de resultados en lotes de 30: Cada lazy load traía 30 ítems, lo que generaba una tarea de procesamiento y renderizado costosa. Reducir el lote a 10 ítems fragmentó el trabajo en tareas más pequeñas y repartió la carga.

Estado de formulario sincronizado a Redux en cada keystroke: Actualizar el store global de Redux en cada tecla disparaba re-renders completos del árbol de componentes. La solución fue gestionar el estado del input localmente (estado local de React) y sincronizar al store solo en el evento blur — cuando el usuario abandona el campo.

El resultado: una reducción del 72% en el INP de los campos de input, con interacciones que pasaron de 870-900ms a 350-370ms. El impacto en negocio fue un incremento del 7% en ventas totales. redBus documentó la metodología completa usando la librería web-vitals de Google con RUM a través de una pila ELK (Elasticsearch-Logstash-Kibana), midiendo en el percentil 95 — no en la mediana.

Las cuatro causas raíz de un INP deficiente

1. Tareas largas en el hilo principal

Una tarea larga es cualquier tarea que ocupa el hilo principal durante más de 50ms. Durante ese tiempo, el navegador no puede responder a eventos de usuario, lo que se traduce directamente en input delay. Los culpables habituales: parsing y ejecución de JavaScript pesado en el momento de la interacción, timers que ejecutan trabajo costoso, y scripts de terceros (analytics, chat widgets, scripts de A/B testing) que se ejecutan en el hilo principal sin ceder control.

La solución es fragmentar esas tareas largas. Addy Osmani, engineering manager en Google Chrome y autor de referencia en rendimiento web, lo resume con claridad: “JavaScript is your most expensive asset” — no por su tamaño de descarga, sino por el trabajo de parseo y ejecución que exige en el hilo principal.

2. Event handlers con demasiado trabajo síncrono

Un handler de evento que hace demasiado trabajo de forma síncrona bloquea el hilo principal hasta que termina. Si un clic en “añadir al carrito” dispara una validación de stock, actualiza el estado global, recalcula el precio total y re-renderiza el header con el contador, todo eso ocurre en la misma tarea. El siguiente frame no puede pintarse hasta que esa tarea termine.

La solución es separar el trabajo urgente (actualizar la UI inmediatamente para dar feedback visual al usuario) del trabajo diferible (sincronizar con el servidor, actualizar contadores secundarios, registrar el evento de analytics). El trabajo diferible puede ejecutarse en una tarea separada después del siguiente frame renderizado.

3. Reconciliación costosa en frameworks JavaScript

React, Angular y Vue gestionan el DOM a través de una capa de abstracción que añade trabajo adicional cuando el estado cambia. En aplicaciones grandes, una interacción simple puede desencadenar la re-renderización de un árbol de componentes que incluye decenas o cientos de elementos.

Para React específicamente, las herramientas más efectivas son: React.memo para evitar re-renders innecesarios de componentes que no han cambiado, useMemo para memorizar cálculos costosos, useCallback para estabilizar referencias de funciones, y startTransition (React 18+) para marcar actualizaciones de estado como no urgentes y permitir que el navegador priorice el feedback visual inmediato.

4. DOM excesivamente grande

Un DOM con más de 1.400 nodos es una señal de advertencia de Lighthouse. Cada vez que JavaScript modifica el DOM, el navegador necesita recalcular estilos y layout. En un árbol DOM muy grande, esos recálculos son más costosos y contribuyen al retraso de presentación. La virtualización de listas largas — renderizar solo los elementos visibles en el viewport — es la técnica estándar para webs con contenido dinámico extenso.

Técnicas concretas de optimización INP

Yielding al hilo principal

La técnica de yielding consiste en fragmentar una tarea larga en subtareas más pequeñas, cediendo el control al navegador entre ellas para que pueda procesar eventos pendientes. El patrón más simple usa setTimeout con delay 0:

button.addEventListener('click', () => {
  // Trabajo urgente: feedback visual inmediato
  updateButtonState('loading');

  // Cede el control al navegador antes de continuar
  setTimeout(() => {
    processExpensiveWork();
    updateUI();
  }, 0);
});

La API scheduler.yield() (disponible en Chromium desde 2024) ofrece una versión más granular de este patrón con mejores garantías de priorización. Es la evolución del yielding manual con setTimeout y se espera que su soporte se expanda a otros navegadores.

Separar trabajo de renderizado del trabajo posterior al frame

Para interacciones donde necesitas actualizar algo visualmente y luego hacer trabajo adicional, el patrón requestAnimationFrame + setTimeout(0) de web.dev es preciso:

textInput.addEventListener('input', (event) => {
  // Actualiza el UI (trabajo de renderizado — debe ir antes del frame)
  updateDisplay(event.target.value);

  // Programa trabajo no visual para después del frame
  requestAnimationFrame(() => {
    setTimeout(() => {
      runSpellCheck(event.target.value);
      syncToStore(event.target.value);
    }, 0);
  });
});

El requestAnimationFrame garantiza que updateDisplay se ejecuta en el ciclo de renderizado correcto. El setTimeout(0) dentro del callback aplaza el resto del trabajo a una nueva tarea, después de que el frame se haya pintado.

Debounce y throttle para eventos de alta frecuencia

Los eventos input, scroll y resize pueden dispararse decenas de veces por segundo. Ejecutar lógica costosa en cada disparo satura el hilo principal. Debounce (ejecutar solo después de que el usuario haya dejado de interactuar durante N ms) y throttle (ejecutar máximo una vez cada N ms) reducen drásticamente el número de ejecuciones sin afectar la percepción de respuesta.

CSS content-visibility para DOM grande

La propiedad CSS content-visibility: auto indica al navegador que puede omitir el rendering de secciones fuera del viewport, reduciendo el coste de layout y paint. En páginas con mucho contenido debajo del fold, esta propiedad puede reducir el tiempo de renderizado inicial y aliviar el retraso de presentación en interacciones que modifican el DOM.

Cómo diagnosticar INP con herramientas reales

PageSpeed Insights: Introduce la URL para obtener el INP de campo (datos del CrUX con usuarios reales) y el INP de laboratorio (Lighthouse simulado). El dato de campo es el que Google usa para ranking. Si hay diferencia grande entre ambos, investiga si hay interacciones que Lighthouse no simula pero los usuarios reales sí hacen.

Chrome DevTools — pestaña Performance: Graba mientras interactúas con la página. Busca las barras rojas en el hilo principal que indican tareas largas (>50ms). Haz clic en una interacción para ver la descomposición en input delay, processing time y presentation delay. El flame chart muestra qué funciones consumen más tiempo dentro de cada tarea.

Extensión Web Vitals de Google: Muestra el INP en tiempo real mientras navegas. Útil para identificar qué interacciones específicas son las más lentas en tu flujo de usuario real.

Librería web-vitals.js en producción: Para RUM (Real User Monitoring) en producción, la librería oficial de Google reporta INP con atribución del elemento que la desencadenó. Es la misma metodología que usó redBus para identificar sus campos de input como la fuente de sus problemas.

import { onINP } from 'web-vitals/attribution';

onINP(({ value, attribution }) => {
  console.log(`INP: ${value}ms`);
  console.log(`Elemento: ${attribution.interactionTarget}`);
  console.log(`Tipo: ${attribution.interactionType}`);
});

INP y su relación con el posicionamiento en Google

INP es uno de los tres Core Web Vitals que Google usa como señal de ranking desde marzo de 2024, junto con LCP y CLS. Un INP deficiente no genera una penalización directa de posiciones, pero funciona como desventaja comparativa: cuando dos páginas son equivalentes en contenido y autoridad, las señales de experiencia de página — incluyendo INP — actúan como factor de desempate.

El informe de DebugBear sobre el Google Core Update de diciembre de 2025 documentó caídas del 31% de visibilidad en páginas con INP superior a 300ms en móvil. No todas las pérdidas de posicionamiento se atribuyen exclusivamente al INP — la mayoría de actualizaciones core afectan múltiples señales — pero el patrón confirma que un INP deficiente forma parte del perfil técnico de las páginas que pierden posiciones.

Para e-commerce, donde la velocidad de respuesta del carrito, filtros y buscadores interno tiene impacto directo en conversión, la optimización de INP tiene ROI doble: mejora el ranking y mejora la tasa de conversión de forma independiente.

Si quieres saber dónde está el INP de tu web y qué interacciones específicas lo están arrastrando hacia abajo, lo revisamos como parte de cualquier auditoría técnica. Cuéntanos tu caso.