PageSpeed Insights is Google’s free tool for measuring how quickly a page loads and how stable it feels to use. The report can look hostile at first: a score out of 100, then metrics called LCP, INP and CLS. The score is a rough signal. The metrics underneath it are what tell you where the problem actually is.
Below is what each metric measures, what counts as a good result, and which of them affect your search rankings. You do not need to be a developer to understand any of it. Some of the fixes at the end do need one, and we have said which.
What is Google PageSpeed Insights?
PageSpeed Insights is a free tool at pagespeed.web.dev that tests any public web address and reports how fast and how usable that page is. You do not need to log in, install anything, or own the website you are testing. It runs mobile and desktop as two separate reports, and mobile is both the harsher test and the one worth paying attention to first.
Two things are worth knowing before you read a single number. The report covers one page at a time, so testing your home page tells you little about the service page your enquiries land on. And it contains two different sets of data, which is what the next section is about.
Lab data vs field data: why your score keeps changing
Field data is what your real visitors experienced. Google collects it from opted-in Chrome users over the previous 28 days and publishes it as the Chrome User Experience Report, or CrUX. It does not cover Safari or Chrome on an iPhone, so it is not quite everyone. This is the data Google’s ranking systems draw on, so when field data and lab data disagree, field data is the one to trust.
Lab data is one simulated load, run on a throttled mid-range Android phone on a slow 4G connection with an empty cache. Almost none of your customers are in that situation. That is deliberate. It is a stress test, not a typical visit, and its value is diagnostic: it tells you what is slow and why, in a repeatable way you can test a fix against.
Low-traffic websites often show “No Data” in the field section. PageSpeed Insights first falls back from this one page to figures for your website as a whole, and only reports No Data when the whole website is too quiet to publish an average. That is not a fault, and the Core Web Vitals report in Google Search Console is the next place to look. The lab score, meanwhile, moves: run the same test twice in ten minutes and it will usually shift by several points, so do not read a small change either way as a win or a regression.
If you want to go through a live report panel by panel, our guide on how to read a PageSpeed Insights report walks through a real one with screenshots.
The Core Web Vitals explained
Core Web Vitals are the three field measurements Google uses for the speed and stability part of page experience, and its ranking systems do take them into account. They cover loading, responsiveness and visual stability. A page passes when the 75th percentile of real visits lands in the good band for all three, with mobile and desktop judged separately. That is why a page can feel fine on your own laptop and still fail.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading speed | 2.5s or less | Over 2.5s to 4s | Over 4s |
| Interaction to Next Paint (INP) | Responsiveness | 200ms or less | Over 200ms to 500ms | Over 500ms |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less | Over 0.1 to 0.25 | Over 0.25 |
Largest Contentful Paint (LCP): loading performance
LCP measures how long it takes for the largest visible element on the page to finish rendering, which is usually a hero image or a heading block. It is the closest thing to the moment a visitor would say the page has loaded.
Poor LCP usually traces back to a slow server response, oversized images, render-blocking CSS and JavaScript, or underpowered hosting. Of those, hosting and images are the two that most often move the number on a small business website.
Interaction to Next Paint (INP): responsiveness
INP measures how quickly the page responds when someone taps, clicks or types. Google replaced First Input Delay with INP in March 2024, because FID only measured the very first interaction, while INP watches the whole visit and reports close to the worst response. It reports a high-percentile interaction, close to the worst of the visit once outliers are set aside.
Slow INP is usually main-thread work: your own JavaScript, third-party scripts, or a page that is expensive to render. Sliders, chat widgets, tracking scripts and booking embeds all compete for the single thread the browser uses to respond to taps. When that thread is busy, the button you pressed does nothing for half a second, and that is what INP records. PageSpeed Insights does not report INP in its lab section, because that test loads the page without any clicks or taps.
Cumulative Layout Shift (CLS): visual stability
CLS measures how much the page moves around on its own while it loads. It is the score for the experience of starting to read a paragraph, or reaching for a button, and having the whole thing jump down the screen. It is not measured in seconds, and the thresholds are in the table above.
The usual causes are images and videos inserted without width and height attributes, so the browser reserves no space for them; ads, maps and embeds that push content down when they arrive; and web fonts that load late and reflow the text. CLS is often the cheapest of the three to fix, because most of it is markup rather than architecture.
The other metrics worth knowing: FCP, TBT and Speed Index
Three more measurements help explain a poor score. None of them is a Core Web Vital, and they do not carry ranking weight on their own.
- First Contentful Paint (FCP) is when the first piece of anything appears on screen, the first sign to a visitor that something is happening. 1.8 seconds or less is good. Unlike the two below, FCP is reported from real visitors in the field panel as well as in the lab.
- Total Blocking Time (TBT) is how long the main thread was frozen and unable to respond during the test. Lab only. It is the stand-in for INP, and like INP it is driven by main-thread work. It carries the largest single share of the performance score.
- Speed Index is how quickly the visible part of the page fills in. Lab only, and a general indicator rather than something to chase.
What is a good PageSpeed score, really?
A perfect 100 is rarely necessary or realistic. Content-rich websites, online shops and anything carrying booking systems or embedded video sit lower by design, and the work needed to drag those last points up tends to be the fragile kind that breaks the next time someone edits a page.
For search, passing Core Web Vitals in the field data matters more than the lab score. Google’s ranking systems use the field measurements rather than the simulation, though they are one signal among many and will not lift a thin page above a more useful one. A website with green vitals and a mobile score of 72 is in better shape than one failing its vitals with a mobile score of 85.
A sensible target for most New Zealand business websites is green across all three Core Web Vitals, and a mobile lab score of 70 or above. Expect that to still look orange in the tool: Google paints 90 and above green, 50 to 89 orange, and below 50 red, so a perfectly healthy business website often shows an amber score. That target is achievable on ordinary hosting with ordinary content, and it is the point where further work starts costing more than it returns.
How to improve your PageSpeed Insights scores
These are the levers that move the numbers, roughly in order of how much they return for the effort.
Start with hosting. Server response time sits underneath every other metric, and no amount of optimisation compensates for a slow server. If your website is on shared hosting with hundreds of neighbours, that is usually the single biggest gain available, and it is a change of plan rather than a change of code.
Fix your images. Oversized images are the most common cause of poor LCP on a WordPress website. Serve them in a modern format such as WebP or AVIF, size them to the space they actually occupy, and make sure width and height are set so the browser reserves the room. Our guide on adding images without slowing your website down covers what to do before you upload.
Turn on caching. Caching saves a finished copy of each page so the server stops rebuilding it for every visitor. We use WP Rocket, and there is a guide to which of its settings are safe to turn on. Other caching plugins do the same job; the settings that break things are similar across all of them.
Add a CDN. A content delivery network serves your images and files from a location near the visitor rather than from a single server. For a New Zealand website with any overseas audience, this is one of the more noticeable improvements you can make.
Cut down the JavaScript. Every plugin, tracking pixel and embedded widget adds to the work the browser has to do before it can respond, which is what TBT and INP are measuring. Audit what is loading, remove what is no longer earning its place, and defer what is not needed for the first screen.
Reduce the DOM size. Pages built from deeply nested layouts give the browser thousands of elements to calculate. Keeping the DOM small helps both loading and responsiveness, though it usually means changing how the page is built rather than changing a setting.
The first four are within reach of most website owners. The last two, along with server configuration and anything living in the theme, need someone who can read the code and knows what will break.
Need help getting your website up to speed?
Understanding what the metrics mean is one thing. Working out which of them is costing you enquiries, and fixing the technical ones without breaking the website, is another. We audit WordPress websites, identify what is dragging the scores down, and do the work.
Start with a website health check if you want a written picture of where your website stands, or get in touch and send us the address you tested. We will tell you what is worth fixing and what is not. If performance turns out to be one problem among many, a website redesign is often the better use of the budget.
