Core Web Vitals: Google scores your speed per page, but your report groups them
Google scores the speed of your website per page, at the 75th percentile of what real visitors experienced over 28 days. Search Console just doesn't show that per individual URL: the report bundles pages with a similar experience into a group, and when there isn't enough data it falls back on a group for your whole domain. That's how one slow template page turns a whole group red. So start with your slowest pages, not your homepage.
What are Core Web Vitals and why do they matter
Core Web Vitals are three metrics Google uses to determine how fast and pleasant your website is for visitors. They're not suggestions but hard numbers that directly affect your positions in the search results.
LCP (Largest Contentful Paint)
measures how fast the largest visible element loads. Google's threshold: 2.5 seconds.INP (Interaction to Next Paint)
has replaced the old FID metric since March 2024 and measures how fast your site responds to user interaction. Threshold: 200 milliseconds.CLS (Cumulative Layout Shift)
measures unexpected shifts of elements while the page loads. Target value: below 0.1.Google scores these values per page, at the 75th percentile of the real user data; that's how it's set out in Google's explanation of Core Web Vitals. Want to brush up on the basics first, take a look at our knowledge base.
Why your report lumps pages together
You'll sometimes read that Google has scored your whole site as one unit since March 2026, under the name composite CWV scoring. That change never happened and that term doesn't come from Google. What is true: Google scores page experience per page and has never announced a composite site score.
The confusion comes from your report
Search Console bundles URLs with a similar user experience into a group and gives the whole group the same status. If a group has too little data, the report falls back on a group for your whole domain. That's how one slow template page turns a whole group red, even if the rest of that group is fast. That's a display quirk in your report, not a site-wide ranking assessment.
Why one slow page drags its whole group down
A group in Search Console takes on the status of the worst-performing URLs within it. Ten fast pages in the same group don't fix that: you see red, and you don't immediately see which URL is causing it.
That's no small thing, because that report is what you steer by month after month
As long as your group is red, you don't know whether your problem sits in a single template or everywhere, and you often end up speeding up the wrong page.
Tip: open the red group, sort by the worst URLs and start there
Fixing one slow page gains you more than speeding up ten fast pages even further.
How to find out whether your site has a problem
You don't have to guess. With three free tools you can see where you stand within a few minutes.
Google Search Console
open the Core Web Vitals report in the left-hand menu and see how many pages are rated poor. More than 20 per cent points to a problem.PageSpeed Insights
go to pagespeed.web.dev and enter your URL. Don't just test your homepage, but also your contact page, blog posts and service pages.Site Kit for WordPress
this plugin links your Search Console data directly to your WordPress dashboard.Only checking your homepage is a common mistake. It's precisely the forgotten pages deeper in your site that drag the score down.
What to do now: five concrete steps
Step 1: list your worst pages
Open Search Console, go to the Core Web Vitals report and sort by poor. These are your priorities.Step 2: tackle your images
On small business sites, this is the cause we run into most often. We're deliberately leaving out a percentage, because that would be an impression from our own work, not a measurement. Compress them to under 200 KB, use the WebP format and turn on lazy loading. Plugins such as ShortPixel or Imagify automate this.Step 3: tidy up your scripts
Every plugin, widget, tracker and chatbot slows down your page. Remove what you don't genuinely need.Step 4: fix your hosting
Cheap shared hosting is often not enough. Managed WordPress hosting with caching and a CDN has a measurable impact, but entry prices vary widely: Cloudways starts around $11 a month, Kinsta around $35, and WP Engine somewhere in between. For a business site with real traffic, budget €30 to €50 a month, and check what that price actually includes in CDN, backups and a staging environment.Step 5: remove or improve old pages
Pages with a poor score and no traffic are better removed and redirected to a relevant page.Tip: think of the 80/20 rule as a rule of thumb, not a measurement: in practice, most of your speed problem sits in a small share of your pages.
Can't get to the bottom of it yourself, we'll pick this up for you as part of improving SEO.
The most common speed killers on small business websites
Uncompressed images
the biggest culprit. A six-megabyte photo on page 17 can wreck the score of your entire site.Too many plugins
on most sites we open, there are plugins that were switched on for something once and never tidied up afterwards. Count them and ask, for each one, what it's still there for today.No caching
the difference can run to 3 to 4 seconds of load time per page.External third-party scripts
Google Analytics, Facebook Pixel, HotJar, Google Tag Manager. Every extra request slows down your page.Embedded content
a YouTube embed loads a complete player with its own scripts, and that costs noticeable time. Exactly how much varies per page, so measure it yourself once, with and without. Use a thumbnail with a play button that only loads the video on a click.Want to look beyond speed alone? Then read how to get found in Google AI Overviews and ChatGPT.
Field data and lab data: why PageSpeed gives two results
Enter a page into PageSpeed Insights and you get two blocks, one below the other, and they regularly contradict each other. At the top sit the field data: what real visitors on real devices over real connections experienced over the past 28 days. Below that sits the Lighthouse lab measurement: a simulation, right now, on a simulated device over a simulated connection.
Only that first block counts towards the assessment
The field data comes from the Chrome User Experience Report, the collection Chrome builds up from visitors who gave permission for it; see the Chrome User Experience Report documentation, checked on 25 August 2026. The lab measurement is diagnostic, not a verdict.
They diverge because the lab doesn't know certain things
No cache, no logged-in session, no visitor scrolling halfway through or tapping a button. INP is even missing from the lab entirely, because there's nothing to measure without interaction. The other way round, the field misses the cross-section: it tells you it was slow, not which line of code caused it.
Two consequences that often cause confusion
Scoring green in the lab and red in the field can therefore happen easily, because your visitors are, on average, on slower devices than the simulation assumes. And a page with too few visitors has no field data at all; then the report falls back on the group, exactly as described above.
The division of labour then follows naturally: use the lab to search for where it sits, use the field to establish whether it's fixed
Reverse that, and you're optimising a simulation.
What the 75th percentile means for your page
Google doesn't score your average visitor but your 75th percentile. Line up all the page views from the past 28 days from fastest to slowest and take the view three-quarters of the way along that line: that's the value that counts. So three out of four visitors had it as good or better, one in four had it worse.
That's a deliberate choice, not an arbitrary one
An average can be pulled up by a large group of fast visitors, and that's exactly why the tail where the problem sits disappears. The 75th percentile forces you to look at that slow quarter, because as long as that's slow you won't hit the threshold, however fast the rest is.
Something follows from that which surprises a lot of people: your fastest visitors don't help you
Speeding up a page that already loads within a second by another two hundred milliseconds doesn't change your 75th percentile. The gain sits in the slow quarter, and that usually consists of a recognisable group: older Android devices, a mobile network out in the countryside, and the first visit from someone who has nothing cached yet.
So don't just test on your own fibre connection with a new laptop, because then you're measuring the end of the line that's already fine
Turn on throttling in your browser's developer tools, choose a slow connection and a limited processor, and reload with an empty cache. That won't match your real visitors exactly, but it gets you close to the end where the number actually comes from.
Finally, note that mobile and desktop are scored separately
A page can stay comfortably within the threshold on desktop and go well over it on mobile. So always look at the mobile block first, because that's where most of the visits sit for most sites.
LCP broken down: four chunks of time, four kinds of work
Of the three metrics, LCP is the most common problem, and also the most commonly tackled the wrong way. That's because people treat LCP as a single number when it's actually a sum. Google splits that sum into four chunks that happen one after another, and the work involved is completely different for each chunk. The breakdown is set out in Google's explanation of optimising LCP, checked on 25 August 2026.
The first chunk is the wait on your server: how long it takes before the browser receives the first byte
That's hosting, caching and how fast your database answers. The second chunk is the delay before loading starts: the time between that first byte and the moment the browser works out that an image or font is needed. That chunk grows when the element only becomes known via a stylesheet or via JavaScript instead of simply sitting in the HTML.
The third chunk is the download itself, and that's the only chunk compression is actually about
The fourth chunk is render delay: the file has arrived, but it isn't on screen yet because there's still blocking CSS or JavaScript ahead of it in the queue.
INP and CLS come from somewhere else
INP has nothing to do with loading and everything to do with responding. That value also breaks down, into three chunks: the input delay before the browser gets to your tap, the processing time of the code attached to it, and the presentation delay before the result is on screen. That breakdown is set out in Google's explanation of optimising INP, checked on 25 August 2026.
In practice, the problem is almost always in the first chunk, and the cause is almost always the same: the browser is busy with something else
A third-party script running at that moment, a large chunk of JavaScript running all at once, a chat widget building itself up. As long as that task is running, the browser can't do anything with your tap, and the visitor sees nothing happen.
One more thing to know: INP doesn't look at your first click but at the slowest interaction of the visit, with a single outlier disregarded on pages with very many interactions. So a menu that opens smoothly nine times out of ten and sticks the tenth time genuinely is your INP. So don't look for what's slow on average, look for what occasionally stutters.
CLS is the only one of the three you can see with the naked eye, and the causes are well known
Google names, among others: images and videos without known dimensions, fonts that turn out larger or smaller than the fallback font, third-party ads and widgets that grow themselves along the way, resources that arrive asynchronously while the visitor is already reading, and content that gets dynamically inserted above existing content. The list is set out in Google's explanation of Cumulative Layout Shift, checked on 25 August 2026.
The fix for CLS is usually the cheapest of the three
Set a width and height on every image, reserve a fixed height for your cookie banner and your banners, and let your fonts swap in a way that doesn't cause a jump. You test it by slowly scrolling down on a phone with an empty cache and watching whether anything slides away under your thumb.
Finally, a limit worth naming
These three values are about your visitor's experience, not about whether your page actually answers what was searched for. A page that loads in half a second and doesn't answer the question is still a page that doesn't answer the question. Speed opens the door, the content does the work behind it, and that part is covered in the knowledge base.
Frequently asked questions
Does Google score Core Web Vitals per page or site-wide?
Per page. Search Console shows them in groups of pages with a similar experience, and when there's too little data, in a group for your whole domain. See a red group there, and you look for the slowest URL in that group. Google has never announced a site-wide Core Web Vitals score.
How much impact do Core Web Vitals have on my rankings?
Core Web Vitals aren't the most important ranking factor. They count, and they count most when the competition is evenly matched on content. We won't put a number of positions on it: that differs per search term and nobody can calculate it in advance, us included.
Should I remove all my old pages?
No. Only remove pages that perform poorly and bring in little traffic. Pages that do attract traffic, you improve.
How soon will I see results?
Google bases Core Web Vitals on 28 days of user data. So budget at least four weeks before an improvement can show up in the report, because that's how long it takes for the measurement window to shift forward. When your positions respond to that can't be predicted: that also depends on everything your competitors do in those same weeks.
Can TheSEO help?
Yes. We carry out a full analysis, identify your problem pages and deliver a concrete action plan with priorities. See our approach at improving SEO or dig further into the knowledge base yourself.
If you don't know which chunk of FIG.03 is your problem
The hardest part of Core Web Vitals isn't fixing it but pinpointing it. As long as you don't know whether your loss sits in server time, in the discovery of your hero image, or in a script blocking render, you're paying for work that doesn't move your number. Buying new hosting while the problem sits in chunk 04 is the most expensive way to fix nothing.
You can start yourself right away: run your slowest page through the Core Web Vitals meter and hold the result up against the four chunks from FIG.03. Still can't see which chunk is eating the time, or does your Search Console give you a red group whose culprit URL you can't find, then put it to us once.
Through contact we schedule a half-hour call in which we lay your report, your slowest three URLs and your current hosting side by side. You'll then hear which chunk to tackle first and roughly what that costs, even if the answer is that you can sort it out yourself. Does it turn out to be broader than speed alone, then we'll pick it up as part of improving SEO.