Google does not just rank pages by words anymore — it measures how your page actually feels to use. Is it fast? Does it respond when tapped? Does the layout jump around while loading? Google bundles these real-user experience measurements into something called Core Web Vitals, and since 2021 they have been an official part of how Google ranks pages. Sites that pass get a ranking edge; sites that fail leave traffic on the table.
The good news: there are only three metrics to understand, the tools to check them are free, and most failures come from a short list of fixable problems. This guide explains each Core Web Vital in plain English — LCP, INP, and CLS — shows you exactly how to check your own scores, and walks through the fixes that move the needle, whether you do it yourself or hand it to a developer.
What Core Web Vitals are (and why Google cares)
Core Web Vitals are three specific measurements of user experience that Google uses as ranking signals. They are not lab guesses — Google collects them from real Chrome users visiting your site (a dataset called the Chrome User Experience Report, or CrUX), then grades each metric as Good, Needs Improvement, or Poor. To “pass,” a page needs all three metrics in the Good range for at least 75% of real visits.
Why does Google care? Because slow, janky pages make people hit the back button, and Google’s entire business depends on search results that satisfy users. Page experience has been a confirmed ranking factor since the 2021 Page Experience update, and while great content still matters most, Core Web Vitals are frequently the tiebreaker between two equally good pages. They also directly affect conversions: studies consistently show that each extra second of load time cuts conversions by a noticeable percentage, so this is revenue, not just rankings.
LCP: Largest Contentful Paint (loading speed)
LCP measures loading performance — specifically, how long it takes for the largest visible element on the page to appear. That is usually your hero image, a big headline block, or a video thumbnail. Think of it as answering the user’s question: “is anything actually showing up yet?”
The thresholds are simple: under 2.5 seconds is Good, 2.5–4 seconds Needs Improvement, and over 4 seconds is Poor. A poor LCP almost always comes from the same culprits: an unoptimized hero image (a 3MB photo where a 150KB one would do), slow server response time, render-blocking JavaScript and CSS that delay everything, or lazy-loading applied to the hero image itself (a surprisingly common mistake — the most important image on the page should load first, not last).
Quick wins for LCP: compress and resize your hero image and serve it in WebP format, preload it so the browser fetches it immediately, upgrade slow shared hosting if your server response time is over 600ms, and remove or defer JavaScript that is not needed for the first screen. On WordPress, a caching plugin plus image optimization (we cover both in our essential WordPress plugins guide) fixes LCP for most sites without touching code.
INP: Interaction to Next Paint (responsiveness)
INP measures responsiveness — how quickly your page reacts when a visitor taps, clicks, or types. Not the first reaction, but the worst one: Google looks at nearly all interactions on the page and scores you on the slowest ones. It replaced the older FID metric in March 2024 because FID only measured the first interaction, which missed most real frustration.
The bar: under 200 milliseconds is Good, 200–500ms Needs Improvement, over 500ms is Poor. Poor INP feels like a site that ignores you — you tap a menu and nothing happens for a beat, you type in a search box and the letters lag behind. The usual cause is JavaScript hogging the browser’s main thread: heavy frameworks, dozens of third-party scripts (chat widgets, trackers, social embeds), and event handlers doing too much work on every keystroke.
Fixing INP is more technical than fixing LCP, but the playbook is clear: cut third-party scripts ruthlessly (every chat bubble, tracker, and widget costs you), break up long JavaScript tasks so the browser can breathe between them, debounce input handlers on search boxes and filters, and avoid loading entire JavaScript frameworks for simple interactions. If your developer mentions “main thread blocking” or “long tasks,” this is what they are talking about.
CLS: Cumulative Layout Shift (visual stability)
CLS measures visual stability — how much the page layout jumps around while loading. You know the experience: you are about to tap a button, an ad or image loads above it, everything shifts down, and you tap the wrong thing. That infuriating jump is layout shift, and CLS adds up every unexpected shift during the page’s life.
Unlike the other two, CLS is not measured in seconds — it is a unitless score, and under 0.1 is Good, 0.1–0.25 Needs Improvement, over 0.25 is Poor. The fixes are refreshingly concrete: always set width and height (or aspect ratio) on images and videos so the browser reserves the space before they load, reserve space for ads and embeds instead of letting them pop in, never insert content above existing content unless the user asked for it, and use font-display: swap carefully so custom fonts do not reflow your text.
CLS is the metric most sites can fix in an afternoon, because it is usually caused by a handful of specific elements rather than deep architecture problems. Cookie banners that push content down, late-loading web fonts, and images without dimensions account for the vast majority of failures we see on client sites.
How to check your Core Web Vitals
You have three free tools, each answering a slightly different question. Start with PageSpeed Insights (pagespeed.web.dev): paste any URL and you get both lab data (a simulated test, instant) and field data (real Chrome user data for that page, when available). The field data is what Google actually uses for rankings — if it says your LCP is Poor for real users, that is the number that counts.
Second, Google Search Console’s Core Web Vitals report shows your whole site at once, grouped by URL patterns that share the same problem — invaluable when you have hundreds of pages, because it tells you “all your blog posts fail CLS because of the same ad slot” instead of making you test pages one by one. Third, the Web Vitals Chrome extension (or Lighthouse in Chrome DevTools) gives you live measurements as you browse, which is perfect for testing fixes in real time.
One important note: lab scores and field scores often disagree, and field data wins. Your site might score 95 in a lab test run from a fast server while real users on mid-range phones with 4G connections experience something much worse. Always optimize for the field data — real users — not the lab number.
Common causes of Core Web Vitals failures
Across hundreds of audits, the same offenders show up again and again. If your scores are poor, check this list before anything else:
- Unoptimized images. The number one cause of poor LCP. Multi-megabyte hero images, PNG screenshots where WebP would be a tenth the size, no responsive sizing for mobile.
- Too many third-party scripts. Chat widgets, analytics, heatmaps, social feeds, ad networks — each one blocks rendering, eats main-thread time (INP), and can shift layout (CLS). Audit them quarterly and kill what you do not use.
- Cheap, slow hosting. If the server takes over a second just to respond, no front-end trick can save your LCP. Time to first byte over 600ms means the hosting is the bottleneck.
- Page builders and bloated themes. Some WordPress themes and builders ship hundreds of kilobytes of CSS and JavaScript on every page. A lean theme is often the single biggest speed upgrade available.
- Web fonts loaded badly. Multiple font weights from Google Fonts, loaded render-blocking, cause both slow LCP and layout shift when text reflows.
- No caching. Every visit regenerating the page from scratch on the server. A caching layer is a one-hour fix with an outsized payoff.
Notice how few of these require rewriting your site. Most Core Web Vitals failures are configuration and asset problems, not architecture problems — which is why a proper speed diagnosis usually pays for itself many times over in recovered traffic and conversions.
How Core Web Vitals affect your SEO
Let us be precise about what passing actually buys you in search rankings. Core Web Vitals are a confirmed ranking factor, but they are a tiebreaker, not a trump card. A fast page with thin content will not outrank a slower page with genuinely better content. But when two pages satisfy the search intent equally well — which happens constantly in competitive niches — the one with Good Core Web Vitals wins.
The indirect SEO effects are arguably bigger. Faster pages get crawled more efficiently (Google allocates each site a crawl budget, and slow pages waste it), have lower bounce rates, and convert better — and user behavior signals feed back into how Google perceives your pages over time. There is also a mobile dimension: Core Web Vitals are evaluated on mobile scores, and with mobile-first indexing, your phone experience is your SEO experience.
Our practical advice: treat Good Core Web Vitals as table stakes, not a growth strategy. Fix them, keep them green with quarterly checks, then invest your real energy in content and authority — which is exactly what our SEO services (from $250/month) focus on once the technical foundation is solid. Speed gets you into the race; content wins it.
Frequently asked questions
What are Core Web Vitals in simple terms?
Core Web Vitals are Google’s three measurements of how a page feels to use: LCP (how fast the main content loads, good under 2.5 seconds), INP (how quickly the page responds to taps and clicks, good under 200 milliseconds), and CLS (how much the layout jumps while loading, good under 0.1). Google uses them as a ranking factor.
How do I check my website’s Core Web Vitals?
Use PageSpeed Insights (pagespeed.web.dev) for any single URL — it shows both lab test data and real-user field data. For your whole site at once, use the Core Web Vitals report in Google Search Console, which groups failing pages by their shared cause. Both tools are free.
What is a good Core Web Vitals score?
A page passes when all three metrics are in the Good range for at least 75% of real visits: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. You do not need perfect scores — moving from Poor to Good captures nearly all of the ranking and conversion benefit.
Do Core Web Vitals really affect Google rankings?
Yes, they are a confirmed ranking factor since 2021, but they work as a tiebreaker rather than a trump card — great content still matters most. Their indirect effects are often bigger: faster pages have lower bounce rates, get crawled more efficiently, and convert better, all of which compound your SEO results over time.
Why do my lab scores differ from real-user Core Web Vitals?
Lab tests simulate a visit under controlled conditions, while field data comes from real Chrome users on real devices and connections — often mid-range phones on mobile networks. Field data is what Google uses for rankings. If lab scores look fine but field data is poor, optimize for slower devices: smaller images, fewer scripts, and faster hosting.
How long does it take to fix failing Core Web Vitals?
Common fixes like image optimization, caching, and setting image dimensions take a few hours to a couple of days. Deeper issues like JavaScript bloat or slow hosting can take 1–3 weeks. After fixing, allow up to 28 days for Google’s field data to reflect the improvement, since it is based on a rolling window of real visits.
Like what you just read?
Tell us about your project and get a clear, fixed quote within 24 hours — free, no obligation.
Get a free quote →