To test your website’s speed, put the address into Google’s PageSpeed Insights at pagespeed.web.dev and read the mobile result. That takes a minute. Knowing which of the numbers it shows you matter, which ones move every time you run it, and what to do when half the report says “No data” takes a little longer, and that is what this article is for.
How do I test my website’s speed?
Four checks, in this order, cover what a small business needs:
- PageSpeed Insights. Go to pagespeed.web.dev, paste your homepage address and press Analyze. It is free and needs no account.
- The mobile tab. The report has a mobile and a desktop result. The mobile test is the harder one, and someone looking for a plumber from a pavement is on a phone, so read that first.
- Your busiest pages, not only the homepage. Run the services page, the menu, the contact page: whichever page people land on from Google.
- Your own phone. Turn Wi-Fi off, open a private browser tab so nothing is cached, and load the site on mobile data. Count how long until you could read the page and tap the phone number. Do it somewhere with an ordinary signal, not next to the router.
The last step is the one people skip, and it is the one closest to your customer’s experience. A lab test is a simulation; your phone on 4G in a car park is the real thing.
Field data and lab data: two different reports
The top half of PageSpeed Insights, headed with an assessment of whether you pass the Core Web Vitals, is field data. Google’s documentation says it comes from the Chrome User Experience Report and covers real visits over the previous 28 days. It is the most honest number on the page, because it describes what happened to actual visitors on their actual phones.
The bottom half, under a large circular score, is the lab test. Lighthouse loads the page once on a simulated mid-range phone over a throttled mobile connection. It is useful for finding problems, but it is one run on one imagined device.
Many small business sites see “No data” in the top half. That is not a fault. Chrome’s documentation says a page or site must be “sufficiently popular” to be included, and does not publish the threshold. A plumber’s site with a few hundred visits a month will often fall below it. When that happens, the lab test is what you have, and the phone in your pocket matters more.
What is a good PageSpeed score?
Lighthouse bands the score as 90 to 100 good, 50 to 89 needing improvement, and under 50 poor. Treat it as a summary, not a target. It is a weighted blend of five lab measurements, and Chrome’s documentation gives the weights: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, and First Contentful Paint and Speed Index 10% each.
The score also moves between runs. Chrome’s own page on scoring says much of that variability “is not due to Lighthouse”: network routing, ads or tests on the page, the hardware running the test, browser extensions and antivirus software all shift it. Run the test three times and take the middle result. A move from 72 to 78 is noise. A move from 45 to 85 is a real change.
Which numbers actually matter?
Google’s Core Web Vitals are three measurements, each with a published threshold. Google judges them at the 75th percentile of visits, which means three visitors in four should get a result at least that good.
-
Largest Contentful Paint
Largest Contentful Paint (LCP) is how long until the biggest thing on the first screen, usually the main photograph or the headline, has appeared. Good is 2.5 seconds or less; over 4 seconds is poor.
-
Interaction to Next Paint
Interaction to Next Paint (INP) is how quickly the page responds when someone taps a button or opens a menu. Good is 200 milliseconds or less; over 500 is poor. It needs real taps to measure, so it appears only in field data. In the lab test, Total Blocking Time stands in for it.
-
Cumulative Layout Shift
Cumulative Layout Shift (CLS) is how much the page jumps about as it loads: the button that moves as your thumb arrives. Good is 0.1 or less; over 0.25 is poor.
Those thresholds come from Google’s PageSpeed Insights documentation, which also lists two supporting measures: First Contentful Paint, good under 1.8 seconds, and Time to First Byte, good under 0.8 seconds. A slow Time to First Byte points at the hosting rather than the page, more often than not.
Reading a report: a worked example
Here is an invented mobile lab result for a café homepage, and how to read it. Performance 54. LCP 5.8 seconds. Total Blocking Time 620 milliseconds. CLS 0.31.
Start with LCP, because it is the one a visitor feels first. Scroll down to the part of the report that names the element behind it. Here it is the hero photograph, and the report shows it is a 4 MB image straight off a camera, shown on a phone screen 400 pixels wide. Resized to the width it is displayed at and saved as WebP or AVIF, it will usually be a small fraction of that size.
Then Total Blocking Time. Further down, the report lists third-party code by how long it holds up the page. On a small business site the usual names are a chat widget, an embedded social media feed, a booking widget and two or three tracking scripts. Each one is a decision: if the Instagram feed is not bringing bookings, it is costing speed for nothing.
Then CLS. The report shows which elements moved. The common causes are images without a width and height set, so the page cannot reserve their space, a cookie banner that pushes everything down, and web fonts that swap in late.
The Copperline Plumbing demo we built shows what the photograph fixes look like in practice: each photograph is offered at two widths in AVIF and WebP, with its dimensions declared, and the ones below the first screen load only when someone scrolls to them.
Does website speed affect your Google ranking?
Yes, but less than most sales emails claim. Google says Core Web Vitals are part of the page experience its ranking systems “seek to reward”, and recommends good scores. On the same subject it also says that “Google Search always seeks to show the most relevant content, even if the page experience is sub-par”, and that good scores do not guarantee a top position.
So speed is rarely why a site is invisible. It matters more for what happens after the click: a visitor who waits on a blank screen goes back and taps the next result. If people are finding the site and not getting in touch, speed is one of the things to check, alongside the others in website not getting enquiries?
Do not pay for a “speed optimisation” plugin stack before you know what is slow. Most slow small business sites are slow for one or two reasons visible in the report: a huge photograph, a heavy widget, slow hosting. Adding a caching plugin, an optimisation plugin and a lazy-loading plugin on top of those often changes the score a little and the cause not at all.
What to fix first
In most small business sites the order below gets most of the gain for the least work:
- Resize and convert the photographs on the first screen of every page.
- Remove any widget that is not earning its place: feeds, pop-ups, unused chat.
- Set a width and height on images and embeds so the page stops jumping.
- Check Time to First Byte; if it is well over 0.8 seconds on every run, the hosting is the problem and no amount of page tidying will fix it.
- Run the test again, three times, and compare the middle results.
If you have Google Search Console set up, its Core Web Vitals report shows the same field data across the whole site, grouped by problem. For a small site it is often empty for the same reason PageSpeed Insights says “No data”. That is expected, and the lab test and your own phone are still enough to work from.
If you would rather someone else read the report, send us your site. We reply in writing with the three things we would change first, and if speed is one of them, we will say which part of the page is causing it.
Speed is one part of a site that converts. For the rest, there is what a tradesperson’s website actually needs, and for what to ask before paying someone to fix it, how to read a website quote.
Official sources
Google’s own pages for the points above:
