Your website feels fine to you. It opens instantly on the laptop in the office, the menu works, nothing looks broken. Then Search Console emails to say a group of your pages has a "poor" score for something called Interaction to Next Paint, and somebody sends you a screenshot of a red circle with the number 34 in it. Core Web Vitals is why both of those things happened. It is Google's attempt to put numbers on whether a page feels good to use, measured on your customers' phones rather than on your desk.
The three metrics are straightforward once somebody explains what they measure and what breaks them. The confusion comes from the tooling, which reports two kinds of data in two places that routinely disagree. Here is all of it in plain English, ending with the short list of fixes that actually move the numbers.
Key takeaways
- Core Web Vitals are three numbers: how fast the main content appears, how quickly the page responds to a tap, and how much it jumps about while loading.
- The published good thresholds are 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift.
- Interaction to Next Paint replaced First Input Delay in March 2024, and it is a harder test, so sites that used to pass now fail.
- PageSpeed Insights and Search Console disagree because one runs a simulated test and the other reports real Chrome visits from the last 28 days.
- Scores come from the 75th percentile of real visits, so a fast page on your own phone proves nothing.
- The same culprits do most of the damage: oversized images, too many scripts, late fonts and cheap hosting.
- Core Web Vitals are a small ranking input. Treat them as a conversion problem with a Google report attached.
Who this guide is for
This is written for the person who owns the business, not the person who owns the code. You do not need to know what a render-blocking resource is, and by the end of this you still will not. What you will be able to do is read the report, decide whether you have a real problem, and have a sensible conversation with whoever maintains your site.
It is most useful if your site was built a few years ago and has quietly accumulated plugins, tracking tags and a chat widget nobody remembers installing. That is where Core Web Vitals problems cluster, and where the fixes are cheap. If your site is hand-built on modern hosting, you are probably passing already.
One warning first. There is a whole industry selling speed optimisation on the strength of a scary-looking score, and much of it goes to businesses whose actual problem is that nobody can find their services page. Speed is worth fixing. It is rarely the most valuable thing on your list, and the section on rankings is honest about that.
What Core Web Vitals actually measure
Google has been talking about page speed for over a decade, and for most of that time the numbers on offer were unhelpful. "Page load time" sounds precise but means very little. A page can finish loading in eight seconds while looking ready after one, then rearrange itself under your thumb.
Core Web Vitals were the answer. Instead of measuring when the browser stops working, they measure three moments a human would notice: when the page looks like it has arrived, whether it responds when you touch it, and whether it stays where you put it.
| Metric | What it measures | Good score | Usual cause of a bad one |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How long until the biggest visible thing appears | Under 2.5 seconds | An oversized hero image, or slow hosting |
| Interaction to Next Paint (INP) | How quickly the page responds when tapped | Under 200 milliseconds | Too much JavaScript: chat widgets, tags, page builders |
| Cumulative Layout Shift (CLS) | How much the page moves while loading | Under 0.1 | Images without dimensions, injected banners, font swaps |
Notice that two of the three are about restraint rather than technology. You do not need a faster website so much as a lighter one, which is why the cheapest fixes tend to be deletions.
Why Google wanted real-world numbers
The old measurements were taken from the browser's point of view rather than the visitor's. A page could score well on paper while feeling awful, because nothing in those numbers described tapping a button and having nothing happen for half a second.
Chrome also gathers performance data from users who have opted in to sharing usage statistics, so Google has a picture of how sites behave on real phones on real networks. Core Web Vitals were built to be collected that way.
What Core Web Vitals are not
They are not a measure of whether your website is any good. A page can score three greens and still fail to explain what you do, hide the phone number and lose every enquiry. Google is measuring the mechanics, not the usefulness.
They are also not the score out of 100 that everybody screenshots. That is a lab estimate built from different measurements, and you can pass Core Web Vitals with a mediocre score or fail with a good one. Confusing the two is the most common source of panic we see.
Largest Contentful Paint, or how long until the page looks ready
Largest Contentful Paint measures how long it takes for the biggest piece of content in the visible part of the page to appear. On most small business sites that is the hero image, or the headline sitting over it. The clock stops when that element is drawn.
The threshold is 2.5 seconds. Under that is good, 2.5 to 4 seconds needs improvement, and over 4 seconds is poor. Those numbers come from real visits, so a slow phone on a weak signal counts as much as your laptop on fibre.
What counts as the largest element
The browser looks at what is visible without scrolling and picks the largest block of content by area. Usually that is an image or a background image on the hero section. On a text-heavy page it can be a heading.
This matters because it tells you where to look. If your score is bad, one specific element is responsible and PageSpeed Insights will name it. You are not optimising a whole site, usually just one image at the top of one template.
What usually causes a bad one
The cause is almost never exotic. It is a photograph that came straight off a phone or a stock library at 4,000 pixels wide and several megabytes, dropped into a slot that displays it at 800 pixels. The browser has to download all of it before it can show any of it.
The second most common cause is a slow server. If your hosting takes a second and a half to start sending the page, most of the budget is gone before an image has begun downloading.
- Oversized or wrong-format images. A 3MB JPEG where a 120KB WebP would look identical at the size shown.
- Hero sliders. They load several large images to show one, and the visitor waits for the slowest.
- Render-blocking fonts and scripts. While the browser waits on a stylesheet or font file, it will not draw your headline.
Interaction to Next Paint, or how the page feels when you tap it
Interaction to Next Paint measures the delay between a visitor doing something and the page visibly responding. Tapping a menu, opening an accordion, ticking a box, hitting submit. It records how long the screen took to change in reply.
The threshold is 200 milliseconds, a fifth of a second. Between 200 and 500 milliseconds needs improvement and anything over 500 milliseconds is poor. That sounds tight until you remember that half a second after a tap is long enough for someone to tap again, assume it is broken, or leave.
What changed when INP replaced FID in March 2024
The metric it replaced, First Input Delay, only looked at the very first interaction on a page, and only measured the wait before the browser started dealing with it. It did not care how long the work then took, which made it an easy test that nearly everybody passed.
Interaction to Next Paint looks at interactions across the whole visit and follows them through to the screen actually updating. In practice it reports roughly the worst interaction on the page. Plenty of sites failed the moment the switch happened, without changing a thing.
What makes interaction sluggish
Interaction problems are nearly always JavaScript problems. The browser can only do one thing at a time where interactions are handled, so if a script is busy your tap sits in a queue. The more scripts, the longer the queue.
On a small business site that queue is made of things that were each individually reasonable. A chat widget, a cookie banner, a booking embed, analytics, a heatmap tool from a redesign, a review carousel, a page builder shipping scripts for every feature the theme supports. None of them is the problem. All of them together are.
Tag managers are the quiet version of the same thing. Nobody ever removes the tracking pixel for a campaign that ended in 2022, so the list only grows, and every one of those tags is code your visitor downloads before the page will answer a tap.
Cumulative Layout Shift, or the page that will not sit still
Cumulative Layout Shift measures how much the content moves around while the page is loading. You start reading a paragraph and it slides down. You go to tap "Contact", an image finishes loading above it, and you tap "Careers" instead.
The score is not a time. It is a unitless number combining how much of the screen moved and how far, added up as the page loads. Under 0.1 is good, 0.1 to 0.25 needs improvement, above 0.25 is poor. It is the one metric where a bad score is obvious to the naked eye.
Layout shift is the only one of the three that customers complain about by name. Nobody will tell you your Largest Contentful Paint is 3.1 seconds. They will absolutely tell you the page jumped and they pressed the wrong thing.
Images and embeds with no reserved space
The classic cause is an image with no width and height set in the HTML. The browser does not know how tall it will be until it has downloaded it, so it lays the page out as though the image takes no space, then shoves everything down when it arrives.
The fix is genuinely that simple. Give every image its dimensions so the browser can reserve the space before the file lands. The same goes for video and map embeds. Anything that arrives late and takes up room needs its room booked in advance.
Banners, cookie bars and late-loading fonts
The second cause is anything injected at the top of the page after rendering has started. A cookie banner, a delivery notice, a "closed for Christmas" bar. If it appears above the existing content and pushes it down, every visitor gets a shift.
Fonts cause a subtler version of the same thing. The browser shows your text in a fallback first, then swaps to your web font once it downloads. If the two are different widths, every line reflows at the swap, which on a text-heavy page can be enough to fail on its own.
Lab data, field data, and where to see your real numbers
This is the part that causes the most confusion, and once it clicks the rest of the tooling makes sense. There are two completely different kinds of Core Web Vitals data, collected in different ways, and they will not match. One is a simulation you can run on demand. The other is a recording of what happened to real visitors.
Use them for different jobs. Lab data tells you what to fix. Field data tells you whether you actually pass, and it is the version Google acts on.
What PageSpeed Insights is actually showing you
PageSpeed Insights shows both, stacked, which is exactly why people misread it. The section at the top labelled as real user experience is field data. The score out of 100 underneath is a lab test on a simulated mid-range Android phone on a throttled connection.
The lab score is not your Core Web Vitals result. It is a diagnostic, and a good one, because it tells you what to fix. The field data at the top is what Search Console reports and what Google uses. If the top says good and the score below says 41, you are passing with less headroom than you would like.
The Core Web Vitals report in Search Console
You will find it under Experience in the left-hand menu, split into Mobile and Desktop. Look at Mobile first, because that is the version Google indexes and where the problems live. The report lists issues such as "LCP issue: longer than 4s (mobile)" with a URL count against each.
Click one and you get example URLs grouped by similarity, and those groups are the useful part. If sixty URLs in a group are failing they almost certainly share a template, so you have one fix rather than sixty. If the tool is new to you, our guide to Google Search Console in plain English covers the rest.
The 75th percentile, and why your own phone is not a measurement
Google does not score you on your average visitor. It uses the 75th percentile, so three quarters of visits have to be at or under the threshold before a page is graded good. Sort a hundred load times fastest to slowest and look at the 75th. At 2.4 seconds you pass, at 2.6 seconds you fail.
That is why the phones your customers use matter more than the phone in your pocket. If a real slice of your audience is on a four-year-old Android on rural mobile data, that slice is what is being measured, and a new handset on office wifi will never show it to you.
It also explains the message plenty of owners see instead of a score. Field data needs enough Chrome visitors to produce a reading, and many smaller sites never get there, so Search Console says there is not enough data. That is not a failure. It means the lab test is your only measurement.
The fixes with the biggest effect
There is an enormous amount of speed advice online, most of it aimed at sites far more complicated than yours. On a typical small business website a handful of things account for nearly all of the available improvement, listed here roughly in order of return for effort.
Work down the list rather than across it. Doing the first two properly pulls most sites from red to green. If somebody proposes a rebuild before the images have been dealt with, ask them why.
Images: size, format and dimensions
This is the big one, and on most sites the only one that really needs doing. Images are the heaviest thing on the page by a wide margin, and almost always larger than necessary, because a phone camera makes files sized for printing.
Three things need to be right. The image should be no bigger in pixels than the space it fills, saved as WebP or AVIF rather than JPEG or PNG, and given its width and height in the HTML. The first two help Largest Contentful Paint, the third fixes Cumulative Layout Shift.
- Resize before uploading. A full-width hero rarely needs more than 2,000 pixels across, and a thumbnail needs a few hundred.
- Convert to WebP. Usually a large saving at the same visible quality, and every current browser supports it.
- Serve different sizes to different screens. A phone should not download the desktop hero image.
Lazy loading, used carefully
Lazy loading tells the browser not to fetch an image until the visitor scrolls near it. On a long page with twenty photographs that is a big saving, because most people never reach the bottom.
The rule is simple and frequently broken. Lazy load everything below the fold and nothing visible when the page opens. Optimisation plugins default to lazy loading the lot, which delays the hero image. If a plugin made your score drop, this is usually why.
Fewer plugins and third-party scripts
Every plugin and embedded tool adds code that has to be downloaded, parsed and run before the page can respond. This is the main lever on Interaction to Next Paint, and unlike the image work it needs a decision rather than a technique.
Go through what is installed and be ruthless. The chat widget nobody has answered in eight months, the heatmap tool from a redesign two years ago, the social feed showing four photos. Removing three of them beats any amount of caching configuration.
Fonts and hosting
Web fonts are an easily missed cause of both slow rendering and layout shift. Host them yourself rather than calling them from elsewhere, load only the weights you use, and pick a fallback with similar proportions. Most sites load five weights and use two.
All of this assumes the server answers promptly. Google's guidance is to keep server response under roughly 0.8 seconds, and budget shared hosting often misses that at busy times. The symptom is a site that is quick in the evening and slow when customers are looking.
How much this actually matters for rankings
Where they sit as a ranking factor
Here is the honest position. Core Web Vitals are a ranking input, Google has confirmed that, and they are a small one. They work more as a tie-breaker between pages that are otherwise similarly useful than as a lever you can pull to climb the results.
In practice a fast page with thin content will not outrank a slower page that genuinely answers the question. If your services page is not ranking, the likelier problem is that it does not say what you do in the words people search for. We would fix the content first every time.
The reason that actually matters
The stronger argument has nothing to do with Google. A page that takes four seconds to appear, jumps under somebody's thumb and then ignores the first tap on the contact button loses enquiries from people who were ready to get in touch. You will never see those in a report, because they leave before anything is recorded.
So treat the report as a health check rather than a target. Green is nice, but a site somebody can use on a phone in a car park is the point. For where speed sits among everything else technical, see our guide to what technical SEO actually is.
Common mistakes
Most of the damage we see is not caused by ignoring Core Web Vitals. It is caused by taking them too seriously, in the wrong order, usually after somebody selling a fix has shown the owner a red score.
The pattern behind all of them is chasing a number rather than an experience. A site can be tuned to score well on a test while remaining unpleasant to use, and that effort is not being spent on the pages that bring in work.
Read the list against what you have actually done rather than what you meant to do. The gap between the two is where most of these live.
- Chasing 100 out of 100. The lab score is a diagnostic, not a target. Passing the three field thresholds is the finish line.
- Installing three optimisation plugins. They conflict, they double-minify and they break layouts. One, or none.
- Judging a fix after a week. Field data moves on a 28-day window. Give it a month.
- Testing on your own phone and calling it evidence. A new device on office wifi with a warm cache is the best case, not the 75th percentile.
- Lazy loading the hero image. The most common self-inflicted Largest Contentful Paint problem there is.
- Reading "not enough data" as a fault. It means low traffic, nothing more.
- Optimising the homepage only. People land on service pages from search, and those share a template nobody has tested.
A realistic plan
This is roughly a morning's work spread over a few weeks, most of which is waiting for data rather than doing anything. The sequence matters, because the first few steps normally solve the problem and the later ones are only worth doing if they have not.
Do not start by changing things. Start by finding out whether you have a problem at all, because a surprising number of sites that get sold speed work were already passing.
- Check Search Console first, ten minutes. Open the Core Web Vitals report, look at Mobile, note which metric is failing and how many URLs. If it says there is not enough data, skip to step three.
- Identify the template, ten minutes. Run one failing URL from each group through PageSpeed Insights. Note the named Largest Contentful Paint element and anything listed as shifting.
- Fix the images, one to two hours. Resize and convert the heroes on your main templates, confirm width and height are set, and check the top image is not lazy loaded.
- Audit what is installed, thirty minutes. List every plugin, tag and embed, then remove anything nobody has used in six months. Be honest about the chat widget.
- Check the server, thirty minutes. Find your server response time in the PageSpeed diagnostics. If it is consistently over a second, talk to your host.
- Tidy the fonts, thirty minutes. Host them yourself, cut the weights you do not use, set a fallback.
- Wait a month, then look again. Reopen the Search Console report and compare.
If step seven still shows red, bringing in help is a reasonable decision rather than a reflex. You will also be able to describe the problem precisely, which produces better quotes than "somebody said my site is slow".
Frequently asked questions
What are good Core Web Vitals scores?
Why does PageSpeed Insights look bad when Search Console says my pages are fine?
My report says there is not enough data. Is something wrong?
What happened to First Input Delay?
How much do Core Web Vitals affect my Google rankings?
Will an optimisation plugin fix this for me?
Should I rebuild my website to pass Core Web Vitals?
Where this fits
Core Web Vitals are worth understanding and not worth obsessing over. They describe something real, which is whether your website is pleasant to use on a phone with a middling signal, and they are the only free standardised measurement of that available. Treat them as an annual health check rather than a scoreboard.
If you take one thing away, make it the order of operations. Look at the real data before changing anything, fix the images before touching the code, and remove scripts before adding tools. If speed in general is your question rather than these three metrics, our guide to how fast a small business website should be is the wider version of this conversation.
If you would rather not spend the afternoon, this is the sort of thing we deal with routinely. Our web design work builds sites that pass these thresholds by construction rather than by bolting on plugins, and our SEO work treats speed as one input among several. If you want a straight answer about whether your site has a real problem, get in touch and we will tell you honestly, including when the answer is that you have better things to spend money on.
