Page Speed Under Load Trends

Überblick

Page Speed Under Load Trends zeigt, wie sich die Core Web Vitals einer Seite unter Spitzenlast über die letzten Läufe desselben Tests entwickelt haben. Während die Ansicht This run beantwortet, "wie hat die Seite in diesem einen Lauf unter Last abgeschnitten", beantwortet die Ansicht Over runs eine andere Frage: "wird unsere Geschwindigkeit unter Last über die Releases hinweg besser oder schlechter, und wann begann sie zu driften?"

Sie erreichen sie über den Reiter Speed Under Load auf der Ergebnisseite eines Lasttests. Nutzen Sie den Umschalter This run | Over runs oben und wechseln Sie zu Over runs.

Für jede der vier Vitals wird ein Punkt pro Lauf dargestellt:

• LCP (Largest Contentful Paint)
• CLS (Cumulative Layout Shift)
• FCP (First Contentful Paint)
• TTFB (Antwortzeit des Servers)

Jeder Punkt ist der Wert unter Spitzenlast für diesen Lauf, also der Wert, der bei der höchsten erreichten Anzahl virtueller Nutzer gemessen wurde. Es ist genau die Zahl, die auch das Pass/Fail-Budget bewertet, sodass die Trendlinie und das Budget-Badge niemals zwei verschiedene Geschichten erzählen können.

Warum es wichtig ist

Ein einzelner Lauf, und selbst ein Budget, sagt Ihnen nur etwas über diesen einen Lauf: bestanden oder nicht bestanden. Er kann Ihnen nicht sagen, dass Ihr LCP unter Last über die letzten vier Releases um 400 ms gestiegen ist, während jeder dieser Läufe trotzdem bestanden hat. Dieses langsame Driften ist Lauf für Lauf unsichtbar und im Trend offensichtlich. Die Ansicht Over runs macht es sichtbar, sodass Sie eine Regression erkennen, bevor sie schließlich ein Budget reißt, und sie dem Release zuordnen können, das sie verursacht hat.

So lesen Sie ihn

• Die x-Achse sind Läufe, beschriftet mit der Laufnummer (zum Beispiel #4, #5), der älteste links.
• Die y-Achse ist die Vital in ihrer eigenen Einheit (ms für LCP, FCP und TTFB; ein einheitenloser Wert für CLS).
• Jeder Punkt ist der Spitzenlastwert eines Laufs. Es erscheinen nur Läufe, die tatsächlich Core Web Vitals gemessen haben; Läufe, in denen die Funktion aus war, werden übersprungen statt als Lücken gezeichnet.
• Über jedem Diagramm vergleicht eine einzeilige Zusammenfassung den letzten Lauf mit dem Median der jüngsten Läufe, zum Beispiel "LCP under load up 18% vs recent runs" oder "down 15% vs recent runs". Eine Änderung von weniger als ein paar Prozent gilt als "stable".

Wenn Sie ein Budget gesetzt haben

Wenn der Test ein Page-Speed-Budget hat, ergänzt der Trend eine gestrichelte Budgetlinie und färbt jeden Punkt:

• grün, wenn die Spitze dieses Laufs innerhalb des Budgets lag,
• rot, wenn sie über dem Budget lag.

Wenn die letzten Läufe über dem Budget lagen, sagt Ihnen die Zusammenfassung auch, wie lange schon, zum Beispiel "over budget for the last 2 runs". Ohne Budget sind die Punkte neutral gefärbt und es wird keine Linie gezeichnet.

Voraussetzungen

• Ein General (URL) Cloud-Lasttest mit gemessenem Page Speed Under Load. Der Trend enthält nur Läufe, die Core Web Vitals erfasst haben; diese Funktion ist nicht für JMeter- oder k6-Tests verfügbar.
• Mindestens zwei Läufe, die Core Web Vitals gemessen haben. Bei weniger als zwei zeigt die Ansicht einen kurzen Hinweis statt Diagramme, denn ein Trend braucht mehr als einen Punkt.
• Verwenden Sie Runs to show, um zu wählen, wie viele der letzten Läufe einbezogen werden (Standard 10, bis zu 50), und dann Reload.

Trends und Budgets zusammen

Budgets und Trends beantworten zwei Hälften derselben Frage:

• Ein Budget sagt Ihnen, ob dieser Lauf seine Core Web Vitals unter Last nicht bestanden hat, und kann einen Lauf in der CI blockieren.
• Der Trend sagt Ihnen, wann die Verschlechterung begann, über die Läufe hinweg, sodass Sie die Richtung verstehen und wissen, welches Release sie bewegt hat.

Setzen Sie ein Budget, um Fehler zu erkennen, und lesen Sie den Trend, um sie zu verstehen.

Einen Lauf aus der CI taggen

Trendpunkte sind viel nützlicher, wenn Sie erkennen können, zu welchem Release jeder Punkt gehört. Es gibt zwei Wege, einem Lauf eines general (URL) Cloud-Lasttests ein Release-Tag zuzuordnen:

Beim Start taggen (ein Schritt)

Wenn Ihre Pipeline Lasttests bereits aus der CI heraus startet, fügen Sie dem execute-Aufruf, den Sie schon verwenden, zwei zusätzliche Parameter hinzu:

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 — eine kurze Bezeichnung, zum Beispiel eine Version (v2.3.1) oder ein Commit-SHA. Sie wird zur Beschriftung des Punkts im Over-runs-Trend.
• releaseUrl (optional) — ein Link, den der Punkt beim Klick öffnet, zum Beispiel die Release Notes oder den CI-Build, der den Lauf ausgelöst hat.

Das ist der einstufige CI-Weg, dieselbe Idee wie --tag bei k6 run: Der Lauf wird genau wie zuvor ausgeführt, und das Tag wird gespeichert, sobald der Lauf eine testrunid erhalten hat.

Einen bestehenden Lauf taggen (oder erneut taggen)

Um einen Lauf nachträglich zu taggen oder ein bereits gesetztes Tag zu korrigieren oder zu löschen, rufen Sie mit Ihrem API-Schlüssel den eigenständigen Annotation-Endpunkt auf:

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

• Senden Sie ein leeres label, um das Tag von diesem Lauf zu entfernen.
• url ist optional, genau wie releaseUrl oben.

In beiden Fällen zeigt der Punkt im Over-runs-Trend nach dem Taggen einen kleinen Marker mit der Beschriftung, und Tooltip sowie Klick-Link funktionieren unabhängig davon, welcher Weg das Tag gesetzt hat.