Page speed checker
Measures real page load times: 1.5s counts as fast, 3s is the acceptable ceiling.
What TMOD checks
- Actual measured load time for the first ten pages of the crawl, recorded live rather than estimated from page weight. Ten is a deliberate ceiling: measuring every page of a large site means hundreds of extra requests against your server to sharpen a number that ten already answers.
- A 1.5 second threshold for fast and a 3 second ceiling for acceptable, applied per page.
- Up to five pages measured concurrently, so the measurements reflect your server under mild parallel load rather than a single isolated request.
- A result per measured page rather than one site average, so a fast homepage cannot hide the slower templates behind it.
Why it matters
Speed affects two different things and they are worth separating. It is a direct, confirmed ranking factor, though a small one, it rarely decides a competitive result. It also affects whether visitors stay, and that effect is much larger and much more immediate.
Measuring every crawled page rather than one URL matters more than it sounds. Homepages are usually the most optimised page on a site. The slow pages are article pages with unoptimised images, category pages loading fifty thumbnails, and anything with a heavy embed. Those are the pages search traffic actually lands on.
Third-party scripts are the most common cause of a slow site that looks well-built. Every analytics tag, chat widget, ad script, font provider and embed adds a connection and a blocking request, and the total is usually much worse than any individual owner assumed.
How to fix it
01Fix images first
On most content sites images are the majority of transferred bytes and the largest single win. Serve WebP or AVIF, size them for their actual display dimensions, set explicit width and height, and lazy-load everything below the fold. The content audit checks the same images for alt text, so the two passes are usually one job.
02Audit your third-party scripts
List every external script and justify it. Most sites carry tags for tools nobody uses any more. Those that survive should load with async or defer, and anything not needed for the first screen should load after it.
03Cache aggressively
Static assets should carry long cache lifetimes with content-hashed filenames. HTML should be cached at the CDN edge where it can be. For most sites this is a configuration change with a much larger effect than any code change.
04Look at server response time before the front end
If the initial HTML takes more than half a second to arrive, no front-end optimisation will save the page. That is a hosting, database or application problem, and it is the ceiling everything else works under.
Where the seconds actually go
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.
Measuring so the number means something
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.
Questions
How does this differ from PageSpeed Insights?
PageSpeed Insights runs one URL in a simulated environment and produces a composite score with lab and field data. This measures actual wall-clock load time for every page we crawl, from our servers, and reports each one. It is a wider, shallower measurement: better for finding which pages are slow, worse for diagnosing why a specific page is slow. Use this to find them, then PageSpeed Insights on the worst offender.
My site is fast for me but reports as slow.
You are almost certainly measuring a warm cache on a fast connection, geographically near your server. Our measurement is a cold request from elsewhere. That is closer to what a first-time visitor experiences, which is the visit that matters most.
Does the 3 second ceiling come from Google?
Not as an official threshold. It reflects consistent findings across many studies that abandonment rises sharply past roughly three seconds. Google's own formal targets are the Core Web Vitals, which are checked separately, LCP under 2.5 seconds being the closest equivalent.