Core Web Vitals explained: why a slow website costs you sales

What are Core Web Vitals?

Core Web Vitals are a set of three metrics Google uses to describe the experience of loading and using a web page. They measure how quickly the main content appears, how quickly the page responds when someone taps or clicks, and whether the layout jumps around while it loads. Together they turn the vague complaint that a site feels slow into numbers you can track and improve.

The metrics are based on data from real Chrome users rather than a single test, and Google evaluates mobile and desktop separately. A page passes when at least 75 per cent of visits meet the good threshold for each metric. Core Web Vitals form part of Google’s page experience signals, which can influence search visibility alongside relevance and content quality.

LCP, INP and CLS: the current thresholds

Largest Contentful Paint (LCP) measures loading. It records how long it takes for the largest visible element, usually a hero image, video poster or headline, to render. Visitors judge a page by when its main content appears, so LCP is a good proxy for whether the page feels quick. Aim for 2.5 seconds or less.

Interaction to Next Paint (INP) measures responsiveness across the whole visit. It looks at clicks, taps and key presses and reports how long the page takes to show a visual response. INP replaced First Input Delay in March 2024 because FID only measured the first interaction. Aim for 200 milliseconds or less.

Cumulative Layout Shift (CLS) measures visual stability: how much content moves unexpectedly as the page loads. A button that shifts just as someone taps it, or text that jumps when an advert appears, creates frustration and accidental clicks. CLS is a unitless score, and a good page scores 0.1 or less.

Why a slow website costs you sales

Every extra moment of waiting gives a visitor a reason to leave. Slow pages raise bounce rates on landing pages, interrupt checkout journeys and make paid advertising less efficient because you pay for clicks that never become sessions. Unresponsive buttons and shifting layouts erode trust, particularly on mobile, where connections and devices vary widely.

Speed also affects how much of your marketing effort is visible. Page experience is one of many signals Google considers, and when two pages are similarly relevant, the better experience can help. More importantly, a fast site makes every other investment, from content to campaigns, work harder, because more visitors stay long enough to read, compare and buy.

How to measure Core Web Vitals

Start with PageSpeed Insights, Google’s free tool. Enter a URL and it shows two kinds of data: field data from real Chrome users, drawn from the Chrome User Experience Report (CrUX) over the previous 28 days, and lab data from a Lighthouse test run on simulated hardware. Field data tells you what customers actually experience; lab data helps diagnose why.

Google Search Console provides a Core Web Vitals report that groups your URLs into good, needs improvement and poor for mobile and desktop. It is the best way to see problems across a whole site rather than one page at a time. After deploying fixes, you can ask Search Console to validate them as new field data accumulates.

For deeper analysis, CrUX data is available through its API and BigQuery, and developers can collect their own real-user measurements with Google’s open-source web-vitals JavaScript library. Note that lab tools such as Lighthouse cannot measure INP directly, because it needs real interactions; Total Blocking Time is used as a lab proxy.

• PageSpeed Insights: page-level field and lab data
• Search Console: site-wide Core Web Vitals report
• CrUX API and BigQuery: historical real-user data
• Chrome DevTools and Lighthouse: diagnosing causes
• web-vitals library: your own real-user monitoring

Common fixes for each metric

Most Core Web Vitals problems come from a handful of causes: oversized images, too much JavaScript, slow servers, render-blocking resources, web fonts and third-party scripts such as chat widgets, tag managers and advertising tags. The fixes below address these causes and are the usual starting point for any professional performance audit.

Prioritise by impact. Fix the templates that carry the most traffic or revenue first, such as product, category and landing pages, rather than polishing rarely visited pages. Re-measure after each change, and remember that field data takes several weeks to reflect improvements fully, because CrUX reports a rolling 28-day window. Keep a simple log of changes so you can connect each improvement to its cause.

• Serve images in modern formats such as WebP or AVIF, correctly sized for each device
• Preload the LCP image and never lazy-load content above the fold
• Use a CDN and caching to reduce server response time
• Remove unused JavaScript and split large bundles
• Break up long tasks so the browser can respond to input quickly
• Audit and defer third-party scripts, removing those you no longer need
• Set width and height on images, videos and embeds to reserve space
• Reserve space for adverts, banners and cookie notices
• Load web fonts efficiently and use font-display settings to avoid layout shifts

Making performance improvements last

Performance is not a one-off project. New campaigns, plugins, tracking tags and design changes gradually add weight, and a site that passes today can fail in six months. Set performance budgets for page weight and script size, check Core Web Vitals in your release process, and review the Search Console report monthly.

If your site consistently struggles, the platform or architecture may be the limiting factor rather than individual pages. Gen7Ven’s performance optimisation service audits real-user data, fixes the highest-impact issues and puts monitoring in place so improvements hold. Whoever you work with, ask for before-and-after field data rather than lab scores alone.