---
title: "Core web vitals guide"
description: "Master Core Web Vitals - Google's page experience metrics. Learn LCP, CLS, INP thresholds, how to measure them, and fixes that improve rankings and conversions."
canonical_url: "https://unlighthouse.dev/learn-lighthouse/core-web-vitals"
last_updated: "2025-01-18"
---

Core Web Vitals are Google's metrics for measuring user experience. They became an official [Google ranking factor in June 2021](https://developers.google.com/search/docs/appearance/core-web-vitals) and directly affect both search visibility and user satisfaction.

As of 2024, only [48% of mobile sites pass all Core Web Vitals](https://almanac.httparchive.org/en/2024/performance). Optimizing these metrics gives you a competitive advantage over half the web.

## What are core web vitals

Core Web Vitals are three specific metrics that measure loading performance, visual stability, and interactivity:

<table>
<thead>
  <tr>
    <th>
      Metric
    </th>
    
    <th>
      Full Name
    </th>
    
    <th>
      Measures
    </th>
    
    <th>
      Good
    </th>
    
    <th>
      Poor
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        LCP
      </strong>
    </td>
    
    <td>
      Largest Contentful Paint
    </td>
    
    <td>
      Loading speed
    </td>
    
    <td>
      ≤2.5s
    </td>
    
    <td>
      >4.0s
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        CLS
      </strong>
    </td>
    
    <td>
      Cumulative Layout Shift
    </td>
    
    <td>
      Visual stability
    </td>
    
    <td>
      ≤0.1
    </td>
    
    <td>
      >0.25
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        INP
      </strong>
    </td>
    
    <td>
      Interaction to Next Paint
    </td>
    
    <td>
      Responsiveness
    </td>
    
    <td>
      ≤200ms
    </td>
    
    <td>
      >500ms
    </td>
  </tr>
</tbody>
</table>

Google [measures these thresholds at the 75th percentile](https://web.dev/articles/defining-core-web-vitals-thresholds) of page loads. 75% of visitors must experience "good" scores for your site to pass.

[INP replaced FID as a Core Web Vital on March 12, 2024](https://web.dev/blog/inp-cwv-march-12). If you're still optimizing for First Input Delay, you're targeting an outdated metric.

---

## Largest contentful paint (LCP)

LCP measures how long it takes for the largest visible content element to render. It's the hardest Core Web Vital to pass - [only 59% of mobile pages achieve good LCP](https://almanac.httparchive.org/en/2024/performance).

### What is a good LCP score

<table>
<thead>
  <tr>
    <th>
      LCP Time
    </th>
    
    <th>
      Rating
    </th>
    
    <th>
      What It Means
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ≤2.5s
    </td>
    
    <td>
      Good
    </td>
    
    <td>
      Users perceive the page as fast
    </td>
  </tr>
  
  <tr>
    <td>
      2.5-4.0s
    </td>
    
    <td>
      Needs Improvement
    </td>
    
    <td>
      Noticeable delay causes users to bounce
    </td>
  </tr>
  
  <tr>
    <td>
      >4.0s
    </td>
    
    <td>
      Poor
    </td>
    
    <td>
      Significant user frustration, high abandonment
    </td>
  </tr>
</tbody>
</table>

### What elements can be LCP

The LCP element is the largest image or text block visible in the viewport:

- **Images** (including CSS background images) - [73% of mobile pages use an image as their LCP element](https://almanac.httparchive.org/en/2024/performance)
- **Video poster images** (the thumbnail before playback)
- **Block-level text elements** (headings, paragraphs)
- **SVG elements** containing text or images

### Common LCP issues

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Prevalence
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="/learn-lighthouse/lcp/slow-server-response">
        Slow server response (TTFB)
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Sites with poor LCP average <a href="https://almanac.httparchive.org/en/2024/performance" rel="nofollow">
        2,270ms TTFB
      </a>
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/lcp/render-blocking-resources">
        Render-blocking resources
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      CSS and JS that delay first paint
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/lcp/large-images">
        Large unoptimized images
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Uncompressed or oversized images
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/lcp/client-side-rendering">
        Client-side rendering delays
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      JavaScript-heavy frameworks
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/lcp/prioritize-lcp-image">
        LCP image not prioritized
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Missing fetchpriority or preload
    </td>
  </tr>
</tbody>
</table>

### LCP business impact

- [Vodafone improved LCP by 31% and saw 8% more sales](https://web.dev/case-studies/vodafone)
- [NDTV halved their LCP and achieved 50% lower bounce rates](https://web.dev/case-studies/ndtv)
- [Tokopedia reduced LCP by 55% and increased organic traffic by 23%](https://web.dev/case-studies/tokopedia)

→ [Complete LCP guide](/learn-lighthouse/lcp) | [All LCP fixes](/learn-lighthouse/lcp#common-lcp-issues)

---

## Cumulative layout shift (CLS)

CLS measures unexpected layout shifts during the page lifecycle. It's the easiest Core Web Vital to pass - [79% of mobile sites achieve good CLS](https://almanac.httparchive.org/en/2024/performance).

### What is a good CLS score

<table>
<thead>
  <tr>
    <th>
      CLS Score
    </th>
    
    <th>
      Rating
    </th>
    
    <th>
      What It Means
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ≤0.1
    </td>
    
    <td>
      Good
    </td>
    
    <td>
      Stable layout, minimal shifts
    </td>
  </tr>
  
  <tr>
    <td>
      0.1-0.25
    </td>
    
    <td>
      Needs Improvement
    </td>
    
    <td>
      Noticeable movement frustrates users
    </td>
  </tr>
  
  <tr>
    <td>
      >0.25
    </td>
    
    <td>
      Poor
    </td>
    
    <td>
      Significant layout instability
    </td>
  </tr>
</tbody>
</table>

Lighthouse calculates CLS as: **Impact Fraction × Distance Fraction**. A shift affecting 50% of the viewport that moves 25% of the viewport height = 0.5 × 0.25 = 0.125 CLS.

### What causes layout shifts

<table>
<thead>
  <tr>
    <th>
      Cause
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Prevalence
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="/learn-lighthouse/cls/unsized-images">
        Images without dimensions
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      <a href="https://almanac.httparchive.org/en/2024/performance" rel="nofollow">
        66% of mobile pages
      </a>
      
       have unsized images
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/cls/ads-embeds-iframes">
        Ads and embeds
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Third-party content without reserved space
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/cls/dynamic-content-injection">
        Dynamically injected content
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Banners, notifications, modals
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/cls/web-fonts-causing-foit">
        Web fonts causing FOIT/FOUT
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Font swapping changes text size
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/cls/animations-transitions">
        CSS animations
      </a>
    </td>
    
    <td>
      Low
    </td>
    
    <td>
      Animations that trigger layout
    </td>
  </tr>
</tbody>
</table>

### CLS business impact

- [Redbus reduced CLS from 1.65 to 0 and saw 80-100% higher mobile conversion](https://web.dev/case-studies/vitals-business-impact)
- [Yahoo! Japan fixed CLS and achieved 15% more page views per session](https://web.dev/case-studies/vitals-business-impact)
- [AliExpress improved CLS and reduced bounce rate by 15%](https://web.dev/case-studies/vitals-business-impact)

→ [Complete CLS guide](/learn-lighthouse/cls) | [All CLS fixes](/learn-lighthouse/cls#common-cls-issues)

---

## Interaction to next paint (INP)

INP measures how quickly your page responds to user interactions. Unlike FID (which only measured the *first* interaction), INP tracks *all* interactions because [90% of user time on a page is spent after initial load](https://web.dev/articles/inp).

### What is a good INP score

<table>
<thead>
  <tr>
    <th>
      INP Time
    </th>
    
    <th>
      Rating
    </th>
    
    <th>
      What It Means
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ≤200ms
    </td>
    
    <td>
      Good
    </td>
    
    <td>
      Interactions feel instant
    </td>
  </tr>
  
  <tr>
    <td>
      200-500ms
    </td>
    
    <td>
      Needs Improvement
    </td>
    
    <td>
      Noticeable lag on interactions
    </td>
  </tr>
  
  <tr>
    <td>
      >500ms
    </td>
    
    <td>
      Poor
    </td>
    
    <td>
      Sluggish, frustrating experience
    </td>
  </tr>
</tbody>
</table>

### How lighthouse calculates INP

INP measures the full interaction lifecycle:

1. **Input delay**: Time from user action to event handler start
2. **Processing time**: Time to execute event handlers
3. **Presentation delay**: Time to render the visual update

The reported INP is typically the worst interaction (or 98th percentile for pages with many interactions).

### Common INP issues

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Lab Proxy
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/long-running-javascript">
        Long-running JavaScript
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Total Blocking Time (TBT)
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/event-handler-delays">
        Heavy event handlers
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Main thread work
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/dom-size">
        Large DOM size
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      DOM nodes >1,400
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/third-party-scripts">
        Third-party scripts
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Blocking main thread
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/hydration-issues">
        Hydration delays
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Framework-specific
    </td>
  </tr>
</tbody>
</table>

### The INP gap

While [93% of sites passed FID](https://web.dev/blog/inp-cwv), only [74% pass INP](https://almanac.httparchive.org/en/2024/performance). The desktop vs mobile gap is stark: **97% desktop** vs **74% mobile** pass INP.

### INP business impact

- [Trendyol reduced INP by 50% and saw 1% increase in click-through rate](https://web.dev/case-studies/vitals-business-impact)
- [The Economic Times cut INP by 30% and achieved 50% lower bounce rate](https://web.dev/case-studies/economic-times-inp)
- [redBus improved INP by 75% alongside 7% increase in conversions](https://web.dev/case-studies/redbus-inp)

→ [Complete INP guide](/learn-lighthouse/inp) | [All INP fixes](/learn-lighthouse/inp#common-inp-issues)

---

## Other web vitals

Beyond the three Core Web Vitals, several other metrics affect your Lighthouse Performance score and user experience.

### First contentful paint (FCP)

FCP measures when the first text or image is painted. It's the earliest signal that the page is loading.

<table>
<thead>
  <tr>
    <th>
      FCP Time
    </th>
    
    <th>
      Rating
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ≤1.8s
    </td>
    
    <td>
      Good
    </td>
  </tr>
  
  <tr>
    <td>
      1.8-3.0s
    </td>
    
    <td>
      Needs Improvement
    </td>
  </tr>
  
  <tr>
    <td>
      >3.0s
    </td>
    
    <td>
      Poor
    </td>
  </tr>
</tbody>
</table>

**Weight in Lighthouse:** 10% of Performance score

FCP issues share root causes with LCP - fix render-blocking resources and server response time to improve both.

### Speed index (SI)

Speed Index measures how quickly content is visually populated during page load. It captures the perceived loading experience.

<table>
<thead>
  <tr>
    <th>
      Speed Index
    </th>
    
    <th>
      Rating
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ≤3.4s
    </td>
    
    <td>
      Good
    </td>
  </tr>
  
  <tr>
    <td>
      3.4-5.8s
    </td>
    
    <td>
      Needs Improvement
    </td>
  </tr>
  
  <tr>
    <td>
      >5.8s
    </td>
    
    <td>
      Poor
    </td>
  </tr>
</tbody>
</table>

**Weight in Lighthouse:** 10% of Performance score

Speed Index improves when above-the-fold content loads progressively rather than all at once.

### Time to first byte (TTFB)

TTFB measures server responsiveness - the time from request to first byte of response. While not a Core Web Vital itself, it is the primary driver of LCP.

<table>
<thead>
  <tr>
    <th>
      Metric
    </th>
    
    <th>
      Good
    </th>
    
    <th>
      Needs Improvement
    </th>
    
    <th>
      Poor
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Core Web Vitals
      </strong>
    </td>
    
    <td>
      ≤800ms
    </td>
    
    <td>
      800ms-1800ms
    </td>
    
    <td>
      >1800ms
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Lighthouse Audit
      </strong>
    </td>
    
    <td>
      <600ms
    </td>
    
    <td>
      600ms-1200ms
    </td>
    
    <td>
      >1200ms
    </td>
  </tr>
</tbody>
</table>

Sites with poor LCP have an [average TTFB of 2,270ms](https://almanac.httparchive.org/en/2024/performance). Fix TTFB first if your server response exceeds **600ms** to pass the Lighthouse audit.

→ [Fix slow server response](/learn-lighthouse/lcp/slow-server-response)

### Total blocking time (TBT)

TBT measures the total time the main thread was blocked by long tasks (>50ms) between FCP and Time to Interactive. It's a lab proxy for INP.

<table>
<thead>
  <tr>
    <th>
      TBT
    </th>
    
    <th>
      Rating
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ≤200ms
    </td>
    
    <td>
      Good
    </td>
  </tr>
  
  <tr>
    <td>
      200-600ms
    </td>
    
    <td>
      Needs Improvement
    </td>
  </tr>
  
  <tr>
    <td>
      >600ms
    </td>
    
    <td>
      Poor
    </td>
  </tr>
</tbody>
</table>

**Weight in Lighthouse:** 30% of Performance score - the highest-weighted metric

TBT [correlates well with INP](https://web.dev/articles/tbt), making it the best lab metric for predicting real-world interactivity.

→ [Fix total blocking time](/learn-lighthouse/inp/total-blocking-time)

### Lighthouse performance score weights

The overall Lighthouse Performance score is a [weighted average](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) of five metrics:

<table>
<thead>
  <tr>
    <th>
      Metric
    </th>
    
    <th>
      Weight
    </th>
    
    <th>
      Primary Improvement
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        TBT
      </strong>
    </td>
    
    <td>
      30%
    </td>
    
    <td>
      Reduce JavaScript, break up long tasks
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        LCP
      </strong>
    </td>
    
    <td>
      25%
    </td>
    
    <td>
      Optimize images, improve TTFB
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        CLS
      </strong>
    </td>
    
    <td>
      25%
    </td>
    
    <td>
      Set dimensions, reserve space
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        FCP
      </strong>
    </td>
    
    <td>
      10%
    </td>
    
    <td>
      Remove render-blocking resources
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        SI
      </strong>
    </td>
    
    <td>
      10%
    </td>
    
    <td>
      Progressive loading, critical CSS
    </td>
  </tr>
</tbody>
</table>

LCP, CLS, and TBT account for **80%** of your score. Focus there first.

→ [Try the score calculator](/tools/lighthouse-score-calculator)

---

## How to measure core web vitals

### Lab data (synthetic testing)

Lab tools test in controlled environments - useful for debugging but [not used by Google for ranking](https://developers.google.com/search/docs/appearance/core-web-vitals#ranking).

**Tools:**

- [**Core Web Vitals Checker**](/tools/cwv-checker) - Test any page with lab and field data
- [**LCP Finder**](/tools/lcp-finder) - Identify your LCP element and optimization opportunities
- [**CLS Debugger**](/tools/cls-debugger) - Find and fix layout shift sources
- [**INP Analyzer**](/tools/inp-analyzer) - Diagnose interaction responsiveness issues
- **Chrome DevTools**: Performance panel shows LCP, CLS, and long tasks
- **Lighthouse**: Full performance audit with actionable recommendations
- **WebPageTest**: Filmstrip view and waterfall analysis

For CI/CD integration, [Lighthouse CI](/learn-lighthouse/lighthouse-ci) runs audits on every commit and fails builds when metrics regress.

```bash
npx unlighthouse --site https://your-site.com
```

### Field data (real user monitoring)

Field data from actual visitors is what Google uses for ranking:

- [PageSpeed Insights](https://pagespeed.web.dev) - Shows CrUX data for your URL and origin ([how it differs from Lighthouse](/learn-lighthouse/pagespeed-insights-vs-lighthouse))
- [Search Console](https://search.google.com/search-console/about) - Core Web Vitals report with URL-level groupings
- [Chrome UX Report (CrUX)](https://developer.chrome.com/docs/crux) - 28-day rolling average of real user data

Expect a [28-day delay](https://developer.chrome.com/docs/crux/methodology) between fixes and improved CrUX data.

### Lab vs field differences

<table>
<thead>
  <tr>
    <th>
      Aspect
    </th>
    
    <th>
      Lab Data
    </th>
    
    <th>
      Field Data
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Device
      </strong>
    </td>
    
    <td>
      Simulated throttling
    </td>
    
    <td>
      Real user devices
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Network
      </strong>
    </td>
    
    <td>
      Fixed conditions
    </td>
    
    <td>
      Variable connections
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Interactions
      </strong>
    </td>
    
    <td>
      Scripted or none
    </td>
    
    <td>
      Real user behavior
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Use for
      </strong>
    </td>
    
    <td>
      Debugging, CI/CD
    </td>
    
    <td>
      SEO ranking, real UX
    </td>
  </tr>
</tbody>
</table>

Your lab scores often differ significantly from field data. A page can score 95 in Lighthouse but fail Core Web Vitals in the field if real users have slower devices or networks.

---

## Why core web vitals matter for SEO

Core Web Vitals are a confirmed [Google ranking factor](https://developers.google.com/search/docs/appearance/page-experience).

### Ranking studies

- [Pages at position 1 are more likely to pass CWV than lower-ranking pages](https://developers.google.com/search/docs/appearance/page-experience)
- Sites failing Core Web Vitals see a measurable drop in search visibility compared to competitors who pass.
- CWV act as a [tie-breaker when content quality is similar](https://developers.google.com/search/docs/appearance/page-experience)

**Pass all three metrics** to gain ranking advantage - there's no partial credit.

### User experience & conversions

The [Google research on the business impact of Core Web Vitals](https://web.dev/case-studies/vitals-business-impact) found a **0.1 second improvement** in site speed can:

- Increase retail conversions by **8.4%**
- Boost average order value by **9.2%**
- Increase travel conversions by **10.1%**

Google research shows bounce rate increases [32% when load time goes from 1 to 3 seconds](https://web.dev/learn/performance/why-speed-matters), and [90% at 5 seconds](https://web.dev/learn/performance/why-speed-matters).

---

## Current state of the web (2024)

According to [HTTP Archive 2024 data](https://almanac.httparchive.org/en/2024/performance):

<table>
<thead>
  <tr>
    <th>
      Metric
    </th>
    
    <th>
      Mobile Pass Rate
    </th>
    
    <th>
      Desktop Pass Rate
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      LCP
    </td>
    
    <td>
      59%
    </td>
    
    <td>
      72%
    </td>
  </tr>
  
  <tr>
    <td>
      CLS
    </td>
    
    <td>
      79%
    </td>
    
    <td>
      72%
    </td>
  </tr>
  
  <tr>
    <td>
      INP
    </td>
    
    <td>
      74%
    </td>
    
    <td>
      97%
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        All Three
      </strong>
    </td>
    
    <td>
      <strong>
        48%
      </strong>
    </td>
    
    <td>
      <strong>
        54%
      </strong>
    </td>
  </tr>
</tbody>
</table>

The trend is improving: mobile CWV pass rates grew from 31% (2022) to 48% (2024). But over half the web still fails.

---

## Test your entire site

Most tools only test one page. Your homepage might score 100, but what about:

- Product pages with heavy images?
- Blog posts with embedded videos?
- Dynamic pages with JavaScript widgets?

The [2024 Web Almanac](https://almanac.httparchive.org/en/2024/performance) notes that homepage performance is often not representative of an entire site.

```bash
npx unlighthouse --site https://your-site.com
```

---

## Next steps

1. **Audit**: [Run Unlighthouse](/guide/getting-started/installation) to find issues across all pages
2. **Prioritize**: Fix the highest-impact issues first (TBT, LCP, CLS account for 80% of score)
3. **Automate**: Set up [Lighthouse CI](/learn-lighthouse/lighthouse-ci) to catch regressions before they reach production
4. **Monitor**: Set up continuous monitoring to track real user metrics
*Monitor**: Set up continuous monitoring to track real user metrics
l user metrics