Lighthouse vs CrUX: Why the Numbers Don’t Always Match
Lighthouse vs CrUX is an important comparison when measuring website performance because the tools provide different types of evidence. Lighthouse runs controlled lab tests that help developers reproduce issues and investigate possible fixes, while the Chrome User Experience Report (CrUX) provides aggregated real-user experience data from eligible Chrome users. Their results can differ because of device capabilities, network conditions, page interactions, testing environments, and data availability. This guide explains how lab and field data work, why performance scores disagree, and when to use each measurement method.
You run a Lighthouse test and get an excellent performance result.
Then you check your site’s Core Web Vitals in PageSpeed Insights or Search Console and discover that real users are having a much worse experience.
Or the opposite happens: your Lighthouse results look disappointing, while your real-world Core Web Vitals are comfortably in the green.
Which number should you believe?
The answer is not that one tool is wrong.
Lighthouse and CrUX are measuring performance in fundamentally different ways.
Lighthouse performs a controlled test of a page. CrUX, the Chrome User Experience Report, represents experiences collected from eligible real Chrome users.
One is useful for controlled diagnosis.
The other tells you what is happening in the real world.
Understanding that distinction is essential if you are trying to improve Core Web Vitals rather than simply chase a better-looking performance score.
Quick Answer
Lighthouse provides lab data. CrUX provides field data from real users.
Lighthouse loads a page under a controlled configuration and generates performance diagnostics that can help developers identify potential problems.
CrUX aggregates performance measurements from eligible Chrome users and shows how a page or origin performs across real devices, networks, locations, and browsing conditions.
A simple way to think about them is:
| Lighthouse | CrUX |
| Lab data | Field data |
| Controlled test | Real-user experiences |
| Useful for diagnosis | Useful for measuring real-world experience |
| Can be run on demand | Based on collected user data |
| Results can vary between runs | Represents an aggregation over a collection period |
| Provides detailed audits | Provides real-world metric distributions |
| Does not require existing traffic | Requires sufficient eligible real-user data |
Neither should replace the other.
For serious performance work, Lighthouse helps explain the problem while CrUX helps confirm whether users are actually experiencing it.
What Is Lighthouse?
Lighthouse is an open-source automated tool for auditing web pages.
It can analyze a page for several areas, including:
- Performance
- Accessibility
- Best practices
- SEO
For performance work, Lighthouse measures and analyzes a page during a controlled audit.
You can run Lighthouse through Chrome DevTools, PageSpeed Insights, the command line, or automated workflows such as Lighthouse CI.
This makes Lighthouse particularly useful during development.
A developer can change something, run the audit, inspect the results, make another change, and test again.
That feedback loop is one of Lighthouse’s biggest strengths.
What Is CrUX?
CrUX stands for Chrome User Experience Report.
Instead of creating a synthetic test, CrUX aggregates measurements from eligible real Chrome users who visit websites.
The data can represent differences in:
- Devices
- Network conditions
- Geographic locations
- Hardware capabilities
- Browsing environments
- User behavior
CrUX contains user-centric performance metrics including the Core Web Vitals:
- Largest Contentful Paint (LCP)
- Interaction to Next Paint (INP)
- Cumulative Layout Shift (CLS)
It also includes other performance-related metrics.
Because the measurements come from real browsing experiences, CrUX can reveal problems that a controlled test may never reproduce.
That is its biggest advantage.
Lab Data vs Field Data
The terms lab data and field data describe two different approaches to measuring web performance.
Lab Data
Lab data is collected under controlled or simulated conditions.
The environment is configured so the test can be repeated and compared.
This makes lab testing excellent for debugging.
For example, if you remove a large JavaScript bundle and your Lighthouse LCP improves, you have a useful signal that the change helped under the tested conditions.
Field Data
Field data comes from real user experiences.
Instead of asking:
“How does this page perform under this test configuration?”
field data asks:
“How has this page actually performed for real users?”
That distinction is enormous.
Real visitors don’t all have the same:
- CPU
- Memory
- Network
- Screen size
- Location
- Browser state
- Cache state
A field dataset captures some of that diversity.
The Core Difference Between Lighthouse and CrUX
The easiest way to understand the difference is to imagine a restaurant.
Lighthouse is like a food inspector visiting the kitchen under a controlled inspection.
The inspector can examine the kitchen carefully, repeat checks, and identify specific problems.
CrUX is more like collecting feedback from thousands of actual customers.
Customers experience different waiting times, different staff interactions, different tables, and different conditions throughout the day.
Both perspectives are useful.
One helps you investigate the system.
The other tells you what customers actually experienced.
Website performance works in much the same way.
Why Lighthouse and CrUX Can Show Different Results
It is completely normal for Lighthouse and CrUX to disagree.
There are several reasons.
Different Devices
A Lighthouse test uses a specific test configuration.
Real users may be visiting from high-end desktops, inexpensive smartphones, laptops, tablets, and other supported environments.
A page that feels extremely fast on a modern desktop can behave very differently on a lower-powered mobile device.
Different Network Conditions
Your Lighthouse test may simulate a particular network environment.
Real visitors can be using:
- Fast broadband
- Mobile networks
- Congested connections
- High-latency connections
- Different network providers
Network conditions can have a major effect on loading performance.
Different Geographic Locations
A server may respond quickly to a test running relatively close to the infrastructure but more slowly for users farther away.
CDNs can reduce this problem, but geography still matters.
A real-world dataset can therefore reveal patterns that a single test location cannot.
Different Page States
A laboratory test usually starts from a particular page state.
Real users may arrive with:
- Cached resources
- Existing connections
- Stored preferences
- Different cookies
- Personalized content
- Different browser state
These differences can influence performance.
Different User Behavior
Some metrics depend on what users actually do.
INP is the clearest example.
A synthetic test cannot reproduce every interaction performed by every visitor.
A real-user dataset can capture interaction behavior across actual sessions.
Why a Lighthouse Score Is Not a Real-User Score
This is one of the most important points to understand.
A Lighthouse Performance score is an assessment generated from a laboratory test.
It is not a percentage of your users who experienced a fast page.
A score of 95 does not mean:
“95% of visitors had a good experience.”
Likewise, a score of 55 does not mean:
“55% of visitors had a bad experience.”
The Lighthouse score is based on the metrics and weighting used by the Lighthouse version running the test.
It is useful as a lab indicator.
It should not be interpreted as a population statistic.
What CrUX Actually Tells You
CrUX is much closer to a measurement of actual user experience.
Its data represents aggregated experiences from eligible Chrome users.
For Core Web Vitals, the data can be examined at page or origin level when sufficient data is available.
The measurements are aggregated rather than showing you an individual person’s browsing session.
That distinction protects users while still giving site owners meaningful performance information.
CrUX therefore answers questions such as:
- Are real users experiencing poor LCP?
- Is CLS a problem across the site’s traffic?
- Is INP worse on mobile than desktop?
- Is performance improving over time?
- Is a particular page performing differently from the origin overall?
These are questions Lighthouse alone cannot answer.
Why CrUX Data May Not Exist for Your Page
One of the first surprises for website owners is opening PageSpeed Insights and finding no real-user data.
That does not necessarily mean the page has poor performance.
CrUX has eligibility requirements.
The page or origin needs to be publicly discoverable and have sufficient real-user data to create a useful aggregated dataset.
A new page may therefore have excellent performance but no page-level CrUX data.
A low-traffic website can encounter the same situation.
When page-level data is unavailable in PageSpeed Insights, the tool may show origin-level data when enough origin-level data exists.
If there is insufficient data at both levels, field data may not be available.
This is particularly important for small websites.
No CrUX data does not mean bad Core Web Vitals.
It can simply mean there is not enough eligible data.
How PageSpeed Insights Combines the Two
PageSpeed Insights is where the distinction between Lighthouse and CrUX becomes especially useful.
When you enter a URL into PageSpeed Insights, you can see both types of information.
The lab section is powered by Lighthouse.
The real-user section is powered by CrUX.
So PageSpeed Insights is not itself a third kind of performance measurement.
It is a convenient interface that brings these sources together.
You can think of it like this:
PageSpeed Insights = Lighthouse lab analysis + CrUX field data
That makes PSI particularly useful for diagnosing a page while also checking whether real users are experiencing similar problems.
A Simple Example
Imagine a website produces these results:
Lighthouse:
- LCP: 1.8 seconds
- CLS: 0.03
- INP: not meaningfully represented by the same kind of controlled interaction coverage
- Performance score: 94
The owner assumes the page is excellent.
But CrUX shows:
- LCP: 3.1 seconds at the 75th percentile
- CLS: 0.18 at the 75th percentile
- INP: 260ms at the 75th percentile
Now the picture is different.
The laboratory environment looks good.
Real users are having a considerably less consistent experience.
The correct conclusion is not:
“Lighthouse is wrong.”
The correct conclusion is:
The controlled test does not represent all of the conditions experienced by the site’s users.
That is exactly why field data exists.
The Reverse Situation Can Happen Too
Suppose your Lighthouse test produces a poor LCP because the test environment is particularly demanding.
But CrUX shows that real users have a good LCP at the 75th percentile.
That does not mean the Lighthouse test should be ignored.
It may have uncovered a weakness that does not currently affect enough real users to push the field data into a poor range.
That weakness could become important later.
For example, your audience might change.
Your traffic could shift toward slower devices.
A new JavaScript library could increase page weight.
An advertising provider could introduce heavier resources.
A server configuration could change.
Lab testing gives you a way to detect potential problems before they become widespread field problems.
Which One Should You Trust?
This question is slightly misleading.
You should trust each source for the question it is designed to answer.
If you want to know:
“What are my real users experiencing?”
CrUX is the more relevant source.
If you want to know:
“What might be causing this performance problem, and can I reproduce it?”
Lighthouse is extremely useful.
For Core Web Vitals, field data deserves particular attention because Core Web Vitals are intended to represent real user experience.
But that does not make lab testing optional.
A field metric can tell you that something is wrong without immediately telling you what to fix.
Lighthouse can help narrow that investigation.
When Should You Use Lighthouse?
Lighthouse is especially useful when:
You Are Developing a New Page
You don’t need to wait for real-user data.
You can audit the page immediately.
You Just Changed the Site
After changing JavaScript, CSS, images, fonts, hosting, caching, or a theme, you can run a new audit and compare the results.
You Need Diagnostic Information
Lighthouse provides audits and opportunities that help identify potential performance improvements.
You Need Repeatable Testing
A controlled test is useful when comparing versions of a page.
You Are Investigating a Page With Little Traffic
A page without sufficient CrUX data can still be tested with Lighthouse.
When Should You Use CrUX?
CrUX becomes particularly valuable when:
You Want to Know What Real Visitors Experience
This is the obvious use case.
Your Traffic Is Diverse
A broad real-world dataset can expose differences that a single lab configuration cannot.
You Want to Monitor Core Web Vitals
CrUX provides field measurements for Core Web Vitals when sufficient data exists.
Your Lighthouse Result Looks Suspiciously Good
If a perfect-looking lab test conflicts with real-user data, field data deserves investigation.
You Are Evaluating the Impact of a Change
Field data can help determine whether a performance change improved the actual experience at scale.
CrUX Uses a Rolling Data Window
CrUX data should not be interpreted like a live speedometer.
The data represents a collection period rather than the result of one visitor’s visit.
PageSpeed Insights reports real-user metrics from the previous 28-day collection period.
This means a change you made yesterday may not immediately transform your field data.
The old experiences are still part of the aggregation.
That creates an important difference in how you interpret the two systems.
Lighthouse can react immediately to a change.
CrUX reflects accumulated real-world experience over its reporting window.
This is why field-data improvements often take time to become visible.
Why Field Data Is Often More Important for Core Web Vitals
Core Web Vitals are designed around user experience.
LCP represents loading performance.
INP represents responsiveness.
CLS represents visual stability.
All three can be affected by real-world conditions.
A developer’s laptop may have a fast processor.
A visitor’s phone may not.
A developer’s broadband connection may be excellent.
A visitor may be on a slower mobile network.
A developer may never trigger a particular interaction.
A real visitor may interact with the page dozens of times.
Field data captures a much broader range of these experiences.
That makes it particularly valuable when deciding whether a problem is actually affecting users.
Why Field Data Is Not Enough
There is a temptation to look at CrUX and stop there.
That is also a mistake.
Suppose CrUX reports poor LCP.
You know there is a problem.
But what caused it?
Possible causes include:
- Slow server response
- Late resource discovery
- Large images
- Render-blocking resources
- Slow font loading
- Client-side rendering
- Network conditions
- Third-party resources
CrUX does not replace technical debugging.
You still need tools such as Lighthouse, Chrome DevTools, browser performance traces, server logs, and real-user monitoring where appropriate.
Field data tells you what users experienced.
Diagnostic tools help determine why.
Lighthouse and CrUX Are Complementary
The most useful way to think about these tools is not as competitors.
They form a feedback loop.
A practical workflow looks like this:
1. Check CrUX
Find out whether real users have a Core Web Vitals problem.
2. Check the affected metric
Determine whether LCP, INP, or CLS is responsible.
3. Run Lighthouse
Look for reproducible issues and diagnostic clues.
4. Inspect the page
Use DevTools and performance traces when necessary.
5. Make a targeted change
Fix the likely cause rather than applying unrelated optimizations.
6. Run Lighthouse again
Confirm that the change behaves as expected in the lab.
7. Monitor field data
Wait for enough real-user data to determine whether the improvement appears in actual experiences.
This is much more reliable than repeatedly running Lighthouse until the number looks good.
Why Running Lighthouse Ten Times Can Produce Different Results
If you run Lighthouse repeatedly without changing the page, the results may still move around.
That does not automatically indicate a broken tool.
Performance measurements can vary because of:
- CPU contention
- Network variability
- Background processes
- Resource timing
- Server response differences
- Cache state
- Third-party resources
A single Lighthouse result is therefore not a permanent property of a webpage.
It is a measurement under particular conditions.
For comparisons, use a consistent testing setup and look for meaningful patterns rather than reacting to every small numerical change.
Lab Data Is Not a Ranking Score
Another common mistake is treating the Lighthouse Performance score as a direct SEO score.
It isn’t.
Lighthouse includes an SEO category, but the Performance score is a separate measurement based on lab performance metrics.
A website does not become “95% optimized for Google” because Lighthouse reports 95.
Likewise, dropping from 95 to 88 does not automatically mean your search rankings will drop.
Performance matters, and Core Web Vitals are part of Google’s page experience signals, but search visibility is influenced by many other factors.
The Lighthouse score should therefore be treated as a diagnostic indicator rather than a ranking prediction.
Why the 75th Percentile Matters
Core Web Vitals field data is generally evaluated at the 75th percentile.
This is important because averages can hide poor experiences.
Imagine these LCP values:
- 1.2 seconds
- 1.4 seconds
- 1.6 seconds
- 1.8 seconds
- 5.5 seconds
The average is pulled upward by the slow visit, but it does not tell you exactly how the distribution behaves.
A percentile provides a different way of understanding the experience distribution.
For Core Web Vitals, the 75th percentile is used to judge whether the majority of experiences are meeting the relevant threshold.
This is one reason a site’s field data should be viewed as a distribution rather than just one number.
Page-Level Data vs Origin-Level Data
CrUX can provide information at different levels.
Page-Level Data
This describes experiences associated with a particular page when sufficient data is available.
This is useful when one template or URL behaves differently from the rest of the site.
Origin-Level Data
Origin-level data aggregates experiences across the website’s origin.
For example:
The origin-level view can include experiences from multiple pages on that website.
This can be useful when individual pages do not have enough traffic to produce page-level data.
But be careful when interpreting it.
A fast homepage and a slow article template can be averaged together at origin level.
Origin-level performance does not necessarily tell you how one specific page behaves.
Why Your Page Can Be Slow Even If the Origin Looks Good
Imagine a site with 500 pages.
Most pages are simple articles.
One page contains:
- A large interactive gallery
- Multiple third-party embeds
- Heavy JavaScript
- Several advertising placements
The origin-level data may still look healthy because the problematic page represents only a small part of the overall traffic.
That page can nevertheless have poor user experience.
This is why page-level data is preferable when available for diagnosing a specific URL.
Lighthouse vs CrUX: A Practical Comparison
| Question | Lighthouse | CrUX |
| Is it lab or field data? | Lab | Field |
| Uses real visitors? | No | Yes, eligible Chrome users |
| Can run immediately? | Yes | Only when sufficient data exists |
| Useful for debugging? | Excellent | Limited by aggregation |
| Represents real-world diversity? | Limited | Much broader |
| Shows Core Web Vitals? | Yes, in applicable lab contexts | Yes |
| Shows real-user Core Web Vitals? | No | Yes |
| Provides detailed audits? | Yes | No |
| Useful for development? | Excellent | Monitoring/validation |
| Results change immediately after a code change? | Potentially | Not immediately |
The important word in this table is purpose.
Lighthouse and CrUX were not designed to answer exactly the same question.
What About PageSpeed Insights?
PageSpeed Insights is often confused with Lighthouse.
They are related, but they are not identical.
PageSpeed Insights uses Lighthouse for its laboratory analysis.
It also incorporates CrUX data for real-user performance information.
So when someone says:
“My PageSpeed score is 92 but my Core Web Vitals are poor,”
there may be no contradiction.
They may simply be comparing:
- A Lighthouse lab result
- A CrUX field result
Those measurements are describing different populations and conditions.
A Better Way to Read PageSpeed Insights
Instead of opening PageSpeed Insights and focusing immediately on the large performance score, look at the report in this order:
First: Check Field Data
If CrUX data is available, look at the actual Core Web Vitals experienced by users.
Second: Identify the Failing Metric
Determine whether the problem is LCP, INP, or CLS.
Third: Look at the Lab Results
Use Lighthouse to investigate potential causes.
Fourth: Examine Diagnostics
Look for specific resources, scripts, images, or rendering problems associated with the metric.
Fifth: Make a Targeted Fix
Avoid changing unrelated parts of the site simply to increase the score.
Sixth: Monitor Again
After the change has had enough time to affect the field dataset, check whether real-world performance improved.
This approach keeps the numbers in context.
Common Mistakes When Comparing Lighthouse and CrUX
Mistake 1: Treating Them as Competing Scores
They are not two judges giving different grades to the same test.
They are two different measurement systems.
Mistake 2: Assuming Lighthouse Represents Every User
It doesn’t.
A lab test represents the conditions under which that audit was run.
Mistake 3: Assuming CrUX Explains the Cause
CrUX is excellent for measuring aggregated real-user experience, but it is not a full debugging trace.
Mistake 4: Chasing a 100 Lighthouse Score
A perfect lab score is not the objective.
A page that provides a consistently good real-world experience is more important.
Mistake 5: Expecting CrUX to Update Immediately
Field data represents a rolling collection period.
A change made today will not instantly rewrite historical user experiences.
Mistake 6: Comparing Unrelated Configurations
If you compare a desktop Lighthouse test with mobile CrUX data, the difference may be expected.
Always check the device category and test conditions before drawing conclusions.
Mistake 7: Ignoring Pages Without CrUX Data
A page without field data has not necessarily failed.
It may simply lack enough eligible traffic.
What Should You Do If Lighthouse Is Good but CrUX Is Poor?
Start with the assumption that your laboratory environment does not represent the conditions affecting your users.
Then investigate:
- Mobile performance
- Device capability
- Network conditions
- Geographic distribution
- Third-party resources
- Advertising
- Server response
- Cache behavior
- Interaction patterns
- Page templates
Look for differences between the lab setup and the audience actually visiting the site.
If the site’s traffic is primarily mobile, a desktop-focused test is unlikely to tell the whole story.
If users are geographically distributed, server and CDN behavior may also matter.
The goal is to discover which real-world condition the lab test is failing to represent.
What Should You Do If Lighthouse Is Poor but CrUX Is Good?
Don’t automatically dismiss the Lighthouse result.
Ask what the lab test is exposing.
Perhaps the page has a weakness under slower simulated conditions that most current visitors are not experiencing strongly enough to affect the field data.
That can still be worth fixing.
Think of Lighthouse as an early warning system.
A lab weakness may not be a current field problem, but it can become one as traffic, content, devices, or third-party dependencies change.
The Right Performance Strategy
There is no useful goal called:
“Make Lighthouse green and forget everything else.”
A stronger goal is:
Build a page that performs well under controlled testing and continues to perform well when real people use it.
That requires both perspectives.
Use Lighthouse when you need to experiment.
Use CrUX when you need to understand real-world experience.
Use PageSpeed Insights when you want a convenient place to see both.
And when the numbers disagree, don’t panic.
Ask what each measurement is actually telling you.
Final Verdict
Lighthouse and CrUX answer two different questions.
Lighthouse asks what happens when the page is tested under controlled conditions.
CrUX asks what happened to real users under real-world conditions.
That difference is not a weakness.
It is the reason both tools are valuable.
Lighthouse gives developers something they can work with immediately. You can reproduce a page load, inspect diagnostics, change the implementation, and test again.
CrUX provides the reality check. It shows whether actual users are experiencing good or poor Core Web Vitals across the conditions represented in the dataset.
When the two disagree, the answer is rarely to pick a winner.
Instead, investigate the gap.
A strong performance workflow uses Lighthouse for diagnosis, CrUX for validation, and PageSpeed Insights as a convenient bridge between the two.
The objective isn’t a perfect Lighthouse number.
It is a website that remains fast, responsive, and visually stable when real people use it.
Related Article:
Use these as contextual links within the Friday Core Web Vitals cluster:
- What Is LCP? Largest Contentful Paint Explained
- What Is INP? Interaction to Next Paint Explained
- What Is CLS? Cumulative Layout Shift Explained
- What Is TTFB? Time to First Byte Explained
- How to Fix Core Web Vitals Issues
Recommended Resources:
Use these resources to understand lab testing, real-user performance data, and Core Web Vitals:
- Lighthouse documentation explains how Lighthouse audits pages and identifies potential improvements.
- Chrome UX Report describes CrUX and its real-user experience data.
- Google PageSpeed Insights presents lab diagnostics and field data when available.
- Web Vitals explains the key metrics used to evaluate loading, responsiveness, and visual stability.
- Chrome UX Report API explains how to retrieve CrUX data programmatically.