INP: cómo arreglar una web lenta al hacer clic

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 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.

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.

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 y la optimización de rendimiento 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. Conoce nuestro servicio de sitios corporativos o pide una revisión desde contacto.