Page Speed Under Load Trends

Overview

Page Speed Under Load Trends shows how the peak-load Core Web Vitals of a page have moved across the last runs of the same test. Where the This run view answers "how did the page perform under load in this one run", the Over runs view answers a different question: "is our under-load speed getting better or worse across releases, and when did it start to drift?"

You reach it from the Speed Under Load tab of a load-test result page. Use the This run | Over runs toggle at the top and switch to Over runs.

For each of the four vitals it plots one point per run:

• LCP (Largest Contentful Paint)
• CLS (Cumulative Layout Shift)
• FCP (First Contentful Paint)
• TTFB (server response time)

Each point is the peak-load reading for that run, that is the value measured at the highest virtual-user count the run reached. It is the exact same number the pass/fail budget grades, so the trend line and the budget badge can never tell you two different stories.

Why it matters

A single run, and even a budget, only tells you about that one run: did it pass or fail. It cannot tell you that your under-load LCP has crept up 400ms over the last four releases while every one of those runs still passed. That slow drift is invisible run by run and obvious on a trend. The Over runs view makes it visible, so you can catch a regression before it finally trips a budget, and tie it to the release that introduced it.

How to read it

• The x-axis is runs, labelled by run number (for example #4, #5), oldest on the left.
• The y-axis is the vital in its own unit (ms for LCP, FCP and TTFB; an unitless score for CLS).
• Each point is one run's peak-load value. Only runs that actually measured Core Web Vitals appear; runs where the feature was off are skipped rather than drawn as gaps.
• Above each chart, a one-line summary compares the latest run against the median of the recent runs, for example "LCP under load up 18% vs recent runs" or "down 15% vs recent runs". A change smaller than a few percent reads as "stable".

If you have set a budget

When the test has a Page Speed budget, the trend adds a dashed budget line and colours each point:

• green when that run's peak was within budget,
• red when it was over budget.

If the latest runs have been over budget, the summary also tells you for how long, for example "over budget for the last 2 runs". Without a budget the points are a neutral colour and no line is drawn.

Requirements

• A general (URL) cloud load test with Page Speed Under Load measured. The trend only includes runs that captured Core Web Vitals; this feature is not available on JMeter or k6 tests.
• At least two runs that measured Core Web Vitals. With fewer than two, the view shows a short note instead of charts, because a trend needs more than one point.
• Use Runs to show to choose how many recent runs to include (default 10, up to 50), then Reload.

Trends and budgets together

Budgets and trends answer two halves of the same question:

• A budget tells you whether this run failed its Core Web Vitals under load, and can gate a run in CI.
• The trend tells you when it started degrading, across runs, so you understand the direction of travel and which release moved it.

Set a budget to catch failures, and read the trend to understand them.

Tag a run from CI

Trend points are far more useful once you can tell which release each one belongs to. There are two ways to attach a release tag to a run of a general (URL) cloud load test:

Tag at launch (one step)

If your pipeline already fires load tests from CI, add two extra parameters to the same execute call you use today:

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 — a short label such as a version (v2.3.1) or a commit SHA. It becomes the point's label on the Over runs trend.
• releaseUrl (optional) — a link the point opens when clicked, for example the release notes or the CI build that triggered the run.

This is the one-step CI path, the same idea as passing --tag to k6 run: the run executes exactly as before, and the tag is stored alongside it once the run has been assigned a testrunid.

Tag (or re-tag) an existing run

To tag a run after the fact, or to fix or clear a tag you already set, call the standalone annotation endpoint with your API key:

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

• Send an empty label to remove the tag from that run.
• url is optional, same as releaseUrl above.

Either way, once a run is tagged its point on the Over runs trend shows a small marker with the label, and the tooltip and click-through link work the same regardless of which path set it.