Speed is the one SEO factor your customers notice too. A visitor staring at a blank screen for three seconds does not come back to complain: they hit back and pick the next result. Google measures that behaviour and has had an official name for it since 2021: the Core Web Vitals.
These vitals are not abstract numbers. They measure three things a person actually experiences: how long before something appears, whether the page jumps away under your finger, and whether it responds when you tap it. This article explains them, along with the overall performance score and the server headers underneath. They are the checks a report lists under “Speed”.
LCP: how long before something is there
Largest Contentful Paint measures when the biggest visible element appears. In practice that is your hero image or your main heading. It is the best approximation of the moment a visitor thinks: the page has arrived.
Google calls under 2.5 seconds good, 2.5 to 4 seconds in need of improvement, and over 4 seconds poor. That is measured on mobile, on a connection slower than the one on your desk.
There are three usual causes. The first is an oversized hero image: a 3 MB photo displayed at 1200 pixels wide. The second is a slow server: if the first byte only arrives after 800 milliseconds, a third of your budget is gone before the browser can do anything. The third is render-blocking CSS, often a font or a third party stylesheet.
CLS: does the page jump under your finger
Cumulative Layout Shift measures how much the content moves while the page loads. Everyone knows the feeling: you go to tap a link, a banner loads in above it, and you tap something else entirely. Under 0.1 is good, over 0.25 is poor.
The cause is almost always the same: elements taking up space that was never reserved for them. Images without width and height, adverts, cookie notices sliding in from the top, and web fonts that land with a different line height than the temporary font.
The good news is that this is the cheapest of the three to fix. Put width and height on your images and a large part of the problem disappears. There is more on that in the article on alt text and fast images.
TBT and INP: does the page respond
Total Blocking Time measures how long the page ignores taps and clicks because JavaScript is occupying the main thread. It is the lab version of Interaction to Next Paint, the responsiveness metric Google has actually been measuring on since 2024.
Under 200 milliseconds is good, over 600 is poor. The cause is rarely your own code: it is usually third party scripts. A chat widget, two tracking pixels, a cookie banner and a review system together easily demand more processing time than the page itself.
So that is the first place to prune. Every external widget costs speed, and the question for each one is whether it earns that cost back.
The overall performance score
Lighthouse, the engine behind Google PageSpeed Insights, adds the loading metrics up into a single number from 0 to 100. Above 90 is good, 50 to 89 needs work, below 50 is poor. We take that score as Google measures it, on mobile.
Two things worth knowing. First, the score moves: two runs back to back can differ by five points, because it is measured on shared infrastructure. Watch the direction, not the last decimal.
Second, this is a lab measurement: one load, on a simulated device. For ranking, Google prefers field data, meaning what real visitors in Chrome actually experienced. With enough traffic you can see that in Search Console under Core Web Vitals. That is the measure that counts; the lab measurement is the one that lets you work without waiting a month.
Compression and what your server sends along
Underneath the vitals sits something simpler: the way your server ships the files. Text, meaning HTML, CSS and JavaScript, should be compressed with gzip or Brotli. In practice that saves around seventy percent of the bytes, and it is usually one line in the server configuration or one checkbox at your host.
Our report also notes two things that cost no points but do say something. Time to first byte shows how long your server needs before it starts answering; above 600 milliseconds the problem lies with your hosting or your database rather than your page. And the X-Powered-By header gives away which PHP version you run, which nobody needs to know unless they are already logged in.
What you can do today
- Measure your most important page on PageSpeed Insights and look only at the mobile tab.
- Find the largest image on that page and check how many kilobytes it weighs. Above 300 kB there is almost always something to gain.
- Count the external scripts on your site: chat, analytics, reviews, adverts. Drop one nobody will miss.
- Check with your host that compression is switched on.
- If your site has enough traffic, look in Search Console under Core Web Vitals to see what real visitors experience.
Want all of this checked in one go? The free SEO check runs through these points and shows you what was found on your page for each of them.
