INP: por qué tu web tarda en responder al clic
El problema ya no es "tarda en cargar", es "no responde"
Durante años medimos la velocidad de una web con una sola pregunta: cuánto tarda en aparecer el contenido. Esa pregunta sigue importando, pero dejó de ser suficiente. Hoy el usuario toca un botón, el botón no responde y se va.
Los datos de campo acompañan esa intuición: en el reporte de Chrome UX de julio de 2026, apenas el 56,4% de los orígenes medidos aprobaba las tres Core Web Vitals, mientras que el INP pasaba el umbral en más del 87%. Es decir, la mayoría de los sitios ya carga razonablemente bien, pero la interactividad sigue siendo el punto flojo.
Qué mide el INP (y qué no mide)
El Interaction to Next Paint mide el tiempo entre una interacción del usuario (clic, tap, tecla) y el siguiente cuadro que efectivamente se pinta en pantalla. Se mide durante toda la visita y se reporta el peor caso representativo, no el promedio. El umbral para considerarlo bueno es 200 milisegundos.
Se descompone en tres fases:
- Input delay: cuánto espera el evento antes de empezar a procesarse (el hilo principal está ocupado).
- Processing time: lo que tardan tus manejadores de eventos.
- Presentation delay: lo que tarda el navegador en calcular estilos, layout y pintar.
Si solo mirás el número final, vas a optimizar a ciegas. La fase que falla te dice qué tocar.
Dónde se mide de verdad
Lighthouse y PageSpeed Insights en modo laboratorio sirven para detectar problemas, no para aprobar métricas. El INP es una métrica de campo: necesitás Search Console, el reporte de Chrome UX o tu propio RUM con la librería web-vitals y un PerformanceObserver que capture eventos con interactionId.
Las cinco causas que vemos en sitios argentinos
- Terceros cargados de entrada. Chat, píxeles, tag manager con veinte etiquetas, mapa de sucursales y encuesta de satisfacción compitiendo por el hilo principal.
- Hidratación de islas enteras. Un framework que hidrata el layout completo para que funcione un menú.
- Listeners caros en
scrolloinput. Validaciones de formulario que recorren el DOM en cada tecla. - DOM gigantesco. Menús mobile con todas las categorías y subcategorías renderizadas aunque estén cerradas.
- Layout thrashing. Cambios de fuente, banners que se insertan tarde y anuncios que empujan el contenido justo cuando el usuario va a tocar algo.
Cómo priorizar sin perder semanas
Medí por plantilla, no por sitio
El INP de la home no dice nada del checkout. Segmentá por plantilla: home, listado, ficha de producto, carrito y checkout. Ahí aparecen los verdaderos cuellos de botella.
Aislá los terceros
Cargá el chat y las encuestas después de la primera interacción o con requestIdleCallback. Un widget de soporte que bloquea el primer clic cuesta más ventas de las que recupera.
Partí las tareas largas
Si un cálculo tarda más de 50 ms, partilo. Hoy tenés scheduler.yield() o un setTimeout para devolverle el control al navegador. Y en los manejadores, actualizá la interfaz primero, calculá después.
Reducí el trabajo, no solo el peso
Virtualizá listas largas, memoizá cálculos, evitá re-renderizar componentes que no cambiaron y sacá animaciones que corren en el hilo principal.
Ponele presupuesto
Un presupuesto de performance en el pipeline de integración continua evita que el INP se degrade en silencio con cada sprint.
El INP se degrada solo
A diferencia de otras métricas, el INP empeora con el tiempo sin que nadie toque el código: se suma un píxel, se agrega una app, se publica una campaña con un script nuevo. Por eso la medición tiene que ser continua y con alertas, no una auditoría anual.
El próximo paso
Si tu web carga rápido pero se siente lenta al usar, el problema es la interactividad. En Codit Digital medimos INP con datos de campo, identificamos la fase que falla y corregimos sobre el código real, no sobre un informe genérico. Conocé nuestro servicio de soporte continuo, hosting y SEO técnico o pedí un diagnóstico.
