Websites
Core Web Vitals explained: why does my site score badly in PageSpeed?
Short answer
Core Web Vitals are three measurements Google uses to judge how a page feels to a visitor: how soon the main part is on screen (LCP), how fast the page responds to a tap or click (INP) and whether the content jumps around while loading (CLS). A poor score usually comes from heavy images, too many third-party scripts or slow hosting. The score in PageSpeed Insights is a test; what counts is what real visitors experience.
What exactly does Google measure?
Three things a visitor feels, even without a word for them.
| Measurement | What a visitor notices | Good | Poor |
|---|---|---|---|
| LCP, Largest Contentful Paint | How long it takes before the main part of the page is visible | Up to 2.5 seconds | More than 4 seconds |
| INP, Interaction to Next Paint | How long the page “thinks” after you tap something | Up to 200 milliseconds | More than 500 milliseconds |
| CLS, Cumulative Layout Shift | Whether buttons and text jump while you are already reading | Up to 0.1 | More than 0.25 |
INP replaced an older measurement in 2024. If a report still shows FID, the report is out of date.
Where does a poor LCP come from?
Almost always from one of these four.
An oversized image at the top. A four-megabyte photo that the browser first has to download in full and then shrink. The right dimensions and a leaner file format fix this.
The server takes long. Before anything can load, the server has to build the page. On cheap hosting with hundreds of sites on one machine, or on a site without a cache, a second or more can disappear there.
Styling and scripts hold back the picture. The browser waits to draw until certain files are in. With ten style files and scripts in the head of the page, the visitor stares at a white screen all that time.
Fonts from another server. Every external address costs a new connection.
Where does a poor INP come from?
From too much JavaScript. Every plugin, tracker, chat button and cookie banner adds code that the phone has to run. While the phone is busy with that, the page does not respond to a tap.
The usual sources:
- Measuring and advertising scripts from third parties, often several side by side
- A cookie banner that is a sizeable program in itself
- A page builder that loads every possible component on every page
- Sliders and animations at the top of the page
This is also why a site without trackers has a head start. What you do not load does not have to be run. More on this in is a cookie banner required.
Where does a poor CLS come from?
From components that arrive later and take up space that was not reserved.
- Images without a stated width and height
- A banner or advert inserted above the content
- A font that loads late, so the text is laid out again
- A cookie banner that pushes the page down
You recognise it when you go to tap a button and the page shifts at that moment.
How do you read PageSpeed Insights?
At the top is what real visitors experienced, if there is enough data. Below that is the test, with a score from 0 to 100 and a list of recommendations.
Three things to remember:
- Look at mobile. That tab is the default, and rightly so.
- The test score fluctuates. Testing twice in a row gives two results. Look at the picture across several runs.
- Not every recommendation is worth the same. The list is generated automatically. Half a second gained on the largest image does more than ten small points.
If your site has few visitors, Google shows no data from real users. Then the test is all you have.
What gives the most?
In the order we tackle it:
- Measure where the time goes. Server, images or scripts. Without measuring you are guessing.
- Hosting and cache. A page that is already prepared does not have to be built again.
- Images. The right size, a lean format, and load only what comes into view.
- Clear out third-party scripts. What nobody uses any more goes.
- Reserve space. For images and everything that arrives later.
A plugin that promises to fix everything with one click addresses points 2 and 3 in part at best, and makes point 4 worse.
We do this for WordPress and WooCommerce under a faster website and for Magento under speed and optimisation. We measure before and after, and we do not promise a figure before we know what causes it.