Page Speed Under Load Trends

Vue d'ensemble

Page Speed Under Load Trends montre comment les Core Web Vitals sous charge maximale d'une page ont évolué au fil des dernières exécutions du même test. Là où la vue This run répond à "comment la page s'est comportée sous charge lors de cette exécution précise", la vue Over runs répond à une autre question : "notre vitesse sous charge s'améliore-t-elle ou se dégrade-t-elle d'une version à l'autre, et quand a-t-elle commencé à dériver ?"

Vous y accédez depuis l'onglet Speed Under Load de la page de résultats d'un test de charge. Utilisez le sélecteur This run | Over runs en haut et passez à Over runs.

Pour chacun des quatre vitals, un point est tracé par exécution :

• LCP (Largest Contentful Paint)
• CLS (Cumulative Layout Shift)
• FCP (First Contentful Paint)
• TTFB (temps de réponse du serveur)

Chaque point est la valeur sous charge maximale de cette exécution, c'est-à-dire la valeur mesurée au plus grand nombre d'utilisateurs virtuels atteint par l'exécution. C'est exactement le nombre que le budget de réussite/échec évalue, de sorte que la ligne de tendance et le badge de budget ne peuvent jamais raconter deux histoires différentes.

Pourquoi c'est important

Une seule exécution, et même un budget, ne vous renseigne que sur cette exécution : réussite ou échec. Elle ne peut pas vous dire que votre LCP sous charge a augmenté de 400 ms au fil des quatre dernières versions alors que chacune de ces exécutions réussissait encore. Cette lente dérive est invisible exécution par exécution et évidente sur une tendance. La vue Over runs la rend visible, pour que vous repériez une régression avant qu'elle ne finisse par dépasser un budget, et que vous l'associez à la version qui l'a introduite.

Comment la lire

• L'axe des x correspond aux exécutions, étiquetées par numéro d'exécution (par exemple #4, #5), la plus ancienne à gauche.
• L'axe des y correspond au vital dans sa propre unité (ms pour LCP, FCP et TTFB ; un score sans unité pour CLS).
• Chaque point est la valeur sous charge maximale d'une exécution. Seules apparaissent les exécutions qui ont réellement mesuré les Core Web Vitals ; les exécutions où la fonction était désactivée sont ignorées plutôt que dessinées comme des trous.
• Au-dessus de chaque graphique, un résumé sur une ligne compare la dernière exécution à la médiane des exécutions récentes, par exemple "LCP under load up 18% vs recent runs" ou "down 15% vs recent runs". Une variation inférieure à quelques pour cent est lue comme "stable".

Si vous avez défini un budget

Lorsque le test possède un budget Page Speed, la tendance ajoute une ligne de budget en pointillés et colore chaque point :

• vert lorsque le pic de cette exécution était dans le budget,
• rouge lorsqu'il dépassait le budget.

Si les dernières exécutions ont dépassé le budget, le résumé vous indique aussi depuis combien de temps, par exemple "over budget for the last 2 runs". Sans budget, les points ont une couleur neutre et aucune ligne n'est tracée.

Prérequis

• Un test de charge cloud general (URL) avec Page Speed Under Load mesuré. La tendance n'inclut que les exécutions ayant capturé les Core Web Vitals ; cette fonction n'est pas disponible pour les tests JMeter ou k6.
• Au moins deux exécutions ayant mesuré les Core Web Vitals. En dessous de deux, la vue affiche une courte note au lieu des graphiques, car une tendance a besoin de plus d'un point.
• Utilisez Runs to show pour choisir combien d'exécutions récentes inclure (10 par défaut, jusqu'à 50), puis Reload.

Tendances et budgets ensemble

Les budgets et les tendances répondent à deux moitiés de la même question :

• Un budget vous dit si cette exécution a échoué à ses Core Web Vitals sous charge, et peut bloquer une exécution en CI.
• La tendance vous dit quand la dégradation a commencé, au fil des exécutions, pour que vous compreniez la direction et quelle version l'a fait bouger.

Définissez un budget pour détecter les échecs, et lisez la tendance pour les comprendre.

Marquer une exécution depuis la CI

Les points de tendance sont bien plus utiles dès que vous pouvez savoir à quelle version chacun appartient. Il existe deux façons d'associer un tag de version à une exécution d'un test de charge cloud general (URL) :

Marquer au lancement (une seule étape)

Si votre pipeline lance déjà des tests de charge depuis la CI, ajoutez deux paramètres supplémentaires au même appel d'exécution que vous utilisez déjà :

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 — une étiquette courte, par exemple une version (v2.3.1) ou un SHA de commit. Elle devient l'étiquette du point sur la tendance Over runs.
• releaseUrl (facultatif) — un lien que le point ouvre au clic, par exemple les notes de version ou le build CI qui a déclenché l'exécution.

C'est le chemin en une étape depuis la CI, la même idée que passer --tag à k6 run : l'exécution se lance exactement comme avant, et le tag est enregistré dès que l'exécution reçoit un testrunid.

Marquer (ou re-marquer) une exécution existante

Pour marquer une exécution après coup, ou pour corriger ou effacer un tag déjà posé, appelez le endpoint d'annotation autonome avec votre clé 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

• Envoyez un label vide pour retirer le tag de cette exécution.
• url est facultatif, comme releaseUrl ci-dessus.

Dans les deux cas, une fois l'exécution marquée, son point sur la tendance Over runs affiche un petit marqueur avec l'étiquette, et l'infobulle ainsi que le lien au clic fonctionnent de la même façon quel que soit le chemin utilisé.