---
title: "Interaction to Next Paint (INP): medir y mejorar la interactividad"
description: "Optimizar el INP: un buen valor es de 200 ms como máximo en el percentil 75."
locale: "es"
canonical: "https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/interaction-to-next-paint-inp-medir-y-mejorar-la-interactividad"
category: "SEO & GEO"
topic: "SEO técnico"
updated: "2026-10-28T13:09:05.710Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Interaction to Next Paint (INP): medir y mejorar la interactividad

Interaction to Next Paint (INP) es una Core Web Vital que mide la capacidad de respuesta de una web a lo largo de todas las interacciones del usuario durante una visita a la página, desde la entrada hasta el siguiente fotograma visible. Un buen valor se sitúa en 200 milisegundos o menos en el percentil 75. Desde marzo de 2024, el INP sustituye a First Input Delay y, a diferencia de este, tiene en cuenta todas las interacciones y no solo la primera.

## De un vistazo

- El INP mide la capacidad de respuesta en todas las interacciones de una carga de página; un buen valor es <= 200 ms en el percentil 75 de las cargas de página. Desde marzo de 2024 sustituye al FID.
- Los datos de campo (CrUX, PageSpeed, web-vitals, RUM) son los que cuentan. Los datos de laboratorio solo sirven para depurar, con el Total Blocking Time como indicador indirecto.
- Un hilo principal sobrecargado es la causa número uno. En móvil, la página mediana pasa 2.366 ms en tareas largas (escritorio: 329 ms). Con 1.208 ms, el TBT es unas 18 veces mayor que en escritorio.
- En móvil, solo el 74 % de las webs tiene un buen INP, frente al 97 % en escritorio. El móvil necesita su propio presupuesto de JavaScript, más estricto.
- Dividir las tareas largas (scheduler.yield, postTask, setTimeout), eliminar el JS no utilizado (el 44 % de los bytes servidos en móvil) y limitar la frecuencia de los manejadores de eventos.
- Los Server Components, el streaming y la hidratación selectiva de Next.js reducen los costes de hidratación. Así, Economic Times pasó de ~1.000 ms a 257 ms de INP.
- Los scripts de consentimiento y de tracking suelen bloquear la primera interacción. Una carga diferida, supeditada al consentimiento o fuera del hilo principal protege el INP cumpliendo el RGPD.

## Por qué el INP importa para el SEO técnico en Austria

Interaction to Next Paint (INP) mide la rapidez con la que una web responde a las interacciones del usuario. Los clics, toques y pulsaciones de teclado desencadenan un proceso que termina con el siguiente fotograma visible (paint). El INP registra el retraso a lo largo de toda la visita a la página y no solo en la primera entrada. Desde el 12 de marzo de 2024, el INP es una [Core Web Vital estable y sustituye a First Input Delay](https://web.dev/blog/inp-cwv-launch). Con ello, la métrica forma parte de las señales de experiencia en la página que, según la documentación de Google, [están alineadas con los sistemas principales de ranking](https://developers.google.com/search/docs/appearance/core-web-vitals).

Para los proveedores B2B en Austria, esto tiene doble relevancia. Primero, la capacidad de respuesta es un factor de negocio: un análisis de cuatro sitios de e-commerce mostró una [correlación negativa constante entre el INP y la tasa de conversión](https://www.speedcurve.com/blog/INP-user-experience-correlation/), y las conversiones a veces ya se resentían a 100 ms, es decir, dentro del rango «bueno». Segundo, en Austria algo más de dos de cada cinco accesos llegan desde dispositivos móviles: según StatCounter, el acceso se reparte entre un [57,6 % de escritorio y un 42,4 % de móvil](https://gs.statcounter.com/platform-market-share/desktop-mobile/austria) (mayo de 2026). Con [8,69 millones de usuarios de internet y un 95,3 % de penetración](https://datareportal.com/reports/digital-2026-austria) (octubre de 2025), el [rendimiento móvil](https://blckalpaca.at/es/servicios/agencia-seo) decide sobre una parte considerable de la visibilidad.

El obstáculo es real. A nivel internacional, según DebugBear, en móvil solo el [64,9 % de las webs superaba la prueba del INP](https://www.debugbear.com/blog/hardest-core-web-vitals-metric); en el caso del [CLS](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/cumulative-layout-shift-cls-estabilidad-visual), era el 76,9 %. Solo el LCP, con un 54,9 %, resultaba aún más difícil de superar. Estos valores se basan en datos de CrUX de noviembre de 2023. Para 2024, el Web Almanac llega a un [74 % de buen INP en webs móviles, frente al 97 % en escritorio](https://almanac.httparchive.org/en/2024/performance). La brecha entre dispositivos sigue siendo grande.

## Cómo funciona el INP: tres fases y la diferencia clave con el FID

El INP divide cada interacción en tres fases. **Input Delay:** el tiempo hasta que el hilo principal queda libre y puede ejecutar el manejador de eventos. Un hilo bloqueado por JavaScript alarga esta fase. **Processing Time:** la ejecución de los propios manejadores de eventos, es decir, tu lógica de negocio, las actualizaciones del framework y los cálculos. **Presentation Delay:** el tiempo hasta que el navegador renderiza el resultado y pinta el siguiente frame.

La diferencia central con [First Input Delay](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/core-web-vitals-lcp-inp-y-cls-explicados) está en el alcance de la medición. El FID solo registraba el retraso de la primera entrada e ignoraba el tiempo de procesamiento y el de presentación. El INP tiene en cuenta todas las interacciones de una carga de página y reporta (de forma simplificada) el valor relevante más alto. Por tanto, una web puede haber tenido un FID perfecto y aun así mostrar un mal INP, porque interacciones posteriores como abrir un menú, filtrar una lista o enviar un formulario son lentas. El umbral: al menos el 75 % de las cargas de página debería alcanzar un INP [de 200 milisegundos como máximo](https://web.dev/articles/inp).

La causa principal de los malos valores es un hilo principal sobrecargado. Las tareas largas lo bloquean y retrasan cada nueva entrada. Toda tarea de más de 50 ms se considera una tarea larga. Los datos son claros: la página móvil mediana pasa [2.366 ms en tareas largas, frente a solo 329 ms en escritorio](https://almanac.httparchive.org/en/2024/javascript), con 14 tareas largas frente a 3 en la mediana. El Total Blocking Time, el indicador de laboratorio habitual para el INP, se sitúa en móvil en una mediana de [1.208 ms frente a 67 ms en escritorio](https://almanac.httparchive.org/en/2024/javascript), es decir, unas 18 veces más.

## Medir el INP: los datos de campo ganan a los de laboratorio

Para un diagnóstico fiable, tienes que separar los datos de campo de los de laboratorio.

**Datos de campo (los que cuentan):** proceden de usuarios reales. El Chrome User Experience Report (CrUX) alimenta PageSpeed Insights y Search Console. Para una monitorización continua, integras la librería JavaScript `web-vitals` o una solución de Real User Monitoring (RUM). Solo los datos de campo reflejan los dispositivos, la calidad de red y los patrones de interacción reales. Justo aquí se ve la desventaja del móvil, que se debe a la potencia de cálculo y la calidad de red reales.

**Datos de laboratorio (diagnóstico):** Lighthouse y las Chrome DevTools ofrecen valores reproducibles en un entorno controlado. El INP en sí no se puede medir directamente en laboratorio, porque requiere interacciones a lo largo del tiempo. En su lugar, el Total Blocking Time sirve como indicador indirecto: muestra cuánto se bloquea el hilo principal durante la carga. Los datos de laboratorio sirven para depurar y para pruebas de regresión en el pipeline de CI, pero nunca sustituyen la evaluación en campo.

La consecuencia: no optimices a ciegas para una puntuación de Lighthouse. Prioriza por percentil. El valor de INP lo determina el extremo lento de la distribución, es decir, del percentil 75 hacia arriba. Una interacción que es rápida en la mayoría de las cargas pero tarda 600 ms en un tercio de ellas es tu verdadero problema.

## Buenas prácticas: aliviar el hilo principal y acelerar las interacciones

Las palancas más eficaces reducen el trabajo de JavaScript o lo reparten en el tiempo.

**Dividir las tareas largas:** divide el trabajo en unidades más pequeñas y devuelve el control al hilo principal antes de superar los 50 ms. `scheduler.yield()` cede el control tras el trabajo en curso y lo reanuda con prioridad. `scheduler.postTask()` permite prioridades explícitas. `setTimeout` sirve como alternativa con mayor compatibilidad. Google ya [desaconseja usar](https://web.dev/articles/optimize-long-tasks) `isInputPending()`, porque la [API](https://blckalpaca.at/es/glosario/api) puede pasar por alto entradas. Mejor cede el control con regularidad, haya una entrada pendiente o no.

**Reducir la carga de JavaScript:** en la mediana se sirven en móvil [558 KB de JavaScript, de los cuales unos 206 KB no se usan](https://almanac.httparchive.org/en/2024/javascript), es decir, el 44 %. El code splitting, el tree shaking y la eliminación de código muerto actúan directamente sobre el Input Delay y el Processing Time. Carga solo lo que necesita cada página y aplaza la lógica no crítica.

**Optimizar los manejadores de eventos:** limita la frecuencia de los eventos recurrentes. El debouncing para las entradas y el throttling para los manejadores de scroll o resize evitan trabajo innecesario. El caso de redBus lo demuestra con precisión: con debouncing del manejador de scroll y gestión local del estado con sincronización diferida de Redux, el [INP de la página de búsqueda bajó un 72 %, con un aumento de ingresos del 7 %](https://web.dev/case-studies/redbus-inp). Evita re-renders costosos, usa `requestAnimationFrame` para las actualizaciones visuales, emplea CSS en lugar de JavaScript para las animaciones y alivia el renderizado con `content-visibility`.

**Domar los scripts de terceros y de consentimiento:** los scripts de tracking, de tag managers y de consentimiento suelen ejecutarse en el hilo principal y lo bloquean justo cuando el usuario quiere interactuar. Cárgalos de forma diferida, después de la primera interacción o en un Web Worker. Comprueba qué scripts son realmente críticos.

## Arquitectura Next.js para valores de INP bajos

En Next.js, gran parte de la carga de INP procede de la hidratación: el navegador tiene que «revivir» con JavaScript del cliente el HTML renderizado en el servidor, lo que sobrecarga el hilo principal.

[**React Server Components](https://blckalpaca.at/es/servicios/software-a-medida):** los componentes sin interactividad se renderizan en el servidor y no envían JavaScript al cliente. Eso reduce el bundle y, con ello, los costes de hidratación desde la raíz. El efecto está documentado en la práctica: Economic Times redujo el Total Blocking Time de [3.260 ms a 120 ms y el INP de unos 1.000 ms a 257 ms](https://web.dev/case-studies/economic-times-inp), entre otras cosas gracias a la migración a Next.js. El resultado: un 50 % menos de rebotes y un 43 % más de páginas vistas.

**Streaming y Suspense:** con `<Suspense>` transmites partes de la página en cuanto están listas, en lugar de esperar a todo. Eso acorta el tiempo hasta que las zonas visibles son interactivas.

**Hidratación selectiva e importaciones dinámicas:** marca solo las islas interactivas como componentes de cliente (`"use client"`). Los componentes de cliente pesados los cargas mediante `next/dynamic`, idealmente solo cuando hacen falta. Así evitas bundles de cliente grandes que bloquean el hilo principal desde el principio.

## Errores frecuentes al optimizar el INP

**Fijarse solo en la puntuación de Lighthouse:** un valor verde en laboratorio no garantiza un buen INP en campo. Los datos de laboratorio no conocen interacciones reales a lo largo del tiempo. Sin datos de campo ni análisis por percentiles, optimizas sin dar en el problema.

**Ignorar el caso más lento:** quien mira promedios pasa por alto el percentil 75. Justo ahí se mide el INP. Identifica de forma específica la interacción más lenta.

**No tocar los scripts de consentimiento y de tracking:** los scripts de los banners aparecen pronto y a menudo bloquean justo la primera interacción. Sin carga diferida o fuera del hilo principal, el efecto sigue siendo visible, sobre todo en las condiciones reales de los dispositivos móviles.

**Equiparar el presupuesto de móvil y de escritorio:** los dispositivos móviles tienen menos potencia de cálculo. Con [1.208 ms de TBT mediano en móvil frente a 67 ms en escritorio](https://almanac.httparchive.org/en/2024/javascript), el móvil necesita un presupuesto de JavaScript más estricto. Un bundle aceptable en escritorio puede superar con creces el umbral en móvil.

**Acumular JavaScript sin control:** si el 44 % del [JavaScript servido no se usa](https://almanac.httparchive.org/en/2024/javascript), es lastre muerto. Revisa la cobertura con regularidad y elimina el código no utilizado.

## Métricas, depuración y priorización en la práctica

Para depurar de forma específica, hoy existen herramientas precisas.

**API Long Animation Frames (LoAF):** ofrece datos detallados sobre frames largos, incluidos los scripts causantes y la fuente del bloqueo. Así no solo identificas que un frame fue largo, sino qué código lo causó.

**Panel Performance de Chrome DevTools:** muestra la pista de interacciones con Input Delay, Processing Time y Presentation Delay. Así ves cuál de las tres fases domina y orientas la medida en consecuencia: el Input Delay apunta a bloqueos del hilo principal, un Processing Time largo a manejadores costosos y un Presentation Delay alto a costes de renderizado o de layout.

**Atribución de la interacción más lenta:** con la librería `web-vitals` en modo de atribución o con una solución RUM, registras en cada carga de página la peor interacción junto con su contexto. Prioriza por frecuencia y gravedad en el percentil 75.

**Derivar valores objetivo para Austria:** fija 200 ms como límite máximo estricto, pero deja margen, porque según [SpeedCurve las conversiones a veces ya se resienten a 100 ms](https://www.speedcurve.com/blog/INP-user-experience-correlation/). Define presupuestos separados para móvil y escritorio. Como en Austria, según StatCounter, el [42,4 % del tráfico fue móvil](https://gs.statcounter.com/platform-market-share/desktop-mobile/austria) en mayo de 2026 y los dispositivos móviles superan el umbral con mucha más frecuencia pese a un [99,5 % de conexiones móviles con banda ancha (3G/4G/5G)](https://datareportal.com/reports/digital-2026-austria), el presupuesto móvil debería ser tu principal variable de control.

## Para profundizar: INP, crawlers de IA y consentimiento RGPD

El INP no actúa de forma aislada. Para la [Generative Engine Optimization](https://blckalpaca.at/es/servicios/geo) (GEO) cuenta sobre todo el contenido servido que recogen los crawlers de [IA](https://blckalpaca.at/es/glosario/ia). Una arquitectura ligera y renderizada en el servidor ayuda por igual a crawlers y usuarios: los Server Components reducen el JavaScript del cliente y entregan el contenido directamente en el HTML inicial. Los crawlers lo recogen de forma más fiable y los usuarios reciben respuesta más rápido.

El consentimiento [RGPD](https://blckalpaca.at/es/glosario/rgpd) es el punto ciego más frecuente. Las [plataformas de gestión del consentimiento](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/consent-mode-v2-y-privacy-sandbox-que-queda-despues-de-2025) se cargan pronto, renderizan overlays y, cuando el usuario acepta, desencadenan una cascada de scripts de terceros que ocupan todos el hilo principal. Tres medidas ayudan sin poner en riesgo el cumplimiento legal: carga los scripts de tracking solo después de obtener el consentimiento y de forma diferida. Traslada los scripts no esenciales al servidor o a un Web Worker. Y mantén el propio script de consentimiento lo más ligero posible, porque por definición aparece antes de la primera interacción. Así el hilo principal queda libre cuando el usuario cierra el banner, y es precisamente esa primera interacción la que entra en el INP.

## Datos y estadísticas

- El INP es una Core Web Vital estable desde el 12 de marzo de 2024 y sustituye a First Input Delay; umbral de 200 ms en el percentil 75 — [web.dev (equipo de Google Chrome) - 'Interaction to Next Paint is officially a Core Web Vital' (2024)](https://web.dev/blog/inp-cwv-launch)
- INP < 200 ms, LCP < 2,5 s, CLS < 0,1 como umbrales buenos; las Core Web Vitals están alineadas con los sistemas principales de ranking de Google — [Google Search Central - 'Understanding Core Web Vitals and Google search results' (2025)](https://developers.google.com/search/docs/appearance/core-web-vitals)
- 74 % de las webs móviles frente al 97 % de las de escritorio con buen INP (<= 200 ms) en 2024 — [HTTP Archive - Web Almanac 2024, capítulo Performance (2024)](https://almanac.httparchive.org/en/2024/performance)
- Total Blocking Time mediano: 1.208 ms en móvil frente a 67 ms en escritorio (aprox. 18 veces más) — [HTTP Archive - Web Almanac 2024, capítulo JavaScript (2024)](https://almanac.httparchive.org/en/2024/javascript)
- Tiempo mediano en tareas largas: 2.366 ms en móvil frente a 329 ms en escritorio; 14 frente a 3 tareas largas en la mediana — [HTTP Archive - Web Almanac 2024, capítulo JavaScript (2024)](https://almanac.httparchive.org/en/2024/javascript)
- 558 KB de JS servido en móvil (mediana); unos 206 KB sin usar (44 % de los bytes servidos) — [HTTP Archive - Web Almanac 2024, capítulo JavaScript (2024)](https://almanac.httparchive.org/en/2024/javascript)
- INP de la página de búsqueda mejorado un 72 %, +7 % de ingresos gracias al debouncing y a la gestión local del estado — [web.dev (Google) - Caso práctico 'How redBus improved their website's INP' (2024)](https://web.dev/case-studies/redbus-inp)
- TBT 3.260 ms -> 120 ms; INP ~1.000 ms -> 257 ms; -50 % de tasa de rebote; +43 % de páginas vistas; migración a Next.js — [web.dev (Google) - Caso práctico 'Economic Times quest for fixing INP' (2023)](https://web.dev/case-studies/economic-times-inp)
- Correlación negativa constante entre el INP y la tasa de conversión en cuatro sitios de e-commerce; efecto visible en algunos casos ya con INP = 100 ms — [SpeedCurve - 'Does Interaction to Next Paint actually correlate to user behavior?' (Cliff Crocker) (2023)](https://www.speedcurve.com/blog/INP-user-experience-correlation/)
- Austria: 57,6 % escritorio frente a 42,4 % móvil (mayo de 2026) — [StatCounter Global Stats - Desktop vs Mobile Market Share Austria (2026)](https://gs.statcounter.com/platform-market-share/desktop-mobile/austria)
- Austria: 8,69 millones de usuarios de internet (95,3 % de penetración, octubre de 2025); el 99,5 % de las conexiones móviles son de banda ancha (3G/4G/5G) — [DataReportal - Digital 2026: Austria (2026)](https://datareportal.com/reports/digital-2026-austria)
- Móvil: INP bueno en el 64,9 %, CLS bueno en el 76,9 %, LCP bueno en el 54,9 % (experiencia buena en al menos el 75 % de los casos; datos de CrUX a nivel de origen, noviembre de 2023) — [DebugBear - 'Core Web Vitals: Which Metric Is The Hardest To Pass?' (2025)](https://www.debugbear.com/blog/hardest-core-web-vitals-metric)

## Preguntas frecuentes

### ¿Qué es un buen valor de INP?

Un buen valor de INP es de 200 milisegundos o menos, medido en el percentil 75 de las cargas de página (en esencia, cada carga cuenta con su interacción más lenta). Los valores superiores a 500 ms se consideran malos. Lo que cuenta son los datos de campo de usuarios reales, no las mediciones de laboratorio. Como, según un análisis internacional, las conversiones a veces ya se resienten a partir de 100 ms, conviene dejar un margen por debajo del umbral.
### ¿En qué se diferencia el INP del First Input Delay (FID)?

El FID solo registraba el retraso de la primera entrada e ignoraba el tiempo de procesamiento y de presentación. El INP tiene en cuenta todas las interacciones de una visita a la página y reporta el valor relevante más alto. Cubre las tres fases Input Delay, Processing Time y Presentation Delay. El INP sustituyó al FID como Core Web Vital el 12 de marzo de 2024.
### ¿Cómo mido el INP correctamente?

El INP lo mides con datos de campo del Chrome User Experience Report (CrUX), PageSpeed Insights, Search Console, la librería web-vitals o una solución RUM. Los datos de laboratorio de Lighthouse y las DevTools solo sirven para depurar, y el Total Blocking Time se considera un indicador indirecto del INP. El INP en sí no se puede medir directamente en laboratorio, porque requiere interacciones reales a lo largo del tiempo.
### ¿Por qué mi INP es peor en móvil que en escritorio?

Los dispositivos móviles tienen menos potencia de cálculo y a menudo peor calidad de red. La página móvil mediana pasa unos 2.366 ms en tareas largas, frente a solo 329 ms en escritorio. El Total Blocking Time mediano también es unas 18 veces mayor en móvil: 1.208 ms frente a 67 ms en escritorio. Por eso el móvil necesita su propio presupuesto de JavaScript, más estricto.
### ¿Cómo mejora Next.js el INP?

Next.js reduce el INP sobre todo gracias a los React Server Components, que no envían JavaScript al cliente y así reducen los costes de hidratación. El streaming con Suspense, la hidratación selectiva de islas interactivas y las importaciones dinámicas evitan bundles grandes en el cliente. Con la migración a Next.js y la reducción del Total Blocking Time, Economic Times bajó el INP de unos 1.000 ms a 257 ms.
### ¿Qué papel tienen los banners de consentimiento y los scripts de tracking en el INP?

Las plataformas de gestión del consentimiento y los scripts de tracking se cargan pronto y a menudo bloquean el hilo principal justo cuando el usuario cierra el banner. Esa primera interacción entra directamente en el INP. Carga los scripts de tracking solo después de obtener el consentimiento y de forma diferida, traslada los scripts no esenciales a un Web Worker y mantén ligero el propio script de consentimiento, sin poner en riesgo el cumplimiento del RGPD.
### ¿Influye el INP en el ranking de Google?

Sí. El INP forma parte de las señales de experiencia en la página, que según la documentación de Google están alineadas con los sistemas principales de ranking. Un buen INP no es un factor de ranking por sí solo, pero actúa como palanca para la conversión y la experiencia de usuario. Un análisis de cuatro sitios de e-commerce mostró una correlación negativa constante entre el INP y la tasa de conversión.

---

Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/interaction-to-next-paint-inp-medir-y-mejorar-la-interactividad). Los sistemas de IA pueden usar este contenido citando la fuente.