# INP: cómo arreglar una web lenta al hacer clic > Qué es INP (Interaction to Next Paint), cómo medirlo, por qué tu web responde lento al hacer clic y los arreglos más efectivos en JavaScript, terceros y renderizado. URL: https://codegea.com/inp-como-arreglar-una-web-lenta-al-hacer-clic Web · 2026-10-05 · Derian Pinto Haces clic en un menú, en «agregar al carrito» o en un filtro y la página tarda en reaccionar. Esa sensación tiene nombre y número: **INP** (Interaction to Next Paint), la métrica con la que Google mide qué tan rápido responde una página cuando alguien interactúa con ella. Es una de las tres métricas de [Core Web Vitals](/core-web-vitals-en-2026-que-son-y-como-mejorarlos) y, en la práctica, la que más cuesta arreglar. > INP mide el tiempo que pasa entre una acción del usuario y el momento en que la pantalla muestra una respuesta. Si es lento, el usuario siente que tu sitio «no responde». ## Qué mide exactamente Cada vez que alguien hace clic, toca la pantalla o pulsa una tecla, el navegador: 1. **Recibe la acción** (a veces tiene que esperar si está ocupado). 2. **Ejecuta el código** asociado (los «manejadores» de eventos). 3. **Actualiza la pantalla** con el resultado. INP toma las interacciones de una visita y reporta, aproximadamente, la más lenta (con excepciones para visitas con muchas interacciones). Google considera **bueno** un INP de **200 ms o menos**, y **deficiente** uno por encima de **500 ms**. ## Cómo medirlo - **Datos reales (de campo):** Search Console (informe de Core Web Vitals) y PageSpeed Insights muestran el INP de tus visitantes reales. - **Pruebas locales:** las herramientas de desarrollo de Chrome permiten registrar interacciones y ver cuáles son lentas y por qué. - **Medición propia:** puedes capturarlo en tu analítica con la biblioteca `web-vitals` de Google. Mide en un **móvil real o simulado de gama media**, no solo en tu computadora potente: ahí es donde se nota el problema. ## Por qué una web responde lento Casi siempre es una de estas causas: ### 1. El hilo principal está ocupado El navegador procesa JavaScript, estilos y pintado en un solo hilo. Si está ejecutando una tarea larga, el clic espera. Tareas de más de 50 ms ya empiezan a notarse. ### 2. Demasiado JavaScript Cada biblioteca, widget y script suma tiempo de descarga, análisis y ejecución. Los sitios que cargan frameworks pesados para mostrar contenido casi estático lo pagan en cada interacción. ### 3. Scripts de terceros Chat, analítica, píxeles de publicidad, mapas, mapas de calor: cada uno compite por el hilo principal. Suelen ser la causa más subestimada. ### 4. Manejadores de eventos lentos Un clic que dispara cálculos pesados, actualiza muchos elementos o espera a un servidor antes de mostrar algo. ### 5. Renderizado costoso Páginas con un DOM enorme, estilos que obligan a recalcular todo el diseño, listas largas sin virtualizar o animaciones que fuerzan trabajo constante. ## Cómo arreglarlo, por orden de impacto ### Reduce y divide el JavaScript - **Elimina** bibliotecas que ya no uses. - **Carga solo lo necesario** en cada página (división de código). - **Pospone** lo que no se necesita al inicio (cargar al interactuar o al hacerse visible). - Para sitios de contenido, considera una arquitectura que envíe poco JavaScript al navegador. Compara enfoques en [Astro vs Next.js para landing pages](/astro-vs-next-js-para-landing-pages-rendimiento-y-seo-comparados). ### Controla los scripts de terceros - **Haz inventario** y quita los que no aportan. - **Carga diferida** de los que no son críticos. - Evalúa reemplazar un widget pesado por una alternativa liviana o un enlace. ### Divide las tareas largas Si una acción necesita mucho trabajo, parte el proceso en trozos y devuelve el control al navegador entre uno y otro, para que pueda pintar y responder. Lo primero que el usuario espera ver (por ejemplo, que un botón cambie de estado) debe mostrarse enseguida, y el resto puede ocurrir después. ### Responde primero, calcula después Ante un clic, actualiza la interfaz de inmediato (estado de carga, botón marcado) y haz el trabajo pesado o la petición al servidor sin bloquear. Esto se llama respuesta optimista y mejora la percepción incluso si la operación tarda lo mismo. ### Simplifica el renderizado - Mantén el **DOM pequeño:** menos elementos, menos anidación. - Evita **cambios de diseño** costosos durante la interacción. - **Virtualiza** listas largas. - Revisa animaciones: usa propiedades baratas (como `transform` y `opacity`). ### Cuida el servidor y la caché Si la interacción depende de una respuesta del servidor, el backend también cuenta. Caché, consultas eficientes y un buen servidor reducen la espera. Mira [caché en el servidor](/cache-en-el-servidor-redis-varnish-y-opcache-que-hace-cada-uno). ## En tiendas y sitios con filtros Los filtros de catálogo, el carrito y el checkout son los puntos donde más duele un INP alto, porque están cerca de la compra. Revisa los [errores de checkout que cuestan ventas](/errores-en-el-checkout-que-te-hacen-perder-ventas-en-ecuador) y la [optimización de rendimiento](/optimizacion-de-rendimiento-en-desarrollo-web) de tu sitio. ## Un orden de trabajo práctico 1. **Mide** tu INP real y detecta qué páginas e interacciones son las peores. 2. **Reproduce** el problema en las herramientas de desarrollo. 3. **Corrige la causa principal** (casi siempre, scripts o JavaScript de más). 4. **Vuelve a medir** y confirma la mejora con datos reales; los datos de campo tardan unas semanas en actualizarse. 5. **Vigila** que no vuelva a empeorar con cada plugin o script nuevo. ## Cómo lo hacemos en Codegea Auditamos el rendimiento de tu sitio, identificamos qué interacciones son lentas y corregimos la causa en el código, los scripts de terceros y el servidor. Para mantener los resultados en el tiempo, lo integramos en un [plan de retainer](/retainer). Conoce nuestro servicio de [sitios corporativos](/servicios/desarrollo-de-sitios-corporativos) o pide una revisión desde [contacto](/contacto).