Frontend
INP: rendimiento después de que la página cargó
Una guía para encontrar tareas largas y responder rápido durante toda la vida de una página.
La idea central
Localiza qué parte de la interacción espera: entrada, procesamiento o presentación. La duración del handler por sí sola no explica lo que percibe el usuario.
Interaction to Next Paint mide la latencia de las interacciones durante la visita y representa qué tan rápido aparece el siguiente cuadro visual. Un buen objetivo es 200 milisegundos o menos en el percentil 75, separado por móvil y escritorio.
Una interacción se divide en espera de entrada, ejecución de manejadores y retraso de presentación. Medir solo el tiempo de una función puede ocultar trabajo previo en la cola o un render costoso que bloquea el siguiente cuadro.
Anatomía de una interacción de 180 ms
01
Espera de entrada
Trabajo previo en el hilo principal
02
Procesamiento
Handlers y actualización de estado
03
Presentación
Render, layout y siguiente paint
Las mejoras suelen venir de dividir tareas largas, reducir JavaScript cliente, evitar recalcular layout, renderizar menos nodos y ofrecer respuesta visual inmediata antes de una operación asíncrona. Cada optimización debe comprobarse en dispositivos representativos.
Los datos de laboratorio ayudan a reproducir, pero el INP de campo muestra combinaciones reales de hardware, extensiones, red y uso. La mejor práctica es instrumentar rutas críticas y conservar contexto suficiente para ubicar qué interacción produjo el valor.
Diagnosticar la fase correcta
Un input delay alto apunta a tareas que ya ocupaban el hilo principal. Processing alto señala handlers o cálculos costosos. Presentation alto suele relacionarse con render, estilos o demasiados nodos. Separar fases impide optimizar una función pequeña mientras el verdadero bloqueo ocurre antes o después.
Conectar datos de campo con contexto
El percentil 75 debe segmentarse por ruta y tipo de dispositivo. Para investigar conviene registrar el tipo de interacción, elemento, versión y duración, cuidando privacidad y cardinalidad. Las sesiones lentas importan más que una demo rápida en el equipo del desarrollador.
Liberar el hilo principal
Dividir tareas permite que el navegador atienda entradas entre bloques. Reducir JavaScript cliente, virtualizar listas grandes, evitar renders amplios y mover trabajo no urgente después de la respuesta visual suele producir más impacto que microoptimizar una operación aislada. Cada cambio se valida en hardware representativo.
Definir presupuestos de interacción
Los flujos críticos necesitan objetivos por interacción y alertas por regresión. Una tabla filtrable, un buscador y un checkout tienen perfiles distintos. Integrar medición en releases ayuda a relacionar cambios de bundle, componentes o datos con el deterioro antes de que el promedio mensual lo oculte.
Caso didáctico
Un filtro que responde tarde aunque su función sea rápida
Una tabla filtra registros en una función breve, pero el clic llega mientras el hilo principal procesa trabajo de otra parte de la pantalla. Después, el cambio vuelve a renderizar muchas filas y provoca trabajo de estilos y layout. Medir exclusivamente el filtro llevaría a concluir que no hay nada que optimizar.
Graba la interacción y separa espera de entrada, ejecución y presentación. Si domina el render, reduce el trabajo visible, revisa qué componentes se actualizan y considera virtualizar una lista extensa. Si domina un cálculo que no necesita el DOM, evalúa un worker. Mover trabajo tiene costos de comunicación; un worker no corrige un layout excesivo.
Una respuesta visual temprana comunica que el clic fue recibido, pero el navegador necesita una oportunidad de pintar. Cambiar un estado de carga y ejecutar inmediatamente un cálculo síncrono largo puede impedir ese feedback. Divide trabajo no urgente y comprueba el resultado en un dispositivo representativo. INP mide hasta el siguiente paint; mide por separado cuánto tarda en completarse la tarea útil.
Qué elegir y qué implica
| Situación | Decisión | Límite a considerar |
|---|---|---|
| Espera antes del handler | Reducir o dividir tareas previas en el hilo principal. | Optimizar el handler no libera una cola ya bloqueada. |
| Cálculo intensivo | Evaluar fragmentación o un worker. | Hay costos de transferencia y coordinación de resultados. |
| Presentación costosa | Reducir nodos, invalidaciones y trabajo de layout. | El feedback debe seguir siendo comprensible y accesible. |
Desliza la tabla para comparar las tres columnas.
Llévalo a la práctica
Construye una comparación reproducible
- Usa el mismo dispositivo, datos y recorrido al comparar versiones.
- Anota la fase dominante y prueba un cambio cada vez.
- Comprueba INP de campo al percentil 75 por móvil y escritorio cuando haya datos suficientes.
Qué comprobar: La interacción mejora fuera de la máquina de desarrollo y el tiempo de completar la tarea no empeora a cambio de pintar antes.
La carga no termina en el primer paint
INP obliga a cuidar toda la vida de la página. Un sitio puede cargar rápido y sentirse lento después; el objetivo es mantener disponible el hilo principal y producir una respuesta visual comprensible durante cada interacción importante.
Para seguir leyendo
Frontend
Next.js 16 y React 19: una arquitectura más explícita
Qué cambia cuando caché, límites servidor-cliente y actualizaciones optimistas dejan de ser detalles implícitos.
IA y agentes
Agentes con MCP: útiles por diseño, seguros por control
Cómo exponer herramientas a un agente sin convertir cada integración en un permiso implícito.