INP: La Nueva Métrica de Google para Interactividad

La métrica que nadie medía hasta marzo de 2024

Durante años, la comunidad SEO se obsesionó con el LCP y el CLS como las métricas de Core Web Vitals más relevantes para el ranking. El FID (First Input Delay) existía como tercera métrica, pero rara vez causaba problemas: medía únicamente el retraso entre la primera interacción del usuario y el inicio de su procesamiento, y la mayoría de las páginas lo superaban sin esfuerzo. Bastaba con que el hilo principal no estuviera completamente bloqueado en el momento del primer clic.

En marzo de 2024, Google eliminó el FID y lo sustituyó por el INP (Interaction to Next Paint). El cambio no fue cosmético. INP mide algo fundamentalmente distinto: la latencia completa de todas las interacciones del usuario durante toda la vida de la página, no solo la primera. Y el resultado fue una revelación: según datos del Web Almanac de HTTPArchive publicados en 2025, el 27% de los sitios web que superaban el umbral de FID ahora suspenden el de INP. Casi tres de cada diez sitios que creían tener buena interactividad descubrieron que no la tenían.

INP es una señal de ranking con el mismo peso que el LCP y el CLS dentro de los Core Web Vitals. Las páginas con un INP superior a 500ms aparecen como deficientes en Google Search Console, y los datos que Google utiliza para evaluar este factor provienen del Chrome UX Report: el percentil 98 de todas las interacciones reales de los últimos 28 días. No hay margen para ignorar esta métrica.

Qué es el INP y por qué sustituyó al FID

El Interaction to Next Paint mide la capacidad de respuesta de una página web cuantificando cuánto tiempo transcurre desde que el usuario interactúa — un clic, un tap, una pulsación de teclado — hasta que el navegador pinta la actualización visual resultante. Este ciclo completo incluye tres fases:

Input delay. El tiempo que transcurre entre la interacción del usuario y el momento en que el navegador comienza a ejecutar los event handlers asociados. Si el hilo principal está ocupado ejecutando JavaScript, la interacción queda en cola hasta que el hilo se libera. Esta era la única fase que medía FID.

Processing time. El tiempo que tardan los event handlers (callbacks de JavaScript) en ejecutarse. Un event handler de clic que ejecuta una función compleja (filtrar una lista, validar un formulario, recalcular un layout) puede tardar cientos de milisegundos si el código no está optimizado.

Presentation delay. El tiempo que transcurre desde que los event handlers terminan hasta que el navegador completa el siguiente frame visual (paint). Incluye el tiempo de style recalculation, layout, composite y paint. Si los event handlers modifican el DOM o los estilos de forma extensiva, esta fase puede ser la más costosa.

FID solo medía la primera fase de la primera interacción. INP mide las tres fases de todas las interacciones y reporta el percentil 98 como valor final. Esto significa que una sola interacción extremadamente lenta en toda la sesión es suficiente para degradar el INP.

Google tomó la decisión de reemplazar FID por INP porque los datos de campo mostraban que el FID no reflejaba la experiencia real del usuario. Un sitio podía tener un FID excelente — el hilo principal estaba libre cuando el usuario hacía su primer clic — pero ofrecer una experiencia terrible en interacciones subsiguientes: botones que tardan 400ms en responder, formularios que se congelan al validar, filtros que bloquean el navegador durante medio segundo.

Cómo mide el INP la interactividad: el ciclo completo

Para entender cómo optimizar el INP, es necesario comprender el ciclo completo de procesamiento de una interacción en el navegador.

Cuando un usuario hace clic en un botón, la secuencia es la siguiente:

1. El navegador registra el evento y lo añade a la cola del hilo principal. Si el hilo principal está libre, comienza a procesarlo inmediatamente. Si está ejecutando una long task de JavaScript (> 50ms), el evento espera hasta que la task actual termine. Este tiempo de espera es el input delay.

2. Los event handlers se ejecutan. Todo el JavaScript asociado al evento (listeners de click, pointerdown, keydown, etc.) se ejecuta secuencialmente en el hilo principal. Si múltiples handlers están registrados para el mismo evento, se ejecutan en orden. El tiempo total de ejecución es el processing time.

3. El navegador recalcula estilos, ejecuta layout y pinta. Si los event handlers modificaron el DOM o los estilos CSS, el navegador debe recalcular todo el layout afectado, componer las capas visuales y pintar los píxeles actualizados. Este proceso es el presentation delay.

4. El siguiente frame visual aparece en pantalla. El tiempo total desde el paso 1 hasta el paso 4 es lo que INP mide para cada interacción.

Un dato técnico relevante: el navegador funciona a 60fps (frames por segundo) cuando todo va bien, lo que significa un frame cada 16.7ms. Si el procesamiento completo de una interacción cabe en un solo frame, la respuesta es instantánea para el usuario. Cuando el procesamiento supera los 200ms — el umbral de INP de Google — el usuario percibe un retraso notable.

La Long Animation Frames API (LoAF), disponible en Chrome desde la versión 123, permite medir con precisión qué ocurre durante cada frame prolongado. Proporciona datos granulares sobre qué scripts están ejecutándose, cuánto tarda cada uno, y dónde se produce el cuello de botella. Esta API reemplaza a la Long Tasks API para diagnóstico de INP porque reporta no solo la duración sino también la cadena de scripts responsables.

Umbrales de INP: bueno, necesita mejora y deficiente

Google define tres rangos para el INP:

• Bueno: inferior a 200ms. La interacción se percibe como instantánea o casi instantánea. Según datos de CrUX de 2025, el 63% de los orígenes web alcanzan este umbral en mobile.

• Necesita mejora: entre 200ms y 500ms. El usuario percibe un retraso notable pero no lo suficientemente largo como para abandonar la interacción. El 21% de los orígenes se sitúan en este rango.

• Deficiente: superior a 500ms. La interacción se percibe como bloqueada o congelada. El usuario puede intentar hacer clic repetidamente o abandonar la página. El 16% de los orígenes tienen un INP deficiente.

Un aspecto que distingue al INP de las otras métricas de Core Web Vitals es que utiliza el percentil 98 en lugar del percentil 75 para la evaluación. Esto tiene una implicación práctica significativa: si una página recibe 100 interacciones durante una sesión, el INP reportado será la segunda peor interacción. Este percentil tan alto fue elegido deliberadamente por Google para capturar la peor experiencia representativa sin ser distorsionado por outliers extremos.

El impacto del INP en ranking se mide a nivel de origen (dominio), no de URL individual. Google agrega los datos de campo de todas las páginas de un dominio para calcular el INP general. Esto significa que unas pocas páginas con formularios o filtros muy lentos pueden degradar el INP de todo el dominio, incluso si el resto de las páginas son rápidas.

Diagnóstico: cómo identificar interacciones lentas

Diagnosticar problemas de INP requiere herramientas que permitan identificar qué interacciones específicas son lentas y qué está causando el retraso en cada fase del ciclo.

Chrome DevTools — Performance tab. Graba una sesión en la que interactúes con los elementos problemáticos de la página: clics en botones, interacciones con filtros, escritura en formularios. En la grabación, busca las interacciones marcadas con un indicador rojo o amarillo en la sección “Interactions”. Cada interacción muestra el input delay, processing time y presentation delay desglosados. Los bloques de color naranja en la línea de tiempo son long tasks que potencialmente están causando input delay.

Long Animation Frames API (LoAF). En la consola de Chrome, el código performance.getEntriesByType('long-animation-frame') devuelve todos los frames que superaron los 50ms, incluyendo los scripts específicos que se ejecutaron durante cada frame. Para diagnóstico de INP, filtra los frames que coinciden temporalmente con las interacciones problemáticas. Esta API identifica no solo el script sino la función específica y la línea de código responsable del retraso.

Web Vitals Chrome Extension. Muestra el INP en tiempo real y resalta la interacción que está determinando el valor actual. Al pasar el cursor sobre el indicador de INP, la extensión muestra qué elemento fue interactuado y cuál fue el desglose de tiempos.

PageSpeed Insights y CrUX. Proporcionan el INP de campo — el percentil 98 real de los últimos 28 días — que es el valor que Google utiliza para ranking. El INP de laboratorio es útil para diagnóstico pero puede no coincidir con el de campo si los patrones de interacción de los usuarios reales son diferentes a los que el desarrollador simula.

Google Search Console. El informe de Core Web Vitals en Search Console clasifica las URLs del dominio por su estado de INP (“Bueno”, “Necesita mejora”, “Deficiente”) y agrupa las URLs con patrones similares, lo que permite identificar templates o tipos de página que comparten un problema común.

Las causas más comunes de un INP alto

Las causas de INP alto se agrupan en tres categorías directamente relacionadas con las tres fases del ciclo de interacción:

Long tasks en el hilo principal (input delay). Cualquier tarea de JavaScript que dure más de 50ms bloquea el hilo principal y retrasa el procesamiento de interacciones. Las fuentes más frecuentes de long tasks son: scripts de analytics (Google Analytics, Hotjar, Mixpanel) que procesan datos de forma síncrona, scripts de publicidad que evalúan bidding y cargan creativos, polyfills o transpilaciones de JavaScript que ejecutan código innecesario en navegadores modernos, y frameworks JavaScript que realizan hydration pesada al cargar la página.

Según datos del Web Almanac 2025, el JavaScript de terceros es responsable del 65% de las long tasks en sitios comerciales. Un solo script de analytics mal configurado puede añadir entre 100 y 300ms de bloqueo al hilo principal, degradando el input delay de cualquier interacción que ocurra durante su ejecución.

Event handlers lentos (processing time). Los callbacks de JavaScript que se ejecutan en respuesta a una interacción pueden ser costosos por múltiples razones: manipulación extensiva del DOM (insertar, eliminar o reorganizar cientos de nodos), ejecución de lógica computacionalmente pesada en el hilo principal (sorting, filtering, validación de formularios complejos), llamadas síncronas a APIs o localStorage, y recálculo forzado de layout por leer propiedades como offsetHeight o getBoundingClientRect() después de modificar el DOM.

Actualizaciones visuales costosas (presentation delay). Cuando los event handlers modifican el DOM o los estilos CSS de forma extensiva, el navegador debe ejecutar style recalculation, layout, composite y paint antes de mostrar el siguiente frame. Las operaciones más costosas son: modificar propiedades que fuerzan relayout (width, height, top, left, font-size), añadir o eliminar elementos del flujo del documento, y cambiar clases CSS que afectan a muchos elementos del DOM.

Técnicas de optimización: long tasks, event handlers y web workers

La optimización del INP se estructura en tres niveles que corresponden a las tres fases del ciclo de interacción:

Nivel 1: Eliminar o reducir long tasks (input delay). La técnica más eficaz es dividir las long tasks en bloques menores de 50ms que permitan al navegador procesar interacciones entre bloques. Las opciones modernas incluyen:

• scheduler.yield() (disponible en Chrome 129+): permite al navegador pausar la ejecución del script para procesar eventos pendientes y reanudar después. Es la API más limpia para dividir long tasks.
• scheduler.postTask(): programa tareas con prioridad (user-blocking, user-visible, background), permitiendo que las interacciones del usuario siempre tengan prioridad sobre el trabajo de fondo.
• requestIdleCallback(): delega trabajo a momentos en que el navegador está inactivo, ideal para tareas que no son urgentes como pre-carga de datos o analytics.

Para scripts de terceros que causan long tasks pero no pueden ser modificados, la solución es cargarlos con defer o async, o moverlos a un Web Worker. Un Web Worker ejecuta JavaScript en un hilo separado que no bloquea el hilo principal, eliminando su impacto en el input delay.

Nivel 2: Optimizar event handlers (processing time). Las técnicas clave son:

• Debounce y throttle: para interacciones que se disparan repetidamente (scroll, input, resize), limitar la frecuencia de ejecución del handler evita procesamiento redundante. Un input de búsqueda con debounce de 150ms ejecuta la función de filtrado solo cuando el usuario deja de teclear, en lugar de en cada pulsación.
• Virtualización de listas: para interfaces que muestran cientos de elementos, renderizar solo los visibles en el viewport y reciclar los nodos del DOM reduce el processing time de O(n) a O(1). Bibliotecas como react-window o @tanstack/virtual implementan este patrón.
• Offload a Web Workers: cualquier lógica computacionalmente pesada — sorting, procesamiento de datos, transformación de imágenes — puede ejecutarse en un Worker sin bloquear el hilo principal. El handler del evento envía los datos al Worker vía postMessage() y recibe el resultado de vuelta.

Nivel 3: Reducir el coste visual (presentation delay). Las técnicas para minimizar el impacto de los cambios en el DOM son:

• Usar transform y opacity en lugar de propiedades que fuerzan relayout para animaciones desencadenadas por interacciones.
• Agrupar las modificaciones del DOM para que el navegador ejecute un solo ciclo de layout en lugar de múltiples.
• Usar content-visibility: auto en secciones fuera del viewport para que el navegador no recalcule su layout durante las interacciones.
• Evitar forzar layout síncrono leyendo propiedades de layout después de escribir en el DOM dentro del mismo frame.

La combinación de estas tres capas de optimización puede reducir el INP de un sitio de 500ms a menos de 150ms sin alterar la funcionalidad visible. Según datos publicados por web.dev en 2025, los sitios que implementaron scheduler.yield() para dividir sus long tasks principales reportaron mejoras de INP del 40 al 60% en datos de campo.

La velocidad web y la interactividad comparten las mismas causas raíz: un hilo principal sobrecargado de JavaScript retrasa tanto la carga inicial (LCP) como la respuesta a interacciones (INP). Optimizar una métrica suele mejorar la otra, lo que convierte al rendimiento del hilo principal en el factor técnico más determinante de los tres Core Web Vitals. Dicho de otro modo: resolver el JavaScript bloqueante a menudo es la única intervención que necesitas hacer.