Un filtro tarda en actualizarse, un menú se abre con retraso o el texto escrito aparece tarde, aunque la página cargue rápidamente. Para encontrar la causa, revise la respuesta tras cada acción y el trabajo de JavaScript. Si la aplicación utiliza Workers o iframes, examine también el intercambio de mensajes.
Por qué un sitio rápido puede tardar en responder a las acciones
Después del clic, el navegador debe manejar el evento, ejecutar JavaScript y mostrar el marco actualizado. Si el hilo principal está ocupado, algún trabajo espera su turno. Por tanto, una buena velocidad de carga no garantiza una respuesta rápida de menús, filtros y formularios.
Trasladar los cálculos a un Web Worker puede liberar el hilo principal, pero añade intercambio de datos. La ventana de la página, los Workers y los iframes intercambian mensajes mediante postMessage(). Un mensaje enviado puede tener que esperar antes de procesarse.
Dónde se producen retrasos en la cola de mensajes
Comience con tres posibles razones:
- El receptor está realizando una tarea síncrona de larga duración. El nuevo mensaje se procesará cuando el hilo esté libre.
- Hay demasiados mensajes. Incluso los manejadores breves crean una cola si el trabajo llega más rápido de lo que se procesa.
- Se transfiere una gran cantidad de datos. La serialización en el remitente y la deserialización en el destinatario requieren tiempo en los respectivos subprocesos.
Por ejemplo, una búsqueda envía una solicitud a un Worker por cada letra escrita. Si aún calcula los resultados anteriores, las solicitudes se acumulan. El usuario ya ha terminado de escribir, pero la aplicación sigue calculando resultados para la entrada antigua. Mida la frecuencia de los mensajes, el tiempo de procesamiento y el volumen de datos transferidos.
Cómo mide INP la respuesta de la página
INP, Interaction to Next Paint, evalúa la respuesta a clics, toques y pulsaciones de teclas durante la visita. El valor refleja una de las interacciones más lentas, según las reglas de exclusión de valores atípicos. Cada interacción incluye la espera hasta el procesamiento, la ejecución de los manejadores y el tiempo hasta mostrar el siguiente fotograma.
Un buen valor de INP no supera los 200 ms. El rango por encima de 200 a 500 ms requiere mejora; por encima de 500 ms se considera pobre. Para evaluar un sitio, el percentil 75 de visitas se utiliza por separado en dispositivos móviles y de escritorio.
La cola de mensajes puede contribuir a esta latencia cuando su procesamiento ocupa el hilo principal e interfiere con la entrada o la representación. Pero el tiempo de respuesta del Worker no puede considerarse automáticamente INP.
Volvamos a la búsqueda: la letra ingresada puede aparecer inmediatamente y los resultados se actualizarán más tarde. El siguiente fotograma ya se ha mostrado, aunque el trabajo útil aún no se ha completado. En tal escenario, mida la respuesta a las entradas y el tiempo hasta los resultados reales por separado. Un indicador de carga rápida no prueba que la búsqueda en sí se haya vuelto más rápida.
Comprobación de INP y análisis de JavaScript en Milten
La comprobación de INP ayuda a investigar retrasos en una prueba. Seleccione la página con la acción problemática: menú, catálogo, formulario o carrito. Compruebe qué interacciones se realizaron y qué causas se detectaron. La conclusión se limita a esa prueba y sus condiciones.
JS Scanner analiza JavaScript mientras carga una sola página en Chromium, sin hacer clic ni desplazarse. Muestra tamaños y cargas de scripts, ejecución de código, tareas de larga duración, errores y scripts con un nombre de host diferente. Un mapa de los módulos dentro de los paquetes está disponible si el sitio proporciona mapas fuente.
Compare informes para seleccionar un área para inspeccionar. Un archivo pesado en JS Scanner puede explicar la carga al iniciar la página, pero su presencia aún no demuestra el motivo del clic lento. El comportamiento después de la carga debe reproducirse por separado. Ambas herramientas le ayudan a limitar su búsqueda; no proporcionan un rastro de cada mensaje entre todas las ventanas y Workers.
Es posible que se necesite código que no se ejecutó durante la carga después de un clic o en otro estado de página. Verifique estos scripts antes de eliminarlos. Un script con otro nombre de host tampoco es necesariamente superfluo: la propia CDN del proyecto puede entrar en este grupo.
Cómo encontrar la causa de un INP malo
- Grabe los pasos de reproducción. Especifique el estado de la página, el dispositivo y la interfaz. Por ejemplo: abra un catálogo, ingrese rápidamente una consulta y luego seleccione un filtro.
- Si hay un RUM o CrUX, utilice los datos de campo para seleccionar el problema más notable. La prueba de laboratorio no sustituye a las estadísticas de visitas reales.
- Ejecute una verificación INP y haga coincidir la cobertura del informe con la actividad problemática. Si no ha sido reproducido, examínelo por separado en el navegador.
- Explore la carga de JavaScript a través de JS Scanner. Seleccione archivos sospechosos y tareas largas que puedan superponerse con retraso.
- Registre el escenario problemático en DevTools. Para un trabajador o iframe, realice un seguimiento del mensaje que se envía, el procesamiento iniciado, la respuesta y la actualización de la pantalla. Los ID de solicitud ayudarán a distinguir la respuesta a la entrada anterior de la actual.
- Después de solucionarlo, repita los mismos pasos con el mismo dispositivo, CPU y configuración de red. Compare varias ejecuciones y luego verifique los datos de campo a medida que se acumulan.
Qué cambiar para optimizar INP
La optimización de INP empieza por reducir el trabajo que retrasa el siguiente fotograma. Reduzca el trabajo de los manejadores síncronos, divida las tareas largas y permita que el navegador muestre una respuesta visual antes de los cálculos opcionales.
En una aplicación con Workers, compruebe si todo el trabajo enviado es necesario. En las búsquedas, puede agrupar actualizaciones frecuentes y descartar resultados obsoletos. Ajuste el intervalo de debounce al comportamiento de la interfaz: si es demasiado largo, también retrasará la búsqueda.
Reduzca los mensajes a la información que el destinatario necesita. En lugar de todo el directorio, después de cada cambio de filtro, a veces basta con pasar los parámetros de consulta. Para datos binarios adecuados, considere objetos transferibles. Considere la transferencia de propiedad: el búfer transferido deja de estar disponible para el remitente.
Pruebe cada hipótesis por separado. Si ha reducido el tamaño del mensaje, compare el tiempo de transmisión y procesamiento. Si movió el cálculo, verifique la respuesta de la interfaz y el tiempo hasta el resultado. Esto mostrará qué edición ayudó.
¿Es posible ver automáticamente la sobrecarga de la cola?
La propuesta de WICG plantea ahora ampliar la API Long Animation Frames para detectar una congestión sostenida de las colas de tareas en documentos y Workers. La medición de cada mensaje y de los costes de serialización no forma parte del alcance actual.
La propuesta es experimental. No haga depender el diagnóstico de los primeros ejemplos de observación de delayed-message. Empiece por un recorrido reproducible, INP Scanner, análisis de JavaScript y una grabación en DevTools. Siga una acción lenta hasta el resultado que necesita el usuario.
