When should you use Page loads fast enough?
page-load-speed · functional · recommended
When should you use this check?
Run this on pages where a visitor's patience is the budget — paid landing pages, product pages, signup flows, anywhere a bounce costs you money directly. It times the load from the browser's own clock and names the file that held it up, which makes it useful for the argument as well as the alarm: you get the number and the culprit in the same finding. It is most informative on a schedule, because performance regresses through accumulated asset and tag changes rather than in one visible release.
When should you not?
Do not use it as a substitute for field data. The measurement is a single clean load on a fast connection with nothing cached, so it tells you whether the page is slow by construction, not what your actual visitors experience on their own devices and networks. Skip it on pages behind authentication that the audit cannot reach in a representative state, and on pages whose slowness you already know and have accepted — a heavy interactive tool will fail this every time without teaching you anything new.
What does it inspect?
Measures the page load from the browser's own performance timeline: Largest Contentful Paint, time to first byte, first paint, page weight and a per-resource-type breakdown of bytes and time, plus the heaviest and slowest resources. Only LCP is judged, against the configurable maxLcpMs budget (2500 ms by default); everything else is reported, because the harness measures one unthrottled load and no published threshold settles them. See docs/PAGE-LOAD-SPEED.md.
What does a failure mean?
A failure means the page's largest contentful paint landed later than the target, and the finding names the element or file responsible. Because the run is unthrottled and uncached, a failure here is a strong statement: the page is slow in the most favourable conditions it will ever see, so it is slower for everyone else. A pass is a weaker statement in the other direction — it means nothing structural is wrong, not that real users are having a fast experience.
What are the Standard defaults — and why?
One parameter carries the check: `maxLcpMs`, defaulting to `2500`. That is web.dev's "good" largest-contentful-paint boundary, and it is worth knowing the boundary was defined at the 75th percentile of *field* data while this applies it to a single unthrottled lab load. That is intentional and one-sided: a page that cannot clear the field threshold in laboratory conditions is too slow everywhere, which makes a failure meaningful and a pass deliberately unambitious.
How does an agent call it?
{
"type": "url",
"url": "https://example.com",
"validations": [
"page-load-speed"
]
}
Who governs the Standard?
Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.
Author ArbiterQA · Reviewed by ArbiterQA · 2026-08-14