Core Web Vitals – what LCP, INP and CLS mean, why they matter and how to optimise them

Definition

Core Web Vitals are three metrics from Google – LCP, INP and CLS – that measure how fast a page loads, how quickly it responds to interaction and how visually stable it is. They are part of Page Experience and a confirmed ranking signal.

The three Core Web Vitals metrics – LCP, INP and CLS

Core Web Vitals are three metrics Google uses to quantify how real users experience a page: how fast it loads, how quickly it responds to interaction and how visually stable it is. Each metric is assessed at the 75th percentile of your visitors' page views – in other words, the experience that at least three out of four users get.

‍

• LCP (Largest Contentful Paint) – loading performance: the time until the largest visible element on the page (usually a hero image or a large heading) has rendered. Good: under 2.5 s · Needs improvement: 2.5–4 s · Poor: over 4 s.
• INP (Interaction to Next Paint) – responsiveness: the delay from when the user clicks, taps or types until the next frame is painted. INP takes every interaction during the visit into account, not just the first. Good: under 200 ms · Needs improvement: 200–500 ms · Poor: over 500 ms.
• CLS (Cumulative Layout Shift) – visual stability: how much the content jumps unexpectedly while loading, for example when an image with no reserved height pushes the text down. Good: under 0.1 · Needs improvement: 0.1–0.25 · Poor: over 0.25.

The thresholds are confirmed by Google Search Central: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. For a page to pass, all three metrics have to be in the green range at the same time – two out of three is not enough.

INP replaced First Input Delay (FID) as an official metric on 12 March 2024. FID only measured the delay on the first interaction, while INP reflects responsiveness throughout the visit – a more honest measure of how a page actually feels to use. FID has since been phased out of Google's tools completely.

Are Core Web Vitals important for SEO?

Yes, but not in the way many people think. Core Web Vitals are a confirmed ranking signal within Google's broader Page Experience framework. Google's Page Experience documentation says that achieving good values "aligns with what our core ranking systems seek to reward". But it is a relatively weak signal compared with relevance, content quality and links.

The right way to think of Core Web Vitals is as a tie-breaker, not a rocket booster. Between two pages with equally good content, better values can tip the balance – but no performance score in the world lifts a page that does not answer the search intent. The most common misconception is that a perfect score in PageSpeed Insights automatically means higher rankings. It does not work that way: the score is a diagnostic tool, not a ranking factor in itself.

So the strongest business case is rarely about rankings – it is about conversion. A page that loads slowly, responds sluggishly to clicks or jumps around while loading increases drop-offs and lowers the conversion rate – wherever you rank. Technical performance sits on top of strong content and a clear offer; it does not replace them.

If you want to see where performance fits among the other factors that decide visibility, we have gone through the most common causes in Website not showing on Google? The 10 most common causes.

How to test your Core Web Vitals – field data vs lab data

There are two kinds of Core Web Vitals data, and the difference is crucial. Field data (Real User Monitoring) comes from the Chrome User Experience Report (CrUX) and reflects what your actual visitors experience on their devices and connections. Lab data comes from a simulated test in a controlled environment. Google's ranking is based solely on field data – lab data is for debugging.

• Google PageSpeed Insights (pagespeed.web.dev) – shows both field data from CrUX and a lab test via Lighthouse, with specific suggestions for fixes. The starting point for most people.
• Search Console – the Core Web Vitals report – groups every page on the website by status and flags those with poor values. Best for finding problems at scale across a whole website.
• Chrome DevTools – Lighthouse – local lab analysis with in-depth technical suggestions. Best for debugging a single page.
• CrUX and RUM tools – for anyone who wants to track field data over time and segment by device, country and page type.

The most common trap is chasing 100 out of 100 in Lighthouse on your own fast computer on a fibre connection. The lab score can be green while the field data is red, because your real visitors are on mobile and slower networks. Trust the field data when it exists – the lab data only shows where the problem might be.

How often are your Core Web Vitals values updated?

The field data Google uses is based on a rolling 28-day window in CrUX. So an improvement you make today will not show up in the field data straight away – it can take up to four weeks for the full effect to come through, as older, worse data points gradually drop out of the window. Lab tools such as Lighthouse, on the other hand, show the effect immediately. Expect a lag, then, when you track an optimisation in the field data, and use the lab to confirm that the change has actually worked.

Core Web Vitals are no longer Chrome-only

Historically, Core Web Vitals have in practice been a Chrome-only affair: the field data came from Chrome and the underlying APIs only existed there. That changed at the end of 2025. According to web.dev, LCP and INP became "Baseline Newly available" on 12 December 2025, after Safari 26.2 and Firefox implemented the underlying APIs (the LargestContentfulPaint API and the Event Timing API) as part of the Interop 2025 initiative.

In practice, two of the three metrics can now be measured in all major browsers, not just Chrome. CLS is still measured primarily via Chrome and CrUX data, and Google's own ranking will continue to be based on Chrome's field data. But for anyone building websites, the milestone is a sign that performance measurement is being standardised – Core Web Vitals have gone from a Google-specific signal to an industry standard for web performance.

Core Web Vitals optimisation: how to improve each metric

Optimising Core Web Vitals almost always comes down to the same basic principles: send fewer and smaller resources, prioritise what is seen first and reserve space for what loads late. Here are the most effective measures for each metric.

Optimise LCP (loading)

• Compress the hero image and serve it in a modern format (WebP or AVIF) and at the right size for the viewport.
• Give the most important element high loading priority (fetchpriority) and preload critical resources.
• Serve the content via a CDN and cut the server response time (TTFB).
• Make sure the LCP element is not blocked by render-blocking CSS or JavaScript.
• Load web fonts with font-display swap so text shows immediately.

Optimise INP (responsiveness)

• Split long JavaScript tasks (long tasks) into smaller pieces so the browser's main thread is not blocked.
• Defer or remove heavy third-party scripts – analytics, chat widgets and A/B testing tools are common culprits.
• Reduce the amount of JavaScript that runs on interaction and avoid unnecessary re-renders.
• Move work that does not have to happen immediately to requestIdleCallback or a web worker.

Optimise CLS (stability)

• Always set width and height (or aspect-ratio) on images, video and embeds.
• Reserve space for ads, banners and dynamic content before it loads.
• Choose a fallback font with similar metrics to the web font to avoid layout shifts when the font swaps.
• Insert new content below, not above, what the user is already looking at.

For in-depth technical guides to each metric, web.dev is the primary source: Optimize LCP, Optimize INP and Optimize CLS.

Total Blocking Time (TBT) and its link to INP

Total Blocking Time (TBT) is a lab-based metric that measures the total time the page's main thread is blocked between First Contentful Paint and Time to Interactive. TBT is calculated as the sum of the blocking time of all long tasks (tasks longer than 50 ms) during that period. Because real interaction is hard to simulate in a lab environment, Lighthouse uses TBT as a proxy for INP.

High TBT correlates strongly with poor INP: if you improve TBT – for example by splitting heavy JavaScript tasks or deferring third-party scripts – INP usually improves in practice as well. Alongside Core Web Vitals, three supporting metrics often appear in the tools and are worth understanding: TTFB (Time to First Byte), which measures server response time and affects LCP; FCP (First Contentful Paint), which measures when the first content is painted; and TBT. They are not Core Web Vitals in themselves, but they point to where a problem starts.

Core Web Vitals in Webflow

Webflow gives you a strong technical foundation from the start: a global CDN, automatic image compression with responsive image sizes, clean semantic markup and minified code. A well-built Webflow website therefore often handles LCP and CLS well without extra work. But the platform does not solve everything automatically – most problems come from how the website is built, not from Webflow itself.

• LCP – large, uncompressed hero images and heavy background videos are the most common cause. Upload images at the right size and let Webflow serve them responsively.
• INP – this is where Webflow is most vulnerable. Heavy use of animations through Webflow Interactions or GSAP, combined with third-party embeds (chat, booking, analytics), can block the main thread and worsen INP. Be sparing with simultaneous animations and load heavy scripts late.
• CLS – usually caused by web fonts swapping, embeds with no reserved height or content that loads late. Set explicit dimensions on embedded content.

The rule of thumb: a Webflow website without heavy third-party integrations passes Core Web Vitals without active optimisation, while a complex website with lots of animations, chat widgets and marketing scripts needs the same considered performance work as it would on any other platform.

Core Web Vitals with a headless CMS

A coded website with a headless CMS – for example a front end in Next.js or Astro on top of Sanity, Contentful or Storyblok – gives maximum control over performance. You decide exactly what is sent to the browser. The flip side is that responsibility shifts to the developer: nothing is optimised automatically.

• Strong for LCP – static generation (SSG) and rendering on the server or at the edge mean HTML can be delivered extremely fast, often from a CDN close to the user. Built-in image optimisation handles format and size automatically.
• Risk for INP – the big performance threat in modern frameworks is too much JavaScript. Heavy hydration and large client bundles can block the main thread and cause poor INP even when the page loads fast. Astro's islands architecture, which ships zero JavaScript by default, is one of the strongest choices for low INP.
• Control over CLS – with your own code it is easy to reserve space for images and dynamic content, but the developer has to actually do it.

We explain how a stack like that is built in practice in AI-assisted web development: Claude Code, Next.js and a headless CMS.

Core Web Vitals in WordPress

WordPress can definitely reach green Core Web Vitals – but it is the platform that needs the most active work to get there, and the most maintenance to stay there. Unlike Webflow, almost nothing is optimised automatically; the result depends entirely on the theme, plugins, hosting and how the website is built.

The most common causes of poor values on WordPress:

• Page builders – Elementor, Divi and WPBakery add layers of extra HTML, CSS and JavaScript that weigh down both LCP and INP.
• Plugin bloat – every plugin can load its own scripts and styles on every page. Twenty plugins quickly become hundreds of kilobytes of unnecessary code.
• jQuery and third-party scripts – many themes and plugins rely on jQuery, which blocks the main thread and drags down INP.
• Cheap shared hosting – a weak server means a high TTFB, which directly worsens LCP.

This is what it takes for a WordPress website to perform well:

• Fast hosting (ideally a specialised WordPress host) and a CDN.
• A caching and optimisation plugin such as WP Rocket or LiteSpeed Cache for caching, critical CSS and deferred JavaScript.
• Image optimisation to WebP or AVIF via a plugin – it does not happen automatically.
• A lightweight theme (for example GeneratePress or Kadence) or a block theme instead of a heavy page builder.
• Discipline over the number of plugins, and a plan for testing whether each update affects performance.

The bottom line: WordPress can be made fast, but it takes the right choices from the start and ongoing attention. That is why we reserve WordPress for niche cases where the plugin ecosystem or existing editorial habits outweigh technical simplicity – and choose Webflow or a headless stack when performance has to hold without constant maintenance.

Webflow, headless or WordPress – what does it take to get good Core Web Vitals?

All three platforms can reach green values. The difference lies in how much work it takes to get there – and to stay there. The table below summarises where each platform stands: Core Web Vitals without optimisation, effort, performance control and maintenance.

‍

When do you need a Core Web Vitals consultant?

You can fix most Core Web Vitals problems yourself with the tools above and a little patience. But sometimes you get stuck – and at that point your time costs more than the help would. A Core Web Vitals consultant is worth the money when:

• Search Console flags many URLs and you cannot find the pattern behind the problems.
• The website has red field data despite green lab scores, and you do not know why.
• INP is poor because of scripts and animations you are wary of touching yourself.
• Performance is part of a larger migration, redesign or platform switch.

Strong performance is rarely an isolated technical problem – it comes from the combination of technology, design and content. A solid technical SEO foundation determines whether the optimisation lasts or just earns a temporary green tick. That combination is what we work with at SEOS Design, whether the website is built in Webflow or headless.

Want help interpreting or improving your Core Web Vitals? See our services or get in touch for a review.