Core Web Vitals Explained: What They Are and Why They Matter?

Website performance has a direct and measurable impact on business outcomes. Websites that load faster, respond quickly to user interactions, and maintain stable layouts consistently see higher engagement and better conversion rates. Core Web Vitals are Google's initiative to quantify exactly that experience and translate it into a ranking signal.

However, most Core Web Vitals documentation is written for developers, full of technical jargon that assumes you understand render trees, JavaScript execution threads, and browser parsing pipelines. The reality is that many of the most damaging Core Web Vitals issues are caused by business and content decisions, not code, and most of them can be addressed without a developer.

If you are new to how Google evaluates your website, our guide on what is technical SEO covers the foundation before you dive into this.

This guide explains what Core Web Vitals are, how each one is measured, where to find your scores, and the most common issues, both developer and non-developer, that cause pages to fail.

What Are the Core Web Vitals?

Core Web Vitals are a set of three metrics Google uses to measure the real-world page experience of your website. They became an official Google ranking factor in June 2021 as part of the Page Experience update and have remained a confirmed ranking signal ever since.

The three metrics are:

Largest Contentful Paint (LCP) measures loading performance: how long it takes for the largest visible element on the page, typically a hero image or a main heading, to appear after the page starts loading.

Cumulative Layout Shift (CLS) measures visual stability: how much the content on the page shifts around unexpectedly while it is loading.

Interaction to Next Paint (INP) measures interactivity: how quickly the page responds to clicks, taps, and keyboard inputs. INP replaced the older First Input Delay (FID) metric in March 2024 and is now the official responsiveness signal.

Each metric has a three-tier threshold: Good, Needs Improvement, and Poor. Lower numbers are always better across all three.

How Are Core Web Vitals Measured?

Core Web Vitals are measured by the real users visiting your website. They are not what Google's crawler thinks, not a lab simulation, and not a guess. They are aggregated data from real Chrome users who have actually visited your pages.

Different users will produce different results depending on their device speed, network connection, and the specific page they visited. Google collects this data through the Chrome User Experience Report (CrUX), which aggregates field data from opted-in Chrome users. This data feeds into Google Search Console and PageSpeed Insights.

If your site does not yet have enough traffic to appear in CrUX, PageSpeed Insights will fall back to lab data generated by Lighthouse, Google's open-source automated auditing tool. Lab data is useful for diagnosis but is not what Google uses for ranking purposes.

How to Find Your Core Web Vitals?

PageSpeed Insights is the fastest way to check your scores with no setup required. Go to pagespeed.web.dev, enter your URL, and you will see your real-user field data from the past 28 days. You can toggle between mobile and desktop, and between a single URL and the full origin data for your domain.

Google Search Console is more useful for site owners because it shows Core Web Vitals data across every page Google has indexed on your site, not just a single URL. The Core Web Vitals report groups pages by URL patterns, so you can quickly identify whether a specific category of page, product pages, blog posts, or landing pages is the source of your performance issues. It requires ownership verification but is free.

For a deeper workflow covering how to use both tools together, Google's own Core Web Vitals workflows with Google tools guide is the most detailed reference available.

Largest Contentful Paint (LCP)

What does it measure?

LCP measures the time from when a user clicks a link or navigates to a page until the largest piece of visible content has finished rendering in the viewport. On most web pages, that element is a hero image or a large banner. On text-heavy pages, it may be a large heading or paragraph block.

Thresholds

Common LCP Issues

Slow server response time (TTFB). Time to First Byte is the time it takes for a user's browser to receive the very first byte of data from your server. If TTFB is high, LCP cannot be good, the page has not even started downloading yet. For sites serving a global audience from a single server location, a Content Delivery Network (CDN) is the most impactful fix. It caches copies of your site closer to your users geographically.

Unoptimized images. The LCP element is an image on approximately 80% of web pages. Large images in outdated formats like PNG or JPEG take significantly longer to download than the same image converted to WebP or AVIF. Providing images at the correct display dimensions rather than relying on CSS to resize them is an equally important fix that most site owners overlook.

Lazy loading is applied to the LCP image. Lazy loading defers image loading until the element scrolls into view. It is beneficial for images lower down the page, but if applied to your hero image, which is the LCP element, it tells the browser to intentionally delay loading the most important asset on the page. This is one of the most common and most avoidable LCP mistakes.

Render-blocking resources. CSS and JavaScript files that load in the document <head> before the page content can block the browser from rendering anything. Every non-critical stylesheet and script that loads before your LCP element adds directly to your LCP time.

Redirects. When running ad campaigns or email campaigns, each redirect in the URL chain adds latency before the page even begins to download. Using example.com/blog that redirects to www.example.com/blog that redirects to https://www.example.com/blog is three network round trips before a single byte of the actual page is received.

A/B testing tools. Many A/B testing solutions deliberately hide the page from the user until the test variant has been applied to prevent a flash of the original version. This delay adds directly to LCP. Server-side A/B testing implementations avoid this problem entirely. If you are running client-side A/B tests, limiting them to the specific pages being tested and to a subset of users reduces the impact significantly.

Cumulative Layout Shift (CLS)

What does it measure?

CLS measures how much the visible content of a page moves around unexpectedly as the page loads. If you have ever started reading a paragraph on a web page and then had an ad or image load above it, pushing your text down so you lose your place, that is a layout shift. If you have ever tried to tap a button and had it shift just as you tapped it, causing you to click something unintended, that is also a layout shift.

CLS is expressed as a unitless score calculated by multiplying the fraction of the viewport that was shifted by the distance it shifted.

Thresholds

Common CLS Issues

Images without declared dimensions. When a browser parses your HTML, it needs to know how much space to reserve for each image before that image has been downloaded. If your <img> tags have no width and height attributes, the browser reserves zero space, and when the image loads, it pushes all surrounding content down the page. Declaring dimensions on every image is the single most impactful CLS fix available.

Ads without reserved space. Ad slots load asynchronously, meaning they arrive after the initial page content. If the container that holds the ad has no defined minimum height, the content above and below it will shift when the ad appears. Assigning a minimum height to ad containers that matches the expected ad dimensions prevents this entirely.

Dynamically injected content. Cookie consent banners, promotional ribbons, newsletter popups, and live chat widgets that inject into the page after load and push existing content down are a significant source of CLS. Overlaying these elements on top of content rather than inserting them into the content flow eliminates the shift.

Web font loading. When a browser renders text before a custom font has loaded, it uses a fallback font. When the custom font arrives, the text re-renders and often shifts slightly. Using font-display: optional prevents this shift entirely by only applying the custom font if it loads within a brief initial window.

CSS animations on layout properties. Animations that change top, left, margin, width, or height cause layout shifts because they trigger re-layout in the browser. Animations using transform and opacity run on the compositor thread and do not cause layout shifts.

Interaction to Next Paint (INP)

What does it measure?

INP measures how quickly a page responds to every user interaction across the entire lifetime of the page, not just the first click. It tracks clicks, taps, and keyboard inputs, and reports the worst-performing interaction with some tolerance for statistical outliers.

The distinction from its predecessor FID is important. FID only measured the delay before the browser started processing the first interaction. INP measures the full time from the interaction until the next visual update, including input delay, processing time, and presentation delay. It is a considerably more demanding metric.

Thresholds

Common INP Issues

Excessive JavaScript. The browser's main thread handles rendering, layout, and responding to user interactions. Heavy JavaScript files that execute on the main thread block it from processing user input. When a user clicks a button during a long JavaScript task, the browser cannot respond until the task finishes.

Third-party scripts. Chat widgets, CRM trackers, heatmap tools, advertising pixels, and analytics scripts all add to the JavaScript that the browser must parse and execute. A page running fifteen or more third-party scripts on every load is almost certainly producing poor INP on mid-range mobile devices.

Tag manager bloat. Google Tag Manager is a common cause of INP issues on sites that have been running marketing campaigns over time. Even when an old campaign tag is no longer firing, its code still loads and compiles on every page visit. Removing expired tags from your tag manager has a direct impact on INP with no developer involvement.

Large and complex DOM. A page with thousands of DOM nodes, such as a product listing page displaying hundreds of items simultaneously, takes longer to update in response to user input. Paginating large listings rather than loading everything at once reduces DOM complexity and improves INP.

Expensive widgets loaded globally. A Google Maps embed loaded on every page of a site, rather than only on the contact page where it is actually needed, adds JavaScript execution cost to every page visit. Loading widgets only on the pages that require them is a straightforward fix.

Core Web Vitals and SEO Rankings

Core Web Vitals are confirmed as a Google ranking signal but operate as a tiebreaker rather than a primary ranking driver. Content relevance, backlinks, and site authority still carry significantly more weight. Read our breakdown of what actually decides Google rankings for more context on where Core Web Vitals fit within the full picture.

The practical implication is this: poor Core Web Vitals scores will not prevent a page with strong authority and highly relevant content from ranking, but they create a ceiling. In competitive SERPs where multiple pages are roughly equivalent in authority and relevance, page experience becomes the deciding factor. Beyond rankings, the indirect effects are significant: faster pages produce lower bounce rates, longer session durations, and higher conversion rates, all of which feed positive behavioral signals back to Google.

Core Web Vitals and Your Website Platform

WordPress. WordPress sites range from very fast to extremely slow depending on the theme, plugins, and hosting. The most common causes of poor Core Web Vitals on WordPress are heavy page builder themes, unoptimized images, and plugin accumulation. Caching plugins, CDN integration, and image compression plugins address the majority of issues.

Shopify. Shopify manages CDN, hosting infrastructure, and image optimization automatically. The primary causes of poor CWV on Shopify are theme file bloat, excessive third-party app installs, and large product images. Because direct code access is limited, most Shopify CWV improvements involve app management and image optimization.

Wix and Squarespace. These platforms have improved their Core Web Vitals performance substantially in recent years. Your control over underlying code is limited, so your available fixes centre on image optimization, reducing embedded third-party content, and using simpler page templates.

Next.js. Next.js is built with performance as a foundational priority. Automatic image optimization, static site generation, incremental static regeneration, and code splitting at the route level all contribute directly to strong Core Web Vitals scores by default. Suppose your site is currently built on a framework that consistently fails Core Web Vitals despite optimization efforts; a rebuild on a more performant architecture addresses the problem at the root. Our Next.js website development service is designed specifically for businesses where performance is a competitive requirement.

Getting More Help

The issues described in this guide represent the most common non-developer causes of poor Core Web Vitals. Many of them can be addressed without writing a single line of code, image optimization, removing unused plugins, cleaning up tag manager, and reserving space for ads.

Beyond these, a web developer with performance expertise will be needed to address render-blocking resources, JavaScript execution issues, server-side caching configurations, and code-level changes to how your page loads assets.

Google's web.dev resource is the most comprehensive documentation available for the technical implementation side. For platform-specific guidance, most major platforms maintain their own performance documentation.

If you want a systematic audit of your site's Core Web Vitals with a prioritized fix list, our technical SEO services include a full page experience audit as a core component of every engagement.

Related: What Factors Actually Decide Google Rankings · On-Page SEO: The Only Strategy You Need