What are Core Web Vitals? Understanding LCP, INP, CLS & Performance Scores

Most of your customers arrive on mobile devices with limited patience. If a page takes too long to load, shifts around while they try to tap a button, or freezes when they interact, they leave. Core Web Vitals metrics turn that vague “site feels slow” feedback into three measurable targets for website performance and website speed optimisation.

Core Web Vitals are three user experience metrics defined by Google: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Together, they measure how fast a page loads, how quickly it reacts, and how stable it looks.

For small and medium businesses, shaving seconds off load time translates into more enquiries, more basket completions, and better return from paid traffic. Good performance metrics correlate with higher conversion rates and revenue across every traffic source, not just organic search.

At Smart Digitants, we use both lab tools and real user monitoring field data in web development to tune website performance. This data-led approach has helped us drive up to 200% revenue increases for clients. This article explains how to read a Core Web Vitals report, and explains where a web development partner can step in to fix issues.

Core Web Vitals Explained In Plain English

Core Web Vitals are user-centric performance metrics established by Google and the wider web community to capture three things about every web page: loading performance, interactivity, and visual stability. They are measured from actual users across devices, network conditions, and locations, not just in a developer’s browser.

Core Web Vitals impact SEO rankings since June 2021. Here is what each web vital measures:

• Largest Contentful Paint (LCP) measures loading performance. Think of it as the shop doors opening so customers can see the main display. If the hero image or headline appears fast, visitors know the site works.
• Interaction to Next Paint (INP) measures responsiveness. It is like pressing a button at a till and waiting for the cash register to respond. If the page freezes after a tap, users leave.
• Cumulative Layout Shift (CLS) measures visual stability. Imagine shelves moving under a customer’s hand as they reach for a product. When buttons and text jump around, people misclick and lose trust.

Core Web Vitals metrics go through experimental, pending, and stable phases before being adopted. Stable metrics change no more than once per year, giving site owners time to adapt.

Largest Contentful Paint (LCP)

Largest Contentful Paint measures loading performance of the largest element visible in the viewport. On a UK e-commerce product page, the LCP element is usually the main product image. On a service landing page, it tends to be the hero banner or headline above the fold. Your visitor’s first impression of page speed depends on how quickly this largest element renders.

The current Core Web Vitals thresholds for LCP: a good LCP score is under 2.5 seconds for 75% of users. Between 2.5 and 4.0 seconds sits “Needs Improvement.” Above 4.0 seconds is “Poor.” Google uses the 75th percentile of page loads over the preceding 28 days to make this assessment.

Common causes of slow LCP:

• Unoptimised hero images (oversized files, outdated formats)
• Render-blocking CSS and JavaScript loaded before content
• Slow Time to First Byte from the server
• Heavy third-party scripts (tracking pixels, chat widgets) loaded early

To improve LCP: compress and resize images, convert to modern formats like WebP or AVIF, implement proper caching headers, use a content delivery network, and streamline critical CSS so the browser can paint the largest element without waiting for non-essential resources.

Interaction to Next Paint (INP)

Interaction to Next Paint replaced First Input Delay as a Core Web Vital on March 12, 2024. While First Input Delay only measured the delay before the browser began processing the first interaction, INP captures every relevant user interaction across the entire page visit. INP was promoted to pending status in May 2023 before becoming the official responsiveness metric.

When a user taps a button, the browser must stop other work, run the event handler JavaScript, update layout, then paint the next visual change. INP times that full cycle. A good INP score is under 200 milliseconds. Between 200 and 500 ms is “Needs Improvement.” Above 500 ms is “Poor,” again measured at the 75th percentile.

What causes bad INP:

• Large JavaScript bundles or frameworks blocking the main thread
• Long-running event handlers that prevent the browser from painting
• Analytics, ad, and social scripts competing for processing time
• Unnecessary re-renders triggered by complex UI state changes

High-level fixes include splitting large JavaScript bundles, deferring non-critical scripts until after the initial load, using web workers for heavy computation, and profiling user interactions with Chrome DevTools to identify the slowest ones. Total blocking time in lab data often predicts INP problems in the field.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift measures unexpected layout shifts during a session. Every time a visible element moves without the user initiating that movement, CLS increases. It is unitless and cumulative across the page experience.

Concrete examples of bad CLS that frustrate users:

• A cookie banner loads late and pushes all content down just as someone reaches to tap a link
• An image without defined dimensions loads and shoves nearby text sideways
• A web font replaces a fallback font, causing paragraphs to reflow and buttons to shift position

A good CLS score is below 0.1. Between 0.1 and 0.25 is “Needs Improvement.” Above 0.25 is “Poor,” per Google’s specification.

Common technical causes include images or embeds without width and height attributes, dynamically injected banners without reserved space, late-loaded fonts, and responsive ads that resize after initial render.

Fixes: always set explicit width and height or CSS aspect-ratio for images and video embeds. Preload or self-host fonts. Reserve containers for banners and dynamic content. Test across common mobile screen sizes, as layout shift issues are often worst on smaller devices.

Lab Data vs Field Data: How Your Core Web Vitals Are Measured

You can measure Core Web Vitals in two ways, and both matter for serious website performance optimisation.

Lab Data

Lab data comes from synthetic tests run on specific desktop devices and mobile emulations under controlled network conditions.

Lab tools like Lighthouse in Chrome DevTools and Google PageSpeed Insights’ lab mode produce repeatable results useful for debugging. They run against a single URL in a clean lab environment, making them ideal for isolating a specific issue. However, lab data cannot capture the full range of real world experience.

Field Data

Field data comes from real user monitoring. Core Web Vitals are measured using real user data from CrUX (Chrome User Experience Report), which collects anonymised performance data from Chrome browser users who have opted in.

This CrUX data reflects what actual users experience across varying devices, connections, and locations over a rolling 28-day window.

Why do scores differ?

A page may show “Good” in lab mode because the test uses a fast connection and a powerful device. Field data may reveal worse results from users on older phones, high-latency mobile networks, or uncached first visits.

Core Web Vitals data based on real user data is what Google uses for its assessments. Use lab tools when building or debugging; use field tools and field data to validate improvements and catch regressions after launches.

Where To See Your Core Web Vitals Report and Scores

There is no single Core Web Vitals report. Instead, several tools surface your Core Web Vitals scores from different angles.

• Google PageSpeed Insights presents both lab and field data for any URL you enter. The PageSpeed Insights test displays LCP, INP, CLS, plus supporting metrics like First Contentful Paint and Time to First Byte in a colour-coded report. If a page has enough data from real users, the field section shows what actual visitors experienced. If not, it falls back to origin-level data for your entire website.
• Google Search Console has a dedicated Core Web Vitals report  that groups URLs into Good, Needs Improvement, and Poor for mobile and desktop. This view is useful for spotting patterns across templates or sections. If every product page scores “Poor” for LCP, you know the product page template needs attention.
• Chrome browser extensions can display Core Web Vitals metrics as an overlay while you browse, helpful for quick checks during development. You can also use the web-vitals JavaScript library to monitor performance from your own visitors and pipe the data into your analytics platform.

A structured measurement setup, often managed by a web development partner, combines these dashboards with regular exports so you can analyse traffic trends and track performance month by month.

How Core Web Vitals Connect to Broader Web Performance

Core Web Vitals focus on three metrics of great user experience, but each one depends on a whole stack of underlying performance factors: hosting, caching, image delivery, code quality, and third-party script management.

Time to First Byte

First Contentful Paint marks the moment something first appears on screen. Largest Contentful Paint follows when the main content finishes rendering. A slow database query or misconfigured server delays all three in sequence. Content delivery networks, efficient caching layers, and optimised server stacks directly influence perceived page speed.

Mobile Performance

Weaker device CPUs, higher latency networks, and more aggressive browser throttling turn a borderline “Good” desktop experience into “Needs Improvement” on phones. Only 48% of mobile pages pass all three Core Web Vitals, compared to 56% on desktop. LCP is the hardest metric to get “Good” on mobile.

How We Ensure Good Core Web Vitals?

At Smart Digitants, we integrate Core Web Vitals targets into our broader web performance tuning work. We set performance budgets for JavaScript payloads and images, build continuous monitoring dashboards, and embed these practices into our scalable web architecture approach.

The UK Government Service Manual treats speed and stability as essential usability criteria for digital services, reinforcing that good performance is professional practice, not an optional extra.

Partnering With Smart Digitants to Improve Core Web Vitals

We combine analytics, lab testing, and real user monitoring to prioritise changes that move conversion and revenue. This approach has delivered a 200% revenue increase through Google Ads for one client and 10x sales on the same ad spend for another.

A typical engagement with us follows a clear path:

1. Audit your Core Web Vitals metrics across high-traffic pages
2. Review hosting, codebase, and third-party script impact
3. Build an implementation roadmap ranked by business impact
4. Deploy fixes and monitor through live dashboards
5. Re-measure and iterate after each release cycle

We operate as a long-term growth partner, not a one-off vendor. Several of our client relationships span three years and counting because we treat performance as an ongoing practice, not a single project.

Ready to see where your site stands? Book a consultation or request a callback. We will run a Core Web Vitals test on your key pages and show you exactly where the opportunities are.

Practical Ways to Improve Your Core Web Vitals

This section gives prioritised ideas any business can discuss with its developer or agency. No need to read raw traces for performance issues.

For LCP (loading performance):

• Compress and convert hero images to WebP or AVIF
• Preload critical assets like above-the-fold images and fonts
• Reduce server response time through better hosting or a CDN
• Inline critical CSS and defer non-essential stylesheets

For INP (responsiveness):

• Split large JavaScript files so the browser loads only what each page needs
• Defer analytics and chat scripts until after the page is interactive
• Simplify interaction flows; fewer DOM updates per click means faster paint
• Use code samples and profiling in DevTools to find the worst offenders

For CLS (visual stability):

• Set explicit width and height on every image and video embed
• Reserve space for ad slots and dynamic banners before they load
• Self-host fonts and use font-display: swap to prevent layout reflow
• Test on real mobile devices, not just desktop browser emulators

Start with high-traffic, business-critical pages: your homepage, product listings, and main lead generation pages. Improvements on those pages yield outsized gains in user outcomes.

Run a Core Web Vitals test after each major release to catch regressions early. Compare lab results before and after, then confirm with field data once the 28-day window rolls over. These activities fit naturally into a structured web development process.

Our guide to performance optimisation strategies goes deeper into each technique.

Frequently Asked Questions

How often should we review our Core Web Vitals scores?

Check at least monthly for active sites, and always after changes like new themes, plugins, or tracking scripts. Core Web Vitals data in tools like PageSpeed Insights and Search Console is based on a rolling 28-day window, so improvements or regressions take a few weeks to fully appear.

Do Core Web Vitals matter if most of our traffic comes from paid ads?

Yes. Slow or unstable pages cause drop-offs regardless of traffic source. Businesses running Google Ads see better landing page performance when pages load quickly and respond smoothly, because users are less likely to bounce before converting.

Is there a minimum amount of traffic needed to see core web vitals field data?

Very low-traffic sites may not have enough Chrome User Experience Report data, causing tools to display “insufficient real-user data.” Use lab tools while traffic grows and focus attention on higher-traffic page templates where reliable field data is more likely to appear.

How long does it usually take to see improvements after fixing web vitals issues?

Technical fixes improve lab data immediately. Field data and Core Web Vitals scores based on real users take 2 to 4 weeks to stabilise because of the 28-day reporting window. Plan a realistic timeline: diagnose, implement, and re-measure rather than expecting overnight results.