Page Speed Under Load

Overview

Page Speed Under Load measures Core Web Vitals on one of your pages while a cloud load test runs against it. Instead of seeing only server metrics like response times and error rates, you also see what a real browser experiences as the backend comes under load, and you can read off the virtual user count at which the page experience starts to break down.

While the test ramps up virtual users, LoadFocus loads the page you choose in a real headless browser at intervals and records:

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

Each capture is tagged with the number of virtual users active at that moment, so the results overlay the vital against the load curve on a single timeline.

Why it matters

A load test tells you the server stayed up. It does not tell you whether the page still felt fast to a visitor while it was under load. As the backend saturates, pages get slower to render: LCP climbs, TTFB grows, layout can shift. Page Speed Under Load makes that visible, and the headline it produces is the number that matters most for capacity planning: the virtual user count at which a vital leaves the "good" range.

Requirements

• A general (URL) cloud load test. This feature is available on the standard cloud load test, not on JMeter or k6 tests.
• A Page Speed Monitoring plan. On the free plan the toggle shows an upgrade prompt instead of arming.
• Each captured sample consumes one Page Speed test from your Page Speed Monitoring allowance. A run captures up to about 15 samples.
• It runs on manual test runs. Scheduled runs do not capture Core Web Vitals yet.
• Use a run of at least a few minutes. The cloud browser takes about a minute to start, so a short run can end before it captures anything.

Enabling it

1. Open a general cloud load test and go to its configuration. Under More options, click the Page speed under load row.
2. Turn on Measure Core Web Vitals under load.
3. In Page to measure, enter the page you want measured. It defaults to the first request URL of the test. Use a page that is actually served by the system you are load testing, otherwise the vitals will not reflect the load.
4. Optional: turn on Fail the test when peak-load Core Web Vitals exceed these budgets and set Max LCP (ms), Max CLS, Max FCP (ms) and Max TTFB (ms). Leave a field blank to skip that vital. Each budget is checked against the peak-load reading, the heaviest concurrency the browser sampled.
5. Start the test as usual.

Reading the results

When the run finishes, open its results page and go to the Speed Under Load tab. The Page speed under load panel appears once samples have been collected. The Over runs button switches to the trend across runs, see Page Speed Under Load trends.

• The chart overlays two lines on the run timeline: the virtual user ramp and the selected vital. You can watch the vital rise as load increases.
• The vital selector (LCP, CLS, FCP, TTFB) switches which vital the chart and the tiles display.
• The tiles summarise the run:
  • Baseline: the vital at the lowest load
  • Peak-load: the vital at the highest load
  • Change under load: the percentage difference between them
  • Left good (for example "LCP left good, at ~620 VU"): the virtual user count at which the vital first went above the limit of the "good" range (LCP 2.5 s, CLS 0.1, FCP 1.8 s, TTFB 0.8 s)
• The samples table lists every capture with its time, virtual user count and all four vitals.

Notes

• The virtual user count shown is reconstructed from your test's configured ramp (clients, ramp-up time and steps). It is an accurate approximation of the concurrency at each point rather than the exact realized thread schedule.
• The Core Web Vitals here are lab measurements of the page you specify. They complement, and do not replace, the field data in Page Speed Monitoring.