Una buena puntuación INP es de 200 milisegundos o menos, medida en el percentil 75 de las visitas reales. Entre 200 y 500 ms la página “necesita mejorar”, y por encima de 500 ms se considera deficiente. Google aplica estos umbrales por separado en móvil y en escritorio, así que una página puede aprobar en uno y suspender en el otro.
Interaction to Next Paint (INP) mide la rapidez con la que una página responde visualmente después de que alguien hace clic, toca la pantalla o pulsa una tecla. Se convirtió en Core Web Vital el 12 de marzo de 2024 en sustitución de First Input Delay (FID), que solo medía el retraso antes de procesar la primera interacción. INP tiene en cuenta las interacciones de toda la visita y registra una de las más lentas.
En la práctica, “buena” significa tres cosas: al menos el 75 % de las visitas reales obtienen respuesta en 200 ms, mides con datos de campo y no con una sola prueba de laboratorio, y tienes cierto margen por debajo del límite para que un script nuevo o una semana de rebajas con mucho tráfico no te hagan superarlo.
Esta guía explica cómo se calcula la puntuación, dónde encontrar la tuya, por qué algunas herramientas no muestran nada y cómo diagnosticar y corregir un INP lento sin hacer suposiciones.
¿Cuáles son los umbrales de INP?
Google usa tres franjas, y los valores límite importan. La tabla siguiente refleja la documentación de INP de web.dev y el informe de Core Web Vitals de Search Console.
| Valoración | Valor de INP | Qué significa para los usuarios |
|---|---|---|
| Buena | 200 ms o menos | Los clics y toques se perciben inmediatos en la mayoría de las visitas |
| Necesita mejorar | Más de 200 ms, hasta 500 ms | Retraso perceptible en menús, filtros, formularios o en añadir al carrito |
| Deficiente | Más de 500 ms | Los usuarios repiten clics, creen que la página no funciona o se van |
¿Es buena una puntuación de exactamente 200 ms? Sí. web.dev define como buena una puntuación “inferior o igual” a 200 ms, así que 200 aprueba y 201 no. La misma lógica se aplica a 500 ms: exactamente 500 sigue contando como “necesita mejorar”, y todo lo que esté por encima es deficiente.
Como referencia, las otras dos Core Web Vitals de Search Console usan umbrales de LCP de 2,5 s y 4 s y umbrales de CLS de 0,1 y 0,25. INP es la única que se mide en milisegundos de capacidad de respuesta en lugar de carga o estabilidad visual.
¿Cómo se calcula realmente tu puntuación INP?
INP se calcula primero por visita y después se resume entre visitas en el percentil 75. Entender ambos pasos explica la mayor parte de la confusión que genera esta cifra.
Durante una visita, el navegador cronometra cada clic, toque y pulsación de tecla. Cada interacción tiene tres partes:
- Retraso de entrada: la espera antes de que empiecen tus controladores de eventos, normalmente porque el hilo principal está ocupado con otro trabajo.
- Duración del procesamiento: el tiempo que tardan en ejecutarse tus controladores de eventos.
- Retraso de presentación: el tiempo desde que terminan los controladores hasta que el navegador pinta el siguiente fotograma.
El INP de la visita es la más larga de esas interacciones, con una excepción para las páginas con mucha actividad: web.dev indica que se ignora la interacción más alta por cada 50 interacciones, de modo que un pico aislado en una sesión larga no define la puntuación. Pasar el cursor, desplazarse y hacer zoom no cuentan como interacciones.
Después se agrupan los valores de todas las visitas y se registra el percentil 75. Esa es la “regla del 75 %”: tu página es buena si al menos tres de cada cuatro visitas tuvieron un INP de 200 ms o menos. El cuarto restante puede ser más lento sin que la página suspenda, y por eso importa más corregir tu interacción lenta habitual que perseguir un caso extremo poco frecuente.
Una visita en la que el usuario nunca hace clic, toca ni escribe no genera ningún valor de INP. Las páginas que la gente sobre todo lee, como los artículos largos, suelen tener menos datos de INP que las páginas que la gente utiliza, como los filtros de categoría o el checkout.
¿Es distinta una buena puntuación INP en móvil y en escritorio?
El umbral es el mismo, 200 ms, pero los resultados son muy distintos. Los móviles tienen procesadores más lentos, así que el mismo JavaScript tarda más en ejecutarse, y Google informa de móvil y escritorio por separado tanto en PageSpeed Insights como en Search Console.
El capítulo de rendimiento del Web Almanac 2024 de HTTP Archive concluyó que el 74 % de los sitios web en móvil y el 97 % en escritorio tenían un INP bueno. Dicho de otro modo, INP es sobre todo un problema de móvil. Si tu informe de escritorio está en verde y el de móvil en ámbar, es el patrón normal, no un error de medición.
Prioriza el dispositivo que te trae tráfico e ingresos. Para la mayoría de los sitios de consumo es el móvil, lo que también significa probar en un teléfono Android de gama media o con limitación de CPU en Chrome DevTools, no en un portátil rápido. Nuestra guía de SEO para móviles trata el panorama móvil completo.
¿Dónde puedes consultar tu puntuación INP?
Usa datos de campo para saber si apruebas y herramientas de laboratorio para averiguar por qué no. Cada herramienta responde a una pregunta distinta.
| Herramienta | Tipo de datos | Ideal para |
|---|---|---|
| Search Console, informe de Core Web Vitals | De campo (CrUX), URL agrupadas | Ver qué grupos de páginas suspenden en móvil o escritorio y validar las correcciones |
| PageSpeed Insights | De campo (CrUX, últimos 28 días) más prueba de laboratorio de Lighthouse | Comprobar rápidamente una URL o todo el origen |
| CrUX API, BigQuery o CrUX Vis | De campo (CrUX) | Tendencias a lo largo del tiempo y comparaciones con competidores |
| Monitorización de usuarios reales (RUM), por ejemplo la librería JavaScript web-vitals | De campo, tus propios visitantes | Encontrar qué elemento e interacción causaron un INP lento |
| Panel Performance de Chrome DevTools | Laboratorio | Grabar una interacción y ver qué tarea la bloqueó |
| Lighthouse (modo navegación) | Laboratorio | Total Blocking Time como aproximación; no mide INP en una prueba de carga de página |
La propia documentación de Google es clara sobre la jerarquía: los datos de campo de usuarios reales son la mejor forma de medir INP. Total Blocking Time puede apuntar a problemas, pero web.dev lo describe como una aproximación razonable, “no un sustituto de INP”. Una puntuación perfecta en Lighthouse no significa que apruebes en INP.
¿Por qué PageSpeed Insights no muestra puntuación INP en algunas páginas?
Normalmente porque no hay suficientes datos de usuarios reales para esa URL. PageSpeed Insights obtiene los datos de campo del Chrome UX Report (CrUX), que solo incluye páginas públicamente accesibles y con suficientes visitantes. Google no publica el umbral exacto de tráfico.
Cuando una URL concreta no tiene datos, PageSpeed Insights intenta recurrir a los datos del origen, es decir, de todo tu dominio. Si el origen tampoco tiene datos, la sección de campo muestra “No Data” y solo quedan los resultados de laboratorio de Lighthouse. Otros motivos habituales:
- La página es nueva y aún no ha acumulado 28 días de visitas
- La página está tras un inicio de sesión o bloqueada para la indexación, así que CrUX no la incluye
- Los visitantes apenas interactúan con la página, así que hay pocas muestras de INP incluso con buen tráfico
La solución práctica es añadir tu propio RUM. La función onINP de la librería web-vitals registra el INP de cada visita, y su versión de atribución te dice qué elemento intervino y cuánto duró cada una de las tres fases. Así tienes datos de las páginas con poco tráfico y, sobre todo, el contexto para depurar.
¿Cómo encuentras lo que hace lento el INP?
Diagnostica primero la fase y después la causa. Cada fase apunta a un tipo de corrección distinto.
| Fase lenta | Causa típica | Dónde mirar |
|---|---|---|
| Retraso de entrada | Hilo principal ocupado con otros scripts: gestores de etiquetas, widgets de chat, tests A/B, hidratación pesada durante la carga | Tareas largas en DevTools alrededor del momento del clic |
| Duración del procesamiento | El controlador de eventos hace demasiado: filtrar una lista grande de productos, llamadas de analítica, almacenamiento síncrono, volver a renderizar componentes enteros | El controlador de click o keydown en el panel Performance |
| Retraso de presentación | DOM grande, recálculo costoso de estilos y layout, renderizar grandes bloques de HTML con JavaScript | Entradas “Recalculate Style” y “Layout” después del controlador |
Un flujo de trabajo sencillo:
- En Search Console, busca los grupos de URL con “problema de INP” en móvil.
- Abre una URL de ejemplo e identifica las interacciones que la gente realiza de verdad: el menú, un filtro, el selector de talla, añadir al carrito, un campo de formulario.
- En Chrome DevTools, activa la limitación de CPU, inicia una grabación en Performance, realiza la interacción y detén la grabación.
- Busca tareas largas, que web.dev define como tareas de más de 50 ms, y anota de qué script proceden.
- Repite la interacción mientras la página sigue cargando. Es cuando el hilo principal suele estar más ocupado, y cuando los usuarios reales hacen clic.
¿Cómo mejoras una puntuación INP deficiente?
Haz menos trabajo en el hilo principal en el momento de la interacción y deja que el navegador pinte antes. Las correcciones siguientes están ordenadas aproximadamente de la más sencilla a la más técnica.
Audita primero los scripts de terceros
En muchos sitios de marketing, el mayor coste de INP no es tu código. Los widgets de chat, los mapas de calor, las herramientas de consentimiento, los widgets de reseñas y varias etiquetas de analítica compiten por el hilo principal. Haz una lista de todos los scripts de tu gestor de etiquetas, elimina lo que nadie usa y retrasa las etiquetas no esenciales hasta después de la carga de la página o de la primera interacción.
Muestra primero la respuesta visual y después haz el resto
Actualiza la interfaz de inmediato (abre el menú, muestra el indicador de carga, marca el botón como pulsado) y ejecuta después el trabajo más lento en una tarea aparte. Esto se llama ceder el hilo principal. Una pequeña función auxiliar como la siguiente usa scheduler.yield() cuando el navegador lo admite y recurre a setTimeout en el resto:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showFilterResultsLoading(); // visible update first
await yieldToMain(); // let the browser paint
applyFilters(); // heavier work afterwards
sendAnalyticsEvent();
});Según web.dev, scheduler.yield() es compatible con Chrome y Edge desde la versión 129 y con Firefox desde la versión 142, pero no con Safari, y por eso importa la alternativa.
Divide las tareas largas
Cualquier tarea de más de 50 ms bloquea la entrada. Divide los bucles largos, como el procesamiento de cientos de productos, en bloques con una cesión entre ellos. Pide a tu desarrollador que revise la hidratación en los frameworks de JavaScript, que a menudo se ejecuta como una sola tarea grande durante la carga.
Mantén el DOM ligero
Cada elemento adicional hace más lento el recálculo de estilos y layout. Pagina o virtualiza las listas largas, elimina los menús duplicados ocultos para móvil y escritorio y usa la propiedad CSS content-visibility para omitir el renderizado de las secciones fuera de pantalla.
Evita el layout thrashing
Leer un valor de layout, como la altura de un elemento, justo después de cambiar estilos obliga al navegador a calcular el layout de inmediato. Agrupa las lecturas antes de las escrituras en tus controladores de eventos.
Vuelve a comprobar después de cada cambio
Los datos de campo tardan en moverse. CrUX en PageSpeed Insights abarca los últimos 28 días, y la validación de Search Console tiene un periodo de seguimiento de 28 días. Usa tu propio RUM para confirmar la corrección en pocos días y deja que los informes de Google se pongan al día.
¿Afecta INP al posicionamiento SEO?
INP forma parte de las Core Web Vitals, que según Google se alinean con lo que sus sistemas principales de clasificación buscan premiar, pero no es un atajo hacia los primeros resultados. Google “recomienda encarecidamente” tener unas buenas Core Web Vitals para tener éxito en la búsqueda, mientras que la relevancia y la calidad del contenido siguen siendo decisivas.
El argumento más sólido para corregir INP es comercial. Los filtros lentos, los botones de añadir al carrito con retraso y los formularios que no responden cuestan conversiones directamente, sobre todo en móvil. Considera una buena puntuación INP como el mínimo de un sitio usable y dedica la mayor parte de tu esfuerzo SEO al contenido y la estructura. Nuestra guía de SEO para ecommerce muestra qué lugar ocupa el rendimiento entre las prioridades de una tienda.
¿Qué objetivo deberías fijarte?
Apúnta a un INP en el percentil 75 claramente por debajo de 200 ms en móvil, no solo justo por debajo. Una página con 190 ms aprueba hoy, pero puede suspender tras una nueva etiqueta de marketing o un pico de tráfico desde dispositivos más lentos. Un margen de varias decenas de milisegundos da a tu equipo espacio para añadir funciones.
Fija objetivos por plantilla y no por URL: páginas de categoría, fichas de producto, artículos, formularios y checkout. Corrige primero la plantilla con más tráfico y peor INP, e incluye INP en la lista de comprobación de cada lanzamiento para que los scripts nuevos se revisen antes de publicarse.
¿Qué papel tiene Marketer Coffee?
Marketer Coffee es una agencia de SEO con IA y GEO; tratamos el rendimiento como parte del SEO técnico, junto con la arquitectura, los datos estructurados y el contenido. Resultados de otros sectores:
- Aldi.pl (retail). Los clics orgánicos subieron de 367.127 a 852.724 al mes en 12 meses (+132 %) con contenido de producto, schema Product, una arquitectura más ligera y datos de tiendas unificados. Lee el caso de éxito de Aldi.
- IDG-Online (servicios de CCTV y afiliación). De 500 a más de 30.000 clics mensuales en 16 meses frente a Ceneo, MediaExpert y MediaMarkt, con páginas de ranking, contenido de preguntas y respuestas y schema. Lee el caso de éxito de IDG-Online.
Con quién encajamos: sitios donde la velocidad, la estructura y el contenido necesitan un único plan, a menudo tiendas o sitios internacionales. Con quién no encajamos: equipos que solo necesitan un ingeniero de rendimiento JavaScript para reescribir puntualmente un framework; para eso, contrata a un desarrollador especializado. Para ver cómo rinde tu sitio en la búsqueda con IA además de en Google, empieza con nuestra auditoría gratuita de visibilidad en IA.
Preguntas frecuentes sobre la puntuación INP
¿Qué es una buena puntuación INP?
200 milisegundos o menos en el percentil 75 de las visitas reales a la página, medido por separado en móvil y escritorio. Más de 200 ms y hasta 500 ms necesita mejorar; más de 500 ms es deficiente.
¿Cuándo sustituyó INP a FID?
INP se convirtió en Core Web Vital el 12 de marzo de 2024 en sustitución de First Input Delay. Search Console eliminó FID en esa fecha.
¿Por qué mi INP es bueno en escritorio pero deficiente en móvil?
Los móviles tienen procesadores más lentos, así que los mismos scripts tardan más en ejecutarse. El Web Almanac 2024 encontró un INP bueno en el 97 % de los sitios web en escritorio, pero solo en el 74 % en móvil.
¿Puede Lighthouse medir INP?
Una prueba estándar de carga de página de Lighthouse no incluye interacciones de usuario, así que no puede registrar INP. Muestra Total Blocking Time, que es una aproximación. Usa datos de campo de CrUX o tu propio RUM para valorar INP.
¿Cuánto tarda en reflejarse en Search Console una corrección de INP?
Los datos de campo cubren un periodo móvil de 28 días y la validación de Search Console hace un seguimiento de 28 días, así que cuenta con unas cuatro semanas antes de que los informes reflejen por completo una corrección. Tu propio RUM puede confirmarlo antes.
¿Cuál es la versión corta?
Un INP bueno es de 200 ms o menos para al menos el 75 % de las visitas reales, en cada tipo de dispositivo. Encuentra las plantillas que suspenden en Search Console, graba las interacciones lentas en DevTools, determina qué fase es lenta y corrige la causa: menos scripts de terceros, respuesta visual más rápida, tareas más cortas y un DOM más pequeño. Después, déjate un margen.
Si quieres una segunda opinión sobre qué lugar ocupa el rendimiento entre tus prioridades SEO, Reserva una consulta gratuita.
Fuentes: web.dev, “Interaction to Next Paint (INP)” (umbrales, percentil 75, fases de la interacción, regla de valores atípicos, TBT como aproximación); artículo del blog de web.dev de Jeremy Wagner y Rick Viscomi que anuncia INP como Core Web Vital el 12 de marzo de 2024; web.dev, “Optimize Interaction to Next Paint” y “Optimize long tasks” (tareas largas de 50 ms, compatibilidad con scheduler.yield); Ayuda de Google Search Console, informe de Core Web Vitals (umbrales, validación de 28 días); Google Search Central, “Understanding Core Web Vitals and Google search results”; Chrome for Developers, metodología de CrUX y CrUX en PageSpeed Insights (elegibilidad, periodo de 28 días, recurso al origen); HTTP Archive, Web Almanac 2024, capítulo de rendimiento; Marketer Coffee, casos de éxito de Aldi e IDG-Online (otros sectores).
