Core Web Vitals explained: a practical guide for site owners

Core Web Vitals are three field-measured performance metrics — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — that Google uses to quantify real user experience on the web. They are part of Google’s Web Vitals initiative, which aims to give site owners a unified set of quality signals that actually reflect how people experience a page. Google treats them as a ranking signal, but they sit alongside content relevance and other page experience factors rather than replacing them.

The official “good” thresholds, assessed at the 75th percentile of page loads, are:

• LCP ≤ 2.5 seconds (loading speed of the largest visible element)
• INP ≤ 200 ms (responsiveness to user interactions)
• CLS ≤ 0.1 (visual stability — how much the page jumps around)

The three primary tools to check your scores are:

• Google PageSpeed Insights — lab and field data for any URL, instantly
• Google Search Console Core Web Vitals report — field data from real Chrome users, grouped by URL and device
• Chrome User Experience Report (CrUX) — the underlying dataset that powers Search Console’s report

Key takeaways

Core Web Vitals are three field-measured metrics — LCP, INP, and CLS — that Google uses as part of its page experience signals, with performance assessed at the 75th percentile of real user sessions.

Table of Contents

• What do LCP, INP, and CLS actually measure?
• Why Core Web Vitals matter for your business
• How Core Web Vitals are measured: field data vs lab data
• Which tools should you use to check Core Web Vitals?
• How to improve LCP, INP, and CLS
• Common measurement traps and how to prioritise fixes
• A one-day audit and action plan for Australian site owners
• The honest agency take on Core Web Vitals
• Sources

What do LCP, INP, and CLS actually measure?

Each metric targets a different dimension of the user experience. Understanding what each one captures makes it far easier to diagnose problems and explain them to a developer.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element on the page to fully render. That element is usually a hero image, a large heading, or a video thumbnail. A user’s perception of “did this page load?” is closely tied to when that dominant element appears, which is why Google chose it over older metrics like First Contentful Paint.

A slow LCP often comes from unoptimised images, render-blocking JavaScript or CSS, slow server response times, or missing CDN coverage. If your hero image is a 3 MB JPEG with no lazy loading and no width/height attributes, LCP will suffer on almost every device.

Performance on this metric is categorized qualitatively from good to poor based on loading times.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID only measured the delay before the browser could respond to the first interaction, INP tracks the latency of all interactions throughout a page visit — clicks, taps, keyboard inputs — and reports the worst-case result. A page that feels sluggish when you click a dropdown or submit a form will show a high INP even if it loaded quickly.

Heavy JavaScript, long tasks blocking the main thread, and poorly optimised third-party scripts are the usual culprits.

Performance on this metric is categorized qualitatively from good to poor based on responsiveness times.

Cumulative Layout Shift (CLS)

CLS measures visual stability. Every time an element moves unexpectedly during page load — a button that shifts just as you tap it, a headline that jumps when an ad loads above it — that contributes to the CLS score. The score is a unitless number calculated from the size of the shift and the distance elements move.

Common sources include images without declared dimensions, ads or embeds injected into the page after load, and web fonts that cause text to reflow when they swap in.

Performance on this metric is categorized qualitatively from good to poor based on visual stability scores.

Pro Tip: A URL group in Search Console is classified by its worst-performing metric. If CLS is poor but LCP and INP are fine, the whole group shows as “Poor.” Fix the worst metric first, not the easiest one.

Why Core Web Vitals matter for your business

Poor performance costs real money. Pages that load slowly or shift around lose visitors before they convert, and that pattern compounds across every campaign you run.

Google Search Central is clear that Core Web Vitals feed into Google’s ranking systems as part of page experience, but they are not a shortcut to the top of the results. Content relevance still dominates. What the metrics do is set a floor: a page that performs badly enough on these signals can be disadvantaged even when its content is strong.

The practical business outcomes of improving Core Web Vitals are more immediate than the SEO angle:

• Lower bounce rates — users who see a page load fast and stay stable are more likely to stay
• Higher conversion rates — particularly on mobile, where slow LCP and layout shifts directly interrupt purchase flows
• Better mobile experience — Google assesses mobile and desktop separately; most sites fail on mobile first
• Reduced ad waste — if paid traffic lands on a slow page, you are paying for sessions that bounce before they engage

The connection between SEO and web design runs deeper than most site owners realise. Core Web Vitals sit at that intersection: they are a technical performance problem with direct UX and revenue consequences.

How Core Web Vitals are measured: field data vs lab data

This distinction trips up a lot of site owners. Your PageSpeed Insights score and your Search Console report can show very different numbers for the same page, and both can be correct.

Field data comes from real Chrome users visiting your site. Google collects this anonymously through the Chrome User Experience Report (CrUX) and aggregates it over a 28-day rolling window. Search Console’s Core Web Vitals report is built entirely from CrUX data. Because it reflects actual user conditions — varying devices, network speeds, locations — it is the data Google uses for ranking purposes.

Lab data is what Lighthouse and PageSpeed Insights generate when they simulate a page load in a controlled environment. Lab tests are fast, repeatable, and great for debugging, but they run on a single simulated device and network profile. They will often report different absolute numbers than CrUX.

The Search Console Core Web Vitals report groups URLs by similar page behaviour rather than listing every URL individually. A group’s status is set by its worst-performing metric once minimum data thresholds are met, so a single poor CLS score can drag an entire group to “Poor” even when LCP and INP are fine. When a URL group lacks enough data, Search Console falls back to origin-level reporting, which averages across the whole site.

Pro Tip: A fix you deploy today will show up in Lighthouse almost immediately. It will take up to 28 days to appear in Search Console’s field data because CrUX needs a full rolling window to reflect the change. Set expectations with clients and stakeholders before they ask why the Search Console report hasn’t moved yet.

Which tools should you use to check Core Web Vitals?

Each tool has a specific role. Using them in the right order saves time and avoids chasing phantom problems.

Primary tools:

• Google PageSpeed Insights — paste any URL and get both lab scores and CrUX field data in one view; the fastest starting point for any audit
• Google Search Console Core Web Vitals report — shows field data across your whole site, grouped by URL and device; the source of truth for what Google actually sees
• Chrome DevTools + Lighthouse — run in-browser lab tests, record performance traces, and identify the specific elements causing LCP or layout shift
• web.dev — Google’s official guidance hub with detailed measurement and improvement techniques for each metric
• CrUX via BigQuery — for advanced users who need historical field data or cross-site benchmarking at scale

Step-by-step workflow:

1. Run PageSpeed Insights on your top three to five pages. Note which metrics are red or orange in both the field and lab sections.
2. Open Search Console’s Core Web Vitals report. Check mobile and desktop separately. Identify which URL groups are marked “Poor” or “Needs improvement.”
3. Click into a failing URL group to see which specific metric is driving the status and which URLs are affected.
4. Reproduce the issue in Chrome DevTools or Lighthouse. Use the Performance panel to record a trace and pinpoint the exact element or script causing the problem.
5. Apply fixes, then monitor Search Console over the following 28 days for the field data to update.

Pro Tip: Prioritise mobile first. Most sites have worse Core Web Vitals on mobile than desktop, and Google’s ranking assessment uses mobile data for the majority of sites. Fix mobile, then revisit desktop as a secondary pass.

How to improve LCP, INP, and CLS

The web.dev Core Web Vitals guidance covers each metric in depth, but here is a prioritised starting point for most sites.

Quick wins that apply across all three metrics

• Compress and convert images to WebP or AVIF
• Add explicit width and height attributes to all images and iframes
• Defer non-critical JavaScript with defer or async
• Set up browser caching and use a CDN for static assets
• Remove or delay third-party scripts that are not needed on page load

LCP fixes

Slow server response time (TTFB above 600 ms) is often the root cause. Beyond that:

• Preload the LCP image using <link rel="preload"> in the <head>
• Eliminate render-blocking CSS and JS that delay the browser from painting
• Serve hero images at the correct display size rather than scaling them down in CSS
• Use critical CSS inlined in the <head> so the above-the-fold content renders without waiting for a stylesheet

For WordPress sites built with Elementor, there are specific page speed techniques that address the builder’s default asset loading behaviour.

INP fixes

INP problems almost always trace back to long tasks on the main thread:

• Break up long JavaScript tasks into smaller chunks using setTimeout or scheduler.postTask
• Use requestIdleCallback for non-urgent work that does not need to run during user interactions
• Audit third-party scripts — tag managers, chat widgets, and analytics libraries are frequent offenders
• Optimise event handlers so they do minimal work synchronously before handing off to async processes

CLS fixes

Most CLS problems are preventable at the design stage:

• Always declare image dimensions in HTML or CSS so the browser reserves space before the image loads
• Reserve space for ad slots and embeds with a minimum height, even before the content loads
• Avoid inserting content above existing content after page load
• Use CSS transform for animations rather than properties that trigger layout recalculation (like top, left, or margin)

Pro Tip: Tackle LCP first. It has the highest perceived impact on users and is usually the most fixable with image and server optimisations. A fast-loading page that is stable and responsive converts better than a page with a perfect CLS score that takes four seconds to show anything.

For WooCommerce sites where LCP and conversion speed are tightly linked, platform-specific speed optimisations can make a significant difference.

Common measurement traps and how to prioritise fixes

The biggest mistake most teams make is treating PageSpeed Insights lab scores as the definitive measure of their site’s performance. Lab scores are useful for debugging, but they do not reflect what real users experience on real devices and networks. A page can score 90 in Lighthouse and still have poor field data in Search Console if it is heavy with third-party scripts that behave differently in production.

Other common pitfalls:

• Chasing a perfect score — a score of 100 in PageSpeed Insights does not mean your users have a perfect experience, and Google has said explicitly that marginal score gains should not be the goal
• Misreading URL groups — a URL group marked “Poor” does not mean every URL in that group is failing; it means the group’s worst metric is poor
• Ignoring the device split — fixing desktop performance and ignoring mobile is a common oversight; Google’s field data is device-specific
• Forgetting third-party scripts — advertising slots, chat widgets, and tag manager containers frequently reintroduce CLS and INP problems after you have fixed them

Before you start fixing, prioritise by impact using Van Westendorp pricing research for SaaS to align performance improvements with business value. Ask: which pages drive the most traffic and conversions? Which device type do most of your users visit on? A 10-point improvement on your highest-traffic landing page is worth more than a perfect score on a page nobody visits. Fix the metric that is dragging a URL group’s status first, then move to the next group.

Prioritisation checklist:

• Traffic volume: focus on pages that drive real sessions, not internal or low-traffic pages
• Conversion impact: landing pages and product pages before blog posts
• Device mix: check your Analytics data to confirm whether mobile or desktop dominates
• Fix complexity: separate quick wins (image compression, dimension attributes) from developer-heavy tasks (JS refactoring, server-side changes)
• Third-party risk: flag any fix that could be undone by a future ad or script injection

Pro Tip: Third-party scripts are the most common reason CLS and INP problems return after you have fixed them. After any optimisation sprint, re-run PageSpeed Insights a week later to confirm the gains have held.

A one-day audit and action plan for Australian site owners

CantyDigital has run performance audits for businesses across Australia for 12 years. The workflow below is what we use to triage a site quickly and identify the fixes with the highest return.

One-day audit checklist

1. Open Search Console and navigate to the Core Web Vitals report. Screenshot the current status for mobile and desktop, noting which URL groups are “Poor.”
2. Run PageSpeed Insights on your homepage, your top landing page, and your highest-converting product or service page.
3. Record the LCP, INP, and CLS values for each page in a simple spreadsheet, noting whether the issue is in field data, lab data, or both.
4. Identify the three issues with the highest impact: usually a large unoptimised hero image (LCP), a third-party script blocking interaction (INP), or images without dimensions (CLS).
5. Check whether your hosting server response time (TTFB) is above 600 ms — if it is, server-side improvements should be your first call.

7–30 day action plan

• Days 1–7: Apply quick wins. Compress images, add dimension attributes, defer non-critical JS, and configure caching. Re-run PageSpeed Insights to confirm lab improvements.
• Days 8–14: Address LCP-specific issues — preload the hero image, inline critical CSS, and review your CDN configuration.
• Days 15–28: Schedule developer tasks for heavier work: JavaScript refactoring, INP event handler optimisation, and any server-side changes.
• Day 28+: Check Search Console’s Core Web Vitals report for field data movement. Expect the 28-day rolling window to reflect changes gradually.

When to bring in professional help

Some performance problems are straightforward to fix with the right knowledge. Others are not. Signs you need a professional audit or development support:

• Your site is built on a complex JavaScript framework (React, Vue, Next.js) and INP is consistently above 500 ms
• You have heavy third-party integrations (ad networks, CRM embeds, live chat) that keep reintroducing CLS
• You have run the quick wins and Search Console field data has not improved after 30 days
• Your Google ranking has dropped and you suspect performance is a contributing factor

CantyDigital’s page speed optimisation service covers the full stack — from image and caching fixes through to JavaScript profiling and server configuration.

Pro Tip: If you are unsure where to start, run PageSpeed Insights on your top three pages and look at the “Opportunities” section. Google ranks those suggestions by estimated impact. Start at the top of that list, not the bottom.

The honest agency take on Core Web Vitals

The thing most articles on this topic get wrong is the framing. Core Web Vitals get presented as an SEO checkbox — hit the thresholds and your rankings improve. That is not how it works, and chasing that framing leads to wasted effort.

The metrics matter because they describe real user experience. A page with a CLS score of 0.3 is genuinely frustrating to use. A page with an INP of 800 ms feels broken. Fixing those problems makes the page better for the people using it, and that is the actual goal. The ranking signal is secondary.

The prioritisation rule I apply consistently: fix what users notice first. CLS is visible — people see the page jump. Slow LCP is felt — the page appears dead for a moment. INP is subtle but cumulative — a page that feels sluggish to interact with loses trust gradually. Fix in that order of user impact, not in order of which metric is easiest to move.

One more thing worth saying plainly: if your content is weak, improving Core Web Vitals will not rescue your rankings. Google has been consistent on this. A fast, stable page with thin content will not outrank a slower page with genuinely useful, authoritative content. Get the performance to a “good” threshold, then put your energy into the content and authority signals that actually drive long-term organic growth.

Sources

• Understanding Core Web Vitals and Google search results | Google Search Central
• Core Web Vitals report – Search Console Help
• Web

Recommended

• Accessibility in web design: a practical 2026 guide
• Role of grid systems in web design: 2026 guide
• What is responsive web design: a developer’s guide
• Why SEO and web design connect: the full picture