INP alto: cómo diagnosticar interacciones lentas y reducir trabajo en la thread principal

Lectura ejecutiva

Conclusiones principales

• INP exige interacciones reales; Lighthouse no lo reproduce solo.
• Descubre qué interacción y fase dominan la latencia.
• Divide tareas largas y actualiza solo la parte necesaria.
• Ofrece feedback visual rápido sin ocultar procesamiento excesivo.

Interaction to Next Paint mide cuánto tarda una página en presentar respuesta visual después de clics, toques y teclado. Un INP alto puede ocurrir en carga, búsqueda, menú, selección de variante, carrito o formulario.

El límite recomendado es 200 milisegundos en el percentil 75. Como depende del uso real durante la visita, una prueba que solo carga la página no diagnostica toda la experiencia.

Entiende las tres fases

Retraso de entrada

Es el tiempo entre la acción y el inicio del handler. El navegador puede estar ocupado con JavaScript, un callback de tercero, cálculo de estilos u otra tarea.

Procesamiento

Es el tiempo en handlers y trabajo disparado. Validación pesada, serialización, loops, filtros, estado y renderizados pueden dominar.

Retraso de presentación

Después del código, el navegador calcula estilos, layout y paint. Cambiar una gran parte del DOM o alternar lecturas y escrituras retrasa el frame.

El diagnóstico debe indicar la fase dominante. “Reducir JavaScript” es una dirección, no una causa.

Empieza con datos de campo

Los datos públicos pueden mostrar que un origen falla INP, pero no qué botón fue lento. Instrumentación con web-vitals puede registrar la métrica y atributos respetando privacidad.

Combina la señal con template, dispositivo, etapa, versión, interacciones frecuentes y errores. No captures texto ni datos personales; identifica componentes y tipos de evento.

Reproduce interacciones importantes

Lista acciones críticas: abrir navegación, gestionar consentimiento, usar búsqueda y filtros, seleccionar variante, añadir al carrito, avanzar en checkout, enviar formulario, expandir FAQ y abrir modales.

Graba en Performance de Chrome con dispositivo representativo o desaceleración controlada. Repite. La primera interacción puede inicializar trabajo que las siguientes no ejecutan.

Encuentra tareas largas

Una tarea larga ocupa la thread principal y hace esperar nuevas entradas. Investiga evaluación de bundles, hidratación, tag managers, chat, experimentos, mapas, players, bibliotecas, listas grandes, JSON y validaciones.

Dividir una tarea permite procesar entrada y renderizar entre bloques. Puedes ceder control, programar trabajo no urgente o mover computación apropiada a Web Workers.

Reduce JavaScript inicial y tardío

INP no es solo carga. Scripts tardíos siguen compitiendo.

Pregunta si cada componente necesita hidratar, puede ser HTML y CSS, puede cargar tras interacción, puede ejecutarse en servidor, aparece donde no se usa, duplica una función nativa o trae una dependencia desproporcionada.

Contenido editorial, navegación simple, details/summary y formularios nativos reducen superficie de JavaScript.

Actualiza menos elementos

Un clic pequeño no debería renderizar toda la página. Revisa límites de componentes, selectores de estado y dependencias de efectos.

Problemas comunes: contexto global por tecla, recalcular toda una lista, claves inestables, efectos encadenados, lecturas de layout tras escrituras y tablas grandes sin virtualización adecuada.

Mide antes de memorizar todo. La caché también tiene coste.

Controla eventos frecuentes

input, scroll, pointermove y resize se disparan muchas veces. Usa throttle para trabajo continuo, debounce cuando se puede esperar, requestAnimationFrame para trabajo visual, listeners pasivos cuando corresponda y cancelación de solicitudes obsoletas.

En búsqueda, actualiza el texto inmediatamente y retrasa la red. Así mantienes feedback sin trabajo caro en cada tecla.

Muestra feedback antes del trabajo secundario

Si una acción inicia procesamiento o red, confirma rápido: cambia el botón, muestra progreso, actualiza selección, mantiene foco y anuncio accesible, y pospone analytics.

El feedback no corrige una thread bloqueada, pero renderizar primero el estado mínimo reduce retraso de presentación.

Revisa terceros con criterio comercial

Los scripts externos compiten por la misma thread. Crea un inventario con propietario, finalidad, páginas, bytes, CPU e impacto de retirada. Carga solo donde se usan, pospone hasta consentimiento o interacción, elimina duplicados y define presupuesto de CPU.

No retires medición crítica sin alinear analytics, marketing y legal.

Usa TBT como pista

Lighthouse informa Total Blocking Time durante laboratorio. Reducir tareas largas puede ayudar INP, pero no está garantizado. La interacción lenta puede ocurrir minutos después en un componente no probado.

El flujo correcto: campo confirma INP, profiling reproduce, la corrección reduce trabajo y campo verifica tendencia.

Observación: aplicar un filtro móvil tarda 480 ms; 300 ms se consumen renderizando todos los cards. Acción: filtrar datos normalizados, actualizar solo la lista y posponer analytics. Aceptación: feedback inmediato, resultados correctos y mediana inferior a 200 ms en cinco perfiles.

Después del deploy, acompaña errores, accesibilidad y conversión. Una interfaz rápida pero incorrecta no es éxito.

INP mejora cuando tiempo de CPU y alcance de actualización se tratan como recursos finitos. La pregunta no es solo cuánto JavaScript existe, sino cuándo y por qué se ejecuta y si bloquea la acción.

Respuestas directas

Preguntas frecuentes

¿Cuál es un buen INP?

La recomendación actual es INP de hasta 200 milisegundos en el percentil 75, separado entre mobile y desktop.

¿TBT e INP son la misma métrica?

No. Total Blocking Time es una métrica de laboratorio relacionada con tareas largas durante la carga. Puede indicar riesgo, pero INP mide interacciones reales durante la visita.

¿Debounce siempre mejora INP?

No. Puede reducir llamadas repetidas, pero también retrasar la respuesta percibida. Úsalo según el evento y mantén feedback inmediato cuando sea necesario.