Page Speed
Page Speed measures how long your whole page takes to load — the HTML document plus the CSS, JavaScript, images and fonts it pulls in — and explains the score it gives you. It is an add-on to an existing HTTP check, not a second check.
Why it differs from the response time you already see
Your HTTP check measures one request: the HTML document. Nothing else. That is the right number for "is the server answering, and how fast", and it is what your uptime, SLA and response-time charts are built on.
It is not what your visitors experience. A browser fetches the document and then dozens more resources. On our own production site the gap is stark: the same page loads in 0.9 s from France and 6.3 s from San Jose, while the uptime check reports both in the 0–100 ms bucket. The uptime check is not wrong — it is answering a different question. Page Speed answers the visitor's question.
Same page, same moment
It never marks your site down
Page Speed cannot take your site DOWN
A slow page is never an outage. Page Speed never changes a check's UP/DOWN status, never enters uptime or SLA, never opens an incident and never pages on-call. It cannot: the results are submitted on their own endpoint that has no path to a check's status at all.
Two reasons this is deliberate. Page Speed is sampled hourly at most while uptime is sampled every minute, so a single slow sample would poison an hour of SLA. And nobody wants a 3 a.m. page because a colleague uploaded a large image.
If you do want "slow = alert" on your service's response, that is the response-time threshold on the HTTP check — a separate, per-minute signal.
What you get
- Score and grade (0–100, A–F) — rules-based and deterministic, not a black box.
- Four headline numbers — load time, TTFB, total page size, request count.
- Content-type breakdown — how many bytes are HTML, CSS, JS, images, fonts.
- Every grading rule with its reason — "3 text assets not gzipped", and what it cost you. Passed rules are listed too.
- Waterfall — each resource with its start offset and duration. Large pages are capped at the top 100 resources by size, and the panel tells you when that happened.
- History — load time and score over time, per location.
Locations and cadence (and why locations cost money)
A Page Speed run pulls the whole page from your server — roughly 2 MB and 70 requests, versus tens of KB for an uptime check. That is 50–100× heavier, and every enabled location runs its own full run. Ten locations at hourly cadence is around 480 MB and 16 800 requests a day pulled from a single site. So locations are a paid lever: the people generating the load are the people paying for it.
| Plan | Page-speed locations | Fastest cadence |
|---|---|---|
| Free / Basic | 1 | Every 24 hours |
| Pro | 3 | Every 6 hours |
| Business | 5 | Every hour |
| Enterprise | All locations | Every hour |
When you switch Page Speed on, you choose the locations — we never choose for you, and we never quietly keep "the first few" that fit your plan. The location is whose experience the number describes: the same page can load in 0.9 s from France and 6.3 s from San Jose. A measurement from a continent your customers are not on is worse than no measurement, because it still looks authoritative. So the check will not save until you have ticked at least one location, and if a plan change ever leaves you over your limit, we ask you to pick again rather than dropping locations on your behalf.
Page-speed locations are separate from your geo locations
Restricting Page Speed to one location does not reduce your uptime coverage. Keep monitoring uptime from all ten locations and measure page speed from the one your customers are in. (The reverse does not hold: a location you have excluded from geo monitoring never receives the check, so it cannot run Page Speed either — which is why it is not offered in the picker.)
Budgets
Three optional thresholds. Leave one empty and that rule is off:
- Score below — e.g. alert if the grade drops under 80.
- Load time above — e.g. alert over 3000 ms.
- Page size above — e.g. alert over 2048 KB.
Budget alerts are informational and edge-triggered. You get one notification when a budget is crossed, and one when it recovers — not one every hour for as long as the site stays slow. They go to your notification channels (email/Slack); they do not open an incident, do not page on-call, and do not touch escalation.
What Page Speed does not do
The checker is browserless by design: it fetches the document, parses the HTML, and fetches what the HTML references. That keeps a run cheap enough to offer from ten locations. It also means:
- No Core Web Vitals (LCP, CLS, INP) — those need a real browser engine.
- No JavaScript-injected resources — a resource that only appears after your JS runs is not fetched, so it is not counted.
- No screenshots or filmstrip — again, a browser thing.
For reference: Pingdom's Page Speed check has none of these three either. What you get here is the same class of measurement — full page load, size, requests, waterfall, an explainable grade — from every location you monitor from.