What are Core Web Vitals? They are three metrics Google uses to grade the real-world experience of loading and using a web page: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). A page passes when it hits "good" on all three for most real visitors. They feed Google's page experience signals and can act as a ranking tiebreaker.
What are Core Web Vitals? The 60-second version
Google can't sit on your couch and watch your site feel slow. So it picked three things it can measure that stand in for "this page is a pain to use," and named them Core Web Vitals.
Each one targets a different frustration:
- Largest Contentful Paint (LCP) measures loading. How long until the biggest thing on screen (usually a hero image or headline) shows up?
- Interaction to Next Paint (INP) measures responsiveness. When someone taps, clicks, or types, how long until the page visibly reacts?
- Cumulative Layout Shift (CLS) measures visual stability. Does stuff jump around while the page loads, so you tap the wrong button right as an ad shoves it sideways?
Google grades each as Good, Needs Improvement, or Poor. Hit Good on all three for most of your visitors and you "pass." That's the whole point.
The thresholds (the only numbers you need)
A page is judged at the 75th percentile of real visitors. Translation: it has to be good for roughly three out of four people, not just on your fancy laptop on office wifi. That last quarter matters more than it sounds, because it's disproportionately your mobile users on mid-range phones and patchy networks. A site that flies on a developer's machine can quietly fail in the field because the 75th-percentile visitor lives in a very different world.
| Metric | Measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading | ≤ 2.5s | 2.5s - 4.0s | > 4.0s |
| INP (Interaction to Next Paint) | Responsiveness | ≤ 200ms | 200ms - 500ms | > 500ms |
| CLS (Cumulative Layout Shift) | Visual stability | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
CLS is a unitless score, not a time. Lower is better, and 0 means nothing moved on you. The other two are wall-clock: seconds for LCP, milliseconds for INP.
One thing that trips people up: passing means all three are Good. Two greens and a red is still a fail. And because Google reports these separately for mobile and desktop, you can pass on one and fail on the other. Mobile is almost always the harder grade, and mobile is almost always where the traffic is, so when the two disagree, fix mobile first.
A note on INP (it replaced FID in 2024)
If you've read older guides, you'll see First Input Delay (FID) listed as the responsiveness metric. That's outdated. Google retired FID and made INP an official Core Web Vital on March 12, 2024. The difference matters: FID only measured the delay before the first interaction, which made it easy to look great while the rest of the page felt sluggish. INP measures responsiveness across the whole visit and reports close to the worst interaction. It's a harder, more honest test. If your tooling still talks about FID, it's behind.
How Core Web Vitals are measured
There are two flavors of measurement, and confusing them is where most "but my score was 100" arguments come from.
Field data (this is what Google uses for ranking)
Field data, also called RUM (Real User Monitoring), comes from actual Chrome users hitting your site, collected in the Chrome User Experience Report (CrUX). This is the data that feeds Google Search Console's Core Web Vitals report and influences search. It reflects real devices, real networks, real distance from your server. It's also a 28-day rolling average, so a fix you ship today won't show up in your "pass" status for weeks.
One catch worth knowing: CrUX only has enough Chrome traffic to report on URLs that get a meaningful number of visitors. Low-traffic pages won't show individual field data at all, so Google leans on data from similar pages on your site (the same template or page group). Practically, that means you fix Core Web Vitals at the template level: get your product template or blog template right once, and every page built on it benefits.
Lab data (this is for debugging, not grading)
Lab data comes from tools like Lighthouse and PageSpeed Insights, which load your page in a controlled, simulated environment. Great for finding why something is slow. But a perfect lab score does not mean you pass, because your real visitors aren't all running a throttled test on a clean machine. Use lab data to diagnose; use field data to know where you stand.
If someone shows you a green Lighthouse score and calls the job done, they measured the wrong thing. CrUX is the scoreboard. Lighthouse is the practice field.
Are Core Web Vitals a ranking factor? (the honest answer)
Yes, but calm down. They're a confirmed part of Google's page experience signals, and they're real. They are not a magic lever.
Here's the straight version: Core Web Vitals are best understood as a tiebreaker. When two pages are roughly equal on relevance, content quality, and authority, the better experience can win the spot. What they will not do is float thin content to the top, or rescue a page that doesn't deserve to rank in the first place. Google has said as much, repeatedly: relevance and helpfulness come first.
So where's the actual payoff?
- As a ranking input: modest. A genuine edge in close races, especially on mobile, and nothing to ignore at scale.
- As a conversion input: this is the bigger story. Slow, janky pages bleed money regardless of rank. Every extra second of load drops conversions, and a layout that shifts under someone's thumb torches trust. The revenue case for fixing Core Web Vitals is usually stronger than the rankings case, which is exactly why speed work and conversion rate optimization belong in the same conversation rather than separate budgets.
Treat Core Web Vitals as table stakes, not a strategy. They sit inside the broader discipline of technical SEO: the plumbing that lets your good content get found, crawled, and trusted. Pass the Vitals so they're never the reason you lose, then go win on the things that move rankings: content depth, topical authority, links, and (in 2026) showing up in AI answers.
What breaks each metric, and what to do about it
Knowing the score is useless if you don't know what's dragging it down. Here are the usual suspects for each metric, plus the fix that tends to move the number most.
LCP (slow loading). Culprits: oversized, uncompressed hero images; render-blocking CSS and JavaScript; slow server response (TTFB); no CDN; fonts that block text from painting; client-side rendering that makes the browser do all the work before anything appears. The highest-leverage fix is almost always the hero image itself: serve it in a modern format (WebP or AVIF), size it to the actual display dimensions, and preload it so the browser fetches it early instead of discovering it late. Then kill the render-blocking resources stacked in front of it.
INP (sluggish response). Culprits: heavy JavaScript hogging the main thread; bloated third-party scripts (chat widgets, tag managers, ad tech, "just one more" analytics pixel); long tasks that freeze the page while it "thinks" after a click. The fix is subtraction, not addition: audit every third-party script and cut the ones that don't earn their weight, defer or lazy-load the rest, and break up long JavaScript tasks so the browser can respond between them. Most INP problems are a script problem wearing a costume.
CLS (jumpy layout). Culprits: images and embeds with no width/height set; ads and banners injected after load; fonts that swap and reflow text; content pushed down by something loading late, right as the user reaches for a button. The fix is to reserve space before content arrives: set explicit dimensions on every image and embed, pre-size ad slots, and use font-display settings that don't reflow the whole page when the custom font finally loads.
Most failures trace back to two root causes: too much JavaScript and images doing too much work. Fix those two and you've usually fixed most of the page. This is also why CWV problems tend to surface during a website redesign, where a new theme, a fresh stack of plugins, and an unoptimized image library can quietly tank scores that used to pass.
How to check your own Core Web Vitals
Free, fast, no login for the basics:
- Google Search Console → Core Web Vitals report. The field-data view of your whole site, grouped by issue. Start here. This is the scoreboard Google sees.
- PageSpeed Insights (pagespeed.web.dev). Drop in any URL. Shows real-user CrUX data and a Lighthouse lab audit with specific fixes, side by side.
- Chrome DevTools (Lighthouse + Performance panels). For developers who want to profile exactly which script is eating the main thread.
Check field data first to learn where you stand, then use lab tools to learn why. If your scores were fine and then slid, treat it like any other diagnostic: a sudden drop in Vitals is one of the quieter reasons website traffic starts dropping, and it's easy to miss because the page still looks fine on your screen.
Stop guessing whether your site is fast enough
Most sites fail Core Web Vitals for two boring reasons: too much JavaScript and images doing too much work. Both are fixable. The catch is that the team who built a slow site is rarely the team that knows how to make it fast.
We build sites that pass these out of the box, because performance isn't a plugin you bolt on at the end, it's how the thing is engineered from the first line. If your current site is already live and losing the tiebreaker, our technical SEO work is where we untangle the why and ship the fixes. Want a straight read on where you stand, in plain English, with the actual fixes? See how we build for speed, or email us at admin@moonsauceagency.com. No pressure and no jargon, just the real picture.
Related reading: Technical SEO · Crawl Budget · Conversion Rate · Back to the Glossary
Sources: Understanding Core Web Vitals and Google search results, web.dev Web Vitals, Interaction to Next Paint is officially a Core Web Vital. Last updated June 2026.
