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 crosses into "poor".

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 (the same allowance used by Site Monitoring). A run captures up to about 15 samples.
• It runs on manual test runs. Scheduled runs do not capture Core Web Vitals yet.

Enabling it

1. Open a general cloud load test and go to its configuration.
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. Start the test as usual.

Reading the results

When the run finishes, open its results page. A Page speed under load panel appears once samples have been collected.

• 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: the percentage difference between them
  • Crossing point: the virtual user count at which the vital first crossed the "poor" threshold, for example "LCP crossed 2.5s at ~620 VU"
• The samples table lists every capture with its 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.
• Measurements use real observed conditions, with no simulated network throttling, so the degradation you see comes from the system under load rather than an emulated connection.
• 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.