Core Web Vitals Guide 2026: Thresholds, Scores and Practical Fixes

A core web vitals guide is only useful if it helps you decide what to fix first. Google already publishes the official definitions. The harder job is working out whether poor loading speed, weak responsiveness, or layout instability is holding back your rankings, your conversion rate, or both.

Core Web Vitals measure loading speed, responsiveness, and visual stability using real-user data. For SEO, they are a page experience signal. For users, they are simpler than that: does the page load, respond, and stay still long enough to use without friction?

This guide explains the current thresholds, the 2026 pass-rate data, the practical fixes, and the parts most Core Web Vitals articles still miss: mobile-first impact, cross-browser measurement, insufficient real-user data, and the link between performance and AI search visibility.

Table of contents

• Core Web Vitals definition and purpose
• The three metrics and their thresholds
• Good scores and 2026 pass-rate context
• SEO impact and page experience
• Real-user data, lab testing, and the 75th percentile
• Mobile-first implications for Core Web Vitals
• Cross-browser measurement support in 2026
• Insufficient real-user data explained
• Measurement tools and workflow
• Improving loading, responsiveness and layout stability
• Prioritising fixes by business impact
• AI Overviews and performance
• Common questions

What are Core Web Vitals?

Core Web Vitals are Google-defined performance metrics that measure real-world user experience across loading performance, interaction responsiveness, and visual stability.

Google introduced Core Web Vitals to give site owners a standard way to judge web performance. Before that, teams could run five page speed tools and get five different opinions. Core Web Vitals narrowed the discussion to three user-centred questions: does the main content load quickly, does the page respond when someone interacts, and does the layout stay stable?

Google Search Central explains Core Web Vitals as real-world user experience metrics for Search. The official web.dev Web Vitals documentation gives the metric definitions and the thresholds used by tools such as PageSpeed Insights and Google’s own reporting.

The practical point is this: Core Web Vitals are not decorative technical scores. They expose problems that users feel, especially on mobile connections, older phones, JavaScript-heavy templates, and pages with large hero images or third-party scripts.

What are the three Core Web Vitals metrics?

The three Core Web Vitals metrics are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. LCP measures loading, INP measures responsiveness, and CLS measures visual stability.

Each metric maps to a different part of the page experience. Treat them separately during diagnosis because they usually have different causes and different fixes.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible content element to render in the viewport. That element is often a hero image, main heading, banner image, or large text block.

A poor LCP score usually points to slow server response, unoptimised images, render-blocking CSS, slow font delivery, or a main element that cannot render until too much JavaScript has run. LCP is often the metric that fails commercial landing pages because those pages tend to carry large visual assets above the fold.

Interaction to Next Paint (INP)

INP measures responsiveness after user interactions such as taps, clicks, and key presses. It replaced First Input Delay as a Core Web Vital in March 2024 because FID only measured the delay before the browser started responding, while the newer metric captures more of the experience users notice.

The metric has three useful components: input delay, processing duration, and presentation delay. Input delay is the time before the browser can start handling the action. Processing duration is the work your JavaScript does. Presentation delay is the time before the next visual update appears. If a page feels loaded but buttons respond late, this is the area to investigate.

Cumulative Layout Shift (CLS)

CLS measures unexpected movement of visible content. A poor CLS score means the page moves around while someone is trying to read, tap, or complete a form.

Common causes include images without explicit dimensions, adverts or embeds injected above existing content, cookie banners that move the layout, web fonts swapping late, and dynamic content added after load. CLS is often easier to fix than loading or responsiveness because many issues come from predictable template behaviour.

What is a good Core Web Vitals score?

A good Core Web Vitals score means the page passes LCP, INP and CLS at the 75th percentile of real user visits. One weak metric can cause the whole assessment to fail.

The 75th percentile matters because Google is not asking whether the median user had a good experience. It is asking whether at least three quarters of visits cleared the threshold. A page that is fast for desktop users on fibre but slow for mobile users on weaker connections can still fail.

The May 2026 Chrome UX Report release notes, published on 9 June 2026, show that only 55.9% of measured origins had good Core Web Vitals overall. The individual metric pass rates were higher, which proves the point: passing one or two metrics is not enough.

These figures are useful because they give context. Passing Core Web Vitals does not make a page exceptional by itself, but failing them leaves a site behind a large part of the web and behind competitors with cleaner technical foundations.

Are Core Web Vitals a ranking signal?

Core Web Vitals affect SEO because Google uses them within its page experience signals, but they are not stronger than relevance, content quality, intent match, or authority.

The most honest way to treat Core Web Vitals is as a baseline technical requirement. They rarely rescue weak content. They can matter when competing pages are otherwise similar, and they can suppress performance when poor user experience damages engagement and conversions.

This is where technical SEO judgement matters. A page with poor LCP, thin content, and weak internal links does not have one problem. It has a priority problem. The right answer is not to chase a perfect PageSpeed score while ignoring search intent, but it is equally wrong to dismiss performance because it is not the whole algorithm.

For a wider explanation of how this fits into crawlability, rendering, internal links, and indexation, see my guide to technical SEO.

Real-user data versus lab testing: which should you trust?

Use real-user data to decide whether Core Web Vitals are failing in the wild, then use controlled tests to diagnose the technical cause.

Real-user data comes from the Chrome User Experience Report. It powers Search Console, PageSpeed Insights, and several reporting tools. It is valuable because it reflects real devices, real networks, and real visitors.

Lab testing is still useful because it gives repeatable diagnostics. Lighthouse, Chrome DevTools, and local throttling can show the LCP element, long main-thread tasks, unused JavaScript, layout shift sources, and render-blocking resources. The mistake is treating a single test run as if it represents every user.

A practical workflow is straightforward: start with Search Console to find affected URL groups, use PageSpeed Insights to compare real-user data and diagnostics for example URLs, then use DevTools or real-user monitoring to isolate the cause. For a wider process, fold this into an SEO audit rather than treating speed as a detached task.

Why mobile Core Web Vitals matter most

Mobile Core Web Vitals matter most because Google uses mobile-first indexing and mobile users usually face slower networks, weaker processors, and heavier JavaScript costs.

Google completed the mobile-first indexing move after 5 July 2024. That means Google primarily crawls and indexes sites with Googlebot Smartphone. Your desktop template can be clean, but if mobile content, layout, scripts, or internal links differ, the mobile version carries the risk.

This is why mobile cwv results often lag desktop results. A desktop test on a fast office connection can hide the problem. A mobile visitor may wait longer for the hero image, suffer a late font swap, or tap a button while a third-party script is still blocking the main thread.

For B2B sites, this is easy to underestimate. Buyers may convert on desktop, but research often starts on mobile. Poor site performance at that stage can lose the visitor before analytics has a clean lead source to report.

What changed with cross-browser Core Web Vitals support?

LCP and INP became available across all three major browser engines in December 2025, which makes Core Web Vitals measurement more consistent across Chrome, Safari, and Firefox.

The Interop 2025 work brought loading and interaction metric implementations closer across browsers. web.dev later confirmed that both became Baseline Newly available on 12 December 2025, meaning those features were available in current versions of the major browser engines.

There is a caveat. CrUX is still based on eligible Chrome users, so Google’s Search-facing data remains Chrome-centred. Cross-browser API support helps developers measure performance more consistently, but it does not mean Safari or Firefox users are directly included in Google’s page experience data.

The practical benefit is better debugging. If your own real-user monitoring setup collects data across browsers, you can now compare user experience more fairly instead of relying only on Chrome-based tooling.

What does insufficient real-user data mean?

Insufficient real-user data means Google does not have enough eligible Chrome UX samples for a URL or origin to report a reliable Core Web Vitals assessment.

This is common for smaller sites, new pages, low-traffic templates, and niche B2B pages. It does not mean the page is passing. It means the public dataset cannot show a reliable URL-level result.

PageSpeed Insights may show origin data when URL data is missing. Google may group similar URLs together. If neither source has enough data, you still need to test the template, because users can suffer a poor experience even when Google lacks enough samples to label the page.

For low-traffic commercial pages, use a mix of template testing, PageSpeed Insights diagnostics, and real-user monitoring. The business risk is not the missing label. The risk is assuming no data equals no problem.

How to measure Core Web Vitals properly

The best Core Web Vitals workflow uses Google’s URL group report for prioritisation, PageSpeed Insights for page-level checks, DevTools for debugging, and real-user monitoring when the site needs ongoing measurement.

No single tool does the whole job. Google’s reporting tells you which groups of pages are failing. PageSpeed Insights shows whether public real-user data exists and gives diagnostics. DevTools gives the technical trace. Your own monitoring shows what visitors experience across journeys that matter to the business.

For recurring reporting, avoid turning Core Web Vitals into a vanity dashboard. Report the pages and templates that matter: service pages, category pages, product pages, lead-generation pages, and high-traffic guides. A green blog archive is less useful than a fixed enquiry page.

How to improve Largest Contentful Paint

To improve LCP, identify the LCP element first, then reduce the time needed to fetch, prioritise, and render that element.

Most failed LCP work starts in the wrong place. Teams compress every image on the site while the real issue is a slow server response, a background hero image loaded late by CSS, or a font that blocks the main heading. Start with the element and work backwards.

• Check the LCP element in PageSpeed Insights or Chrome DevTools before changing assets.
• Preload the LCP image when it is known and appears above the fold.
• Serve images in WebP or AVIF with sensible dimensions and responsive srcset values.
• Reduce Time to First Byte through better hosting, caching, database performance, or CDN configuration.
• Remove render-blocking CSS and JavaScript that delays the first meaningful render.
• Avoid lazy-loading the above-the-fold hero image, because it can delay the most important asset.

The commercial point is simple: a slow main content render delays the moment a visitor can judge whether the page solves their problem.

How to improve Interaction to Next Paint

To improve INP, reduce main-thread blocking, split long JavaScript tasks, and delay non-essential third-party work until after the page can respond.

Responsiveness problems are common on modern sites because pages ship too much JavaScript for menus, analytics, chat widgets, consent tools, review widgets, sliders, and personalisation. The page may look loaded, but the browser is still too busy to respond quickly.

• Break long tasks into smaller chunks, especially tasks over 50ms.
• Reduce JavaScript bundle size and remove unused code from page templates.
• Delay third-party scripts that are not needed for the first interaction.
• Use web workers for expensive work where the implementation allows it.
• Review event handlers so clicks and taps do the least work required before the next paint.
• Watch for hydration cost on JavaScript frameworks, especially on mobile devices.

Poor responsiveness is often invisible in stakeholder reviews because nobody tests the page on a mid-range phone while scripts are still loading. Users do.

How to improve Cumulative Layout Shift

To improve CLS, reserve space for media and dynamic elements before they load, then stop scripts, fonts, and embeds from pushing visible content around.

CLS is a stability problem. It is the moment someone tries to tap a button and the button moves. It is also the moment a paragraph shifts because an advert, iframe, banner, or font appears late.

• Set explicit width and height attributes or CSS aspect ratios on images and videos.
• Reserve space for adverts, embeds, review widgets, and newsletter forms before they load.
• Avoid injecting banners above existing content after the page has started rendering.
• Use font-display carefully and preload key font files where typography affects the initial layout.
• Animate with transform and opacity rather than layout properties that force reflow.
• Reduce layout thrashing by avoiding repeated read and write cycles in JavaScript.

Large DOM tree size can make layout work more expensive, so CLS fixes sometimes overlap with broader front-end cleanup. A cleaner template is easier for both users and browsers.

How should you prioritise Core Web Vitals fixes?

Prioritise Core Web Vitals fixes by business impact, template reuse, metric severity, and implementation effort, not by the order a tool lists issues.

A list of 40 diagnostics is not a plan. Fixing every warning on a low-traffic blog tag page matters less than fixing one shared service-page template that fails LCP across every commercial landing page.

Use the same logic you would apply in a technical SEO audit checklist: fix the problem that affects the most valuable pages, has the clearest technical cause, and can be verified after deployment.

Do Core Web Vitals matter for AI Overviews?

Core Web Vitals are not a confirmed direct AI Overview selection factor, but performance can still affect whether users and crawlers can access, read, and trust the page experience around your content.

AI search visibility still depends on being crawlable, indexable, useful, and well-supported by authority signals. Slow pages do not automatically lose AI Overview eligibility, and fast pages do not automatically win citations.

The indirect connection is more practical. Pages that load quickly, respond cleanly, and avoid layout instability are easier for users to engage with and easier for teams to maintain. That matters when organic search is becoming more answer-led and every visit has to work harder.

For most businesses, the right aim is not to optimise Core Web Vitals for AI in isolation. The aim is to remove technical friction from pages that already deserve to rank and be cited.

When should you get technical SEO help?

Get technical SEO help when Core Web Vitals issues affect valuable templates, require developer coordination, or keep returning after individual fixes.

Some fixes are straightforward. An oversized hero image, missing image dimensions, or a font loading issue can often be handled quickly. Other problems need deeper work: JavaScript rendering, framework hydration, caching strategy, server response time, third-party script governance, or template-level CLS.

This is where a technical SEO consultant with front-end experience can save time. The job is not to tell developers to "improve speed". The job is to diagnose the bottleneck, write a clear implementation spec, and verify that the deployed change improves the metric that matters.

If you want a wider review of performance, crawlability, indexation, internal links, and page quality, a professional SEO audit is usually the better starting point than a standalone speed report.

Frequently asked questions about Core Web Vitals

What are the key metrics of Google Core Web Vitals?

The key metrics are LCP, INP and CLS. LCP measures loading performance, INP measures responsiveness after interaction, and CLS measures visual stability. A page needs good scores across all three to pass the Core Web Vitals assessment.

What counts as a good Core Web Vitals score?

A good score means LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less at the 75th percentile of real user visits. The page must pass all three metrics.

How do I test Core Web Vitals for free?

Use PageSpeed Insights for a free URL-level test, Google Search Console for site-wide URL groups, and Chrome DevTools for debugging. If the page lacks enough public real-user data, use template testing and controlled diagnostics instead of assuming the page is healthy.

Do Core Web Vitals still matter for SEO?

Yes, but they are not the main reason most pages rank. Core Web Vitals support page experience and can matter in competitive results, especially when pages are otherwise similar. Relevance, content quality, authority, and intent match still carry more weight.

Why does Search Console say there is not enough data?

Search Console shows insufficient data when Google does not have enough eligible Chrome UX samples for the URL or group. This is common on smaller sites and low-traffic pages. Test the template anyway, because users can still experience slow loading or layout instability.

What causes poor Core Web Vitals scores?

Poor scores usually come from large images, slow server response, render-blocking resources, heavy JavaScript, third-party scripts, missing media dimensions, late-loading fonts, dynamic banners, and complex templates that do too much work on mobile devices.

Core Web Vitals are a business problem before they are a score problem

Core Web Vitals work should end with better pages, not cleaner screenshots from a testing tool. If your most valuable templates are slow, unstable, or unresponsive, users feel the cost before rankings do.

If you need someone to diagnose the technical cause, brief developers with usable specifications, and connect performance fixes back to organic growth, Get in touch.