Core Web Vitals are the three metrics Google uses to measure real user experience: how fast the page loads, how quickly it responds to a tap, and how stable it stays while loading. We run this checklist on every project before we touch content or links, because a slow site burns budget on traffic that never converts. Below is the order we use to diagnose and fix each metric, with the real thresholds and examples from our own stores. No myths like “2 seconds or you’re dead” — we’ll show you where the threshold actually matters and where “needs improvement” is good enough to leave alone.
What Core Web Vitals Are and Why They Matter
Core Web Vitals are a subset of the broader page experience signals, and Google picks them for one reason: they reflect what a user actually feels on the page. Not an abstract “speed score,” but specific moments of friction — waiting for content, a lag after a click, a layout that jumps under your thumb. For a business, that maps straight to bounce rate and lost leads, so we treat these metrics as part of usability, not as an SEO checkbox.
The Three Metrics in Plain English
LCP (Largest Contentful Paint) measures how long the largest visible element takes to render — usually the hero image or headline. INP (Interaction to Next Paint) measures responsiveness: the time from a user action to a visible response. CLS (Cumulative Layout Shift) measures visual stability — how much elements jump around while the page finishes loading. Together they describe three different feelings: how long did I wait, did it respond to my tap, and did everything stay put.
Why Google Made Them a Ranking Signal
Let’s be straight: Core Web Vitals aren’t a magic button for the top of page one. They’re a tiebreaker. When two pages are close on relevance and authority, the faster, more stable one gets the edge. If the content is weak, a perfect LCP won’t save it. That’s why we never sell “speed optimization” as a standalone miracle — it works alongside content and structure as part of SEO services, not instead of them.
The Targets We Aim For
Google sets the thresholds not for a lab ideal but for the 75th percentile of real visits over the last 28 days. In other words, a metric counts as “good” only when three out of four of your users see a good result — on their phones and their connections, not on a developer’s powerful laptop. Here are the values we measure a page against:
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading of the main content | up to 2.5s | 2.5–4s | over 4s |
| INP | Responsiveness to input | up to 200ms | 200–500ms | over 500ms |
| CLS | Visual stability | up to 0.1 | 0.1–0.25 | over 0.25 |
Key point
Don’t chase zero. Moving a metric from “poor” to “good” pays off the most; polishing an already-good score toward perfect is usually wasted budget.
One nuance that saves budget: the goal is “good,” not “zero.” If your LCP is 2.3 seconds, chasing 1.1 seconds at the cost of weeks of engineering isn’t worth it — the ranking gain is negligible. But pulling a metric from “poor” into “good” usually moves the needle for both the user and your bounce rate.
How We Bring LCP Down
LCP almost always comes down to one of three things: a slow server response, a heavy hero image, or render-blocking resources. We start with time to first byte: cheap hosting and no caching can eat 600–900ms before the browser paints anything. Next we tackle the hero image — compress it, serve a modern format, set its dimensions, and load it with priority, while everything below the fold gets deferred instead. We also pull render-blocking CSS and fonts out of the critical path. On one of our stores, that combination — caching, image compression, and preloading the banner — took LCP from 4.1 to 2.2 seconds without rewriting the template. We handle this work as part of performance optimization.
How We Keep INP in Check
In March 2024, INP officially replaced the old FID metric — and that’s not cosmetic, it’s a tougher bar. FID measured only the delay on the first interaction, while INP looks at responsiveness across the whole visit: every click, tap, and keystroke. The usual culprit behind a poor INP is heavy JavaScript that blocks the main thread for too long. We hunt down long tasks, break them into smaller chunks, drop unnecessary third-party scripts (chat widgets, popups, analytics that pull in hundreds of kilobytes), and defer anything the first screen can do without. A well-built front end matters more here than any plugin — so we write the code with this in mind from the start instead of patching it later, as we cover in our piece on clean technical code.
Where Layout Shift Comes From
CLS frustrates users the most: you reach for a button, everything jumps under your thumb, and you tap the wrong thing. The causes are almost always the same — images and videos without set dimensions, banners and widgets that load late and push content down, web fonts that force the text to repaint, and blocks that JavaScript injects above already-visible content. The fix is technically boring but effective: set width and height on media, reserve space for ads and dynamic inserts ahead of time, and load fonts carefully. In most cases, getting CLS to “good” is a few hours of careful work, not a site rebuild.
Lab Data vs. Field Data, and Why They Disagree
The confusion usually starts because PageSpeed Insights shows two blocks. At the top is field data (real visits, that same 75th percentile over 28 days), which is what Google judges the page on. Below it is a Lighthouse lab test: a single synthetic run on an emulated device. They almost never match, and that’s fine — the lab is useful for diagnosing what’s slow, but the verdict on a page comes from field data. The Core Web Vitals report in Search Console is the easiest way to track this across your site — we covered how to read it alongside analytics in our piece on GA4 and Search Console reports. If a new page isn’t in the field yet, lean on the lab, but don’t treat it as a verdict.
The Tools We Measure With
For diagnosis we use PageSpeed Insights, which shows field and lab data side by side, and the Performance panel in Chrome DevTools to see exactly which scripts block the main thread. For trends across the site, the Core Web Vitals report in Search Console groups pages by type and flags what has slipped into “poor.” And for ongoing monitoring on live traffic, we collect real-user metrics with the web-vitals library — that way we catch a regression before Google does, instead of waiting 28 days for it to settle into the field.
The Mistakes We See Most Often
The same misses show up on audit after audit. Here are the ones that cost the most:
- Optimizing the lab score instead of the field score: pushing Lighthouse to 100 while real mobile users still see “poor.”
- Fixing the homepage when the money comes from product and category pages — which stay slow.
- Loading five third-party scripts and then wondering why INP is poor, when half of them aren’t needed at all.
- Forgetting mobile: testing on a desktop with a wired connection while Google judges by 4G on a mid-range phone.
- Chasing perfect numbers where a metric is already “good” instead of pulling pages out of “poor.”
- Doing a one-time pass before launch and never monitoring again — six months later, new banners and plugins quietly undo it.
How We Build Core Web Vitals Into the Work
A standalone “speed optimization” once a year doesn’t hold. We build Core Web Vitals into the process: it starts with a technical audit that measures all three metrics across your key page types, then we prioritize by a simple rule — fix what’s in the “poor” zone and brings traffic first. If the problem is in the foundation of the site, we fix it as part of development rather than papering over it with plugins. And just as important, we leave monitoring in place so the next redesign or marketing script doesn’t quietly roll it all back.
The Takeaway
Speed isn’t the goal — it’s how you stop losing users and leads over technical details.
Core Web Vitals aren’t an end in themselves or a magic button — they’re a way to stop losing users over technical details. Start simple: measure the three metrics on your homepage, a product page, and a category page, and pull whatever brings traffic from “poor” into “good.” That’s enough to see a real effect without rewriting the site. If you want to see where your site is losing ground on speed and stability, we’ll run an audit and show you the specific places to improve.
Frequently asked questions
What are Core Web Vitals
They're the three metrics Google uses to measure real user experience: LCP (how fast the main content loads), INP (how quickly the page responds to input), and CLS (visual stability, meaning whether the layout jumps). Together they describe how a person actually experiences the page.
What counts as good Core Web Vitals scores
Good means LCP up to 2.5 seconds, INP up to 200 milliseconds, and CLS up to 0.1. The score is taken at the 75th percentile of real visits over the last 28 days, so a metric is only "good" when three out of four users see a good result on their own devices.
How is INP different from the old FID metric
In March 2024, INP replaced FID. FID measured only the delay on the first interaction, while INP looks at responsiveness across the whole visit — every click and tap. It's a tougher bar, and the main cause of a poor INP is heavy JavaScript that blocks the main thread.
Why does PageSpeed show one thing and Search Console another
PageSpeed Insights gives two blocks: field data (real visits, which Google judges by) and a Lighthouse lab test (one synthetic run). They almost never match. The verdict on a page comes from field data, while the lab is there to help you diagnose the cause.
How long does it take to fix Core Web Vitals
CLS and basic LCP usually take a few hours — caching, image compression, and setting media dimensions. A tougher INP and deeper front-end issues run from a few days. We can be precise after an audit: it depends on how far into "poor" your pages sit.
Do Core Web Vitals really affect Google rankings
Yes, but they're a tiebreaker, not the main factor. When pages are close on relevance, the faster, more stable one wins. If the content is weak, perfect speed won't save it. That's why we optimize the metrics alongside content and structure, not instead of them.
Co-founder and project manager at heleum.studio. 8+ years managing SEO and web projects: owns strategy, timelines, and results, and personally leads key accounts.
