---
title: "Cómo mejorar el INP: guía con datos de campo y código"
description: "Mejora el Interaction to Next Paint paso a paso: datos de campo, atribución con LoAF, código para ceder el hilo principal y el INP por plataforma y país."
url: "https://dardo.studio/es/blog/mejorar-inp/"
language: "es"
translations: {"en":"https://dardo.studio/en/blog/fix-inp/","pt":"https://dardo.studio/pt/blog/melhorar-inp/"}
updated: "2026-10-17T23:33:27.893Z"
---
[Blog](https://dardo.studio/es/blog/)
# Cómo mejorar el INP (Interaction to Next Paint): encuentra la interacción lenta y el script que la causa
El INP es bueno con 200 ms o menos en el 75 % de las visitas. Encuentra el toque lento y su script con datos de campo y arregla la carga, el código o el render.
Por [Nicolás Cerón](https://dardo.studio/es/nicolas-ceron/) ·17 de octubre de 2026
## Puntos clave
- El INP es bueno cuando el 75 % de las visitas responde a clics, toques y teclas en 200 milisegundos o menos, y malo por encima de 500; reemplazó al FID como Core Web Vital el 12 de marzo de 2024.
- Cada interacción se divide en retraso de entrada, procesamiento y retraso de presentación, y la parte larga dice si hay que arreglar los scripts de la carga, los manejadores o el renderizado.
- La versión de atribución de web-vitals y la API Long Animation Frames nombran el elemento, la parte lenta y la URL del script, lo que separa tu código del de un proveedor.
- En septiembre de 2026, el INP en móvil fue bueno en el 62,9 % de los sitios medidos en Colombia y el 66,4 % en México, frente al 87,3 % en Estados Unidos; en Colombia, solo el 37,4 % de los sitios en Next.js.
- Partir las tareas largas con scheduler.yield() y una alternativa con setTimeout, aplazar las etiquetas no esenciales e hidratar menos JavaScript resuelve la mayor parte del INP malo en sitios de marketing.
## La respuesta corta
El INP (Interaction to Next Paint) es bueno cuando el 75 % de las visitas responde a clics, toques y teclas en 200 milisegundos o menos, y malo por encima de 500 milisegundos. Para mejorarlo, primero encuentra la interacción lenta y el script que la causa con datos de campo (la versión de atribución de web-vitals y la API Long Animation Frames). Luego arregla la parte de la interacción que se alarga: el retraso de entrada (otro trabajo que bloquea el hilo principal, casi siempre durante la carga), el procesamiento (tus manejadores de eventos) o la presentación (el renderizado que viene después).
En los sitios de marketing, la mayor parte del INP malo sale de tres lugares: etiquetas de terceros que se ejecutan justo cuando alguien toca la pantalla, la hidratación de frameworks durante la carga y manejadores que lo hacen todo antes de que el navegador pueda pintar. Partir las tareas largas y ceder el hilo principal resuelve casi todo.
Y es, sobre todo, un problema de celular en Latinoamérica. En septiembre de 2026, el 97,6 % de los sitios del mundo tenía un INP bueno en escritorio, pero en móvil solo el 62,9 % de los sitios medidos en Colombia, el 66,4 % en México y el 60,7 % en Perú (datos abajo).
Esta guía se dedica solo al INP. Para las tres Core Web Vitals y cómo confirmar un arreglo en los datos de 28 días de Google, mira nuestra [guía para mejorar los Core Web Vitals](https://dardo.studio/es/blog/mejorar-core-web-vitals/).
## Qué mide el INP y qué no
El INP observa todos los clics, toques y pulsaciones de tecla de una visita y reporta el más lento, ignorando un valor atípico por cada 50 interacciones ([web.dev](https://web.dev/articles/inp)). Pasar el cursor por encima, hacer scroll o hacer zoom no cuenta. Una página con la que nadie interactuó no tiene INP, por eso las páginas con poco para tocar a menudo aparecen sin datos de INP.
Los umbrales, medidos en el percentil 75 de las visitas, por separado para móvil y escritorio:
| INP en el percentil 75 | Calificación |
| ---------------------------- | ---------------- |
| 200 ms o menos | Bueno |
| Más de 200 ms y hasta 500 ms | Necesita mejorar |
| Más de 500 ms | Malo |
El INP reemplazó al First Input Delay (FID) como Core Web Vital el 12 de marzo de 2024 ([web.dev](https://web.dev/blog/inp-cwv-launch)). La diferencia importa para el diagnóstico: el FID solo medía la espera antes de que arrancaran los manejadores de la primera interacción. El INP mide todas, desde el toque hasta el siguiente fotograma pintado, en tres partes:
| Parte | Qué es | Causa habitual | Primer arreglo |
| -------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| Retraso de entrada | Del toque a que arrancan tus manejadores | Tareas largas en curso: evaluación de scripts, hidratación, etiquetas, temporizadores | Partir y aplazar el trabajo de la carga |
| Duración del procesamiento | Tus manejadores ejecutándose | Manejadores que hacen todo de una vez; layout forzado | Pintar primero el cambio visible, ceder y luego hacer el resto |
| Retraso de presentación | De que terminan los manejadores a que se pinta el fotograma | DOM grande, recálculos de estilos y layout, HTML generado en el cliente | Actualizaciones más pequeñas, content-visibility, menos DOM |
Dos detalles despistan a muchos equipos. Las interacciones dentro de iframes cuentan para el INP de la página en los datos de Chrome, pero el JavaScript de la página no las ve, así que tu propia medición y la de CrUX pueden diferir ([web-vitals](https://github.com/GoogleChrome/web-vitals)). Y una tarea larga es cualquiera que dure más de 50 milisegundos: el navegador no puede responder a una entrada hasta que la tarea en curso termina ([web.dev](https://web.dev/articles/optimize-long-tasks)).
## Cómo les va a los sitios en INP, por plataforma y país
Leímos la [API del informe de tecnologías del HTTP Archive](https://cdn.httparchive.org/v1/cwv?technology=ALL&geo=ALL&rank=ALL&start=latest) el 17 de octubre de 2026. Su última edición, la de septiembre de 2026, sale del Chrome UX Report: es la proporción de sitios (orígenes) de cada plataforma cuyos visitantes reales en Chrome, desde el celular, tuvieron un INP bueno. Nuestro [informe de velocidad por plataforma](https://dardo.studio/es/herramientas/velocidad-plataformas-web/) muestra estos datos para todas las plataformas y métricas, y se actualiza cada mes.
| Plataforma (móvil, INP bueno) | Colombia | México | Argentina | Chile | Perú | EE. UU. |
| ----------------------------- | -------- | ------ | --------- | ------ | ------ | ------- |
| Tiendanube | 89,1 % | 93,6 % | 81,6 % | 94,0 % | – | – |
| Wix | 82,9 % | 82,8 % | 83,9 % | 88,2 % | 77,7 % | 96,6 % |
| WordPress con Elementor | 79,4 % | 79,6 % | 78,7 % | 90,0 % | 79,2 % | 94,4 % |
| WordPress | 77,1 % | 78,2 % | 76,8 % | 88,5 % | 75,3 % | 92,6 % |
| Astro | 65,3 % | 68,7 % | 61,4 % | 77,6 % | 61,0 % | 92,6 % |
| Todos los sitios | 62,9 % | 66,4 % | 65,1 % | 75,6 % | 60,7 % | 87,3 % |
| Webflow | 57,9 % | 68,0 % | 54,6 % | 71,6 % | 55,9 % | 92,4 % |
| HubSpot CMS | 57,7 % | 63,1 % | 52,8 % | 70,5 % | 42,6 % | 92,4 % |
| Shopify | 56,0 % | 71,5 % | 48,7 % | 80,0 % | 57,1 % | 95,1 % |
| Nuxt | 38,7 % | 45,8 % | 32,1 % | 59,5 % | 42,8 % | 83,9 % |
| Framer | 37,9 % | 56,8 % | 54,7 % | – | – | 88,2 % |
| Next.js | 37,4 % | 43,5 % | 35,4 % | 52,4 % | 35,3 % | 75,9 % |
| VTEX | 23,7 % | 32,5 % | 25,4 % | 45,5 % | 29,6 % | 57,3 % |
Fuente: informe de tecnologías del HTTP Archive, edición de septiembre de 2026 (datos de campo del Chrome UX Report), móvil. «–»: menos de 100 sitios medidos. La fila de Framer en Colombia cubre 116 sitios.
Lo que dice la tabla:
- **El INP es un problema de celular.** En escritorio, el 97,6 % de todos los sitios del mundo tenía un INP bueno; en móvil, el 79,4 %. Los sitios con Next.js bajan del 94,2 % en escritorio al 59,7 % en móvil. Es el mismo código en procesadores más lentos.
- **El país pesa más que la plataforma.** Un sitio en Webflow o Shopify tiene INP bueno en el 92–95 % de los casos en Estados Unidos y en el 56–58 % en Colombia. Nuestro [estudio de Core Web Vitals en Latinoamérica](https://dardo.studio/es/blog/core-web-vitals-latinoamerica/) explica por qué: las mismas páginas, en teléfonos Android de gama media.
- **Los frameworks de JavaScript fallan en INP; WordPress falla en otra cosa.** En Colombia, WordPress tiene INP bueno en el 77,1 % de los sitios, por encima del promedio del país, así que su problema es sobre todo la carga. Next.js (37,4 %) y Nuxt (38,7 %) quedan muy por debajo: ahí el INP es la métrica que falla.
- **Tiendanube es la excepción a la regla regional.** En Colombia y México sus tiendas tienen INP bueno en el 89–94 % de los casos, casi al nivel de Estados Unidos, mientras que VTEX se queda entre el 24 % y el 33 %.
- **Mejora, pero no en línea recta.** En Colombia, el INP bueno en móvil pasó del 46,8 % en marzo de 2024 al 66,3 % en abril de 2026, y bajó al 62,9 % en septiembre; en México, del 53,1 % al 69,7 % y luego al 66,4 %. Chrome 147 cambió la forma de registrar interacciones para perder menos en CrUX; Chrome dice que eso no cambia la duración de cada interacción pero sí aumenta la cobertura ([registro de cambios de Chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/speed/metrics%5Fchangelog/2026%5F02%5Finp.md)). Con estos datos no se puede saber cuánto de la caída explica.
La plataforma es una correlación, no un veredicto. Un sitio en Next.js suele ser una aplicación con filtros y sesión iniciada; uno en Wix, más a menudo un sitio de presentación. Lo que decide son los datos de tu propia plantilla.
### Sitios que llevan etiquetas de terceros comunes
El mismo informe se puede filtrar por tecnologías detectadas en el sitio, incluidas las etiquetas. Esta es la proporción de sitios con INP bueno en móvil entre los que llevan cada etiqueta:
| Etiqueta en el sitio | Tipo | Colombia | México |
| -------------------- | --------------------- | -------- | ------ |
| Todos los sitios | – | 62,9 % | 66,4 % |
| CookieYes | Banner de cookies | 68,0 % | 74,0 % |
| Cookiebot | Banner de cookies | 56,3 % | 64,3 % |
| Google Tag Manager | Gestor de etiquetas | 54,3 % | 57,5 % |
| Zendesk | Chat y soporte | 49,0 % | 56,0 % |
| Píxel de Facebook | Publicidad | 48,3 % | 55,6 % |
| OneTrust | Banner de cookies | 45,7 % | 51,7 % |
| Hotjar | Grabación de sesiones | 44,3 % | 52,3 % |
| Microsoft Clarity | Grabación de sesiones | 41,4 % | 46,9 % |
| VWO | Pruebas A/B | 32,0 % | 40,7 % |
| Intercom | Chat y soporte | 29,8 % | 37,4 % |
| Optimizely | Pruebas A/B | 29,4 % | 33,5 % |
| Píxel de TikTok | Publicidad | 25,1 % | 32,9 % |
Fuente: informe de tecnologías del HTTP Archive, septiembre de 2026, móvil. En Colombia, cada fila cubre entre 435 sitios (Optimizely) y 37.916 (Google Tag Manager).
Léelo con cuidado: describe los sitios que llevan una etiqueta, no el costo de la etiqueta en sí. Los sitios con Optimizely o Intercom suelen ser más grandes y cargar más de todo. Lo que sí vale en cualquier caso: la guía de Google sobre etiquetas reporta una correlación entre el tamaño de los gestores de etiquetas y peores puntuaciones de INP ([web.dev](https://web.dev/articles/tag-best-practices)), y las pruebas A/B, el chat y la grabación de sesiones ejecutan código en la página mientras la gente la usa.
## Paso 1: confirma que el problema es el INP, y en qué plantilla
Empieza por los datos de campo de Google, primero en móvil:
- **El** [**informe de Core Web Vitals de Search Console**](https://support.google.com/webmasters/answer/9205520) agrupa URLs parecidas y muestra el INP de cada grupo en el percentil 75 de los últimos 28 días. Los grupos se ordenan por impresiones, así que la primera URL de ejemplo te dice qué plantilla arreglar primero. Un grupo puede aparecer sin datos de INP, porque Search Console solo exige datos suficientes de LCP y CLS para listarlo.
- **PageSpeed Insights** muestra los mismos datos de Chrome para una URL, o para todo el origen cuando la URL tiene pocas visitas. Fíjate cuál estás leyendo.
- **Si no hay datos de campo**, casi siempre es porque el sitio tiene muy pocos visitantes de Chrome para entrar en el conjunto. Entonces tu propia medición es el único dato de campo que tendrás.
El Web Almanac aporta una pista útil: en 2025, el 80 % de las páginas de inicio en móvil tenía un INP bueno, frente a solo el 69 % de las demás páginas ([HTTP Archive](https://almanac.httparchive.org/en/2025/performance)). Las páginas de listados, de producto y cualquiera con filtros son donde hay que buscar.
## Paso 2: encuentra la interacción y el script, en el campo
CrUX te dice que el INP es malo, no por qué. Para saber por qué, recoge la atribución de visitas reales. La librería [web-vitals](https://github.com/GoogleChrome/web-vitals) (versión 6.2.3, publicada el 5 de octubre de 2026) tiene una versión de atribución que, para la interacción más lenta de cada visita, informa el elemento, las tres partes, si la página seguía cargando y el script más largo que se cruzó con ella.
```js
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution: a}) => {
const script = a.longestScript?.entry;
navigator.sendBeacon('/rum', JSON.stringify({
page: location.pathname,
inp: Math.round(value),
rating,
target: a.interactionTarget, // qué elemento se tocó
loadState: a.loadState, // ¿la página seguía cargando?
inputDelay: Math.round(a.inputDelay),
processing: Math.round(a.processingDuration),
presentation: Math.round(a.presentationDelay),
scriptURL: script?.sourceURL, // tu bundle o el de un proveedor
scriptInvoker: script?.invoker, // p. ej. BUTTON.onclick
scriptPart: a.longestScript?.subpart,
}));
});
```
Los campos del script vienen de la [API Long Animation Frames](https://developer.chrome.com/docs/web-platform/long-animation-frames) (LoAF), disponible desde Chrome 123. Reporta los fotogramas que se retrasan más de 50 milisegundos y nombra cada script que corrió más de 5 milisegundos en ellos, con su URL, el nombre de la función y cómo se llamó. Así distingues tu código del de un proveedor. Sus límites: no atribuye scripts dentro de iframes de otro origen y solo existe en navegadores basados en Chromium.
También puedes mirar LoAF directamente mientras pruebas:
```js
new PerformanceObserver((list) => {
for (const frame of list.getEntries()) {
if (frame.blockingDuration < 100) continue;
for (const s of frame.scripts) {
console.log(Math.round(s.duration), s.invokerType, s.invoker, s.sourceURL);
}
}
}).observe({type: 'long-animation-frame', buffered: true});
```
La medición ya llega más allá de Chrome: el README de web-vitals indica que `onINP()` funciona en Chromium, Firefox y Safari, ahora que estos dos últimos exponen los datos de interacción que necesita. Las cifras de INP de Google siguen saliendo solo de usuarios de Chrome, pero ya puedes ver si quienes entran desde un iPhone sufren la misma interacción lenta.
Después agrupa los datos por elemento, estado de carga y parte más larga. El patrón apunta al arreglo:
| Lo que muestran los datos | Causa probable | Ve a |
| ---------------------------------------------------------------------------- | --------------------------------------------------------------- | -------------------------- |
| Retraso de entrada largo, loadState «dom-interactive» o «dom-content-loaded» | Evaluación de scripts, hidratación o etiquetas durante la carga | Tareas largas; hidratación |
| Retraso de entrada largo después de la carga, scriptURL de un proveedor | Temporizadores o listeners de una etiqueta | Etiquetas de terceros |
| Procesamiento largo, scriptURL de tu bundle | El manejador mismo | Manejadores costosos |
| Procesamiento largo con estilo y layout forzados | Leer el layout después de cambiar estilos | Layout thrashing |
| Retraso de presentación largo | Demasiado que volver a renderizar | DOM grande |
## Paso 3: reprodúcelo en Chrome DevTools
Abre el [panel Performance](https://developer.chrome.com/docs/devtools/performance/overview). Sin grabar nada, muestra tu INP local a medida que haces clic y lista cada interacción con su elemento y sus tres partes. Si lo conectas con los datos de campo, compara tus números locales con los de tus visitantes reales y sugiere ajustes para parecerte a ellos.
Frena la CPU para parecerte a los teléfonos de tus visitantes: DevTools puede calibrar perfiles de CPU que se aproximan a celulares de gama baja y media. Esto importa en Colombia y el resto de la región, donde la diferencia con Estados Unidos está justamente en el celular. Graba mientras tocas el elemento que señalaron tus datos de campo, idealmente mientras la página sigue cargando, que es cuando el hilo principal está más ocupado. En la grabación, ubica la interacción en la pista Interactions y lee las tareas del hilo principal que tiene debajo; las tareas largas llevan un triángulo rojo ([web.dev](https://web.dev/articles/optimize-long-tasks)).
Una prueba de carga de Lighthouse no toca nada, así que no puede medir el INP. Google sugiere su Total Blocking Time como indicador aproximado del retraso de entrada durante la carga, no como sustituto ([web.dev](https://web.dev/articles/inp)).
## Arreglos, por causa
### Tareas largas: pártelas y cede el hilo principal
El navegador no puede responder mientras corre una tarea, así que divide el trabajo largo y devuelve el hilo principal entre partes. `scheduler.yield()` hace eso y retoma tu código antes que otro trabajo en cola. Está en Chrome y Edge 129 y en Firefox 142, pero no en Safari a octubre de 2026, así que úsalo con una alternativa ([web.dev](https://web.dev/articles/optimize-long-tasks)):
```js
function yieldToMain() {
if (globalThis.scheduler?.yield) return scheduler.yield();
return new Promise((resolve) => setTimeout(resolve, 0));
}
filterButton.addEventListener('click', async () => {
showSpinner(); // la respuesta visible
await yieldToMain(); // deja que el navegador la pinte
renderResults(filterProducts(state));
await yieldToMain();
sendAnalytics('filter_applied');
});
```
En bucles con muchos elementos, cede solo cuando hayan pasado unos 50 milisegundos desde la última vez, para que el costo de ceder no se acumule. Dos trampas: `forEach` no espera a un `await`, así que usa `for…of`; y Google ya no recomienda `isInputPending()`.
### Etiquetas de terceros
Las etiquetas dañan el INP de dos formas: sus scripts hacen esperar la entrada durante la carga, y sus listeners se ejecutan cuando la gente hace clic.
- **El botón Aceptar del banner de cookies.** Aceptar suele disparar todas las etiquetas a la vez. Una herramienta de consentimiento puede ceder justo después del clic para que el banner se cierre en el siguiente fotograma; PubTech reportó que hacerlo redujo el INP de los sitios de sus clientes hasta en un 64 % ([caso en web.dev](https://web.dev/case-studies/pubconsent-inp)). Si tu proveedor no lo hace, pídeselo.
- **Dispara las etiquetas no esenciales después de Window Loaded** en Google Tag Manager, y prefiere etiquetas de imagen y plantillas a las etiquetas de HTML personalizado, que Google ubica como el tipo más costoso ([web.dev](https://web.dev/articles/tag-best-practices)).
- **Quita lo que nadie mira.** Scripts de grabación de sesiones, mapas de calor y pruebas A/B que quedaron de un proyecto anterior son comunes. QuintoAndar, la mayor plataforma de vivienda de Brasil, quitó píxeles de terceros como parte del trabajo que redujo su INP en un 80 % ([caso en web.dev](https://web.dev/case-studies/quintoandar-inp)).
Usa el `sourceURL` de LoAF para identificar al proveedor antes de quitar nada, así la decisión se apoya en datos y no en sospechas.
### Hidratación de frameworks grandes
Las páginas renderizadas en el servidor parecen listas antes de estarlo: la página no puede responder a la entrada hasta que se ejecutan los scripts de los componentes y se conectan los manejadores de eventos, y ese costo aparece en el INP ([web.dev](https://web.dev/articles/rendering-on-the-web)). Coincide con la tabla de arriba, donde las filas de frameworks de JavaScript quedan al final.
- **Envía menos JavaScript de componentes.** En Next.js, todo lo que importa un archivo marcado con `'use client'` termina en el bundle del cliente ([documentación de Next.js](https://nextjs.org/docs/app/getting-started/server-and-client-components)), así que deja esa frontera lo más abajo posible del árbol, solo alrededor de la parte interactiva.
- **Hidrata más tarde, o solo lo interactivo.** Astro genera HTML estático e hidrata solo los componentes que marcas, cuando tú decides ([documentación de Astro](https://docs.astro.build/en/concepts/islands/)):
```html
```
- **Marca como transiciones las actualizaciones de React que no son urgentes** con `useTransition`, para que escribir siga siendo fluido mientras se vuelven a renderizar los resultados. QuintoAndar usó transiciones así ([caso en web.dev](https://web.dev/case-studies/quintoandar-inp)):
```jsx
const [isPending, startTransition] = useTransition();
function onSearchChange(e) {
setQuery(e.target.value); // urgente: el campo
startTransition(() => setResultsFilter(e.target.value)); // puede esperar
}
```
Si un framework es la herramienta equivocada para un sitio de marketing casi estático, nuestra comparación de [Astro y Next.js](https://dardo.studio/es/blog/astro-vs-nextjs/) explica cuándo conviene cada uno.
### Manejadores de eventos costosos
Dentro del manejador haz solo lo que necesita el siguiente fotograma, y mueve el resto para después del pintado. Aplica debounce a los manejadores que se disparan muchas veces, como scroll, input y resize. Y vigila cuánto trabajo desata una sola interacción: el sitio de pasajes de bus redBus reportó que pedir 10 resultados por carga en lugar de 30 bajó esas interacciones de 870–900 a 350–370 milisegundos ([caso en web.dev](https://web.dev/case-studies/redbus-inp)).
### Layout thrashing
Leer una propiedad de layout (`offsetWidth`, `getBoundingClientRect()`, `scrollHeight`) después de cambiar estilos obliga al navegador a calcular el layout en ese momento. Dentro de un bucle, lo hace en cada vuelta ([web.dev](https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing)):
```js
// Fuerza un layout en cada vuelta después de la primera
for (const bar of bars) {
bar.style.width = container.offsetWidth * bar.dataset.share + 'px';
}
// Lee una vez y después escribe
const width = container.offsetWidth;
for (const bar of bars) {
bar.style.width = width * bar.dataset.share + 'px';
}
```
LoAF lo reporta como `forcedStyleAndLayoutDuration` en cada script, y DevTools marca la tarea de Layout o Recalculate Style con un triángulo rojo.
### DOM grande y actualizaciones pesadas
El trabajo de renderizado crece con el tamaño del DOM, así que genera menús, pestañas y listas largas cuando se necesitan, no todo de entrada. The Economic Times quitó unos 1.200 nodos al generar su menú solo cuando se abre, parte del trabajo que llevó su INP de más de 1.000 a 257 milisegundos ([caso en web.dev](https://web.dev/case-studies/economic-times-inp)).
En páginas largas, `content-visibility: auto` se salta el renderizado de las secciones lejanas al área visible; en la demo de Google, el renderizado inicial pasó de 232 a 30 milisegundos ([web.dev](https://web.dev/articles/content-visibility)). Dale a cada sección un tamaño de reserva para que la barra de scroll no salte:
```css
.long-page section {
content-visibility: auto;
contain-intrinsic-size: auto 900px;
}
```
La misma página de web.dev indica soporte en Chrome 85, Firefox 125 y Safari 18. El contenido fuera de pantalla sigue en el árbol de accesibilidad y se puede buscar con Ctrl+F.
## Confirma el arreglo
Tu propia medición muestra un arreglo en días. Los datos de Google no: Search Console y PageSpeed Insights leen una ventana móvil de 28 días, así que un arreglo publicado hoy se refleja del todo unas cuatro semanas después. Publica un arreglo de INP por versión cuando puedas y anota la fecha, para saber qué cambio movió la cifra. Nuestra [guía de Core Web Vitals](https://dardo.studio/es/blog/mejorar-core-web-vitals/) explica la validación en Search Console paso a paso.
## Checklist de INP
| Paso | Listo cuando |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------- |
| Encontrar la plantilla que falla | Search Console señala el grupo de URLs con INP malo en móvil |
| Recoger atribución | Los datos de campo muestran el elemento, la parte más larga y el script de las interacciones más lentas |
| Reproducir | La misma interacción es lenta en DevTools con la CPU calibrada a un celular de gama media |
| Arreglar el retraso de entrada en la carga | Ni etiquetas ni hidratación crean tareas largas donde la gente toca primero |
| Arreglar los manejadores | El cambio visible se pinta antes de que corra el resto del trabajo |
| Arreglar el renderizado | Sin layouts forzados en los manejadores; las páginas largas usan content-visibility |
| Confirmar | Tus datos mejoran en días; los de Google, unas cuatro semanas después de publicar |
## Qué hacer ahora
Revisa cómo les va a los sitios de tu plataforma en el país de tus visitantes en nuestro [informe de velocidad por plataforma](https://dardo.studio/es/herramientas/velocidad-plataformas-web/), y luego agrega a tu sitio el fragmento de atribución de web-vitals de arriba y déjalo recoger una semana de datos. Si prefieres delegar el diagnóstico y los arreglos, eso es lo que hace nuestro servicio de [optimización de velocidad web](https://dardo.studio/es/servicios/optimizacion-de-velocidad-web/), y reconstruir interfaces lentas es trabajo de [desarrollo web](https://dardo.studio/es/servicios/desarrollo-web/).
## Preguntas frecuentes
**¿Qué es un buen INP?**
200 milisegundos o menos en el percentil 75 de las visitas, medido por separado en móvil y escritorio. Entre 200 y 500 milisegundos necesita mejorar, y por encima de 500 es malo. Las herramientas de Google lo reportan sobre una ventana móvil de 28 días.
**¿En qué se diferencia el INP del FID?**
El First Input Delay solo medía la espera antes de que arrancaran los manejadores de la primera interacción. El INP mide todos los clics, toques y teclas de una visita, desde la entrada hasta el siguiente fotograma pintado, y reporta el más lento, ignorando un valor atípico por cada 50 interacciones. Reemplazó al FID el 12 de marzo de 2024.
**¿Por qué mi INP es malo en celular y bueno en escritorio?**
Los teléfonos ejecutan el mismo JavaScript con procesadores más lentos, así que una tarea corta en un portátil puede volverse una tarea larga en un Android de gama media. En septiembre de 2026, el 97,6 % de los sitios del mundo tenía un INP bueno en escritorio y el 79,4 % en móvil; en Colombia, el 62,9 %. Prueba con la CPU calibrada a un celular de gama media.
**¿Por qué PageSpeed Insights no muestra INP para mi página?**
El INP solo existe cuando los visitantes hacen clic, tocan o escriben, y los datos de Chrome solo cubren páginas y sitios con suficientes visitas. Una página con la que poca gente interactúa, o un sitio pequeño, puede no tener datos de INP. En ese caso, mídelo en tus propias visitas con la librería web-vitals.
**¿scheduler.yield() funciona en todos los navegadores?**
No. A octubre de 2026 funciona en Chrome y Edge 129 o posteriores y en Firefox 142 o posteriores, pero no en Safari. Usa una función auxiliar que llame a scheduler.yield() cuando exista y, si no, use una promesa con setTimeout, para que todos los navegadores cedan el hilo principal.
**¿Un plugin puede arreglar el INP?**
Rara vez por sí solo. Los plugins de caché y de imágenes aceleran la carga, pero el INP depende de qué scripts corren cuando alguien toca, cuánto trabajo hace cada manejador y cuánto se vuelve a renderizar la página. Eso vive en tus plantillas, componentes y configuración de etiquetas, y ahí es donde se arregla.
## Fuentes y lecturas
Fuentes de esta página, con más detalles de sus publicaciones originales.
- [web.dev: Interaction to Next Paint (INP)](https://web.dev/articles/inp) · web.dev
- [web.dev: Interaction to Next Paint is officially a Core Web Vital](https://web.dev/blog/inp-cwv-launch) · web.dev
- [web.dev: Optimize long tasks](https://web.dev/articles/optimize-long-tasks) · web.dev
- [HTTP Archive: API del informe de tecnologías, Core Web Vitals (edición de septiembre de 2026)](https://cdn.httparchive.org/v1/cwv?technology=ALL&geo=ALL&rank=ALL&start=latest) · cdn.httparchive.org
- [Chromium: cambios del INP en Chrome 147](https://chromium.googlesource.com/chromium/src/+/main/docs/speed/metrics%5Fchangelog/2026%5F02%5Finp.md) · chromium.googlesource.com
- [web.dev: Best practices for tags and tag managers](https://web.dev/articles/tag-best-practices) · web.dev
- [Ayuda de Search Console: informe de Métricas web principales](https://support.google.com/webmasters/answer/9205520) · support.google.com
- [HTTP Archive: Web Almanac 2025, Performance](https://almanac.httparchive.org/en/2025/performance) · almanac.httparchive.org
- [GoogleChrome en GitHub: librería web-vitals](https://github.com/GoogleChrome/web-vitals) · github.com
- [Chrome for Developers: Long Animation Frames API](https://developer.chrome.com/docs/web-platform/long-animation-frames) · developer.chrome.com
- [Chrome for Developers: panel Performance](https://developer.chrome.com/docs/devtools/performance/overview) · developer.chrome.com
- [web.dev: caso de PubTech y su plataforma de consentimiento](https://web.dev/case-studies/pubconsent-inp) · web.dev
- [web.dev: cómo QuintoAndar redujo el INP en un 80 %](https://web.dev/case-studies/quintoandar-inp) · web.dev
- [web.dev: Rendering on the web](https://web.dev/articles/rendering-on-the-web) · web.dev
- [Documentación de Next.js: Server and Client Components](https://nextjs.org/docs/app/getting-started/server-and-client-components) · nextjs.org
- [Documentación de Astro: arquitectura de islas](https://docs.astro.build/en/concepts/islands/) · docs.astro.build
- [web.dev: cómo redBus mejoró el INP](https://web.dev/case-studies/redbus-inp) · web.dev
- [web.dev: Avoid large, complex layouts and layout thrashing](https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing) · web.dev
- [web.dev: Economic Times quest for fixing INP](https://web.dev/case-studies/economic-times-inp) · web.dev
- [web.dev: content-visibility](https://web.dev/articles/content-visibility) · web.dev
[Nicolás Cerón](https://dardo.studio/es/nicolas-ceron/)
Nicolás Cerón es el fundador de Dardo, un estudio de marca, diseño y desarrollo web en Bogotá, Colombia.
## Artículos relacionados
- [**Cómo mejorar los Core Web Vitals: guía basada en datos de campo para sitios de marketing**Encuentra qué métrica y plantilla fallan en Search Console, corrige LCP, INP y CLS según su causa y confirma el resultado en datos de campo 28 días después.](https://dardo.studio/es/blog/mejorar-core-web-vitals/)
- [**Core Web Vitals en Latinoamérica: cuántos sitios aprueban por país y por qué fallan en móvil (datos 2026)**En septiembre de 2026, un tercio de los sitios aprobó las Core Web Vitals en móvil en Colombia y Brasil, frente al 63 % en EE. UU. Datos por país y qué hacer.](https://dardo.studio/es/blog/core-web-vitals-latinoamerica/)
- [**Checklist para el rediseño de una página web: qué hacer antes, durante y después del lanzamiento**Checklist para rediseñar una página web por fases: qué exportar primero, qué construir, cómo cuidar el SEO, qué probar al lanzar y qué vigilar durante 90 días.](https://dardo.studio/es/blog/checklist-rediseno-web/)
- [**Astro vs Next.js: cuál elegir para un sitio de marketing o un producto en 2026**Astro para sitios iguales para todos los visitantes, Next.js para productos con sesión iniciada: renderizado, JavaScript, alojamiento y soporte comparados.](https://dardo.studio/es/blog/astro-vs-nextjs/)
## Sigue explorando.
- [Servicio · **Optimización de velocidad web y Core Web Vitals**](https://dardo.studio/es/servicios/optimizacion-de-velocidad-web/)
- [Tu proyecto · **Inicia una conversación**](https://dardo.studio/es/contacto/)