Un INP alto no significa simplemente “hay demasiado JavaScript”: representa una interacción concreta que responde tarde para usuarios reales. El camino útil es identificar qué clic, toque o tecla es lenta y separar retraso de entrada, tiempo de procesamiento y retraso hasta pintar el resultado.
Empieza por la interacción, no por el número
Usa datos de campo o una traza reproducible para nombrar la interacción y el estado de página afectados. Un menú, un buscador y un botón de checkout pueden fallar por motivos distintos.
Separa input delay del trabajo del handler
Las long tasks que ya estaban ejecutándose crean retraso antes del evento; un handler caro crea tiempo de procesamiento. Juntarlo todo como “main thread” oculta el responsable.
Inspecciona la long task que coincide con el evento
En la traza, localiza qué script o función ocupa el hilo principal alrededor de la interacción. Tags de terceros, hydration, sliders o listeners personalizados son candidatos, no conclusiones.
Reduce trabajo en la ruta crítica
Divide tareas síncronas largas, aplaza lo no esencial, reduce cambios de DOM y evita meter analítica o render no relacionado dentro del mismo handler. La respuesta visible al usuario va primero.
Revisa también presentation delay
Un handler rápido puede dar INP malo si después hay layout/render costoso. Busca forced layout, DOM grande o estilos que obliguen a recalcular demasiado.
Repite exactamente la misma interacción
Valida en dispositivos y estados realistas y después observa INP de campo. Una traza de laboratorio mejor ayuda, pero el objetivo es la respuesta real al visitante.
Usa la guía sobre velocidad para visitantes reales para no probar solo como administrador y compara con la variación entre pruebas PageSpeed.