Core Web Vitals Explained: What They Are and How to Improve Them

There is a version of this conversation that gets very technical very quickly. Page rendering models, time-to-first-byte, HTTP/3, preload scanning - none of which is particularly useful if you are a business owner trying to understand why Google says your site is slow and what to do about it.

This guide takes a different approach. We will explain what Core Web Vitals actually are in plain terms, why they matter for both rankings and real user experience, how to measure them on your own site, and what tends to cause problems and how to fix them. We will use a real example from a UK e-commerce business to make it concrete.

What Are Core Web Vitals?

Core Web Vitals are a set of specific metrics that Google uses to measure how users actually experience a webpage - not just whether the page loads technically, but whether it loads in a way that feels fast and stable.

Google introduced them in 2020 and started using them as ranking factors in 2021. The three metrics are:

LCP - Largest Contentful Paint. How long it takes for the main content of a page to become visible to the user. In most cases, this is the hero image or the largest block of text above the fold.

INP - Interaction to Next Paint. How quickly the page responds when a user interacts with it - clicking a button, tapping a menu, filling in a form field. INP replaced the older FID (First Input Delay) metric in March 2024 because it measures responsiveness across the full user session, not just the first interaction.

CLS - Cumulative Layout Shift. How much the page elements move around unexpectedly while the page is loading. You have experienced bad CLS when you go to click a button and it suddenly jumps down the screen because an image or ad loaded above it.

All three metrics are measured from real-user data (called field data), not just from lab simulations. Google collects this data from Chrome users and aggregates it across 28 days.

Why Core Web Vitals Matter: Rankings and Revenue

Core Web Vitals are a confirmed Google ranking factor. They are not the most dominant factor - content relevance and backlinks still carry more weight - but they are a tiebreaker that can meaningfully differentiate between sites competing for similar positions.

Beyond rankings, the business case is direct. Faster, more stable pages convert better. This is not theoretical.

Vodafone UK improved their LCP score and saw a 31% increase in sales. Retailer Farfetch found that a 100ms improvement in page load time correlated with a 1.3% increase in conversion rate. These are not small margins when applied across thousands of daily visitors.

The Asos case study is instructive for UK e-commerce businesses. In 2025, Asos published internal research showing that their mobile checkout pages with poor CLS scores had a 15% higher basket abandonment rate than pages with "Good" CLS scores - even when the actual checkout functionality was identical. Users were clicking the wrong elements because buttons were shifting, growing frustrated, and leaving.

Core Web Vitals, in other words, are not an abstract SEO metric. They are a measure of whether your site works properly for the people using it on their actual devices.

The Thresholds: Good, Needs Improvement, Poor

To pass Core Web Vitals overall, a URL needs to achieve "Good" on all three metrics. Google's Page Experience signal uses the 75th percentile of user visits - meaning 75% of visits to that page need to meet the "Good" threshold, not just the average.

How to Measure Your Core Web Vitals

Google PageSpeed Insights (pagespeed.web.dev) is the fastest starting point. Enter any URL and it gives you both lab data (a simulated test) and field data (real user experience from Chrome). The field data section is what Google uses for ranking. The lab data section is more useful for debugging because it gives you specific recommendations.

Google Search Console shows Core Web Vitals data across your entire site under the "Experience" section. It groups URLs with similar performance and shows trends over time. If you have never looked at this, start here - it gives you the widest view of where your site's performance problems are concentrated.

CrUX (Chrome User Experience Report) is the underlying dataset that both of the above tools draw from. You can query it directly via BigQuery if you want granular historical data, but for most businesses the tools above are sufficient.

Lighthouse runs in Chrome DevTools (press F12, go to the Lighthouse tab). It gives you a detailed lab report with specific, prioritised recommendations for each issue. Useful for developers investigating specific pages.

A note on field data vs lab data: they will not always match. Field data reflects the actual range of devices, connection speeds, and user behaviour patterns visiting your site. Lab data uses a standardised simulated device. Both are useful, but field data is what Google cares about for ranking.

LCP: What Causes It and How to Fix It

The LCP element is whatever piece of content takes up the most space in the visible viewport when the page loads. For most sites, this is the hero image. For text-heavy pages, it might be a heading or a paragraph.

Common causes of poor LCP:

Large, unoptimised images are the most common culprit. A hero image that is 3MB in PNG format, loaded at full resolution on a mobile device with a 4G connection, will produce a terrible LCP score. The fix is to compress images (WebP format achieves similar quality at roughly 30% smaller file size than JPEG), use responsive image sizes (srcset), and implement lazy loading for images below the fold (though never lazy load the LCP image itself - that makes things worse).

Render-blocking resources are another major cause. If your page loads several large CSS files or synchronous JavaScript before it can display the main content, LCP suffers. The fix involves auditing which scripts are truly essential for initial page render, deferring or async-loading everything else.

Slow server response time (TTFB - Time to First Byte) upstream of LCP. If your server takes 1.5 seconds to respond at all, your LCP cannot possibly be under 2.5 seconds. Fix: upgrade hosting, implement server-side caching, or use a CDN (Content Delivery Network) to serve content from servers closer to your users.

INP: What Causes It and How to Fix It

INP measures the time between a user interaction (tap, click, keyboard input) and the next visual update on screen. A high INP means your page feels sluggish to interact with.

Common causes of poor INP:

Heavy JavaScript execution on the main thread. When JavaScript is doing a lot of work - processing data, running animations, handling analytics events - it blocks the main thread and delays visual responses to user inputs. The fix involves identifying long tasks in the browser's Performance profiler and breaking them up, deferring non-essential scripts, or moving heavy work to Web Workers (background threads that do not block the main thread).

Third-party scripts are a particularly common INP offender. Chat widgets, advertising scripts, and analytics tools all run JavaScript that competes for main thread time. Auditing which third-party scripts are genuinely necessary and loading non-essential ones after the page is interactive can make a substantial difference.

Excessive DOM size. Pages with thousands of HTML elements take longer to update when the user interacts with them. Virtualising long lists (only rendering elements visible on screen) and simplifying DOM structure can help.

CLS: What Causes It and How to Fix It

CLS measures unexpected visual shifts while a page loads. A score of 0 means nothing moved unexpectedly. A score of 0.25 or above is poor - users are experiencing significant content jumping around.

Common causes of poor CLS:

Images without dimensions. If your <img> tags do not specify a width and height, the browser does not know how much space to reserve. When the image loads, it pushes everything below it down. The fix is simple: always include width and height attributes on <img> elements.

Ads, embeds, and iframes that load asynchronously. Ad slots that load after the rest of the page is displayed are one of the most common CLS culprits. Fix: reserve space for ad units with a minimum height container before the ad loads.

Dynamically injected content. Banners, cookie consent notices, and personalisation elements that appear after initial load can push content down significantly. Fix: either pre-render these elements as part of the initial HTML or ensure they load in reserved space.

Web fonts causing a flash of unstyled text (FOUT). If your custom font loads after text has already rendered in a fallback system font, the text may reflow if the fonts have different dimensions. Fix: use font-display: optional or preload critical fonts with <link rel="preload">.

A Practical Improvement Story

Here is a realistic example of how Core Web Vitals work in practice.

A UK-based homeware retailer was ranking on page two for several competitive product category terms. Their content was solid, they had reasonable backlinks, but PageSpeed Insights showed an LCP of 5.8 seconds on mobile and a CLS of 0.31 - both in the "Poor" range.

The primary issues were: a 2.4MB hero image on every category page, three chat and analytics scripts loading synchronously, and no dimensions on product thumbnail images.

Over six weeks, they: converted the hero image to WebP and implemented responsive sizing (LCP image size dropped from 2.4MB to 380KB), deferred the analytics and chat scripts, and added width/height attributes to all product images.

Results: LCP improved from 5.8 seconds to 2.1 seconds (Good range). CLS dropped from 0.31 to 0.07 (Good range). Mobile conversion rate increased by 11% over the following 90 days. Three of their target category pages moved from page two to page one within eight weeks of the improvements.

The ranking improvement was not solely due to Core Web Vitals - but the technical foundation enabled their content quality to be assessed more fairly.

Where Core Web Vitals Fit in Your SEO Strategy

Core Web Vitals sit within the broader technical SEO discipline. If you are working through a full technical SEO audit, they are one layer of a larger picture that also includes crawlability, indexability, site architecture, and on-page SEO factors.

For businesses running content marketing programmes, it is worth understanding that a slow or unstable site undermines every other SEO investment. You can publish excellent keyword-targeted content with strong schema markup and solid on-page optimisation, but if your pages perform poorly for real users, Google will deprioritise them in favour of technically sound competitors.

Fix the foundation, then build on it. Core Web Vitals are part of that foundation.

Frequently Asked Questions

Are Core Web Vitals the most important SEO ranking factor?

No. Content relevance, topical authority, and backlinks remain the dominant ranking signals. Core Web Vitals are best described as a quality threshold - passing them does not guarantee top rankings, but failing them puts you at a disadvantage against competitors who pass. Google has confirmed that a page with excellent content may still outrank a faster competitor if the content difference is significant enough. The goal is to ensure poor performance is not the reason you are not ranking, not to assume performance improvements alone will push you to position one.

How long does it take to see improvements after fixing Core Web Vitals?

Google's field data is collected over a rolling 28-day window. This means improvements are not reflected immediately - it typically takes four to six weeks after deploying fixes for the field data to update fully. You will see lab data improvements (in PageSpeed Insights and Lighthouse) immediately. Ranking changes, if they occur, often follow two to four weeks after field data improves.

My PageSpeed Insights score is 95 on desktop but 40 on mobile. Is that a problem?

Yes. Google uses mobile-first indexing, which means it primarily uses the mobile version of your site for ranking assessments. A high desktop score with a low mobile score is a meaningful problem. Mobile devices have slower processors and more variable network connections, so they are inherently more likely to expose performance issues. Fix mobile performance first.

Do Core Web Vitals apply to all pages on my site, or just the homepage?

All pages. Google evaluates Core Web Vitals at the URL level. Your homepage might perform brilliantly while your blog posts or product pages perform poorly. Google Search Console's Core Web Vitals report groups URLs by performance - check it across all your important page types, not just the homepage.

Can I improve Core Web Vitals without a developer?

For some issues, yes. Compressing and reformatting images, removing unnecessary third-party scripts, and switching to a faster hosting provider are changes that often do not require deep technical knowledge. For issues involving JavaScript execution, render-blocking resources, or server-side caching, developer involvement is usually needed. The PageSpeed Insights report gives prioritised recommendations - start with the ones that say "Largest opportunity" and assess which are within reach without development resource.

Core Web Vitals represent Google making official what has always been true in practice: slow, unstable websites provide worse user experiences, and worse user experiences deserve worse rankings. Improving your scores is not just about satisfying an algorithm. It is about building a site that your actual customers enjoy using. Those two things, fortunately, point in exactly the same direction.