INP: qué es Interaction to Next Paint y cómo mejorarlo
INP (Interaction to Next Paint) mide si tu web responde rápido a cada clic y ya es factor de ranking en Google. Qué es, por qué te penaliza y cómo mejorarlo.
¿Dudas sobre tu sitio web? Si quieres una opinión honesta sobre tu caso, conversemos — sin costo ni compromiso.
Tu sitio carga rápido, pero cuando el usuario hace clic en “Agregar al carro” o abre el menú en el celular, pasa medio segundo hasta que algo ocurre. Ese retraso tiene nombre y métrica: se llama INP (Interaction to Next Paint) y, desde marzo de 2024 —cuando reemplazó a la antigua métrica FID—, es uno de los tres Core Web Vitals con los que Google mide la experiencia de tu web, y es mucho más exigente (web.dev).
La diferencia importa para el negocio: una tienda o un portal puede tener buena nota de velocidad de carga y aun así perder ventas porque se siente trabado al hacer clic. Este artículo explica qué es el INP, por qué afecta tu posición en Google y tu conversión, cómo medirlo con datos reales y —lo que importa— cómo mejorarlo paso a paso.
Qué es el INP (Interaction to Next Paint)
El INP mide la capacidad de respuesta de una página a las interacciones del usuario. Observa la latencia de todos los clics, toques en pantalla y pulsaciones de teclado durante toda la visita, y reporta un único valor bajo el cual quedó la gran mayoría de esas interacciones (web.dev). En simple: no mide cuánto demora en cargar, sino cuánto demora en reaccionar cuando alguien la usa.
Por qué se mide así tiene una razón concreta: según datos de uso de Chrome, el 90% del tiempo que una persona pasa en una página ocurre después de que cargó (web.dev). Medir solo la carga deja fuera casi toda la experiencia real. El INP llega justo a ese vacío.
Un detalle clave: el INP solo considera clics, toques y teclado. Desplazarse (scroll), hacer hover o hacer zoom no cuentan. Cada interacción se descompone en tres tiempos: el retraso hasta que el navegador empieza a procesar, el tiempo que tardan en ejecutarse los manejadores de eventos y el tiempo hasta pintar el siguiente cuadro en pantalla. La suma de esos tres tramos es lo que el usuario percibe como “esto responde” o “esto está pegado”.
Los umbrales: qué es un buen INP
Google evalúa el INP en el percentil 75 de las visitas reales (móvil y escritorio por separado). Estos son los tramos oficiales:
| Valor de INP | Calificación | Qué significa |
|---|---|---|
| ≤ 200 ms | Bueno | La página responde de inmediato; se siente ágil |
| 201 – 500 ms | Necesita mejoras | Hay retraso perceptible en los clics |
| > 500 ms | Deficiente | Se siente trabada; el usuario duda o reintenta |
La meta práctica: que al menos el 75% de tus usuarios reciba una respuesta en 200 ms o menos (web.dev).
INP, LCP y CLS: cómo encaja en los Core Web Vitals
Los Core Web Vitals son tres métricas que miden cosas distintas. El LCP mide la velocidad de carga (cuándo aparece el contenido principal), el CLS mide la estabilidad visual (que no salten los elementos), y el INP mide la respuesta a la interacción. No compiten: una web bien hecha aprueba las tres.
La confusión más común es tratar el INP como “velocidad”. No lo es. Un sitio puede cargar rápido y responder lento, porque son problemas de raíz diferente. Si tu foco es la carga en una tienda online, revisa velocidad de carga en eCommerce. Este artículo se concentra en la pieza que casi nadie optimiza: la respuesta al clic.
Por qué el INP afecta tus ventas y tu posición en Google
Hay dos motivos, y los dos pegan en la caja.
El primero es SEO. Los Core Web Vitals son parte de las señales de experiencia de página que Google usa para rankear. No van a subir un mal contenido, pero sí funcionan como criterio de desempate: entre dos páginas igual de relevantes, la que ofrece mejor experiencia tiende a posicionar mejor. Un INP en zona deficiente juega en tu contra justo donde se define el ranking.
El segundo es conversión. Cuando un usuario hace clic y no pasa nada, asume que la página está rota. Vuelve a hacer clic, y cuando el navegador por fin reacciona, procesa los dos clics: el menú se abre y se cierra, o el botón de pago se dispara dos veces. Ese instante de duda es donde se abandonan carros y formularios. En un checkout, en un buscador de productos o en un agendamiento, el INP no es un tecnicismo: es plata. Por eso pesa tanto en operaciones de retail y eCommerce, donde cada interacción va camino a la compra.
Por qué tu web tiene mal INP: casi siempre es el JavaScript
El motor de la interactividad es el JavaScript, y también es su principal cuello de botella. El navegador procesa casi todo en un solo carril —el hilo principal—. Cuando ese carril está ocupado ejecutando scripts, tu clic tiene que esperar en la fila. A esas ejecuciones largas (más de 50 ms) se les llama long tasks, y son la causa número uno de un INP alto.
Los sospechosos habituales en un sitio chileno promedio:
- WordPress con muchos plugins y un page builder. Un sitio típico arrastra decenas de plugins, y constructores como Elementor o Divi inyectan una cantidad enorme de JavaScript. Cada plugin suma su propio script al hilo principal. Es la razón más frecuente de mal INP, y una de las que resolvemos al migrar de WordPress a Astro.
- Scripts de terceros. El widget de chat, el administrador de etiquetas (Tag Manager), el píxel de publicidad, el mapa incrustado. Un solo widget de chat puede sumar cientos de milisegundos de procesamiento aunque el visitante nunca lo abra.
- Aplicaciones a medida sin control del hilo principal. Paneles, buscadores y filtros que hacen demasiado trabajo en el navegador de una vez, en lugar de repartirlo.
El patrón es siempre el mismo: demasiado JavaScript ejecutándose de golpe. La solución no es quitar funcionalidad, sino ordenar cuándo y cómo se ejecuta.
Cómo medir el INP (con datos reales, no de laboratorio)
El INP se mide bien con datos de campo (usuarios reales), no de laboratorio. La razón: depende de con qué interactúa la gente, y eso una prueba automática no lo reproduce. Estas son las herramientas, todas gratuitas:
| Herramienta | Qué te dice |
|---|---|
| PageSpeed Insights | INP real de tu sitio vía CrUX (datos de Chrome), a nivel de origen o de URL |
| Search Console (informe Core Web Vitals) | Qué grupos de URLs están en “deficiente” o “necesita mejoras” y cuántas |
| Librería web-vitals | Mide el INP de tus usuarios en vivo y te dice qué interacción fue la culpable |
| DevTools de Chrome | Reproduce la interacción lenta en laboratorio para encontrar la causa |
El flujo correcto es de afuera hacia adentro: primero mira el campo (PageSpeed Insights y Search Console) para saber si hay problema y dónde, y recién ahí baja al laboratorio para encontrar qué script lo causa. Empezar al revés es adivinar.
Cómo mejorar el INP: plan en 6 pasos
- Mide primero en campo. Saca el INP real desde PageSpeed Insights y Search Console. Sin ese número base, no sabes si mejoraste.
- Rompe las tareas largas. Divide las long tasks de más de 50 ms y devuelve el control al hilo principal entre una y otra, para que un clic pueda “colarse” y responder.
- Aplaza o elimina el JavaScript que no se usa. Carga en diferido lo no crítico y borra los scripts de plugins que ya no ocupas. Menos código en el hilo principal, mejor INP.
- Carga los terceros bajo demanda. Reemplaza el chat, el video o el mapa por una “fachada”: una imagen liviana que solo carga el script pesado cuando el usuario hace clic en ella.
- Baja el peso de base. Menos plugins, menos dependencias, un stack liviano. Un sitio estático (Astro) o una app bien construida envían mucho menos JavaScript de entrada.
- Verifica en producción. Como el INP es dato de campo, vuelve a medir en Search Console algunas semanas después de publicar. La guía técnica oficial de Google detalla cada punto (web.dev).
Cuando el problema está en un sitio que ya no da para más, la vía más rápida suele ser reconstruir sobre una base liviana. En Softdigital eso es un proyecto a medida, que parte con una fase de definición pagada y 100% descontable, tanto para un sitio como para una aplicación interna con lógica pesada que reparta bien el trabajo entre servidor y navegador.
Cuánto cuesta arreglarlo y cómo lo hacemos
Un buen INP no se compra con un plugin: se logra enviando menos JavaScript y ordenando el que queda. En Softdigital construimos sitios y aplicaciones con esa premisa desde el día uno, tratando el rendimiento como un requisito de diseño en cada proyecto, en lugar de parchar después.
El efecto esperable: un rediseño que lleva un sitio de la zona roja de Lighthouse a la verde suele traducirse en un salto de tráfico orgánico, porque Google prioriza sitios rápidos. No es magia: es quitar peso muerto, diferir scripts y construir sobre una base rápida. Trabajamos con precio fijo sin sorpresas —el precio acordado se respeta, sin letra chica— y el código queda en Git y es tuyo al pagar el proyecto completo. Hablas directo con quien construye tu proyecto: el fundador, con más de 8 años de experiencia en desarrollo de software.
Si no sabes en qué tramo está tu web, el primer paso es medirla. En una conversación de 20–30 minutos sin costo revisamos tu INP y el resto de los Core Web Vitals y te decimos, sin vueltas, qué está frenando tu sitio y qué camino conviene para corregirlo. Escríbenos por el formulario de contacto y, si hay encaje, te enviamos el alcance y el precio por escrito en un máximo de 3 días hábiles después de conversar.
Tags
¿Quieres aplicar esto en tu sitio?
Cuéntanos tu caso y te decimos qué conviene priorizar primero.
Cuéntanos tu casoArtículos relacionados
Velocidad de carga en eCommerce: cómo sube tus ventas
La velocidad de carga de tu eCommerce define cuántos visitantes compran y tu ranking en Google. Mira cuánto cuesta cada segundo y cómo acelerar tu tienda.
Migrar de WordPress a Astro: guía 2026 para empresas
Migrar de WordPress a Astro mejora la velocidad, el SEO y la seguridad. Guía 2026 para empresas en Chile: cuándo conviene, cómo hacerlo y cuánto cuesta.
Datos estructurados para SEO: guía 2026 en Chile
Datos estructurados para SEO en 2026: qué son, qué schema sigue sirviendo tras el fin de los FAQ rich results y cómo hacen que la IA cite tu web en Chile.