web-performance
SpeedCurve advierte del impacto de actualizar los agentes de rendimiento
Una actualización de los agentes sintéticos de SpeedCurve muestra cómo los cambios de navegador, Lighthouse y hardware pueden alterar las métricas sin que cambie la aplicación.
SpeedCurve ha descrito el efecto de una actualización de sus agentes de pruebas sintéticas que incorporó nuevas máquinas virtuales y versiones más recientes de Chrome, Firefox y Lighthouse. El cambio es útil para cualquier equipo que utilice presupuestos de rendimiento o series históricas: una variación de la plataforma de medición puede mover las métricas aunque el código de la aplicación permanezca intacto.
La actualización llevó los agentes a Chrome 148, Firefox 153 y Lighthouse 13.4.1. SpeedCurve advierte de que las comparaciones entre periodos pueden verse afectadas por optimizaciones del navegador, cambios de metodología y diferencias en el hardware de ejecución. Por eso recomienda establecer una línea base antes de cambiar el entorno y revisar de nuevo los presupuestos después de la migración.
Entre los cambios con posible impacto aparecen varias mejoras de plataforma. Chrome 148 incorpora carga diferida para vídeo, que puede reducir las descargas en páginas que usan el atributo correspondiente. Una corrección de Chrome 146 también modificó un problema de medición de Largest Contentful Paint en el que, en ciertos casos, se registraba como elemento principal una imagen que todavía no se había pintado.
En Firefox, SpeedCurve señala mejoras en HTTP/3, soporte para Compression Dictionaries y disponibilidad de la Scheduler API, incluida scheduler.yield. Estas capacidades pueden reducir el tamaño de algunas respuestas o permitir que una aplicación ceda el control del hilo principal con mayor precisión. El resultado no es automáticamente una mejora uniforme: depende del código, de la negociación de protocolos y de los perfiles de prueba.
También cambió la infraestructura. La plataforma pasó de instancias c5.large a c6a.large de Amazon EC2 por restricciones de capacidad en algunas regiones. Para conservar un perfil de CPU comparable, SpeedCurve limitó el procesador en las pruebas de escritorio. Aun así, el cambio produjo una mejora aproximada del 12 % en Total Blocking Time en el percentil 75 del perfil Mobile Medium, mientras que LCP y CLS se mantuvieron prácticamente estables en su conjunto de sitios.
La lección es metodológica. TBT, LCP y CLS no son lecturas aisladas del producto: también reflejan navegador, Lighthouse, sistema operativo, hardware, red y configuración del agente. Las pruebas de rendimiento necesitan versionar esos componentes, separar cambios del sistema de regresiones reales y documentar cualquier ruptura de comparabilidad. Sin esa disciplina, un dashboard puede convertir una modificación del termómetro en un falso diagnóstico de la aplicación.