Understand Lighthouse and Core Web Vitals

Updated
Requirements

Learn how lab and field data differ and which scores count as good for LCP, INP, and CLS.

Lighthouse and Core Web Vitals both measure site performance, but they answer different questions. One shows how your page performs in a controlled test. The other shows how real visitors experience it. Using both gives you a complete picture and helps you decide what to fix first.

How they differ

Lighthouse Core Web Vitals
Type of data Lab data Field data
How it's collected Loads your page in a simulated, controlled environment Collected from real visits by real visitors on real devices and networks
Best for Finding problems and testing fixes while you build Confirming how your actual audience experiences your site
Where to find it Chrome DevTools and the top section of PageSpeed Insights The bottom section of PageSpeed Insights, the Core Web Vitals report in Google Search Console, and the Chrome UX Report

Understand Lighthouse (lab data)

Lighthouse loads your page in a simulated environment — by default, a mid-tier phone on a throttled network — so every run tests the same conditions. That makes it ideal for iterating. Make a change, run Lighthouse again, and see whether the numbers moved.

Lighthouse also reports on accessibility, best practices, and search engine optimization (SEO). Those are separate categories from performance. This category focuses on the Performance score and the Core Web Vitals metrics.

Understand Core Web Vitals (field data)

Core Web Vitals are three metrics collected from real visits. Each one maps to something visitors feel:

  • Largest Contentful Paint (LCP) — loading. LCP measures when the biggest visible element on the screen finishes rendering. That's usually your hero image or main headline.
  • Interaction to Next Paint (INP) — responsiveness. INP measures how long the page takes to respond to clicks, taps, and key presses across the whole visit.
  • Cumulative Layout Shift (CLS) — visual stability. CLS measures how much visible content moves around while the page loads.

Good to know

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. If you see older guides that mention FID, INP is the current metric.

What counts as good

Google rates each metric as good, needs improvement, or poor:

Metric Good Needs improvement Poor
LCP 2.5 seconds or less 2.5 to 4 seconds More than 4 seconds
INP 200 milliseconds or less 200 to 500 milliseconds More than 500 milliseconds
CLS 0.1 or less 0.1 to 0.25 More than 0.25

How pass or fail works

Google judges each metric at the 75th percentile (p75) of real visits, on mobile and desktop separately. A page passes when at least 75% of visits meet the "good" threshold for all three metrics. Google uses p75 so a few unusually fast or slow visits don't skew the result.

Where to find your field data

Field data only appears when a page gets enough real visits. New or low-traffic pages might show no field data yet. In that case, use Lighthouse to test your changes.

Why your results can disagree

Lighthouse simulates a mid-tier phone on a slow connection, so it often looks worse than what your laptop feels like. Your field data reflects your actual audience, which might use faster devices and networks, or slower ones. Neither report is wrong. They describe different visitors.

Here's a simple way to use both:

  • Trust field data to tell you whether your pages pass
  • Use lab data to find what to fix and to test your changes

Note

Lighthouse measures a lab metric called Total Blocking Time (TBT) in place of INP, because INP needs real interactions. For a deeper look, read Chrome's guide to lab data vs. field data.

Put your scores to work