---
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: "2026-08-09"
---

Core Web Vitals are Google's metrics for loading performance, visual stability, and interaction responsiveness. Google uses them within its broader [page experience systems](https://developers.google.com/search/docs/appearance/page-experience), while relevance and content quality remain the stronger search signals.

In the [2025 Web Almanac](https://almanac.httparchive.org/en/2025/performance), 48% of mobile sites and 56% of desktop sites passed all three metrics.

## 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 remains the hardest Core Web Vital to pass: [62% of mobile pages achieved good LCP in 2025](https://almanac.httparchive.org/en/2025/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): [76% of mobile pages use an image as their LCP element](https://almanac.httparchive.org/en/2025/performance)
- **Video poster images** (the thumbnail before playback)
- **Block-level text elements** (headings, paragraphs)

### 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>
      Delays every resource discovered from the HTML
    </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 is the most widely passed Core Web Vital: [81% of mobile pages achieved good CLS in 2025](https://almanac.httparchive.org/en/2025/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/2025/performance" rel="nofollow">
        62% of mobile pages
      </a>
      
       have at least one unsized image
    </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 browsers calculate 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 usually the longest interaction. For pages with many interactions, the algorithm ignores one worst interaction per 50 interactions to reduce the effect of rare outliers. Lighthouse cannot measure INP from a normal synthetic page load; use CrUX or real-user monitoring.

### 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

The [2025 Web Almanac](https://almanac.httparchive.org/en/2025/performance) found good INP on 97% of desktop pages and 77% of mobile pages. Mobile devices still face much more main-thread pressure.

### 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 the time from the navigation request until the first response byte arrives. It is not a Core Web Vital, but it precedes every other loading milestone and forms the first sub-part of LCP.

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

<tbody>
  <tr>
    <td>
      <strong>
        TTFB
      </strong>
    </td>
    
    <td>
      ≤800ms
    </td>
    
    <td>
      800ms-1800ms
    </td>
    
    <td>
      >1800ms
    </td>
  </tr>
</tbody>
</table>

The [2025 Web Almanac](https://almanac.httparchive.org/en/2025/performance) found good TTFB on 44% of mobile pages. If TTFB consumes much of the 2.5-second LCP budget, fix caching, redirects, server work, or network distance before tuning the LCP image.

→ [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 the source Google uses to assess Core Web Vitals:

- [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 window of real user data

CrUX uses a rolling 28-day window, so a deployed fix appears gradually as older visits leave the window.

### 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

Google says good Core Web Vitals contribute to [page experience](https://developers.google.com/search/docs/appearance/page-experience), but a perfect report does not guarantee top rankings. Improve failing metrics for users first. Do not remove useful content or functionality merely to chase a score.

### 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 (2025)

According to the [2025 HTTP Archive Web Almanac](https://almanac.httparchive.org/en/2025/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>
      62%
    </td>
    
    <td>
      74%
    </td>
  </tr>
  
  <tr>
    <td>
      CLS
    </td>
    
    <td>
      81%
    </td>
    
    <td>
      72%
    </td>
  </tr>
  
  <tr>
    <td>
      INP
    </td>
    
    <td>
      77%
    </td>
    
    <td>
      97%
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        All Three
      </strong>
    </td>
    
    <td>
      <strong>
        48%
      </strong>
    </td>
    
    <td>
      <strong>
        56%
      </strong>
    </td>
  </tr>
</tbody>
</table>

Mobile pass rates rose from 36% in 2023 to 48% in 2025. More than half of mobile sites still miss at least one Core Web Vital.

---

## 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 [2025 Web Almanac](https://almanac.httparchive.org/en/2025/performance) found different results for home pages and secondary pages. Test every important template, not only the home page.

```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