Lighthouse and Core Web Vitals measure related aspects of web performance, but they do not describe the same thing. Lighthouse runs a controlled laboratory test under simulated conditions. Core Web Vitals field data summarizes how real visitors experience a page across many devices, networks, and sessions.
A Lighthouse score can help identify performance bottlenecks. It should not be treated as a final judgment on a page, a direct representation of every visitor, or a target that must reach 100.
The practical standard is simple: use Lighthouse for diagnosis, use field data for validation, and evaluate both in the context of the page’s actual users and purpose.
Lighthouse and Core Web Vitals answer different questions
Lighthouse asks:
How did this page perform during this particular test, under these simulated conditions?
Core Web Vitals field data asks:
How have real visitors experienced this page or origin over time?
Both questions are useful. Problems begin when a single Lighthouse run is interpreted as if it were a complete account of real-world performance.
Lighthouse provides laboratory data
Lighthouse loads a page in a controlled test environment and audits performance, accessibility, SEO, and other technical categories. Its performance audit may simulate a slower mobile device and constrained network connection so that bottlenecks become easier to observe.
Lighthouse is especially useful for:
- identifying render-blocking resources;
- finding oversized images and inefficient asset delivery;
- examining main-thread work and JavaScript execution;
- detecting layout instability during the test;
- comparing a page before and after a controlled change;
- tracing likely causes of slow rendering.
However, a Lighthouse result represents one test environment and one page load. Results can vary because of server response time, local hardware, browser extensions, network activity, third-party scripts, cache state, test location, and Lighthouse version.
Core Web Vitals provide field data
Core Web Vitals are based on real-user measurements collected through the Chrome User Experience Report, commonly called CrUX. Eligible Chrome visits are aggregated over time to describe loading performance, interaction responsiveness, and visual stability.
Field data can be reviewed through tools such as:
- Google Search Console’s Core Web Vitals report;
- PageSpeed Insights;
- the Chrome User Experience Report;
- CrUX dashboards and APIs;
- a site’s own real user monitoring system.
Search Console groups similar URLs and reports trends over a rolling period. It is useful for identifying affected page groups, but it is not a precise debugging trace. Lighthouse and browser development tools are generally better suited to finding the technical cause of a problem.
The current Core Web Vitals and their thresholds
The three Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading performance of the largest visible content element | 2.5 seconds or less | More than 2.5 and up to 4 seconds | More than 4 seconds |
| Interaction to Next Paint (INP) | Page responsiveness across user interactions | 200 milliseconds or less | More than 200 and up to 500 milliseconds | More than 500 milliseconds |
| Cumulative Layout Shift (CLS) | Unexpected visual movement during the page’s life | 0.1 or less | More than 0.1 and up to 0.25 | More than 0.25 |
For a page or origin to pass the standard Core Web Vitals assessment, all three metrics should fall within the “good” range at the 75th percentile of eligible visits. Mobile and desktop experiences may differ and should be considered separately where the reporting tool provides that distinction.
Largest Contentful Paint
Largest Contentful Paint measures when the largest visible image or text block is rendered within the viewport. It is intended to approximate when the page’s main content becomes visible.
Common LCP problems include:
- slow server response;
- large or poorly compressed hero images;
- late discovery of the primary image or font;
- render-blocking CSS or JavaScript;
- client-side rendering that delays meaningful content;
- ineffective caching or asset delivery.
Understanding the critical rendering path and the broader browser rendering pipeline can make LCP findings easier to interpret.
Interaction to Next Paint
Interaction to Next Paint measures how quickly a page provides visual feedback after user interaction. It considers interactions such as clicks, taps, and keyboard input across the life of the page.
INP replaced First Input Delay as a Core Web Vital in March 2024. Older articles and reports may still refer to FID, but INP is the current responsiveness metric.
Common INP problems include:
- long JavaScript tasks that block the main thread;
- event handlers that perform excessive work;
- large rendering updates after an interaction;
- complex page structures that are expensive to recalculate;
- third-party scripts competing for processing time.
Lighthouse does not reproduce the full range of real interactions needed to measure field INP directly. Its Total Blocking Time metric can help reveal main-thread pressure, but TBT is a laboratory diagnostic—not a substitute for INP field data.
Cumulative Layout Shift
Cumulative Layout Shift measures unexpected movement of visible page elements. A page may load quickly and still feel unreliable if text, buttons, images, or form controls move while someone is trying to use them.
Common CLS causes include:
- images or videos without reserved dimensions;
- advertising or embedded content inserted without allocated space;
- late-loading fonts that significantly change text layout;
- banners added above existing content after rendering;
- dynamic interface components that displace nearby elements.
A Lighthouse test may detect layout shifts during its loading period, but field CLS can include shifts that happen later in a visit. A page with stable laboratory results may still have a field problem caused by delayed content, interactions, consent interfaces, advertisements, or personalization.
How to interpret a Lighthouse performance score
The Lighthouse performance score is a weighted composite of several laboratory metrics. The calculation and weighting can change as Lighthouse evolves, so the score should be read alongside the underlying measurements and audit details.
A high score generally indicates that the tested page performed well under the selected conditions. It does not prove that:
- every real visitor has a fast experience;
- the page passes all Core Web Vitals assessments;
- the page is accessible or easy to use;
- performance is consistent across devices and geographic regions;
- the page will rank well in search results;
- no further investigation is needed.
Similarly, a score below 100 does not automatically indicate a meaningful problem. A page can provide a fast, stable, accessible experience while retaining small opportunities that are impractical, low-impact, or dependent on necessary third-party systems.
Why the score changes between tests
Repeated Lighthouse runs can produce different results even when the page has not changed. Variability may come from:
- server and network response differences;
- cold and warm cache states;
- CPU contention on the testing machine;
- changing third-party requests;
- advertising or analytics behavior;
- dynamic content;
- the selected device, throttling, and test mode.
For meaningful comparisons, run several tests under consistent conditions and examine the median result rather than relying on the best or worst run. Record the environment, Lighthouse version, device profile, cache state, and page version when the comparison matters.
What a score of 100 means
A Lighthouse performance score of 100 means the page met the top scoring criteria during that particular test. It is not a permanent certification and does not represent every user session.
Maintaining a perfect score can also require tradeoffs that are not justified. Removing useful functionality, weakening analytics needed for responsible operations, or introducing fragile technical workarounds may improve a laboratory score while making the website harder to maintain or less useful.
The appropriate goal is not numerical perfection. It is a page that loads promptly, responds reliably, remains visually stable, and can be maintained without unnecessary complexity.
What to do when lab and field data disagree
Lab and field results often differ because they observe different populations, time periods, and conditions. A disagreement is not necessarily an error. It is a reason to investigate the surrounding context.
Good Lighthouse result, poor field data
This pattern may indicate that the controlled test is not reproducing conditions experienced by real visitors. Possible causes include:
- slower real-world devices or networks;
- regional server latency;
- third-party scripts that do not run consistently in the test;
- layout shifts or interactions occurring after the initial load;
- authenticated, personalized, or returning-user states;
- a recent improvement that has not yet moved the rolling field dataset;
- field data being reported at the origin level rather than for the exact URL.
In this situation, do not dismiss the field result because Lighthouse looks healthy. Segment real user monitoring data where possible and test representative devices, templates, locations, and interaction paths.
Poor Lighthouse result, good field data
This may occur when the laboratory test uses more constrained conditions than most real visitors encounter. It can also happen when repeat visitors benefit from browser caching, when the test catches a temporary server delay, or when the affected metric has limited impact on the real audience.
The Lighthouse findings should still be reviewed. A good field assessment can hide a slower minority of visits, and future page changes may expose the weakness more broadly. However, remediation should remain proportional to the demonstrated user impact.
No field data is available
New pages, low-traffic URLs, and some origins may not have enough eligible visits for public CrUX data. In that case:
- use Lighthouse and other lab tools as diagnostic evidence;
- test several representative devices and network conditions;
- compare related templates rather than one isolated URL;
- consider implementing privacy-conscious real user monitoring;
- avoid presenting a laboratory result as confirmed field performance.
A practical performance review process
- Begin with the page and its users. Identify the page’s primary content, important interactions, common devices, and likely network conditions. A publishing page, ecommerce interface, map, and web application may have different performance constraints.
- Review available field data. Check Search Console, PageSpeed Insights, CrUX, or real user monitoring. Determine whether the data applies to the exact URL, a URL group, or the entire origin.
- Identify the affected metric and scope. Separate an isolated URL problem from a template-wide or site-wide issue. A shared header script, image component, font, or layout pattern may affect many pages.
- Use Lighthouse and browser tools to investigate causes. Inspect the metric details rather than responding only to the overall score. Performance traces, network waterfalls, coverage reports, layout-shift records, and long-task information often provide more actionable evidence.
- Prioritize changes by user impact. Address changes that materially improve loading, responsiveness, or stability. Prefer straightforward improvements over fragile workarounds designed only to influence the score.
- Test for broader regressions. Confirm that the change does not harm accessibility, content visibility, analytics integrity, browser compatibility, or essential functionality.
- Validate after release. Repeat controlled tests immediately, then monitor field data as new visits enter the rolling dataset. Field reports will not necessarily reflect a deployment at once.
Common Lighthouse and Core Web Vitals mistakes
Chasing a perfect score
Repeatedly changing a healthy page to move from a high score to 100 can consume substantial engineering time for little observable benefit. Once meaningful performance problems are resolved, additional work should have a clear reason.
Treating every audit suggestion as mandatory
Lighthouse opportunities are diagnostic leads, not universal requirements. An estimated saving may not translate directly into a better field experience, and some recommendations involve tradeoffs that require engineering judgment.
Ignoring the difference between TBT and INP
Total Blocking Time can reveal main-thread congestion in the laboratory, but it does not measure how real visitors experience interactions throughout a session. Use it to investigate likely responsiveness problems, not to declare that field INP has passed.
Testing only the homepage
Different templates may have different performance characteristics. Article pages, category archives, product pages, forms, landing pages, and authenticated interfaces should be sampled separately.
Breaking usability to improve a metric
Deferring essential content, removing useful controls, hiding information, or weakening an interface to improve a test score reverses the purpose of performance work. Metrics are intended to help describe user experience, not replace it.
Adding complexity for marginal gains
Every new loading strategy, script, build step, or caching layer creates maintenance obligations. A small laboratory improvement may not justify additional failure modes or a system that future editors cannot safely understand.
Assuming Core Web Vitals determine rankings by themselves
Core Web Vitals contribute to Google’s broader page-experience considerations, but they are not a guarantee of search visibility. Relevance, content quality, accessibility, crawlability, intent alignment, and many other factors remain important. A passing assessment does not make an irrelevant page relevant.
When performance work is done
Performance work can reasonably be considered complete for the current release when:
- the important page templates load promptly and remain visually stable;
- essential interactions respond without disruptive delay;
- available Core Web Vitals data is within an acceptable range or moving in the expected direction;
- identified regressions have been investigated and addressed;
- improvements have been tested under consistent conditions;
- accessibility and essential functionality remain intact;
- the implementation does not introduce disproportionate complexity;
- monitoring is sufficient to detect future regressions.
“Done” does not mean performance will never change. Websites evolve, third-party services change, content grows, and browser behavior develops over time. It means the present risks are understood, meaningful problems have been addressed, and the page can be monitored without turning every score fluctuation into an emergency.
Interpretation standard
Lighthouse is a diagnostic tool. Core Web Vitals field data is an aggregated view of real-user loading, responsiveness, and visual stability. Neither is a complete definition of user experience.
A durable interpretation standard is:
- Users first: preserve useful, accessible, stable experiences.
- Field data second: validate what real visitors experience over time.
- Metrics third: use individual measurements to locate specific problems.
- Composite scores last: treat the overall Lighthouse score as a summary, not the objective.
A perfect score with a worse interface is not a successful optimization. A less-than-perfect score with healthy field data, strong usability, and maintainable engineering may be the better outcome.
Related reference: URLMD Glossary