What Are Core Web Vitals?

What Core Web Vitals Are and Why Google Created Them

For most of Google's history, ranking was almost entirely about content and links. Did your page answer the query? Did other authoritative sites link to you? Those signals still matter enormously. But by the late 2010s, Google began to recognize a real problem: pages that were technically "relevant" were delivering terrible user experiences. Slow loading times, layouts that jumped around while the page rendered, buttons that didn't respond for several seconds — these experiences frustrated users and eroded trust in Google's results.

In May 2020, Google announced Core Web Vitals as a formal initiative: a specific, measurable subset of user experience signals that would be incorporated into its ranking systems. The message was clear — it was no longer enough to have good content and strong links. The experience of actually loading and using your page had to meet a baseline standard.

Core Web Vitals currently consist of three metrics: Largest Contentful Paint (LCP), which measures loading performance; Cumulative Layout Shift (CLS), which measures visual stability; and Interaction to Next Paint (INP), which measures responsiveness. Each metric has defined "Good," "Needs Improvement," and "Poor" thresholds. Google collects real-world data from Chrome users through the Chrome User Experience Report (CrUX) and uses this field data — not synthetic lab tests — as the primary input for rankings.

The broader context matters here: Core Web Vitals are part of what Google calls the Page Experience signal, which also includes mobile-friendliness, HTTPS security, and the absence of intrusive interstitials. Core Web Vitals are the most technically demanding component of that signal and the area where most sites have room to improve.

LCP: Largest Contentful Paint

Largest Contentful Paint measures how long it takes for the largest visible content element on the page to fully render within the user's viewport. It is Google's preferred proxy for perceived load speed — the moment when a user feels the page has "arrived."

What LCP Measures

LCP tracks the render time of the largest image, video thumbnail, background image rendered via CSS, or block-level text element visible in the initial viewport. In practice, the LCP element on most pages is a hero image, the main H1 heading, or a featured video thumbnail. The browser identifies the largest element at each point during load and updates the LCP candidate as more content appears. The final LCP time is recorded when the page fully loads and user interaction begins.

LCP Thresholds

• Good: 2.5 seconds or faster
• Needs Improvement: 2.5 to 4.0 seconds
• Poor: Slower than 4.0 seconds

Google recommends targeting the 75th percentile of page loads — meaning at least 75% of your real-world visitors need to experience an LCP within the "Good" range for your site to receive the full ranking benefit. A median score of 2.3 seconds is meaningless if 30% of your mobile visitors are waiting 5+ seconds.

Why LCP Matters Beyond Rankings

User research consistently shows that load speed directly correlates with bounce rate and conversion rate. Google's own studies found that as page load time increases from 1 second to 3 seconds, the probability of a mobile visitor bouncing increases by 32%. At 5 seconds, that probability rises by 90%. LCP is a strong predictor of these outcomes because it captures the moment users decide whether the page is worth waiting for. A site with a Poor LCP score is not just losing ranking positions — it is losing customers at the door.

CLS: Cumulative Layout Shift

Cumulative Layout Shift measures the visual instability of a page — specifically, how much the content unexpectedly moves around during and after the initial load. If you've ever tried to tap a button and watched it jump just as your finger landed, causing you to click something else entirely, you've experienced a bad CLS event.

What CLS Measures

CLS is calculated by multiplying two factors: the impact fraction (what portion of the viewport was affected by the shift) and the distance fraction (how far the element moved relative to the viewport). These values are summed across all unexpected layout shifts that occur during the page's lifespan. Only unexpected shifts count — movements triggered by user interaction like clicking a button or scrolling are excluded. The result is a unitless score, where lower is better.

CLS Thresholds

• Good: 0.1 or less
• Needs Improvement: 0.1 to 0.25
• Poor: Greater than 0.25

Common Causes of High CLS

The most frequent CLS culprits are predictable once you understand the mechanism. When the browser begins rendering a page, it lays out elements based on what it knows. If an image has no declared width and height attributes, the browser reserves no space for it — so when the image finally downloads and appears, it pushes everything below it downward. This is the single most common CLS cause on the web today.

• Images and video without explicit dimensions. Always set width and height attributes in your HTML. Modern CSS can then scale them responsively without causing layout shifts.
• Late-loading ads and embeds. Ad slots that expand after initial render, or embedded content (social media posts, iframes) that load asynchronously and push content down, are major CLS contributors.
• Web fonts causing FOUT (Flash of Unstyled Text). When a web font loads late, the browser may swap the fallback font for the web font mid-render. If the two fonts have different metrics, text reflows and everything shifts. Using font-display: swap with size-adjusted fallback fonts mitigates this.
• Dynamically injected content. Banners, cookie consent popups, or newsletter bars inserted above existing content after load cause massive layout shifts and are a primary source of Poor CLS scores on otherwise well-built sites.

INP: Interaction to Next Paint

Interaction to Next Paint is the newest of the three Core Web Vitals and, for many developers and site owners, the hardest to understand and the hardest to fix. It officially replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Why INP Replaced FID

FID measured the delay before the browser could begin processing the very first user interaction on a page — typically a click or tap. It was a reasonable proxy for responsiveness in the early days, but it had a significant blind spot: it only measured the delay for the first interaction, and it only measured the delay before processing began, not how long the actual response took. A page could pass FID easily while still feeling sluggish during every subsequent interaction.

INP fixes both problems. It measures the full response latency — from when the user interacts to when the browser paints the next frame in response — for every interaction throughout the entire page session, not just the first one. The reported INP score is the worst (or near-worst) interaction latency observed, giving a comprehensive picture of how consistently responsive a page actually is.

INP Thresholds

• Good: 200 milliseconds or less
• Needs Improvement: 200 to 500 milliseconds
• Poor: Greater than 500 milliseconds

Why INP Is Harder to Pass Than FID Was

When FID was the standard, sites could pass simply by deferring most JavaScript until after the first interaction. INP cannot be gamed this way because it evaluates all interactions. A site with heavy JavaScript frameworks, excessive event handlers, long tasks that monopolize the main thread, or aggressive third-party script loading will fail INP even if it passed FID comfortably. Many sites that had green scores across all Core Web Vitals under the old framework discovered they had Poor or Needs Improvement INP scores when the metric rolled out.

The practical implication: improving INP often requires deeper JavaScript optimization work — breaking long tasks into smaller chunks, moving heavy computations off the main thread using Web Workers, auditing and reducing third-party script load, and deferring non-critical event handlers.

How to Check Your Core Web Vitals

Before you can fix anything, you need accurate data. The distinction between lab data and field data is critical here — and confusing this distinction leads many site owners to draw wrong conclusions about their performance.

Field Data vs. Lab Data

Field data (also called real-user monitoring or RUM data) comes from actual Chrome users visiting your site. Google collects this through the Chrome User Experience Report and aggregates it over a 28-day rolling window. This is the data that influences rankings. Its limitation: you need sufficient traffic to generate a statistically meaningful dataset, and it takes time to reflect changes you make to your site.

Lab data comes from synthetic tools — automated tests run in a controlled environment simulating a specific device and network connection. Lab data is immediately available and reproducible, making it ideal for diagnosing problems and verifying fixes. But lab scores are not what Google uses for rankings, and a lab score of "Good" does not guarantee your field data is also Good.

Tools for Checking CWV

• Google Search Console — Core Web Vitals report. The authoritative source for field data at scale. Shows which URLs are Good, Need Improvement, or Poor based on real user data, grouped by issue type. This is where to start.
• PageSpeed Insights (PSI). Shows both field data (from CrUX, for the specific URL) and lab data (from Lighthouse). The most useful single tool for diagnosing individual pages.
• Chrome UX Report (CrUX). The raw dataset behind Google's field data. Queryable via BigQuery or accessible through the CrUX API for programmatic analysis.
• Lighthouse. Google's open-source auditing tool, available in Chrome DevTools, as a CLI, and as the engine behind PageSpeed Insights. Best for lab-environment diagnosis and identifying specific technical issues causing poor scores.
• Chrome DevTools Performance panel. For deep-dive diagnosis of LCP element selection, layout shift events, and long tasks that affect INP. Essential when PSI scores don't tell the full story.

Common LCP Failures and How to Fix Them

Poor LCP scores almost always trace back to a small set of root causes. Understanding the sequence — server response, resource loading, render — helps you identify which layer your problem lives in.

Slow Server Response Time (TTFB)

If the server takes 800ms to respond with the initial HTML, LCP cannot possibly be under 2.5 seconds on a slow connection. Time to First Byte (TTFB) is the foundation everything else builds on. Fixes include upgrading hosting infrastructure, implementing server-side caching, using a Content Delivery Network (CDN) to serve responses from servers geographically closer to users, and optimizing database queries for dynamically generated pages.

Render-Blocking Resources

CSS and JavaScript files that are loaded in the <head> block the browser from rendering any content until they finish downloading and processing. Every millisecond the browser spends parsing a 200KB CSS bundle or executing a synchronous JavaScript file is a millisecond added to LCP. Fixes include inlining critical CSS, deferring or asynchronously loading non-critical JavaScript, and eliminating unused CSS/JS from the critical path.

Unoptimized Images

When the LCP element is an image — which it is on the majority of pages — image optimization is the highest-leverage fix available. Key techniques include: converting images to modern formats like WebP or AVIF (typically 30–50% smaller than JPEG at equivalent quality), serving appropriately sized images using the srcset attribute so mobile devices don't download desktop-resolution images, adding <link rel="preload"> hints in the <head> for the LCP image so the browser discovers and starts downloading it immediately, and ensuring the LCP image is not lazy-loaded (lazy loading is counterproductive for above-the-fold content).

Slow Third-Party Scripts

Analytics platforms, live chat widgets, A/B testing tools, advertising pixels, and social media embeds all represent third-party JavaScript that executes on your page. Any one of these can introduce significant LCP delays if they block rendering or compete for network bandwidth during the critical loading window. Audit your third-party scripts regularly using the Network panel in Chrome DevTools. Load non-critical scripts with async or defer attributes, and consider whether every third-party tag in your tag manager is actually delivering measurable business value.

CLS Causes and How to Fix Them

CLS is one of the more fixable Core Web Vitals once you understand the root causes. Most fixes are straightforward HTML and CSS changes that require no complex infrastructure work.

Always Set Explicit Dimensions on Images and Video

Every <img> and <video> element should have both width and height attributes set to the intrinsic dimensions of the media. Modern browsers use these values to calculate the correct aspect ratio and reserve the appropriate space before the media loads, completely eliminating the shift. Pair this with CSS height: auto to maintain responsive behavior. This single fix resolves the majority of CLS issues on image-heavy pages.

Reserve Space for Ads and Embeds

Ad slots should have a minimum size reserved in CSS so that when an ad loads, it fills existing space rather than pushing content downward. Use a wrapper element with a fixed min-height matching the expected ad unit size. For embeds (YouTube videos, Twitter cards, maps), use the aspect-ratio CSS property or padding-bottom hack to maintain proper space reservation before the embed loads.

Use font-display: swap with Size-Adjusted Fallbacks

The font-display: swap CSS property tells the browser to render text immediately using the fallback font and swap to the web font once it loads, preventing invisible text. However, if the fallback and web font have different character widths and line heights, the swap itself causes a layout shift. The modern solution is to use the size-adjust, ascent-override, and descent-override CSS descriptors to make your fallback font metrics match the web font as closely as possible, so when the swap occurs, the visual difference is imperceptible.

Avoid Injecting Content Above Existing Content

Cookie consent banners, promotional notifications, and subscription popups are all legitimate business tools — but they should never be inserted above existing content after the page has rendered. Use fixed or sticky positioning to overlay banners at the top or bottom of the viewport without displacing page content. If a banner must appear in the content flow, reserve its space in the initial HTML so the browser allocates the space before the banner script loads.

INP Causes and How to Fix Them

Improving INP is typically the most technically demanding Core Web Vitals work. It requires understanding JavaScript execution patterns, browser rendering architecture, and the impact of third-party code — areas that go beyond typical SEO optimization.

Long Tasks on the Main Thread

The browser's main thread handles JavaScript execution, layout calculations, paint operations, and user input processing. When a long task — any JavaScript operation that takes more than 50 milliseconds — is running on the main thread, the browser cannot respond to user interactions until the task completes. This is the primary cause of poor INP. Fix: audit your JavaScript bundle for long tasks using the Performance panel in Chrome DevTools, then break monolithic functions into smaller chunks using setTimeout with zero delay, requestIdleCallback, or the Scheduler API to yield control back to the browser between work items.

Heavy JavaScript Frameworks

Single-page applications built on React, Vue, Angular, or similar frameworks can introduce significant INP problems when component re-renders are triggered by user interactions. If a button click causes a large component tree to re-render, the browser must process that entire computation before painting the response. Optimization strategies include memoizing expensive computations, virtualizing long lists, code-splitting to reduce the JavaScript executed on any single interaction, and deferring hydration for above-the-fold content.

Excessive Event Handlers

Every event listener attached to DOM elements consumes processing time when those events fire. Sites that attach hundreds of click, scroll, or input listeners — particularly those using event delegation poorly, or those that trigger synchronous layout reads inside event handlers — can accumulate significant interaction latency. Audit event listeners using Chrome DevTools, consolidate handlers using event delegation at the document level, and avoid forced synchronous layouts (reading layout properties like offsetHeight immediately after DOM mutations).

Third-Party Script Impact on INP

The same third-party scripts that damage LCP can also devastate INP. A chat widget that runs continuous polling on the main thread, or an analytics script that performs heavy computation during page interaction, can add hundreds of milliseconds to every INP measurement. Use the Performance panel to identify which third-party scripts are running during user interactions. Load them in Web Workers where possible, defer them until after the page is interactive, or evaluate whether the business value justifies the performance cost.

How Core Web Vitals Affect Rankings

Google officially incorporated Core Web Vitals into its ranking systems as part of the Page Experience update, which rolled out in June 2021 and completed in August 2021. This made them a confirmed ranking signal — not a future consideration or a vague best practice, but a documented factor in how Google evaluates pages for competitive positions.

The realistic impact on rankings requires some nuance. Core Web Vitals function more as a tiebreaker than as a primary ranking signal. A page with excellent Core Web Vitals scores will not outrank a dramatically more authoritative and relevant page simply because it loads faster. Relevance and authority remain the dominant ranking factors. However, in competitive niches where multiple high-quality pages are competing for the same positions, Core Web Vitals scores can be the differentiating factor that determines which page Google selects for the top three results versus positions four through ten.

There's also an indirect ranking effect that is frequently underestimated. Pages with poor Core Web Vitals scores — particularly slow LCP — generate worse behavioral signals. Users bounce faster, spend less time on the page, and engage with fewer pages per session. Google incorporates behavioral signals into its quality assessments. A page that consistently drives users back to the search results is implicitly signaling to Google that it did not satisfy the query, which depresses rankings over time regardless of how strong the content and links are.

The practical advice: treat Core Web Vitals not as a ranking trick but as a baseline quality standard. If your scores are in the Poor range, fixing them will improve both your direct ranking eligibility and your behavioral metrics. If your scores are already Good, maintaining them is a competitive defensive measure — because your competitors are working on theirs.

The Business Case for Fixing Core Web Vitals

For business owners weighing whether to invest in Core Web Vitals optimization, the ranking argument alone may not be sufficient to justify the work. The business case based on direct user experience outcomes is often more compelling.

The data on load speed and business outcomes is extensive and consistent. Google's research across e-commerce sites found that improving mobile site speed by 0.1 seconds improved conversion rates by 8% on retail sites and 10% on travel sites. A study by Deloitte commissioned by Google found that a 0.1-second improvement in site speed across mobile sites translated to an 8% uplift in conversions. Walmart found that each one-second improvement in page load time resulted in a 2% increase in conversions. These aren't marginal effects — they represent meaningful revenue differences at scale.

Bounce rate is the most directly measurable business consequence of poor Core Web Vitals. When a page is slow to load (poor LCP), visually unstable (poor CLS), or unresponsive to input (poor INP), users leave. Every visitor who bounces before converting is a lost opportunity — paid or organic traffic that generated no return. Improving Core Web Vitals scores reduces bounce rates, increases time-on-site, and raises the probability that visitors complete the actions your business needs them to take.

For businesses running paid advertising — Google Ads, Meta campaigns, display networks — Core Web Vitals improvements compound the return on ad spend. If you're paying for clicks that land on a page with a 5-second LCP, you are paying for a significant percentage of visitors who leave before the page even finishes loading. Fixing the page experience converts more of the traffic you're already paying for, effectively reducing your cost per conversion without reducing your ad budget.