Interaction to Next Paint (INP) para SEO

TL;DR — INP mide la rapidez con la que tu página responde cuando alguien hace clic, toca o escribe. El navegador cronometra el intervalo entre la interacción y la siguiente actualización visual, a lo largo de toda la visita, e informa aproximadamente la peor. Por debajo de 200 ms es bueno; por encima de 500 ms es deficiente. Es una de las tres Core Web Vitals, y reemplazó a una métrica más antigua llamada First Input Delay en 2024.

Qué mide realmente INP

Cuando haces clic en un botón, tocas un menú o escribes en un cuadro, esperas que la página reaccione — se abre un menú, se marca una casilla, aparece texto. Interaction to Next Paint (INP) mide cuánto tarda eso: el tiempo desde tu interacción hasta que el navegador pinta el siguiente fotograma que muestra algo cambiado.

Aquí está la parte que importa. INP no solo observa una interacción. Vigila cada clic, toque y pulsación de teclado durante toda tu visita, y luego informa (cerca de) la más lenta. Así que una sola interacción entrecortada — un cuadro de búsqueda que se congela durante medio segundo cada vez que escribes — puede hundir toda la puntuación.

El desplazamiento, pasar el cursor y el zoom no cuentan. Solo se miden los clics, los toques y las interacciones con el teclado.

Los umbrales

INP se informa en milisegundos, y Google lo clasifica en tres categorías:

• Bueno — 200 ms o menos
• Necesita mejoras — más de 200 ms, hasta 500 ms
• Deficiente — más de 500 ms

Para contexto: 200 ms es rápido, pero no es mucho margen. Todo lo que tu código hace en respuesta a un clic — más el dibujo del resultado por parte del navegador — tiene que caber dentro de ese tiempo.

Por qué reemplazó a FID

La métrica de capacidad de respuesta anterior era First Input Delay (FID). FID solo medía el retraso antes de que la primera interacción en una página comenzara a procesarse — y se detenía en el momento en que comenzaba el trabajo. No contaba cuánto tiempo tomaba realmente ese trabajo, ni cuánto tiempo tardaba la pantalla en actualizarse.

INP arregló todo eso. Mide el tiempo completo (desde el inicio hasta la actualización visual) para todas las interacciones, no solo la primera. Google hizo oficial el cambio el 12 de marzo de 2024, y FID desapareció por completo de las herramientas para septiembre de 2024.

Qué hace que INP sea malo — en términos simples

Casi siempre, es JavaScript acaparando el hilo principal. El navegador solo puede hacer una cosa a la vez en ese hilo, así que si un fragmento de script está ocupado ejecutándose, tu clic tiene que esperar en la fila. Culpables comunes:

• Trabajo pesado que se ejecuta dentro del propio manejador de clic/toque.
• Grandes “tareas largas” de JavaScript que bloquean todo.
• Scripts de terceros — análisis, banners de consentimiento de cookies, widgets de chat, gestores de etiquetas. Estos son algunos de los peores infractores, incluso en sitios de contenido simple.

La solución, en general, es hacer menos trabajo cuando alguien interactúa, y dividir los trabajos grandes en piezas pequeñas para que el navegador pueda intercalar tu interacción entre ellas.

¿Quieres la mecánica real — el desglose de latencia en tres partes, las matemáticas del percentil 75, exactamente cómo arreglar cada causa, y el ángulo de SEO? Cambia a la pestaña Avanzado.

TL;DR — INP es la Core Web Vital para la capacidad de respuesta. Observa la latencia de todas las interacciones de clic, toque y teclado a lo largo de una visita e informa el valor en el percentil 75 (un valor atípico descartado por cada 50 interacciones) — no solo la primera entrada como hacía FID. La latencia de una interacción = retraso de entrada + duración del procesamiento + retraso de presentación. Bueno ≤ 200 ms, deficiente > 500 ms, juzgado con datos de campo en p75. Reemplazó a FID el 12 de marzo de 2024 (FID eliminado por completo de las herramientas en septiembre de 2024). Arrégralo dividiendo las tareas largas, cediendo al hilo principal con scheduler.yield(), haciendo menos en los manejadores de eventos, reduciendo el DOM, y difiriendo los scripts de terceros. Es una métrica de campo — Total Blocking Time es el proxy de laboratorio, y los dos no siempre coinciden.

Qué mide INP — y en qué se diferencia de FID

La definición de Google es precisa: INP “evalúa la capacidad de respuesta general de una página a las interacciones del usuario observando la latencia de todos los clics, toques y pulsaciones de teclado que ocurren a lo largo de la vida de la visita de un usuario a una página.” Evidence for this claim INP observes click, tap, and keyboard interaction latency throughout a page visit rather than measuring only the first input delay. Scope: Current web.dev INP definition and qualifying interaction types. Confidence: high · Verified: 2026-07-14 web.dev: Interaction to Next Paint Esa frase de “todas las interacciones… a lo largo de la vida” es la clave. INP es una métrica a nivel de visita, no de tiempo de carga — y el razonamiento de Google es que la gran mayoría del tiempo de un usuario en una página ocurre después de que se carga, por lo que la capacidad de respuesta durante el uso importa más que la primera impresión por sí sola.

El contraste con First Input Delay es la forma más clara de entenderlo: “FID solo medía el retraso de entrada de la primera interacción en una página. INP mejora FID al observar todas las interacciones en una página, desde el retraso de entrada hasta el tiempo que tarda en ejecutar los manejadores de eventos.” FID cronometraba una cosa sobre una interacción — la espera antes de que comenzara su manejador — e ignoraba tanto cuánto tiempo se ejecutaba el manejador como cuánto tiempo tardaba la pantalla en actualizarse. INP mide la latencia completa de cada interacción.

Un matiz que vale la pena entender bien, porque es un mito común: INP no es literalmente la peor interacción. Para evitar penalizar a una página por un único pico aleatorio, el navegador descarta un valor atípico por cada 50 interacciones y luego informa el valor en el percentil 75 de las vistas de página. En una visita con pocas interacciones, eso cae en la interacción más lenta; en una con muchas, un par de valores atípicos se excluyen primero.

Lo que cuenta como interacción también es más limitado de lo que la gente asume. Solo se miden clics, toques y pulsaciones de teclado. El desplazamiento, el paso del cursor y el zoom están explícitamente excluidos. Y un solo gesto puede disparar varios eventos — un toque produce pointerdown, pointerup y click — que INP agrupa como una interacción, no tres. Dentro de ese grupo, INP toma la duración de evento individual más larga, no la suma de todos — así que un pointerdown rápido junto a un click lento aún se informa como una interacción dimensionada por el evento lento. Si una página no tiene interacciones que califiquen durante una visita, INP simplemente no se informa para ella.

Las tres partes de la latencia de una interacción

La latencia de cada interacción se divide en tres partes secuenciales. Este es el modelo que debes tener en mente, porque cada parte apunta a una solución diferente:

Interaction latency = Input delay + Processing duration + Presentation delay

1. Retraso de entrada — el tiempo antes de que tus manejadores de eventos puedan siquiera comenzar a ejecutarse, normalmente porque el hilo principal está ocupado terminando una tarea larga.
2. Duración del procesamiento — el tiempo que tardan en ejecutarse todas las devoluciones de llamada de tus manejadores de eventos.
3. Retraso de presentación — el tiempo desde que tus manejadores terminan hasta que el navegador pinta el siguiente fotograma en pantalla.

La compilación de atribución de web-vitals expone las tres (inputDelay, processingDuration, presentationDelay) para que puedas ver qué parte domina en una interacción real. Según los datos del Web Almanac de 2024, el retraso de presentación suele ser la parte más grande en la mediana — pero la duración del procesamiento es donde suele estar el margen de optimización, porque es la parte que se dispara en páginas mal construidas.

Los umbrales — y la advertencia del campo p75

Google Search Central establece el objetivo claramente — “an INP of less than 200 milliseconds” (traducción) «un INP inferior a 200 milisegundos» — y enmarca todo el programa así: “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (traducción) «Recomendamos encarecidamente que los propietarios de sitios logren buenos Core Web Vitals para tener éxito en la Búsqueda». El presupuesto de 200 ms es realmente ajustado cuando recuerdas que el navegador quiere un fotograma cada ~16,7 ms a 60 fps; todo tu trabajo de manejadores más el renderizado tiene que caber.

Por qué INP es una métrica de campo (y los datos de laboratorio no son suficientes)

Esta es la trampa que atrapa a muchos especialistas en SEO: una puntuación verde de Lighthouse no significa un buen INP. Pero «Lighthouse no puede medir el INP» necesita tres casos separados, no uno, o malinterpretarás tus propias herramientas:

1. Una ejecución estándar de Lighthouse sin interacción no informa ningún INP. Solo observa la carga de la página — nunca hace clic, toca ni escribe nada — por lo que no hay interacción que cronometrar. Lighthouse recurre al Tiempo de bloqueo total (TBT) como proxy del tiempo de carga. El propio marco de Google: “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (traducción) «Debido a que el TBT se correlaciona bien con el INP, una página con un TBT alto es un indicador razonable de que puede haber valores altos de INP durante la carga.» Las palabras clave son “during load.” (traducción) «durante la carga». El TBT no dice nada sobre una interacción que sale mal diez segundos después cuando se ejecuta un widget de carga diferida — es un proxy, nunca un sustituto ni una fórmula de conversión.
2. Una interacción ejercitada manual o sintéticamente — hacer clic en un botón real en DevTools, o programar un clic en una herramienta de laboratorio — sí produce un número real de latencia estilo INP para esa interacción. Eso es útil para reproducir un error específico. Pero sigue siendo una ruta programada en un dispositivo: no puede representar la mezcla de campo de dispositivos reales, usuarios reales, objetivos de interacción reales y una vida de página completa de una visita. Como dice Google, el valor resultante “will be dependent on what interactions are performed during the measurement period,” (traducción) «dependerá de las interacciones que se realicen durante el período de medición», y el comportamiento real del usuario es demasiado variable para que una sola ejecución de laboratorio lo represente.
3. La distribución de campo es lo único que realmente es el INP. Por eso la fuente autoritativa son los datos de campo: el Informe de experiencia de usuario de Chrome (CrUX), presentado a través de PageSpeed Insights y el informe de Core Web Vitals de Search Console. “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (traducción) «Los datos de campo son la mejor fuente de información que puedes utilizar para entender qué interacciones son problemáticas para los usuarios reales.»

Usa el laboratorio (casos 1 y 2) para encontrar y reproducir una interacción lenta; usa el campo (caso 3) para confirmar si realmente está perjudicando las puntuaciones de los visitantes reales.

Por qué tu puntuación de INP es deficiente

Casi todos los problemas de INP se remontan al hilo principal bloqueado cuando un usuario interactúa. Los sospechosos habituales:

• Tareas largas. Cualquier tarea del hilo principal de más de 50 ms es una tarea larga; la cantidad que supera los 50 ms es su «período de bloqueo». Mientras una se ejecuta, tu interacción no puede manejarse. Esta es la causa más grande.
• Manejadores de eventos pesados. Hacer demasiado de forma síncrona dentro de un manejador de clic/entrada infla directamente la duración del procesamiento.
• Tamaño grande del DOM. Los DOM más grandes cuestan más de renderizar, lo que infla tanto el retraso de entrada como el de presentación.
• Scripts de terceros. Según el Web Almanac, los proveedores de consentimiento, los administradores de etiquetas, la analítica y los widgets de chat son los principales infractores — y afectan incluso a sitios de contenido simple. Son el primer lugar donde miro en una página que no construí.
• JavaScript posterior a la carga. El hecho de que una página se haya renderizado no significa que haya terminado de cargar — los scripts que se evalúan después de la primera pintura pueden bloquear interacciones tempranas.

Cómo solucionarlo

Las estrategias, aproximadamente en orden de impacto:

1. Divide las tareas largas. El consejo principal de Google sobre los manejadores es “do as little work as possible in them.” (traducción) «haz la menor cantidad de trabajo posible en ellos». Divide un trabajo grande en tareas más pequeñas para que el navegador pueda intercalar una interacción del usuario. Cuando las tareas se dividen, “the browser can respond to higher-priority work much sooner — including user interactions.” (traducción) «el navegador puede responder mucho antes a trabajos de mayor prioridad — incluidas las interacciones del usuario».

2. Cede el hilo principal. La forma moderna y recomendada es scheduler.yield() (Chrome 129+, Firefox 142+): await scheduler.yield() pausa tu código, permite que el navegador maneje el trabajo pendiente y se reanuda con prioridad — así otras tareas no se adelantarán a tu continuación. La alternativa clásica es setTimeout(..., 0), que sigue funcionando pero envía tu código al final de la cola de tareas (y los navegadores aplican un mínimo de 5 ms después de varias llamadas anidadas). Una cosa que debes dejar de hacer: isInputPending() — Google ahora dice “we no longer recommend using this API.” (traducción) «Ya no recomendamos usar esta API». Consulta la pestaña Scripts para ver el patrón.

3. Haz menos en los controladores de eventos — difiere el trabajo no crítico. Ejecuta solo la actualización visual que el siguiente fotograma necesita de forma síncrona; empuja todo lo demás (guardado, corrección ortográfica, analítica, recuento de palabras) detrás de requestAnimationFrame + setTimeout o un yield. El usuario ve la respuesta de inmediato; el trabajo de registro ocurre después.

4. Evita el thrashing de layout. Leer propiedades de layout justo después de escribir estilos en la misma tarea obliga al navegador a hacer un layout síncrono que podría haber agrupado. Agrupa las lecturas y luego las escrituras.

5. Reduce el tamaño del DOM. Los árboles más pequeños se renderizan más rápido. content-visibility puede renderizar perezosamente los elementos fuera de pantalla para que no te cuesten durante la carga o la interacción.

6. Audita y difiere los scripts de terceros. Esta es la corrección SEO de mayor impacto en sitios reales. Carga los scripts de consentimiento/etiquetas/analítica de forma perezosa, condiciónalos a la interacción o sácalos de la ruta crítica. Una página de contenido “ligera” puede fallar INP simplemente por un widget pesado incrustado.

¿Afecta INP a los rankings?

Sí — INP es una de las tres Core Web Vitals, y las Core Web Vitals son parte de las señales de experiencia de página de Google. Pero es una señal ligera: un desempate entre resultados igualmente relevantes, no un factor de ranking primario. No persigas una puntuación INP perfecta a expensas del contenido y la relevancia.

Dos puntos SEO prácticos. Primero, el móvil es el número difícil. En el Web Almanac de 2024, ~74 % de los sitios móviles pasaron INP frente a ~97 % en escritorio — y como Google indexa primero el móvil, la cifra móvil es la que cuenta. Segundo, los sitios complejos rinden peor: solo ~53 % de los 1 000 sitios principales pasaron, porque las páginas ricas en funciones envían más JavaScript que bloquea el hilo principal. El desarrollo intensivo de funciones es un riesgo para INP, y las páginas de alta interacción — páginas de producto, checkout, resultados de búsqueda, formularios — están mucho más expuestas que el contenido estático.

INP vs FID — el panorama completo

FID ha desaparecido — eliminado de Search Console el día que se lanzó INP y de CrUX BigQuery/API para septiembre de 2024. Si una herramienta o auditoría aún menciona FID, está desactualizada.

Casos límite que hacen que los datos de INP no coincidan

Un puñado de peculiaridades del ciclo de vida explican la mayoría de las preguntas de “¿por qué mi RUM no coincide con CrUX?”:

• Sin interacciones, no hay INP. Si una visita nunca recibe un clic, toque o pulsación de tecla — o solo recibe gestos excluidos como desplazamiento y pasar el cursor — no hay valor de INP para esa vista de página. Esto es normal en páginas de contenido de solo lectura y no es un error en tu monitoreo.
• Los iframes cuentan para la métrica, pero tu propio JavaScript no puede ver dentro de ellos. Una interacción dentro de un iframe incrustado (un anuncio, un widget, un formulario incrustado) contribuye al INP de la página. Pero un script RUM de origen propio no puede leer eventos de un iframe de origen cruzado de la misma manera que la métrica del propio navegador — así que CrUX y una configuración RUM de mismo origen pueden legítimamente discrepar en páginas con incrustaciones de terceros. Documenta esta brecha en lugar de tratar una discrepancia RUM/campo como un error.
• Las restauraciones de caché de retroceso/avance restablecen el INP a cero. Una página recuperada de bfcache (el botón de retroceso, por ejemplo) comienza un conteo de INP fresco — las interacciones de antes de la navegación de salida no se transfieren.
• Las pestañas de larga duración y en segundo plano aún deben informar. Debido a que una pestaña puede permanecer abierta durante horas sin descargarse formalmente — especialmente en móvil, donde el sistema operativo puede simplemente matarla — el INP debe capturarse cuando la página se oculta, no solo al descargarse. Las configuraciones RUM que solo se vacían en unload perderán silenciosamente datos de estas visitas.

Dónde encaja esto

El INP es una pieza del panorama de Core Web Vitals, junto con Largest Contentful Paint (carga) y Cumulative Layout Shift (estabilidad visual). Verifícalo en PageSpeed Insights y el informe de Search Console (campo), y depúralo en Lighthouse / Chrome DevTools (laboratorio, a través del proxy TBT). Los datos detrás de todo provienen de CrUX.

Resumen de IA

Una versión condensada de la versión avanzada:

• INP = el Core Web Vital para la capacidad de respuesta. Observa la latencia de todas las interacciones de clic, toque y teclado a lo largo de toda una visita e informa el valor en el percentil 75 (un valor atípico descartado por cada 50 interacciones) — no solo la primera entrada como lo hacía FID.
• Latencia = retraso de entrada + duración del procesamiento + retraso de presentación. Cada parte apunta a una solución diferente; la duración del procesamiento suele ser donde está el apalancamiento.
• Umbrales (campo, p75): bueno ≤ 200 ms, necesita mejoras ≤ 500 ms, deficiente

  500 ms.

• Solo cuentan clics, toques y teclado — el desplazamiento, el pasar el cursor y el zoom están excluidos; los múltiples eventos de un solo gesto se agrupan como una interacción.
• Reemplazó a FID el 12 de marzo de 2024 (FID eliminado por completo de las herramientas en septiembre de 2024). FID solo medía el retraso de entrada de la primera interacción.
• Es una métrica de campo, y “Lighthouse no puede medirla” tiene tres casos: una ejecución estándar no interactiva de Lighthouse no informa INP y recurre a Total Blocking Time como proxy de tiempo de carga; una interacción de laboratorio ejercitada manualmente sí produce una latencia real de interacción única pero no puede sustituir a la población de campo; solo los datos de campo de CrUX / PageSpeed Insights / Search Console son autoritativos.
• Causas: tareas largas (>50 ms), manejadores de eventos pesados, DOM grande, y especialmente scripts de terceros (consentimiento, administradores de etiquetas, analítica, chat).
• Soluciones: divide las tareas largas, cede con scheduler.yield() (respaldo de setTimeout; isInputPending() ya no se recomienda), haz menos en los manejadores, evita el thrashing de diseño, reduce el DOM, difiere los scripts de terceros.
• Casos límite: sin interacción calificada no hay valor de INP; las interacciones en iframes cuentan para la métrica pero un script RUM de mismo origen no puede ver dentro de ellos; las restauraciones de bfcache restablecen el INP; las pestañas de larga duración/en segundo plano deberían informar al ocultarse, no solo al descargarse.
• SEO: una señal de ranking ligera. Móvil (~74 % pasa vs ~97 % escritorio) es el número que importa bajo la indexación móvil primero; las páginas de alta interacción son las más expuestas.

Documentación oficial

Documentación de fuente primaria de Google / el equipo de Chrome.

web.dev — las referencias de INP

• Interacción hasta la siguiente pintura (INP) — la definición definitiva: qué mide, el desglose de latencia en tres partes, los tipos de interacción y los umbrales.
• Optimizar la interacción hasta la siguiente pintura — el manual de optimización: hacer menos en los manejadores, diferir trabajo no crítico, el thrashing de diseño, el tamaño del DOM, content-visibility.
• Interaction to Next Paint se convierte oficialmente en una métrica web principal — la publicación de lanzamiento del 12 de marzo de 2024 (Jeremy Wagner y Rick Viscomi); el cronograma de desaprobación de FID.
• Retraso de la primera interacción (FID) — la métrica desaprobada; qué medía y por qué fue reemplazada.
• Una nueva métrica de capacidad de respuesta: envíanos tus comentarios — las limitaciones de diseño de FID y las mejoras de INP.
• Optimizar las tareas largas — la definición de tarea larga de 50 ms, scheduler.yield(), el respaldo de setTimeout, y por qué isInputPending() ya no se recomienda.
• Evaluación de scripts y tareas largas — TBT como proxy de INP y orientación sobre el tamaño de los scripts.
• Detectar interacciones lentas con datos de campo — la compilación de atribución de web-vitals y la API de Long Animation Frames (LoAF).

Chrome / Google Search

• Performance features reference (Chrome DevTools) — la pista Interactions, Live Metrics y la advertencia de 200 ms.
• CrUX release notes — confirma la eliminación de FID de BigQuery/API en septiembre de 2024.
• Core Web Vitals & Google Search results — INP como parte de la señal de experiencia de página; el objetivo de ≤ 200 ms.

Citas de la fuente

Declaraciones públicas de Google / el equipo de Chrome. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Qué mide INP y en qué se diferencia de FID

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (traducción) «INP es una métrica de Core Web Vitals que evalúa la capacidad de respuesta general de una página a las interacciones del usuario al observar la latencia de todos los clics, toques e interacciones de teclado que ocurren durante la vida de la visita de un usuario a una página». — web.dev, Interaction to Next Paint (INP). Ir a la cita
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (traducción) «FID solo medía el retraso de entrada de la primera interacción en una página. INP mejora FID al observar todas las interacciones en una página, desde el retraso de entrada hasta el tiempo que tarda en ejecutar los manejadores de eventos». Ir a la cita
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (traducción) «First Input Delay (FID) ya no es una Core Web Vital y ha sido reemplazada por la métrica Interaction to Next Paint (INP)». — web.dev, First Input Delay (FID). Ir a la cita

El cambio de FID a INP

• “FID will be deprecated.” (traducción) «FID será desaprobado». — Jeremy Wagner y Rick Viscomi, blog de web.dev, Interaction to Next Paint officially becomes a Core Web Vital. Ir a la cita
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (traducción) «FID se eliminará de Google Search Console tan pronto como INP se convierta en una Core Web Vital el 12 de marzo». Ir a la cita

Tareas largas: la causa principal

• “Any task that takes longer than 50 milliseconds is a long task.” (traducción) «Cualquier tarea que tarde más de 50 milisegundos es una tarea larga». — web.dev, Optimize long tasks. Ir a la cita

Los datos de campo son la fuente principal

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (traducción) «Los datos de campo son la mejor fuente de información a la que puedes recurrir para entender qué interacciones son problemáticas para los usuarios reales». — web.dev, Find slow interactions in the field. Ir a la cita

Google Search

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (traducción) «Recomendamos encarecidamente que los propietarios de sitios logren buenos Core Web Vitals para tener éxito en la Búsqueda». — Google Search Central, Core Web Vitals & Google Search results. Fuente

Lista de verificación para corregir INP

Trabaja de arriba hacia abajo: los elementos cercanos a la parte superior tienden a mover más el número:

• Obtén el INP de campo (PageSpeed Insights / informe de CWV de Search Console), no solo una puntuación de laboratorio — y revisa el móvil por separado.
• Identifica la(s) interacción(es) lenta(s) con la compilación de atribución de web-vitals o la pista Interactions de Chrome DevTools (marca cualquier cosa superior a 200 ms).
• Encuentra y divide las tareas largas (cualquier cosa superior a 50 ms en el hilo principal).
• Cede el hilo principal dentro de bucles de larga duración — scheduler.yield(), con un respaldo de setTimeout(..., 0). (Deja de usar isInputPending().)
• Dentro de cada controlador, ejecuta solo la actualización crítica para el renderizado de forma síncrona; difiere guardar, validar, revisar ortografía y analíticas detrás de rAF + setTimeout.
• Comprueba si hay thrashing de layout — leer el layout justo después de escribir estilos en la misma tarea. Agrupa las lecturas y luego las escrituras.
• Audita los scripts de terceros (consentimiento, gestor de etiquetas, analíticas, chat). Difiere, carga diferida o condicionalos a la interacción — normalmente la mayor victoria individual.
• Reduce el tamaño del DOM; aplica content-visibility a las secciones fuera de pantalla.
• Difiere / divide en código el JS no crítico para que los scripts posteriores a la carga no bloqueen las interacciones tempranas.
• Vuelve a medir en el campo después del despliegue — CrUX es una ventana móvil de 28 días, así que la puntuación se mueve lentamente.

INP vs FID — hoja de referencia

Datos rápidos

• Umbrales (campo, p75): Bueno ≤ 200 ms · Necesita mejoras ≤ 500 ms · Deficiente > 500 ms.
• Cuenta: clics, toques, teclado. Excluye: desplazamiento, pasar el cursor, zoom.
• Latencia = retraso de entrada + duración del procesamiento + retraso de presentación.
• Tarea larga = cualquier tarea del hilo principal > 50 ms.
• Proxy de laboratorio: Total Blocking Time — correlaciona, pero solo refleja el bloqueo durante la carga. La fuente autoritativa son los datos de campo (CrUX).
• La tasa de aprobación en móvil (~74 %) está muy por debajo de la de escritorio (~97 %) — y el móvil es lo que cuenta.

Cede el hilo principal

Cuando tienes un bucle de larga duración (renderizar una lista grande, procesar datos al hacer clic), cede el control periódicamente al navegador para que pueda atender una interacción pendiente del usuario. La API moderna es scheduler.yield(); recurre a setTimeout donde no esté soportada.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Algunas notas:

• scheduler.yield() devuelve una promesa que se resuelve en una tarea futura, y su continuación está priorizada — otras tareas en cola no se adelantarán a tu código reanudado.
• setTimeout(..., 0) funciona en todas partes pero empuja tu continuación al final de la cola (y los navegadores aplican un mínimo de ~5 ms después de varias llamadas anidadas).
• No recurras a isInputPending() — Google “no longer recommend[s] using this API.” (traducción) «Ya no recomienda usar esta API».

Diferir trabajo no crítico en un manejador

Ejecuta solo lo que necesita el siguiente fotograma; empuja el resto detrás de una pintura.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Herramientas para medir y corregir INP

Campo (autoritativo — esto es lo que Google puntúa)

• PageSpeed Insights — INP de campo de CrUX para la URL/origen, dividido por móvil y escritorio, más una pasada de diagnóstico de laboratorio.
• Search Console — Informe de Core Web Vitals — estado de INP en tus URLs, agrupado por problema, con datos de campo.
• CrUX — el conjunto de datos subyacente del Chrome User Experience Report (también consultable mediante la API de CrUX / BigQuery).

Laboratorio / depuración

• Chrome DevTools — Panel de rendimiento — la pista Interactions mide el retraso de entrada, procesamiento y presentación de cada interacción, y marca cualquier cosa superior a 200 ms; Live Metrics se actualiza mientras haces clic.
• Lighthouse — no puede medir INP directamente; informa Total Blocking Time como proxy de laboratorio.

Monitoreo de usuarios reales (RUM)

• Biblioteca JS web-vitals — onINP() para el valor; la compilación de atribución (web-vitals/attribution) expone inputDelay / processingDuration / presentationDelay, el selector interactionTarget, y entradas LoAF para que puedas ver exactamente qué script y elemento causaron la interacción lenta. Cualquier configuración de RUM que uses, documenta su tasa de muestreo y cobertura de atribución — una cifra de RUM citada sin ese contexto no es comparable al p75 de campo de CrUX, y no puede ver dentro de iframes de origen cruzado como la métrica agregada (ver Casos límite, en la pestaña Avanzado).

Cómo puntúan las propias herramientas

Un ejemplo en vivo de la métrica que describe esta página — servicios conocidos de velocidad de página y monitoreo clasificados por su propio INP móvil de usuarios reales (datos de campo del Chrome UX Report):

Correcciones de INP que suelen no dar en el clavo

Optimizar solo la primera interacción

INP evalúa las interacciones a lo largo de la visita, no solo la primera entrada. Ejercita menús, búsqueda, filtros, formularios y otros controles repetidos antes de decidir que la página es receptiva.

Tratar el Total Blocking Time como el resultado

TBT es un proxy de laboratorio útil porque expone tareas largas del hilo principal, pero no es INP de campo. Úsalo para encontrar candidatos y luego verifica las interacciones reales con datos de campo o un rastreo de interacción.

Mover todo el trabajo a una sola devolución de llamada retrasada

Diferir un bloque grande puede simplemente mover la congelación. Divide el trabajo en tareas más pequeñas y cede el control para que el navegador pueda pintar entre ellas.

Eliminar la retroalimentación visual para acortar el manejador

Un control que realiza trabajo sin mostrar una respuesta sigue sintiéndose roto. Renderiza el cambio de estado inmediato primero, luego difiere el trabajo de seguimiento no crítico.

Diagnosticar INP con el modelo de latencia de tres partes

Cada interacción lenta tiene tres lugares que revisar:

1. Retraso de entrada: el evento esperó porque el trabajo anterior del hilo principal aún se estaba ejecutando. Audita tareas largas y JavaScript de terceros antes de que comenzara el manejador.
2. Duración del procesamiento: el manejador de eventos en sí hizo demasiado. Reduce el trabajo síncrono, divide bucles y pospone cualquier cosa que el siguiente fotograma no necesite.
3. Retraso de presentación: el estilo, el diseño o la pintura tardaron demasiado después del manejador. Reduce la complejidad del DOM y evita forzar cálculos de diseño repetidos.

Comienza con la fase más grande en el rastreo. Vuelve a grabar la misma interacción después de cada cambio para que un manejador más rápido no oculte un nuevo cuello de botella de presentación.

Demostrar que un cambio de INP mejoró la interacción

Prueba de cesión del handler

Prueba a ejecutar: registra la interacción objetivo en el panel de rendimiento antes y después de dividir o ceder trabajo largo. Resultado esperado: el intervalo de procesamiento de la interacción se reduce o se divide por una pintura. Interpretación del fallo: el trabajo costoso está en otro lugar o aún se ejecuta de forma síncrona. Ventana de monitoreo: inmediata en trazas repetidas. Disparador de reversión: el control se actualiza fuera de orden, pierde estado o produce nuevos errores de entrada.

Prueba de presentación

Prueba a ejecutar: inspecciona el trabajo de estilo, diseño y pintura de la misma traza después del handler de eventos. Resultado esperado: la siguiente pintura llega antes sin una tarea de diseño más grande. Interpretación del fallo: el tamaño del DOM o el diseño forzado sigue siendo el cuello de botella. Ventana de monitoreo: inmediata en trazas de laboratorio. Disparador de reversión: la respuesta visual se vuelve incompleta o inestable.

Confirmación en el campo

Prueba a ejecutar: compara la atribución onINP() posterior al lanzamiento para la interacción y plantilla cambiadas con su línea base. Resultado esperado: el INP p75 mejora y el elemento objetivo ya no domina los eventos lentos. Interpretación del fallo: el caso de laboratorio no representó dispositivos o recorridos reales. Ventana de monitoreo: RUM a medida que llegan las visitas; CrUX en su ventana móvil de 28 días. Disparador de reversión: la capacidad de respuesta o la finalización de la interacción empeoran de manera consistente después del despliegue.

Métricas de INP que vale la pena rastrear

INP de usuarios reales en p75

Métrica: el INP del percentil 75 por plantilla y clase de dispositivo. Qué te dice: si las visitas reales típicas son receptivas en todo su recorrido. Cómo obtenerla: CrUX, PageSpeed Insights o RUM de web-vitals. Referencia / rango realista: 200 ms o menos es bueno; por encima de 500 ms es deficiente. Cadencia: monitorea después de los lanzamientos de JavaScript y revisa la tendencia de campo móvil mensualmente.

Tasa de interacciones lentas

Métrica: la proporción de interacciones medidas por encima de 200 ms, agrupadas por objetivo. Qué te dice: qué controles crean el mayor retraso visible para el usuario incluso cuando el p75 a nivel de página pasa. Cómo obtenerla: la compilación de atribución de web-vitals o los datos de Event Timing en RUM. Referencia / rango realista: establece una línea base por recorrido y reduce los infractores de mayor volumen. Cadencia: semanal para plantillas similares a aplicaciones.

Proporción de fases de latencia

Métrica: retraso de entrada, duración del procesamiento y retraso de presentación para interacciones lentas. Qué te dice: si la programación, el código del handler o el renderizado son la principal restricción. Cómo obtenerla: trazas de DevTools y atribución de INP. Referencia / rango realista: ninguna división universal es saludable; compara cada fase con su propia línea base y el umbral total bueno de 200 ms. Cadencia: durante cada investigación de rendimiento enfocada.

Recursos que valen tu tiempo

Google / Chrome (el canon)

• Interaction to Next Paint (INP) — empieza aquí.
• Optimize Interaction to Next Paint — las correcciones.
• Optimize long tasks — cesión, scheduler.yield().
• Find slow interactions in the field — depuración con LoAF + atribución.
• INP becomes a Core Web Vital — el lanzamiento del 12 de marzo de 2024.

Datos

• Web Almanac 2024 — Performance — los números reales de tasa de aprobación de INP y las medianas de subpartes.

Del sector

• INP — Documentos web de MDN — la entrada de referencia de MDN; útil para contrastar la compatibilidad del navegador y la definición de la métrica fuera de la documentación de Google.
• API del programador: scheduler.yield() — MDN — tabla de compatibilidad del navegador y detalles de la especificación para la primitiva de rendimiento principal.
• PerformanceEventTiming — MDN — la API del navegador subyacente que lee INP; útil al profundizar en los datos brutos de sincronización de eventos.
• API de fotogramas de animación largos — Estado de la plataforma Chrome — seguimiento de la compatibilidad del navegador con LoAF, la API que impulsa la atribución de INP en la biblioteca web-vitals.
• Tema INP — Search Engine Land — cobertura de noticias del sector sobre las actualizaciones de INP, resultados de pruebas y la transición de FID a INP por parte de profesionales.

Estadísticas que vale la pena citar

• ~74 % móvil frente a ~97 % escritorio superan INP (2024). El móvil es mucho más difícil — y, como Google indexa primero el móvil, es el número que importa para el SEO. Web Almanac 2024
• Solo ~53 % de los 1 000 sitios principales superan INP — los sitios con muchas funciones envían más JavaScript que bloquea el hilo principal, por lo que los sitios más grandes suelen obtener peores resultados. Web Almanac 2024
• Tarea larga = > 50 ms. Cualquier cosa que supere los 50 ms en el hilo principal bloquea la respuesta del navegador a las interacciones: el mecanismo directo detrás de un INP deficiente. web.dev — Optimizar tareas largas
• Medianas de subpartes (2024): el retraso de presentación de ~36 ms suele ser el mayor contribuyente individual en la mediana, con el retraso de entrada y el tiempo de procesamiento muy cerca en p75 — útil para saber qué tercio atacar. Web Almanac 2024

Vídeos

• Google Chrome Developers (YouTube) — los explicadores de Core Web Vitals e INP del equipo de Chrome, incluidos tutoriales para diagnosticar interacciones lentas en DevTools. Canal

Ponte a prueba: Interaction to Next Paint

Cinco preguntas rápidas sobre capacidad de respuesta y diagnóstico de INP. Elige una respuesta para cada una y luego comprueba.

Registro de cambios