How to test your own site

You can find out how fast your website actually is, for real visitors, in about twenty minutes, using free tools, without any technical background. What you cannot do in twenty minutes is fix it — but knowing exactly what is wrong changes every conversation you have with a supplier afterwards, because you stop asking whether the site is slow and start asking why this particular thing is.

Work in this order. It goes from what really happened to why it happened, which is the opposite of how most people do it.

Step one: the field data, in Google Search Console

Start here, because this is the only place you will see what your visitors experienced rather than what a simulator predicted.

Open Search Console for your site and find the Core Web Vitals report. It shows your pages grouped by status for mobile and desktop separately, against Google’s published thresholds of Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. Those are Google’s figures, from web.dev, checked on 3 August 2026. The figures underneath this report come from the Chrome User Experience Report (CrUX) — real Chrome users who opted in, not a simulation — which is also why a low-traffic site sometimes has none.

Three things to read carefully.

Look at mobile first, and mostly mobile. They are reported separately because they behave completely differently, and nearly every problem worth money is a mobile one.

Look at the group sizes. Search Console groups pages by similar behaviour, which usually means by template. Forty service pages failing together is one fix in one template, not forty jobs. That distinction is the difference between an afternoon and a project.

Accept that you may have no data. A site with modest traffic may not have enough real-user samples to report. That is not a pass and not a failure. It means you move to step two and use judgement.

The report also lags. It reflects a recent period rather than today, so a fix made this week will not appear for some weeks. Suppliers occasionally get blamed for this. It is not their doing.

Step two: the lab test, in PageSpeed Insights or GTmetrix

Now find out why. Take one representative page from each failing group — not just the home page, which is usually the most optimised page on any site — and run it through PageSpeed Insights. GTmetrix is a commonly used alternative, free at a basic level with paid tiers for more analysis options and a choice of test locations; it reports on the same underlying Lighthouse data, but PageSpeed Insights gives you everything below without an account.

Ignore the score. It is a weighted composite of a single simulated load and it moves between runs for no reason you can act on. Chasing the number is the most common way to waste money on performance work.

Read four things instead:

• The identified Largest Contentful Paint element, named specifically. It will usually be a hero image, and now you know which file.
• The Largest Contentful Paint phase breakdown, which splits the time into server response, delay before the resource started loading, download time, and the gap before it rendered. Whichever phase dominates tells you which category of problem you have.
• The initial server response time. If that is a large share of the total, the problem is server-side. If it is small and the page is still slow, hosting is not your problem — the reasoning is in hosting and speed.
• The layout shift diagnostics, which name the elements that moved.

Run each page more than once. If the numbers move substantially between runs, treat the middle result as the honest one.

Step three: your own device, honestly

Open the site on a phone, on mobile data, away from your office wifi. If you own a budget Android handset, use that one. The site is not judged on your device; it is judged on the device of the person who nearly rang you.

Then do the things a customer does. Tap the menu. Tap the phone number. Scroll to the middle of a service page. Fill in the form and submit it. Notice specifically whether anything hesitates after a tap — that is what interaction to next paint measures, and it is far easier to feel than to read off a chart.

Do all of this in a private browsing window. Your normal browser has the whole site cached and will show you a version of your website that no first-time visitor will ever see.

Step four: browser dev tools, if you are willing

Optional, and genuinely informative. In Chrome, open developer tools and use the Network panel with throttling set to a slow mobile profile. Reload, then sort the requests by size. The largest handful of files are your page weight, and if they are images you have found the answer described in images and formats.

Two more things in the same panel. Count the distinct third-party domains being contacted; each one is a chat widget, tag, pixel or embed that someone added and possibly nobody has reviewed since. And watch the page render slowly enough to see the layout jump, which is the only reliable way to observe cumulative layout shift with your own eyes.

Telling a real problem from noise

Four rules keep you honest.

A single lab score is not evidence — a repeated pattern across runs and pages is. Field data outranks lab data whenever the two disagree, because one is a simulation and one is your customers. A change that does not show up in field data within some weeks may not have worked. And a page that is slow only for you is probably an extension, an ad blocker or your own connection, not the site.

What to send a supplier

Not a screenshot of a score. Send this, and the conversation changes:

• The Search Console field figures for mobile, and how many pages are in the affected group
• The specific page addresses you tested
• The named Largest Contentful Paint element and the phase breakdown
• The initial server response time
• The named elements causing layout shift
• The list of third-party domains, with a note on which ones you can identify a purpose for

Then ask three questions. Which of these is a template fix and which is page by page. Which are one-off and which will come back the next time somebody in the office uploads a photograph. And will the figures be re-measured on real traffic a month after the work, rather than in a lab on the day.

Nobody should promise you a particular ranking outcome from this, and any supplier who does is describing something they do not control.

The same twenty-minute discipline applies to accessibility, where automated tools cover only part of the picture and the rest requires a person — the accessibility self-assessment is the equivalent walkthrough, and the obligation behind it is on website accessibility in Australia. Any term above that is unfamiliar is defined in the glossary.