Free Website Speed Test
Enter a page address and this test measures what your server sends and how the page is built: response time, document size, the real byte weight of your images, how many files the browser has to fetch and what stops it drawing anything. Every finding names the thing to change.
What this checks
Server response time: how long the server takes before it sends a single byte, which is determined by the hosting provider.
HTML document size: the weight of the markup alone, before a single image, stylesheet, or script is fetched.
Sampled page weight: the actual size of a sample of the page assets, measured in bytes rather than assumed, with the heaviest file named.
Request count: how many separate files the page asks for, split into stylesheets, scripts, and images.
Render-blocking files: the stylesheets and scripts that stop the browser from drawing anything until they have all arrived.
Compression: whether the server is sending gzip or Brotli, and how much you are paying per visit if it is not.
Browser caching: cache headers on the page and on a sampled static file, so you know what a returning visitor re-downloads.
Inline CSS and JavaScript: how much of the page is styled and scripts written into the markup, which no browser can cache between pages.
DOM size and nesting depth: the element count and how deep the deepest one sits, which is what makes a page feel sluggish on a mid-range phone.
Image and font cost: oversized images, missing WebP, missing lazy loading, third-party scripts, and how many font families are fetched.
This is not a Lighthouse score, and that is the point
Let us be plain about it, because plenty of tools are not. This test does not use Google PageSpeed Insights and does not produce a Lighthouse score. It does not drive a headless browser, and it does not give you a number out of 100 that you can screenshot for a client.
What it does instead is measure what your server actually sends and how the page is actually built. A Lighthouse score tells you that you are slow. This tells you which file is doing it — the 3.8MB hero image, the eleven stylesheets, the 400KB of CSS written into the document that no browser can cache. One of those you can act on before lunch.
There is a practical reason too. A Lighthouse run is a simulation on a throttled connection, and running the same URL three times gives three different scores, because the emulation is sensitive to load on the machine doing the emulating. Byte counts and cache headers do not move between runs. If a file is 3.8MB, it is 3.8MB whoever asks and whenever.
Why WordPress sites get slow
It is nearly always the same five things, in roughly this order. Images exported straight from a camera or a stock site and uploaded at full size, so a 4000px photograph is displayed in a 600px box. A page builder writing its entire stylesheet into every page rather than serving it as a cacheable file. Plugin sprawl, where twenty plugins each load their own CSS and JavaScript on every page, including the ones that never use them. Shared hosting that has sold the same processor to four hundred other sites. And no caching at all, so WordPress rebuilds the page from the database on every single visit.
None of these is exotic, and none needs a developer to diagnose. They are just invisible from the admin screen, which is why a site can get steadily slower for two years without anyone noticing a single day it got worse.
Several of the findings here are the usual causes of poor Core Web Vitals, even though this tool cannot measure those metrics itself. A huge unoptimised hero image is the classic cause of a bad Largest Contentful Paint. Images with no width and height attributes are the classic cause of Cumulative Layout Shift. A pile of render-blocking and third-party JavaScript is what makes Interaction to Next Paint bad. Fix the causes, and the field data follows, in its own time.
The fix order that actually works
Do not start with the clever things. Start with the ones that apply to every page at once and cannot break anything, then work down to the ones that need testing. Where a caching plugin is concerned, pick one and only one. WP Rocket is the least fiddly paid option, LiteSpeed Cache is excellent and free if your host runs LiteSpeed, and W3 Total Cache is powerful and unforgiving. Running two at once is the most reliable way to make a site slower and harder to debug than it was before.
- Turn on gzip or Brotli. One line of server config, applies to every response, costs nothing in quality.
- Turn on full-page caching and set far-future expiry on CSS, JS, images and fonts. WordPress versions those URLs already, so a long cache never stops an update reaching anyone.
- Fix the images. Resize to the dimensions they are displayed at, convert to WebP, and let ShortPixel or Imagify handle the existing library in bulk. This is usually the single biggest win and the easiest to do.
- Add width and height attributes to every image so the layout stops jumping while they load.
- Cut the request count. Asset CleanUp or Perfmatters let you stop a plugin loading its assets on pages that do not use it — a contact form plugin does not need to load on every blog post.
- Defer the scripts that are not needed for the first screen, then check the site properly afterwards. This is the one step that can break things, so it goes last.
Hosting or plugins: telling the two apart
The report separates them for you, and the dividing line is the server response time. That number is how long your host took to think before sending anything at all — no images involved, no JavaScript, nothing you built. If it is over a second, you have a hosting problem, and no amount of image compression will touch it.
A slow response is usually one of three things: no page caching, so every visit runs the whole of WordPress and a dozen database queries; a plugin doing something expensive on every request, like an uncached external API call or a slider querying the whole post table; or a shared host with too little CPU and too few PHP workers. Caching fixes the first, an audit finds the second, and only moving fixes the third.
If the response is fast but the page still weighs 6MB, the server is doing its job, and the problem is what you are asking it to send. That is a build problem, and it is the cheaper of the two to solve. Moving a heavy, badly built site to expensive hosting makes it a heavy, badly built site on expensive hosting.
What this speed test cannot see
It cannot measure Core Web Vitals. LCP, INP, and CLS are things that happen in a browser, on a real device, with a real person touching the screen — and this test reads what the server sends rather than rendering the page. Any tool that claims a Core Web Vitals figure from the server side is estimating and not saying so. For the real numbers, use the Core Web Vitals report in Google Search Console: that is field data from actual Chrome users on your actual site, and it beats any lab estimate.
It also does not execute your JavaScript, so anything loaded or rendered after the page arrives is outside what is measured. Where asset weight is sampled rather than fully downloaded, the report says so and gives the sample size. And the timing comes from our server on a good connection, not from a phone in a car park on three bars, so treat the response time as a comparison point rather than a stopwatch on your visitors.
What it is good at is the structural stuff, which is also the stuff that stays fixed. Bytes, headers, request counts, and file sizes do not vary by run, by device, or by mood.
Questions people ask
Does this use Google PageSpeed Insights or give me a Lighthouse score?
No. It makes its own requests to your site and measures what comes back — response time, byte weights, headers, request counts, how the markup is built. There is no PageSpeed API behind it and no Lighthouse score in the output.
That is deliberate. A Lighthouse score tells you that you are slow; it rarely tells you what to do on Monday morning. This tells you which file is doing it, how many kilobytes it costs, and where the setting lives. If you also want a Lighthouse score, run PageSpeed Insights alongside this — they answer different questions, and neither replaces the other.
Does this measure Core Web Vitals?
No, and it will not pretend to. LCP, INP and CLS are measured in a browser on a real device, and this reads what your server sends. What it does report are the common causes of poor Core Web Vitals — oversized hero images, images with no dimensions set, render-blocking and third-party scripts — so the findings are actionable even though the metrics are not here. For the actual figures, use the Core Web Vitals report in Google Search Console.
Is the speed test free?
Yes. No account, no card, no plugin to install. There is a fair-use limit so the tool cannot be pointed at a thousand domains in an afternoon, and that is the only restriction.
Do I need to give you my email address?
Not to see the score, the category breakdown or the first fixes. The remainder of the fix list asks for one, because that is how a free tool covers its costs. You are asked once and not again.
Does running the test slow my site down or change anything?
No. It fetches your page and a small sample of its assets — a handful of requests, roughly what one visitor costs you. It never logs in, never submits anything, and never writes to your site. The report is read-only from start to finish.
What is server response time and what is a good number?
It is how long your server takes to start sending the page after being asked — sometimes called TTFB. Under 200ms is excellent, under 600ms is fine, over a second means a visitor is staring at a blank screen before anything can begin. It is almost entirely a hosting and caching number, so it is the one finding you cannot fix by editing the page.
Will a caching plugin fix all of this?
It will fix the server response time, the compression and the browser caching, which is a genuine chunk of the list. It will not make a 4MB image smaller, will not remove twelve plugins loading their scripts on every page, and will not undo a page builder writing 400KB of CSS into the document. Caching hides a slow site from repeat visitors; it does not make the site light.
My host told me the site is fast. Why does this say otherwise?
Both can be true. Hosts measure how quickly the server answers, and by that measure they are often right. This measures everything the visitor then has to download. Check the server response time in the report first: if it is good, your host is right and the weight is coming from how the page is built, which is yours to fix rather than theirs.
Want the slow bits fixed rather than listed?
Most of what this report finds is a day of work, not a rebuild — caching, image weight, a stylesheet that should be a file. Send us the address and we will tell you what we would do and what it would cost.
