Core Web Vitals

What are Core Web Vitals?

Core Web Vitals are a set of Google-defined page experience metrics that measure loading speed (Largest Contentful Paint), responsiveness (Interaction to Next Paint) and visual stability (Cumulative Layout Shift). Each metric tracks something a visitor can feel: how fast the main content appears, how quickly the page reacts to a tap or click, and whether the layout jumps around.

Core Web Vitals sit inside the wider field of technical SEO. Our Technical SEO guide covers the other factors that affect how search engines crawl and render a site.

• Largest Contentful Paint (LCP): how long the largest visible element, such as a hero image or headline, takes to load.
• Interaction to Next Paint (INP): how long the page takes to respond visually after a user taps, clicks or types.
• Cumulative Layout Shift (CLS): how much visible content moves unexpectedly while the page loads.

Lab data is performance measured in a controlled test, with a fixed device and network. It is useful for debugging because you can repeat the test after each fix.

Field data is performance collected from real visitors using real devices and connections. Google uses field data to assess Core Web Vitals, so a page can pass a lab test and still fall short in the field, especially for visitors on slower phones.

Why do Core Web Vitals matter for your business?

Core Web Vitals matter because slow, jumpy or unresponsive pages frustrate visitors and Google uses page experience as one of many ranking signals, though good scores alone do not guarantee rankings. For a business, the practical effect shows up in how people behave on your pages.

Effect on user experience and conversions: a page that loads its main content slowly, shifts while someone is about to tap, or reacts late to a click gives visitors a reason to leave. On a product page, booking form or checkout, that friction can cost enquiries and sales. The size of the effect depends on your audience, devices and how far the page falls short.

• Slow main content makes visitors wait before they can read or buy.
• Layout shifts cause mis-taps, such as hitting the wrong button.
• Delayed responses to taps make forms and menus feel broken.
• Mobile visitors on slower connections usually feel these problems most.

Role in Google search: Google includes page experience, which covers Core Web Vitals, among the signals it uses to rank pages. Relevance and content quality typically carry more weight, so a fast page with weak content will not outrank a strong, relevant one. Treat the metrics as a tiebreaker and a quality floor, not a shortcut.

Our Technical SEO guide shows where page speed sits alongside crawling, indexing and site structure.

What is a good score for each Core Web Vital?

Google publishes 'good' thresholds for each metric, and a page passes when most real-user visits meet them; confirm current numbers in Google's documentation before reporting. Thresholds can be revised, so a figure copied from an old article may be out of date.

Each metric has its own scale, and each is measured in different units. Largest Contentful Paint (LCP) is measured in seconds and times how long the main content takes to appear. Interaction to Next Paint (INP) is measured in milliseconds and times how quickly the page responds to taps, clicks and key presses. Cumulative Layout Shift (CLS) is a unitless score that captures how much visible content jumps around.

Google groups results into three bands: good, needs improvement and poor. Your goal is to land in the good band for all three metrics.

Google assesses the 75th percentile of real visits. That means 75% of page loads must meet the good threshold for a metric to pass. A few fast visits on a strong connection do not offset a slow majority, and one slow visit does not fail the page.

• Use field data (real users) for pass or fail decisions.
• Use lab tests to diagnose causes, not to report results.
• Check mobile and desktop separately, because they are assessed apart.
• Record the date you read the thresholds in your report.

Our technical SEO guide covers how these metrics fit into wider site health.

How do LCP, INP and CLS compare?

A comparison table shows that LCP measures load speed, INP measures responsiveness to input, and CLS measures layout shift, each with different usual causes such as heavy images, long JavaScript tasks or missing image dimensions.

The three metrics rarely share one fix. A page can load its main image fast and still feel sluggish to tap, or respond well and still shift as an ad loads.

Because the causes differ, diagnose each metric separately before changing anything. Our Technical SEO guide covers how these checks fit into a wider site review.

How do you check your Core Web Vitals?

You can check Core Web Vitals with the Core Web Vitals report in Google Search Console for real-user data and with PageSpeed Insights or Lighthouse for page-level diagnosis. Start with Search Console to see which groups of pages have a problem, then use the page-level tools to find the cause.

Search report and PageSpeed Insights: the Search Console report groups URLs as good, needs improvement or poor, separately for mobile and desktop. PageSpeed Insights then tests one URL. It shows field data from real visitors, when enough exists, above a lab test with specific suggestions.

1. Open the Core Web Vitals report in Search Console and note the failing metric and URL group.
2. Pick a representative URL from that group.
3. Run it through PageSpeed Insights and read the field data first.
4. Use the diagnostics and Lighthouse results to find the cause, such as a large hero image or a slow script.
5. Fix the issue, then watch the Search Console report for changes.

Lab tests and real-user data differ because they measure different things. A lab test, such as Lighthouse, loads a page once on a fixed simulated device and connection. Real-user data, often called field data, collects results from actual visitors on varied phones, networks and locations over a period of weeks.

Lab results are useful for debugging because you can repeat them immediately after a change. Field data is what Google reports on, so it is the number to judge success by. Field data updates slowly, so a fix may take several weeks to show in Search Console.

If you want help reading the results, our SEO services include technical audits, and our technical SEO guide covers related checks.

How do you improve Core Web Vitals? A step-by-step checklist

Improve Core Web Vitals by identifying failing page templates, compressing and sizing images, reducing blocking JavaScript, reserving space for dynamic elements, then retesting in field data. Work on one template at a time, so you can see which change moved which metric.

1. Fix the slowest template first: group URLs by template (product, article, category) and start with the one that fails most often and gets the most visits.
2. Compress images, use modern formats, set explicit width and height, and do not lazy-load the main above-the-fold image. This mainly helps LCP.
3. Reduce blocking JavaScript: defer non-essential scripts, remove unused tags and split large bundles. This mainly helps INP and LCP.
4. Reserve space for ads, embeds, banners and late-loading fonts so the layout does not jump. This mainly helps CLS.
5. Retest and monitor after changes: check lab results straight away, then watch field data over the following weeks.

Field data comes from real visitors and is typically reported over a rolling window of about four weeks, so improvements can take time to show. Check it again after each release, since new plugins, tags or design changes can undo earlier fixes.

If you want help prioritising fixes, see our technical SEO guide or contact our team.

How long and how much work does fixing Core Web Vitals take?

Effort depends on your platform, theme, scripts and number of page templates, and field data typically takes weeks to reflect changes because it aggregates real visits over time. A small site with one clean template can need days of work. A large store with many third-party scripts can need several rounds of fixes. These ranges are estimates, not promises.

What affects scope. Core Web Vitals work is scoped by template, not by page, because one fix usually applies to every page built on that template.

• Platform and theme: a heavy theme or page builder adds more to untangle.
• Third-party scripts: chat widgets, tag managers and ad code often slow interaction.
• Page templates: home, category, product and article pages each need checking.
• Media: large hero images and unsized images drive loading and layout problems.
• Access: developer and hosting access speeds up changes.

Why field data lags behind fixes. Field data is collected from real visitors over a rolling period, so old slow visits stay in the average after you ship a fix. Google's Search Console report typically needs several weeks to show a clear change. Lab tests update immediately, so use them to confirm a fix worked while you wait.

If you want help sizing the work, our SEO services start with a site audit and an agreed work plan before changes go live. Timing depends on site size and how quickly we get account access. You can also read our technical SEO guide or contact us for a scoped estimate.

What mistakes should you avoid with Core Web Vitals?

Common mistakes include optimizing only for lab scores, testing only on desktop, and overlooking third-party scripts such as chat widgets and tags that slow pages. Each one can leave you fixing the wrong problem while real visitors still have a slow experience.

These errors are easy to make because the tools that find them are different, and the numbers often disagree.

Chasing a perfect lab score. A lab score comes from a simulated test on one device and one connection. Field data, which is collected from real visitors, is what shows how your pages actually perform. A page can reach a high lab score and still fail in the field, so treat lab tools as a way to find causes, not as the goal.

Ignoring mobile and third-party scripts. Most sites get a large share of visits from phones, which have slower processors and less stable networks than a developer's desktop. Test on mobile first. Then review every third-party script, including chat widgets, analytics, ad tags and embedded video, because each one adds network requests and main-thread work that can hurt loading and responsiveness.

• Fix one template at a time, then recheck field data rather than a single test run.
• Remove third-party scripts nobody uses, and delay the rest until after the page loads.
• Reserve space for images, ads and embeds so the layout does not shift.
• Retest after every release, since new plugins and tags can undo earlier fixes.

If you want help sorting out which problems matter, see our technical SEO guide or contact our team.