Three letters, three simple questions
Core Web Vitals are three metrics Google uses to judge the real experience of a page, beyond the simple "does it work". Each answers a question a visitor asks without ever putting it into words:
- LCP (Largest Contentful Paint): how long before I see the main content of the page?
- INP (Interaction to Next Paint): when I click or type, does it respond right away?
- CLS (Cumulative Layout Shift): does the page move under my fingers while I'm reading it?
None of the three measures a vague feeling. All three are quantified, measurable for free, and Google publishes the exact thresholds that separate a "good" page from one that "needs improvement" and one that's "poor".
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 to 4 s | > 4 s |
| INP | ≤ 200 ms | 200 to 500 ms | > 500 ms |
| CLS | ≤ 0.1 | 0.1 to 0.25 | > 0.25 |
These three metrics have officially been part of Google's ranking factors since 2021. They don't decide your position on their own, but at equal content quality, the faster, more stable page almost always wins.
Why it matters as much as SEO
The link with Google grabs attention, but the direct business impact matters even more. A visitor who waits more than four seconds before seeing your page has, to a large extent, already left the tab before the content even appears. Someone typing their phone number into a form that takes half a second to react to each keystroke gives up before finishing. Someone who clicks a button that shifts right at the moment of the click — because a cookie banner just popped in above it — often clicks the wrong thing, and doesn't come back.
Core Web Vitals aren't a developer topic, then: they're a conversion topic, one that translates directly into forms submitted and calls received.
How to measure your Core Web Vitals for free
There are two families of tools, and the distinction matters.
Field data (what your real visitors actually experience)
- PageSpeed Insights (pagespeed.web.dev): paste your URL and you get both real visitor data (when traffic is sufficient) and a controlled lab test.
- Search Console, "Core Web Vitals" report: shows the trend over time, grouped by page type, directly on your own site.
- CrUX (Chrome User Experience Report): the public dataset behind the two tools above, also browsable via the "Web Vitals" Chrome extension.
Lab data (a simulated test, useful for diagnosing)
- Lighthouse, built into Chrome DevTools (the "Lighthouse" tab, "Analyze page load" button).
- PageSpeed Insights, which combines both: field data up top, lab data below.
The rule to remember: field data tells you the truth about what your visitors experience; lab data helps you understand why and check that a fix works before publishing it. Always test on mobile first, and if possible simulate a 4G connection rather than the office Wi-Fi: that's the real experience of most of your visitors.
The real causes of slowness, ranked by expected gain
Here, in roughly the order of impact we typically observe, are the most frequent causes and what each one costs each metric.
| # | Cause | Metric affected | Expected gain |
|---|---|---|---|
| 1 | Uncompressed or oversized images | LCP | Usually the biggest gain, sometimes 1 to 2 seconds |
| 2 | Web fonts that block text rendering | LCP, CLS | Moderate to high gain, quick fix |
| 3 | Third-party JavaScript (chat, banners, widgets) running before interaction | INP | High gain, especially on mobile |
| 4 | Slow hosting or server response | LCP | High gain if server response time exceeds 600 ms |
| 5 | Ad elements or banners with no reserved dimensions | CLS | Nearly free fix once identified |
| 6 | No caching or CDN | LCP | Mostly noticeable for visitors far from the server |
| 7 | Heavy animations or carousels on the homepage | INP, CLS | Variable gain, often underestimated |
Cause number one, on the vast majority of SME sites we audit, remains the unoptimised image: a 4 MB photo straight out of a phone, uploaded without compression or resizing onto the homepage. It's also the fastest fix to make, and often the one producing the most visible gain.
Fixing each metric, concretely
Bringing down LCP
- Compress and resize images to the size actually displayed, not the original size
- Use modern formats (WebP, AVIF) rather than unoptimised JPEG or PNG
- Load the main image with priority (
fetchpriority="high") and defer the rest - Reduce server response time: an overloaded shared hosting plan is a frequent and underrated cause
- Avoid loading blocking fonts or scripts before the visible content
Bringing down INP
- Limit the number of third-party scripts loaded at startup (live chat, pixels, review widgets)
- Defer their execution until after the user interacts, rather than at page load
- Break up long JavaScript tasks instead of running a single block that freezes the interface
- Test primarily on an entry-level phone: INP degrades there far faster than on a desktop computer
Bringing down CLS
- Always reserve space (
width/heightattributes oraspect-ratio) for every image and video before it loads - Reserve space for cookie banners and ads before they appear
- Avoid inserting content above what the user is currently reading
- Preload fonts to avoid a layout shift the moment they render
The traps that distort the diagnosis
- Testing only on your own computer, on fibre. Most of your visitors are on mobile, on 4G. The gap can be considerable.
- Trusting a single lab test. A Lighthouse result can vary by 20% between two runs on the same page; favour the trend over several days in Search Console instead.
- Fixing one page and ignoring the rest. Core Web Vitals are measured template by template: an excellent homepage doesn't stop a product page from being a disaster.
- Confusing perceived speed with the displayed score. A Lighthouse score of 95 guarantees nothing if the real field data in Search Console tells a different story — and it's always the field data that counts for ranking.
What we see in practice
When we audit a site before a redesign, the three metrics are rarely all bad at once: it's usually a single structural cause dragging everything down, most often images or undersized hosting. Our maintenance plans starting at €150 a month specifically include ongoing monitoring of these three metrics, precisely because a site that was green at launch can turn red again six months later, as images and plugins pile up unwatched.
If your Core Web Vitals have been in the red for a long time and the cause is structural (hosting, CMS, theme architecture), a one-off fix won't be enough: that's a signal worth weighing against the seven signals that show a redesign is needed.
In summary
- LCP measures how long the main content takes to render (good under 2.5 s), INP measures responsiveness to interactions (good under 200 ms), CLS measures visual stability (good under 0.1)
- Measure for free with PageSpeed Insights and Search Console's Core Web Vitals report, mobile first
- The most frequent and most cost-effective cause to fix remains the unoptimised image
- Fix template by template, not just the homepage
- Monitor over time: a site optimised once can degrade within a few months without ongoing tracking
Want to know where your site stands today, and what should be fixed first? Describe your project in two minutes, and we'll come back with a reasoned diagnosis in under 24 hours: start my project.