Page speed checker

A three second budget spends faster than it sounds. DNS, the TLS handshake and the first byte from your server are typically 300 to 700 milliseconds before a single pixel is possible, and on shared hosting with an uncached database query behind it, that alone can be two seconds. Nothing you do in the browser recovers time spent here, which is why server response is the first number to look at.

Then comes render blocking. Every stylesheet and every synchronous script in the head is a round trip the browser waits for before it draws anything. Web fonts extend it: a font loaded without a fallback strategy holds text invisible until it arrives. Both are configuration rather than code, and both are routinely worth a second.

Images are usually the largest transfer and the easiest win, since a hero photograph exported straight from a camera can outweigh the entire rest of the page. Third-party scripts are the least visible: analytics, chat, ad tags, consent platforms and embeds each add a connection, and a consent script in particular is loaded early by design because it has to run before anything it gates. That makes it the one third-party cost you cannot defer, and the one worth choosing carefully.

Speed is not a property of a site, it is a property of a request. The same page is fast on a warm cache over fibre a mile from the server and slow on a cold cache over a phone network on the other side of the world. Both numbers are true and only one describes a first-time visitor, which is the visit that decides whether there is a second.

What we report is a cold request from our servers to every crawled page, which makes it comparable across your own site: the useful reading is which pages are slow relative to the rest, not the absolute figure. Field data works the opposite way, aggregating real visits at the 75th percentile over a rolling window, so it is the better answer to whether visitors experience the site as slow and the worse answer to which template caused it.

Use them in that order. Find the slow pages here, confirm on a phone profile rather than a laptop, and only then open a single-URL tool on the worst offender to see what it is waiting for. The technical audit measures Core Web Vitals alongside this, and the mobile checks cover the other half of what a phone visitor runs into.

Here is a realistic breakdown for an article page that measures 7.2 seconds, the kind of number that gets a page into this report's red band. First byte arrives at 1.9 seconds, shared hosting running an uncached CMS, every request rebuilding the page from the database. DNS and the TLS handshake account for another 0.4. The images cost 2.8 seconds, led by a 3.4 MB hero photograph uploaded straight from a phone and displayed at 800 pixels wide. Scripts add 1.3, a consent platform, analytics, two ad tags and an abandoned heatmap trial from last year. A web font holds the text invisible for the final 0.8.

The fixes, in order of cost. Turning on page caching moves first byte from 1.9 seconds to around 0.3, and it is a plugin setting or a hosting toggle rather than code. Re-exporting the hero at its display size in WebP turns 3.4 MB into roughly 140 KB, and doing the same through the media library settings covers every future upload. Neither change took an hour yet together they recovered more than four seconds.

The script list gets shorter rather than faster. The heatmap tag nobody has looked at since the trial ended is deleted. Analytics and the ad tags get defer, so they stop standing between the visitor and the first paint. The font gets a swap strategy so text renders in a fallback while it loads. The consent script is the one that has to stay early, since everything it gates waits for it, which is a reason to pick a light one rather than a reason to give up.

The page re-measures at roughly 2.1 seconds, and the more important number is the site's, because the article template served every post: one afternoon moved dozens of URLs out of the slow band together. That is the general pattern this check surfaces, slow pages cluster by template, not by page, and the Core Web Vitals pass afterwards confirms the fix from the metric Google actually formalises.