--- title: "INP (Interaction to Next Paint): cómo medirlo y mejorarlo" description: "Aprende qué es INP, cuáles son sus umbrales, cómo diagnosticar interacciones lentas y qué optimizaciones mejoran la respuesta de tu web." url: https://lgdataone.io/blog/inp-core-web-vitals/ date: 2026-09-27 modified: 2026-09-27 author: "LG DATAONE" image: https://lgdataone.io/wp-content/uploads/2026/09/inp-core-web-vitals-rendimiento-lgdataone.jpg categories: ["WPO"] type: post lang: es --- # INP (Interaction to Next Paint): cómo medirlo y mejorarlo **INP (Interaction to Next Paint)** mide cuánto tarda una página en ofrecer una respuesta visual después de que una persona interactúe con ella. No analiza solo el primer clic: observa las interacciones relevantes que se producen durante toda la visita y resume la capacidad de respuesta general de la página. En Core Web Vitals, un INP de **200 milisegundos o menos** se considera bueno; entre 200 y 500 ms necesita mejora y por encima de 500 ms se considera deficiente. Para mejorar INP no basta con “hacer la web más rápida” de forma genérica. Hay que localizar qué interacciones se retrasan, separar el tiempo que se pierde esperando al hilo principal, el tiempo que consume el código del evento y el retraso hasta el siguiente renderizado, y después actuar sobre la fase que realmente está bloqueando la respuesta. * !(https://lgdataone.io/wp-content/uploads/2026/03/LG-DataOne-herramienta-analitica-web-y-CRO-CTA-blog.jpg) ### **Prueba GRATIS 4 MESES LG DataOne** Audita (https://lgdataone.io/blog/que-es-wpo-por-que-fundamental/) y Core Web Vitals y prioriza las mejoras de (https://lgdataone.io/blog/rendimiento-web-velocidad-sitio/). Empieza gratis con el cupón de descuento* **4MESESGRATIS** y obtén 4 meses gratis. (https://lgdataone.io/producto/access/?attribute_pa_nivel=standard&coupon=4mesesgratis) ## Resumen: qué debes saber sobre INP - **Qué mide:** la capacidad de respuesta de una página ante clics, toques y pulsaciones de teclado durante la visita. - **Umbral bueno:** 200 ms o menos en el percentil 75 de las visitas, evaluando móvil y escritorio. - **Necesita mejora:** más de 200 ms y hasta 500 ms. - **Deficiente:** más de 500 ms. - **Qué optimizar:** input delay, processing duration y presentation delay. - **Qué datos priorizar:** primero datos de campo; después laboratorio para reproducir y diagnosticar. - **Objetivo SEO:** mejorar INP ayuda a la experiencia de página, pero por sí solo no garantiza posiciones; Google utiliza muchas señales de relevancia y (https://lgdataone.io/blog/calidad-de-datos-analitica/). !(https://lgdataone.io/wp-content/uploads/2026/09/inp-core-web-vitals-mejoras-lgdataone.jpg) ## Qué es INP y por qué sustituyó a FID Interaction to Next Paint es una métrica de Core Web Vitals centrada en la **responsividad**. Su propósito es reflejar cómo percibe una persona la respuesta de una página cuando intenta hacer algo: abrir un menú, seleccionar una opción, escribir en un campo, cambiar una pestaña, añadir un producto al carrito o pulsar un botón. La diferencia fundamental frente a First Input Delay (FID) es el alcance. FID se concentraba en el retraso de la primera interacción. INP analiza las interacciones durante toda la vida de la página y, de forma simplificada, toma como referencia la interacción más lenta observada, aplicando mecanismos para que determinados valores atípicos no dominen el resultado en páginas con muchas interacciones. Google sustituyó FID por INP dentro de Core Web Vitals el 12 de marzo de 2024. | Métrica | Qué evalúa | Limitación / utilidad | | --- | --- | --- | | FID | Retraso de la primera interacción | No representaba el comportamiento durante toda la visita. | | INP | Responsividad durante la vida de la página | Ofrece una visión más representativa de la experiencia interactiva. | | (https://lgdataone.io/blog/lcp-alto/) | (https://lgdataone.io/blog/velocidad-de-carga-de-una-web/) del contenido principal | Complementa INP: cargar rápido no implica responder rápido. | | CLS | Estabilidad visual | Complementa INP al detectar desplazamientos inesperados. | Por eso conviene analizar las tres Core Web Vitals en conjunto. Una página puede tener un (https://lgdataone.io/blog/lcp-alto/) y, sin embargo, responder lentamente al abrir un desplegable porque el navegador está ocupado ejecutando JavaScript. ## Cuáles son los valores buenos de INP La documentación de Google y web.dev utiliza tres rangos operativos. Para clasificar correctamente una página se toma como referencia el **percentil 75** de las visitas y se diferencia entre dispositivos móviles y ordenadores. Esto evita evaluar la experiencia únicamente con un equipo rápido de desarrollo. | INP | Estado | Interpretación | | --- | --- | --- | | ≤ 200 ms | Bueno | La mayoría de usuarios recibe feedback con rapidez. | | > 200 y ≤ 500 ms | Necesita mejora | Existe una latencia perceptible en parte de las interacciones. | | > 500 ms | Deficiente | La respuesta puede sentirse claramente lenta o bloqueada. | No conviene convertir 200 ms en una obsesión aislada. La propia documentación de Google recuerda que una buena puntuación en Core Web Vitals no garantiza aparecer en las primeras posiciones. La relevancia del contenido, la intención de búsqueda, la calidad y muchas otras señales siguen siendo esenciales. La meta práctica es ofrecer una página útil que además responda con fluidez. ## Cómo se calcula una interacción en INP Una interacción puede dividirse en tres partes. Entender esta descomposición evita aplicar optimizaciones genéricas que no atacan la causa real. 1. Input delay: tiempo desde que el usuario inicia la interacción hasta que el navegador puede comenzar a ejecutar los event handlers. Si el hilo principal está ocupado con una tarea larga, el clic tiene que esperar. 2. Processing duration: tiempo empleado en ejecutar los manejadores asociados a la interacción. Aquí suelen aparecer funciones JavaScript pesadas, cálculos innecesarios, listeners duplicados o trabajo síncrono excesivo. 3. Presentation delay: tiempo entre el final del procesamiento y el siguiente frame que refleja visualmente el resultado. El coste puede venir de recalcular estilos, layout, renderizado o actualizaciones grandes del DOM. Chrome DevTools puede ayudar a separar estas fases durante una traza. Si el input delay es alto, debes investigar qué estaba ocupando el hilo principal antes del evento. Si domina el processing duration, revisa el código del handler. Si el problema está en presentation delay, investiga renderizado, estilos y tamaño de las actualizaciones del DOM. ## Datos de campo frente a pruebas de laboratorio INP es especialmente útil cuando se analiza con **datos de usuarios reales**. Search Console, Chrome UX Report y herramientas que consumen esos datos permiten detectar grupos de URLs cuyo rendimiento necesita atención. El laboratorio sirve para reproducir un problema, pero una sesión de prueba no representa toda la variedad de dispositivos, conexiones y comportamientos de tus usuarios. | Fuente | Sirve para | Limitación | | --- | --- | --- | | Search Console / CrUX | Detectar problemas reales por grupos de URLs | No explica por sí sola qué función o interacción causa el retraso. | | PageSpeed Insights | Combinar datos de campo disponibles con diagnóstico de laboratorio | Puede no disponer de datos suficientes para todas las URLs. | | Chrome DevTools | Reproducir interacciones y localizar tareas lentas | Depende del escenario y del dispositivo usado en la prueba. | | RUM propio | Relacionar interacciones lentas con plantillas, dispositivos o usuarios | Requiere instrumentación, gobernanza y análisis. | Una estrategia eficaz empieza por el campo: identifica qué grupos y plantillas tienen mal INP. Después reproduce las interacciones más probables en laboratorio. Finalmente, vuelve a observar los datos de campo después del despliegue; no des por resuelto el problema solo porque una ejecución local haya mejorado. !(https://lgdataone.io/wp-content/uploads/2026/03/LG-DataOne-herramienta-analitica-web-y-CRO-CTA-blog.jpg) ### **Comprueba cómo funciona LG DataOne** Consulta las demos y revisa cómo LG DataOne ayuda a (https://lgdataone.io/auditar-ga4/) rendimiento, analítica y experiencia antes de priorizar cambios. (https://lgdataone.io/demos/) ## Las causas más frecuentes de un INP alto No existe una única causa. Sin embargo, muchos problemas terminan relacionados con saturación del hilo principal, handlers que hacen demasiado trabajo y renderizados costosos. ### Tareas largas de JavaScript Si el navegador ejecuta una tarea larga cuando llega la interacción, el evento espera. Esto puede ocurrir con bundles demasiado grandes, librerías que inicializan mucho código, scripts de terceros, procesamientos de datos o (https://lgdataone.io/data-componentes/) que se renderizan de una sola vez. Dividir trabajo largo en tareas más pequeñas puede devolver oportunidades al navegador para atender (https://lgdataone.io/blog/eventos-automaticos-ga4-necesitas-saber/). ### Event handlers demasiado costosos Un clic debería hacer el mínimo trabajo imprescindible antes de mostrar feedback. Si el handler valida decenas de campos, recalcula grandes estructuras, modifica mucho DOM o dispara varias tareas síncronas, el usuario espera hasta que todo termina. Una mejora común es separar el feedback inmediato del trabajo secundario. ### Demasiado trabajo de renderizado Cambiar clases, dimensiones o contenido puede desencadenar recalculado de estilos y layout. Si una interacción modifica centenares de nodos o fuerza lecturas y escrituras intercaladas del layout, el coste de presentación aumenta. ### Scripts de terceros Chat, (https://lgdataone.io/blog/personalisation-estrategias-clave-convertir-2026/), publicidad, widgets, mapas, CMPs, analítica y otras herramientas pueden competir por el hilo principal. El objetivo no es eliminarlas automáticamente, sino medir su coste y cargar cada una cuando realmente sea necesaria. ### Interfaces sin feedback temprano Aunque el trabajo no pueda completarse de inmediato, proporcionar una señal visual temprana reduce la sensación de bloqueo. Cambiar el estado del botón, mostrar un indicador o confirmar la recepción de una acción puede mejorar la experiencia mientras el proceso secundario continúa. ## Cómo mejorar INP paso a paso ### 1. Localiza las páginas y plantillas con peor rendimiento Empieza por Search Console y por datos de campo. Agrupa problemas por tipo de plantilla: ficha de producto, (https://lgdataone.io/blog/optimizar-checkout/), buscador, (https://lgdataone.io/check-formularios-web/), landing, área privada o artículo. Priorizar por plantilla suele ser más eficiente que corregir URLs de una en una cuando comparten código. ### 2. Reproduce interacciones reales No midas únicamente el clic que sabes que funciona bien. Abre menús, filtros, acordeones, (https://lgdataone.io/blog/diseno-de-formularios-tasas-conversion-web/), tabs, buscadores, carruseles y elementos que el usuario utilice durante una sesión normal. Prueba también en condiciones menos favorables y con CPU throttling para aproximarte a dispositivos modestos. ### 3. Descompón la interacción lenta Determina si el retraso está antes, durante o después del handler. Este paso cambia por completo la solución. Optimizar una función no ayudará si el problema real es una tarea de terceros que bloquea el hilo antes de que esa función pueda empezar. ### 4. Reduce trabajo innecesario en los handlers Evita cálculos que puedan posponerse. No reconstruyas una vista completa si solo cambia una pequeña parte. Elimina listeners duplicados y revisa bucles, serializaciones y operaciones síncronas. La interacción debe reservar el camino crítico para producir feedback. ### 5. Divide tareas largas Cuando un bloque de trabajo es inevitable, dividirlo permite que el navegador procese entradas entre partes. El objetivo no es fragmentar por fragmentar, sino evitar que una sola tarea monopolice el hilo principal durante demasiado tiempo. ### 6. Reduce el coste del DOM y del renderizado Un DOM grande aumenta el coste potencial de estilos y layout. Actualiza solo los nodos necesarios, evita patrones que alternen lecturas y escrituras del layout continuamente y revisa componentes que generan muchas capas o elementos ocultos. ### 7. Revisa terceros por impacto, no por costumbre Cada (https://lgdataone.io/blog/script-google-tag-manager-guia/) debe justificar su coste. Carga bajo demanda cuando sea posible, retrasa lo no crítico y elimina integraciones redundantes. Un tag manager ayuda a gobernar el despliegue, pero no convierte automáticamente un script pesado en un script barato. ### 8. Mide después del cambio Conserva una fecha de despliegue y compara el comportamiento posterior con el baseline. Los datos de campo necesitan tiempo para reflejar el cambio; evita atribuir una variación inmediata a una única intervención. ## INP en ecommerce, formularios y webs con mucho JavaScript El impacto práctico de INP cambia según la interfaz. En ecommerce, las interacciones críticas suelen concentrarse en variantes de producto, filtros, carrito y checkout. En formularios aparecen validaciones, máscaras, autocompletados y lógica condicional. En aplicaciones con mucho JavaScript, los cambios de vista y actualizaciones de estado pueden acumular trabajo en el hilo principal. En estos escenarios conviene priorizar por negocio. Una interacción lenta en un componente decorativo no tiene el mismo impacto que un botón de “Añadir al carrito” que tarda en mostrar respuesta. Combina rendimiento técnico con analítica para identificar qué interacciones forman parte de recorridos críticos. | Área | Interacciones a revisar | Prioridad | | --- | --- | --- | | Ecommerce | Filtros, variantes, carrito, checkout | Muy alta si afecta al flujo de compra | | Formularios | Validación, campos condicionales, envío | Alta en captación (https://lgdataone.io/blog/conversion-leads-estrategias/) | | Contenido | Menús, acordeones, tablas, navegación | Depende del uso real | | Aplicaciones web | Cambios de vista, tablas, filtros y acciones | Alta cuando forman el núcleo del producto | ## INP y SEO: qué relación existe realmente Google incluye INP dentro de Core Web Vitals y recomienda alcanzar buenos valores tanto por experiencia de usuario como para tener éxito en Search. Al mismo tiempo, Google explica expresamente que no existe una única señal de “page experience” y que obtener una puntuación perfecta de Core Web Vitals no garantiza una posición alta. Por tanto, la estrategia correcta no es perseguir 200 ms ignorando todo lo demás. Un contenido debe responder mejor que sus alternativas a la intención de búsqueda, ser rastreable e indexable, tener una arquitectura coherente y ofrecer una experiencia sólida. INP es una pieza de ese sistema. Para una estrategia WPO completa, combina esta métrica con LCP y CLS, con análisis por dispositivo y con el impacto sobre los recorridos de negocio. La (https://lgdataone.io/velocidad-paginas-web-auditoria-wpo/) puede utilizarse para estructurar esa revisión y priorizar oportunidades de rendimiento. ## Checklist de auditoría de INP - Revisar datos de campo y no depender únicamente de una prueba local. - Evaluar el percentil 75 y separar móvil y escritorio. - Identificar plantillas con peor comportamiento. - Reproducir interacciones críticas y no solo la carga inicial. - Separar input delay, processing duration y presentation delay. - Localizar tareas largas del hilo principal. - Auditar handlers, DOM, renderizado y scripts de terceros. - Proporcionar feedback visual temprano cuando una tarea necesite tiempo. - Guardar baseline y fecha de despliegue. - Volver a comprobar datos de campo después del cambio. 👉 Si necesitas descargarte infografías sobre (https://lgdataone.io/registro-de-newsletter/), descuentos en cursos y herramientas y mucho más puedes hacerlo aquí: (https://lgdataone.io/registro-de-newsletter/) ## Conclusiones INP obliga a mirar más allá de la carga inicial. Una página puede mostrar su contenido principal rápidamente y aun así frustrar a una persona cuando intenta interactuar. La mejora empieza por datos de campo, continúa reproduciendo la interacción en laboratorio y termina actuando sobre la fase que realmente provoca el retraso. Si el problema está en input delay, reduce la ocupación previa del hilo principal. Si domina processing duration, simplifica los handlers. Si el cuello de botella aparece en presentation delay, revisa DOM, estilos, layout y renderizado. Y después de cualquier cambio, vuelve a medir con usuarios reales. Desde el punto de vista SEO, busca equilibrio: buenas Core Web Vitals, contenido relevante, arquitectura clara e indexabilidad. Mejorar INP tiene sentido porque mejora la experiencia del usuario y forma parte de las señales de experiencia que Google considera, no porque exista una relación automática de “menos milisegundos = más posiciones”. LG DATAONE ### ¿Listo para dar el siguiente paso? Convierte el análisis de INP y Core Web Vitals en un plan de mejora priorizado con LG DataOne. (https://lgdataone.io/producto/access/?attribute_pa_nivel=standard&coupon=4mesesgratis) ## Preguntas frecuentes sobre INP ### ¿Qué significa INP? INP significa Interaction to Next Paint. Es una métrica que evalúa la capacidad de respuesta de una página observando la latencia de las interacciones durante la visita. ### ¿Cuál es un buen valor de INP? Un INP de 200 milisegundos o menos se considera bueno. Entre 200 y 500 ms necesita mejora y por encima de 500 ms se considera deficiente. La evaluación se realiza normalmente sobre el percentil 75 de las visitas. ### ¿INP afecta al SEO? INP forma parte de Core Web Vitals, que Google utiliza dentro de sus sistemas relacionados con la experiencia de página. Sin embargo, unas buenas Core Web Vitals no garantizan posiciones altas y deben trabajarse junto con relevancia, calidad e indexabilidad. ### ¿Por qué PageSpeed puede mostrar un INP distinto de mi prueba local? Porque los datos de campo reflejan usuarios, dispositivos y sesiones reales durante un periodo, mientras que una prueba local representa un escenario concreto. Las dos fuentes son complementarias. ### ¿Qué debo optimizar primero si INP es alto? Primero identifica la interacción lenta y descompón su latencia. Optimiza la fase dominante: espera del hilo principal, procesamiento del handler o retraso de presentación. ### ¿Un JavaScript más pequeño garantiza un mejor INP? No por sí solo. Reducir JavaScript puede ayudar, pero también importan cuándo se ejecuta, cuánto trabajo hace cada handler, los scripts de terceros y el coste de renderizado posterior. ## Fuentes - (https://web.dev/articles/inp) - (https://web.dev/articles/optimize-inp) - (https://developers.google.com/search/docs/appearance/core-web-vitals) - (https://developers.google.com/search/docs/appearance/page-experience) - (https://developer.chrome.com/docs/performance/insights/inp-breakdown)