Page Speed Under Load Trends

Visión general

Page Speed Under Load Trends muestra cómo han evolucionado los Core Web Vitals bajo carga máxima de una página a lo largo de las últimas ejecuciones de la misma prueba. Mientras la vista This run responde a "cómo rindió la página bajo carga en esta ejecución concreta", la vista Over runs responde a otra pregunta: "¿nuestra velocidad bajo carga mejora o empeora entre versiones, y cuándo empezó a desviarse?"

Se accede desde la pestaña Speed Under Load de la página de resultados de una prueba de carga. Usa el conmutador This run | Over runs de la parte superior y cambia a Over runs.

Para cada uno de los cuatro vitals se traza un punto por ejecución:

• LCP (Largest Contentful Paint)
• CLS (Cumulative Layout Shift)
• FCP (First Contentful Paint)
• TTFB (tiempo de respuesta del servidor)

Cada punto es la lectura bajo carga máxima de esa ejecución, es decir, el valor medido en el mayor número de usuarios virtuales que alcanzó la ejecución. Es exactamente el mismo número que evalúa el presupuesto de aprobado/fallado, de modo que la línea de tendencia y la insignia de presupuesto nunca pueden contar dos historias distintas.

Por qué importa

Una sola ejecución, e incluso un presupuesto, solo te dice algo de esa ejecución: si aprobó o falló. No puede decirte que tu LCP bajo carga ha subido 400 ms a lo largo de las últimas cuatro versiones mientras todas esas ejecuciones seguían aprobando. Esa deriva lenta es invisible ejecución por ejecución y evidente en una tendencia. La vista Over runs la hace visible, para que detectes una regresión antes de que acabe superando un presupuesto, y la asocies a la versión que la introdujo.

Cómo leerla

• El eje x son ejecuciones, etiquetadas por número de ejecución (por ejemplo #4, #5), la más antigua a la izquierda.
• El eje y es el vital en su propia unidad (ms para LCP, FCP y TTFB; una puntuación sin unidad para CLS).
• Cada punto es el valor bajo carga máxima de una ejecución. Solo aparecen las ejecuciones que realmente midieron Core Web Vitals; las ejecuciones en las que la función estaba desactivada se omiten en lugar de dibujarse como huecos.
• Sobre cada gráfico, un resumen de una línea compara la última ejecución con la mediana de las ejecuciones recientes, por ejemplo "LCP under load up 18% vs recent runs" o "down 15% vs recent runs". Un cambio menor que un pequeño porcentaje se lee como "stable".

Si has fijado un presupuesto

Cuando la prueba tiene un presupuesto de Page Speed, la tendencia añade una línea de presupuesto discontinua y colorea cada punto:

• verde cuando la máxima de esa ejecución estaba dentro del presupuesto,
• rojo cuando estaba por encima del presupuesto.

Si las últimas ejecuciones han estado por encima del presupuesto, el resumen también te dice desde hace cuánto, por ejemplo "over budget for the last 2 runs". Sin presupuesto, los puntos tienen un color neutro y no se dibuja ninguna línea.

Requisitos

• Una prueba de carga en la nube general (URL) con Page Speed Under Load medido. La tendencia solo incluye ejecuciones que capturaron Core Web Vitals; esta función no está disponible en pruebas JMeter ni k6.
• Al menos dos ejecuciones que hayan medido Core Web Vitals. Con menos de dos, la vista muestra una nota breve en lugar de gráficos, porque una tendencia necesita más de un punto.
• Usa Runs to show para elegir cuántas ejecuciones recientes incluir (por defecto 10, hasta 50), y luego Reload.

Tendencias y presupuestos juntos

Los presupuestos y las tendencias responden a dos mitades de la misma pregunta:

• Un presupuesto te dice si esta ejecución falló sus Core Web Vitals bajo carga, y puede bloquear una ejecución en CI.
• La tendencia te dice cuándo empezó a degradarse, a lo largo de las ejecuciones, para que entiendas la dirección y qué versión la movió.

Fija un presupuesto para detectar fallos, y lee la tendencia para entenderlos.

Etiqueta una ejecución desde CI

Los puntos de la tendencia son mucho más útiles cuando puedes saber a qué versión pertenece cada uno. Hay dos formas de asociar una etiqueta de versión a una ejecución de una prueba de carga en la nube general (URL):

Etiquetar al lanzar (un solo paso)

Si tu pipeline ya lanza pruebas de carga desde CI, añade dos parámetros adicionales a la misma llamada de ejecución que ya usas:

POST /api/v1/loadtests/newtest/execute?apikey=<key>&testrunname=<name>&testrunid=<id>&releaseTag=v2.3.1&releaseUrl=https://github.com/your-org/your-repo/releases/tag/v2.3.1

• releaseTag — una etiqueta corta, por ejemplo una versión (v2.3.1) o un SHA de commit. Se convierte en la etiqueta del punto en la tendencia Over runs.
• releaseUrl (opcional) — un enlace que el punto abre al hacer clic, por ejemplo las notas de la versión o la build de CI que disparó la ejecución.

Este es el camino de un solo paso desde CI, la misma idea que pasar --tag a k6 run: la ejecución se lanza exactamente igual que antes, y la etiqueta se guarda en cuanto la ejecución recibe un testrunid.

Etiquetar (o volver a etiquetar) una ejecución existente

Para etiquetar una ejecución a posteriori, o para corregir o borrar una etiqueta que ya pusiste, llama al endpoint de anotación independiente con tu clave de API:

POST /api/test/general/run-annotation
testrunname=<name>
testrunid=<id>
label=v2.3.1
url=https://github.com/your-org/your-repo/releases/tag/v2.3.1

• Envía un label vacío para quitar la etiqueta de esa ejecución.
• url es opcional, igual que releaseUrl arriba.

De cualquiera de las dos formas, una vez etiquetada, el punto de la ejecución en la tendencia Over runs muestra un pequeño marcador con la etiqueta, y el tooltip y el enlace al hacer clic funcionan igual sin importar qué camino la estableció.