Core Web Vitals are Google's standardized set of metrics for measuring page experience. CLS is one of three metrics in the framework, responsible for measuring visual stability. Understanding how the three metrics relate to each other — and how the overall assessment works — is essential for technical SEO and performance optimization.
Core Web Vitals are a subset of web performance metrics that Google has designated as the most important indicators of real-world user experience on the web. They were introduced in May 2020 and began affecting Google search rankings in June 2021 through the Page Experience update. The framework was established because Google recognized that web performance had historically been measured using dozens of different metrics with varying degrees of relevance to actual user experience — a situation that made it difficult for developers and site owners to know what to prioritize.
Core Web Vitals solve this by standardizing three specific metrics that each measure a distinct and meaningful dimension of how users experience a page: how quickly the main content appears, how quickly the page responds to user input, and how stable the layout is during and after loading. Each metric has clearly defined thresholds for Good, Needs Improvement, and Poor performance, which allows consistent measurement and comparison across sites.
The three Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Each is measured from real-user data collected by the Chrome browser, and each must pass its respective threshold for a page to earn a "Good page experience" designation in Google Search Console.
LCP measures the time from when a user initiates a page load to when the largest content element visible in the viewport is rendered. The "largest content element" is typically a hero image, a large above-the-fold photograph, a video poster, or a large block of text. LCP is a loading performance metric — it captures how quickly users see the primary content of a page, which directly corresponds to their perception of how fast the page is.
The LCP thresholds are: Good at 2.5 seconds or less, Needs Improvement between 2.5 and 4 seconds, and Poor above 4 seconds. LCP is generally the most difficult Core Web Vital to improve because it depends on server response time, resource prioritization, image optimization, and render-blocking resources — a broader set of factors than either INP or CLS.
INP measures the latency of all user interactions — clicks, taps, and keyboard events — with a page during its entire lifetime, and reports the worst-case interaction latency. It replaced the earlier First Input Delay (FID) metric in March 2024 because FID only measured the delay before the browser began processing the first input event, while INP captures the full duration from input to visual response for all interactions throughout the page's lifetime.
The INP thresholds are: Good at 200 milliseconds or less, Needs Improvement between 200 and 500 milliseconds, and Poor above 500 milliseconds. Poor INP is typically caused by long JavaScript tasks that block the main thread, preventing the browser from processing user input and updating the display promptly.
CLS measures the visual stability of a page during and after loading. It quantifies how much the visible content unexpectedly moves while users are trying to interact with the page. Unlike LCP and INP, which measure time in seconds or milliseconds, CLS is a dimensionless score calculated from the impact fraction (how much of the viewport is affected by a shift) multiplied by the distance fraction (how far elements moved relative to the viewport). The score is calculated as the maximum score of any five-second session window of consecutive layout shifts during the page's lifetime.
The CLS thresholds are: Good at 0.1 or below, Needs Improvement between 0.1 and 0.25, and Poor above 0.25. CLS is the only Core Web Vital that measures stability rather than speed, and it is the metric most directly connected to the specific frustrations users encounter when content jumps unexpectedly — accidentally tapping the wrong link, losing their reading position, or having a form field shift away from the cursor.
Google's Core Web Vitals assessment evaluates each metric independently, using field data from the Chrome User Experience Report (CrUX). A page is rated based on the 75th percentile of real-user measurements collected over the preceding 28 days. This means that for a page to receive a "Good" rating for CLS, at least 75% of its real-user visits during the past 28 days must have produced a CLS score of 0.1 or below.
The 75th percentile threshold is deliberate and meaningful. It prevents a page from achieving a "Good" rating based on its performance for a fast, well-resourced subset of users if a substantial portion of users — up to 25% — are experiencing poor performance. A page that delivers excellent CLS to 80% of users but 0.40 CLS to 20% of users has a 75th percentile of approximately 0.1 or better and passes the assessment. A page that delivers excellent CLS to 70% of users and poor CLS to 30% of users may fail, depending on the distribution of scores in that 30%.
For a URL to receive an individual Core Web Vitals rating in Search Console, it must have sufficient traffic to be present in the CrUX dataset — typically several thousand visits over the 28-day measurement window. URLs with insufficient traffic are either not rated individually or are grouped with similar URLs on the same site for assessment purposes.
The three Core Web Vitals are causally independent — fixing CLS does not automatically improve LCP or INP, and vice versa. However, certain optimization approaches can affect multiple metrics simultaneously, and understanding the interactions between metrics helps prioritize work effectively.
LCP and CLS are frequently correlated on pages with above-the-fold images. When an image loads and causes a layout shift — because no width and height attributes were declared — it affects both metrics simultaneously: the image load extends LCP (since the image is often the largest visible element), and the shift from its late appearance contributes to CLS. Properly sizing and prioritizing the LCP image (with explicit dimensions and a fetchpriority="high" attribute) can improve both LCP and CLS in one change.
Conversely, aggressive lazy loading of images can create a tension between LCP and CLS. Lazy loading the LCP image improves CLS for users who scroll before the image loads, but it can significantly worsen LCP because the browser does not begin fetching the image until it enters the viewport, delaying the contentful paint. The recommended approach is to apply loading="eager" (or no lazy loading attribute at all) to above-the-fold images and loading="lazy" only to images that are initially below the viewport.
CLS and INP are less directly connected than CLS and LCP, but they share a common root cause: JavaScript executing after the initial page render. Heavy JavaScript execution that causes long main-thread tasks is the primary cause of poor INP. That same late JavaScript execution — when it injects new elements or resizes existing ones — is also a major source of CLS. Pages with large third-party script payloads frequently score poorly on both INP and CLS for this reason: the scripts block the main thread (hurting INP) and inject content that shifts the layout (hurting CLS).
Reducing third-party script load — by auditing and removing unnecessary scripts, deferring non-critical scripts, or replacing heavy third-party embeds with self-hosted alternatives — is one of the few optimization strategies that can simultaneously improve both INP and CLS.
Google announced Core Web Vitals in May 2020 as part of a broader effort to give developers a clear, stable set of quality signals to optimize for. The initial three metrics were LCP, First Input Delay (FID), and CLS. CLS was included from the beginning because layout instability had been consistently identified in user research as one of the most frustrating aspects of web browsing — particularly on mobile devices where accidental taps caused by shifting content are especially disruptive.
The Page Experience ranking signal, incorporating Core Web Vitals, began rolling out in June 2021 and completed its rollout in August 2021. At launch, it applied to mobile search results; it was extended to desktop results in February 2022.
A significant update to the CLS metric itself was made in June 2021. The original CLS calculation summed all individual layout shift scores across the entire page lifetime, which penalized long-lived pages — such as single-page applications and pages that users scroll through over many minutes — disproportionately compared to pages that were loaded and quickly abandoned. Google changed the calculation to use a session window approach, where layout shifts are grouped into windows of up to five seconds (with no gap of more than one second between consecutive shifts), and the CLS score reported is the maximum score of any single window. This change significantly improved the scores of many long-lived pages without changing the underlying measurement of genuinely disruptive shifts.
In March 2024, Google replaced FID with INP as the responsiveness metric within Core Web Vitals. FID measured only the delay before processing the first user input; INP measures the full input-to-display latency for all interactions throughout a page's lifetime and is a more complete and demanding measure of responsiveness. This change did not affect CLS but increased the difficulty of passing the overall Core Web Vitals assessment for many sites with JavaScript-heavy interaction patterns.
Core Web Vitals are the central component of Google's Page Experience signal, but they are not the only component. The full Page Experience signal also incorporates HTTPS usage and the absence of intrusive interstitials (such as full-page pop-ups that block content access). In practice, virtually all modern sites use HTTPS, and the intrusive interstitials signal targets a narrow set of aggressive content-blocking patterns. For most sites, improving Core Web Vitals — and specifically CLS, LCP, and INP — is equivalent to improving Page Experience.
Google has described the Page Experience signal as a tiebreaker rather than a primary ranking factor. In practice, this means that content quality, relevance, and authority remain the dominant ranking determinants. However, on competitive SERPs where multiple pages have comparable content quality, a good Page Experience rating can provide a meaningful ranking advantage. Dismissing CLS improvement as irrelevant to SEO because it is not the primary factor is a strategic error — particularly because the indirect effects of poor CLS on user engagement, bounce rate, and conversion rate have measurable consequences for the organic performance of any commercial website.
For most sites undertaking Core Web Vitals improvement work, the practical prioritization question is which metric to address first. The answer depends on which metric is currently failing, the nature of the site's content and architecture, and the relative difficulty of remediation.
CLS is often the most tractable Core Web Vital to improve because its root causes — images without declared dimensions, ads without reserved space, fonts causing layout reflow, and late-injected content — are identifiable at the element level and can be addressed through targeted changes without major architectural work. By contrast, LCP improvements frequently require server-side changes (CDN configuration, server response time optimization, resource prioritization) that involve more stakeholders and higher implementation complexity. INP improvements often require JavaScript refactoring that can be time-consuming and risky on large codebases.
The recommended starting point is to assess all three metrics in Google Search Console and determine which pages are failing which metrics. For sites where CLS is the primary failure mode — particularly e-commerce sites and content sites with ads — CLS remediation typically delivers the most immediate improvement to the Good URL percentage in Search Console for the least implementation effort.
For sites where all three metrics need improvement, a sequential approach works well: start with CLS (highest reward-to-effort ratio for many site types), then address LCP (the most impactful metric for perceived loading speed and one Google has explicitly identified as its highest-priority Core Web Vital), and finally refine INP (the most complex to remediate because it requires profiling JavaScript execution patterns on specific interaction paths).
Monitoring Core Web Vitals requires tracking both lab data (for diagnosing issues and verifying fixes) and field data (for confirming real-user impact and confirming that Search Console ratings have improved). For CLS specifically, the 28-day rolling window in Search Console means that improvements deployed today will not be fully reflected in the field data for up to four weeks — a timeline that needs to be communicated clearly to stakeholders expecting immediate confirmation of improvement.
For ongoing monitoring across all three metrics, the web-vitals JavaScript library provides a reliable implementation of all three Core Web Vitals that can be integrated into Google Analytics 4 or any custom analytics pipeline. This enables segmentation of CLS, LCP, and INP by page template, device type, geography, and user segment — providing the operational visibility needed to identify regressions quickly and to make the business case for continued investment in performance optimization.
Find out whether your pages pass the Core Web Vitals CLS threshold. Get your lab score, field data from real Chrome users, and a breakdown of the elements causing shifts — all in one free test.
Run the Free CLS Test