What Are Google Core Web Vitals and How to Improve Them

Someone lands on your site from a Google search, and for two full seconds nothing happens. Then, right as they go to tap the button they were reaching for, the page jumps and they hit an ad instead. That's not a bad day. That's a Core Web Vitals problem, and Google has been quietly grading every website on exactly this experience since 2021.

Core Web Vitals are three specific, measurable numbers: how fast your main content shows up, how quickly the page responds when someone clicks or taps, and how much the layout jumps around while it loads. Google pulls these numbers from real Chrome users visiting your site, not a lab test run once and forgotten.

This guide covers what each metric actually measures, the thresholds Google uses to call a page good, needs improvement, or poor, how to check your own scores in under five minutes, and the specific fixes that move each number in the right direction.

What Are Google Core Web Vitals?

Core Web Vitals are three metrics Google uses to measure real-world page experience: Largest Contentful Paint for loading speed, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability, each scored against fixed thresholds pulled from actual Chrome user data.

Google introduced them in 2020 and folded them into ranking as part of the Page Experience update in 2021. Before that, site speed was measured through a grab bag of metrics that mostly meant something to developers and nothing to a business owner trying to figure out if their site was actually fine. Core Web Vitals replaced that with three numbers anyone can check and understand.

The Three Core Web Vitals Metrics

Each metric targets a different point of frustration in a real visit: waiting too long for content to appear, tapping something and feeling a lag before it responds, and losing your place because the page shifted under your finger.

That 75th percentile detail matters more than most site owners realize. Google doesn't average your scores. It looks at the slowest experience out of every four visits and grades you on that. A page that's fast for most people but drags badly on an older phone or a weak connection will still show up as needs improvement or poor, because that slower quarter of real visits is what actually gets counted.

One metric changed recently and it's worth flagging directly: Interaction to Next Paint replaced First Input Delay as the official responsiveness metric in March 2024. FID only measured the delay before the browser started processing your first click. INP measures the full time from interaction to visible response, across every interaction on the page, not just the first one. It's a stricter, more honest number, and it's why some sites that passed comfortably under FID are suddenly failing under INP.

Why Do Core Web Vitals Matter for SEO?

Core Web Vitals matter for SEO because Google uses them as part of the page experience signal in ranking, and because slow, jumpy pages measurably push visitors to leave before converting, which is a business cost that shows up whether or not Google is involved at all.

Be clear about the scale of the ranking effect, because a lot of blog posts oversell it. Google has said page experience is a comparatively small ranking factor next to content relevance, backlink authority, and matching search intent. A page with mediocre Core Web Vitals and genuinely excellent content will still beat a lightning-fast page full of thin, unhelpful writing. This is one input among many, not a silver bullet, and it's the same honest framing we give clients evaluating any single piece of search engine optimization.

Where Core Web Vitals Actually Move the Needle

The scenario where it matters most is the tie. Two pages targeting the same keyword, similar content depth, similar backlink profiles: Core Web Vitals is exactly the kind of signal that can decide which one gets the edge. Most competitive Mississauga service pages are closer to that tie than business owners assume, which is why we run a Core Web Vitals check as a standard part of every technical SEO engagement rather than an optional extra.

The User Behaviour Case, Separate From Rankings

Set Google aside entirely and the numbers still matter. Slow load times and jumpy layouts push people to abandon a page before they ever see your offer, and a mistimed tap caused by a layout shift is a lost lead, not just a bad metric. Improving user experience and improving Core Web Vitals are, in practice, the same project wearing two different names.

How Do You Measure Core Web Vitals?

Measure Core Web Vitals with Google's free PageSpeed Insights tool, which reports both real-user field data and a simulated lab test for any URL, or check the Core Web Vitals report in Google Search Console for a site-wide view across every indexed page.

Field Data vs. Lab Data

These two data sources answer different questions, and mixing them up is one of the most common mistakes we see. Field data comes from the Chrome User Experience Report (CrUX), a rolling 28-day sample of real visits from real Chrome users on real devices and real connections. It's what Google actually uses for ranking, and it's what shows up in Search Console.

Lab data comes from a single simulated page load, usually via Lighthouse, run under fixed, controlled conditions. It's useful for testing a fix before it ships, and it's the only option for a page that doesn't have enough real traffic yet to generate field data. But it's also a single snapshot on one simulated device, and it can't fully measure INP, since INP requires a real interaction. Lighthouse substitutes Total Blocking Time as the closest lab proxy for responsiveness.

Tools to Check Your Core Web Vitals Scores

• PageSpeed Insights: free, URL-based, shows both field and lab data side by side with specific fix suggestions.
• Google Search Console: the Core Web Vitals report groups every indexed URL by status and metric, which is the fastest way to spot a site-wide problem instead of checking pages one at a time.
• Chrome DevTools: the Performance panel records a real session and shows exactly which script or resource is causing a delay, down to the line of code.
• Chrome UX Report (CrUX): the raw field dataset behind PageSpeed Insights and Search Console, queryable directly for anyone who wants historical trend data.
• web.dev/measure: runs the same Lighthouse audit as PageSpeed Insights with a slightly different report layout, useful as a second opinion.

How to Run a Core Web Vitals Check in Under Five Minutes

1. Open PageSpeed Insights and enter your homepage URL, then run the test for both mobile and desktop.
2. Check the field data section first, since that's what Google actually ranks on. If it says "not enough data," the page doesn't get enough traffic yet for a real-user score.
3. Note which of the three metrics, if any, falls into needs improvement or poor.
4. Open the lab data section below it and expand the specific diagnostic tied to the failing metric.
5. Repeat the check on two or three of your highest-traffic pages, not just the homepage, since scores vary page to page depending on content and images.

How Do You Improve Largest Contentful Paint (LCP)?

Improve LCP by compressing and correctly sizing your largest image or text block, removing render-blocking CSS and JavaScript from the page's critical path, cutting server response time, and preloading the specific resource that renders last, whether that's a hero image, a video poster, or a web font.

• Compress and resize images to the actual dimensions they display at, and serve them in WebP or AVIF instead of uncompressed JPEG or PNG.
• Preload the LCP element specifically, usually a hero image or headline font, so the browser starts fetching it immediately instead of discovering it late.
• Cut server response time (Time to First Byte) through better hosting, caching, or a content delivery network, since nothing else on this list matters if the server itself is slow to answer.
• Remove or defer render-blocking CSS and JavaScript that the browser has to process before it can even start painting content.
• Never lazy-load the LCP image itself. Lazy loading is for images below the fold; applying it to the one image Google is timing just adds delay.

Most LCP problems trace back to one of two root causes: an unoptimized hero image, or a slow server response holding up everything downstream of it. Both are exactly the kind of issue an SEO audit is built to catch before they quietly cost you rankings and leads.

How Do You Improve Interaction to Next Paint (INP)?

Improve INP by breaking up long JavaScript tasks so the main thread stays free to respond to clicks, deferring or removing JavaScript that isn't needed for the initial interaction, and keeping event handlers lean so a tap, click, or keystroke gets a fast visual response instead of sitting in a queue.

• Break long JavaScript tasks (anything over 50 milliseconds) into smaller chunks, so the main thread gets regular breaks to handle a click or tap.
• Defer non-critical JavaScript, like chat widgets, analytics, and third-party embeds, until after the page's core content is interactive.
• Move heavy computation off the main thread with a web worker where possible, since work happening there can't block a user's tap.
• Keep your DOM size reasonable. A page with tens of thousands of DOM nodes makes every style recalculation and interaction slower, even on a fast connection.
• Debounce expensive event handlers, like search-as-you-type or scroll listeners, so they don't fire more often than the interface actually needs.

Third-party scripts are the most common INP offender we find in practice: a chat widget, a marketing pixel, or an embedded form that loads a huge JavaScript bundle and locks up the main thread right when someone's trying to interact. This is exactly the kind of embed-loading problem worth flagging to whoever manages your on-page SEO or dev work before it drags every page down.

How Do You Improve Cumulative Layout Shift (CLS)?

Improve CLS by setting explicit width and height (or an aspect-ratio) on every image, video, and embed, reserving space for ads and dynamically injected content before it loads, and avoiding animations that move layout properties instead of using transform and opacity.

• Set width and height attributes, or a CSS aspect-ratio, on every image and video element, so the browser reserves the correct space before the file finishes loading.
• Reserve a fixed-size slot for ad units and embeds instead of letting them push content down whenever they finish loading.
• Never insert new content above existing content a user is already looking at, unless it happens in direct response to something they clicked.
• Use font-display: optional or swap combined with font preloading, so text doesn't visibly reflow once a web font finishes loading.
• Animate with transform and opacity instead of top, left, width, or height, since the first two don't trigger layout recalculation and the second two do.

CLS bugs are sneaky because they're often invisible in a quick manual check and glaring in the actual data. We've traced a site-wide CLS failure back to a single missing script tag before, the kind of root cause that only shows up when you actually trace real page behaviour instead of guessing from a symptom, which is the same discipline we bring to every SEO audit we run.

Common Core Web Vitals Mistakes to Avoid

• Judging a page by lab data alone, when Google ranks on field data and the two can disagree, sometimes significantly.
• Fixing the homepage and assuming the rest of the site follows, when template and content differences mean scores vary page to page.
• Lazy-loading the LCP image, which delays the exact metric you're trying to improve.
• Adding a caching plugin or CDN and stopping there, without addressing the actual JavaScript or image weight causing the slowdown underneath it.
• Chasing a perfect 100 Lighthouse score instead of the real thresholds. Google grades good, needs improvement, or poor. A 92 and a 100 both pass.

Do Core Web Vitals Guarantee Better Rankings?

No. Core Web Vitals are one of many ranking signals, and Google has repeatedly said content relevance and quality outweigh page experience in most searches. Fixing your scores won't rescue a page with thin or unhelpful content, and it won't outrank a genuinely better answer to the same query.

What it does reliably do is remove a friction point that costs you visitors regardless of where you rank. A visitor who bounces because a button jumped out from under their thumb was never going to convert anyway, and that's true whether Google was watching or not. Treat Core Web Vitals as table stakes, not a growth lever, and the priority becomes clear: fix the technical friction, then put the real effort into content and on-page SEO that actually earns the click.

That's exactly why we treat Core Web Vitals as a standard checkpoint in every technical SEO engagement, alongside things like schema markup and canonical tags: small, unglamorous fixes that rarely make a site rank on their own, but that clear the way for the content and strategy work that does.

Frequently Asked Questions

What replaced First Input Delay in Core Web Vitals?

Interaction to Next Paint (INP) officially replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP measures the response time across every interaction on a page, not just the first one, making it a stricter and more complete responsiveness metric.

What is a good Core Web Vitals score?

Good scores are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less, measured at the 75th percentile of real Chrome visits. Hitting all three puts a page in Google's good category for page experience.

Do Core Web Vitals affect mobile and desktop rankings differently?

Google scores and reports Core Web Vitals separately for mobile and desktop, and since Google primarily uses mobile-first indexing, your mobile scores generally carry more practical weight. A page can pass comfortably on desktop and still fail on mobile.

How often does Google update Core Web Vitals data?

Field data in the Chrome UX Report and Search Console rolls on a 28-day window, updating daily but always reflecting the trailing four weeks of real visits. A fix you ship today won't fully show up in field data until that rolling window catches up.

Can a fast website still fail Core Web Vitals?

Yes. A page can feel fast on a good connection and still fail on the slower devices and networks that make up part of your real traffic, since Google grades the 75th percentile of visits, not the average or best case.

Does WordPress hurt Core Web Vitals?

Not by default, but a heavy theme, too many plugins, and unoptimized images commonly do. A lean, well-configured WordPress build with proper caching and compressed images can hit good scores across all three metrics without much difficulty.