A Lighthouse performance score of 90 to 100 is classified as good. A score of 50 to 89 needs improvement, and 0 to 49 is poor. Those ranges describe the lab score shown by PageSpeed Insights; they do not replace real-user Core Web Vitals.
The best target is therefore not simply “100.” Aim for good field Core Web Vitals on important pages, remove meaningful lab bottlenecks, and prevent regressions without breaking the product.
The official score ranges
Google's current PageSpeed Insights documentation and Lighthouse scoring guide use these ranges:
| Lighthouse performance score | Classification |
|---|---|
| 90–100 | Good |
| 50–89 | Needs improvement |
| 0–49 | Poor |
A score of 100 is not required for a result to be green. Lighthouse's scoring curve also has diminishing returns near the top, so moving from 99 to 100 can require substantial metric improvement. That effort may be less valuable than fixing a slow product page, an interaction problem, or an accessibility defect.
What the score represents
PageSpeed Insights runs Lighthouse under a simulated environment and combines several lab metrics into a weighted performance score. The weights and scoring curves can change between Lighthouse versions as the project evolves.
The report's opportunities and diagnostics do not directly add or subtract fixed points. They help explain changes that may improve the measured metrics. A claim such as “this audit is worth exactly 12 points” is unreliable across pages and Lighthouse versions.
The lab score answers a bounded question: how did this page perform in this simulated run under this Lighthouse version and environment? It does not directly describe every visitor.
PageSpeed Insights may also show field data from the Chrome UX Report above the lab section. That field panel reflects real-user experience over a trailing period and uses LCP, INP, and CLS for the Core Web Vitals assessment. Read What Are Core Web Vitals? for the current thresholds and percentile model.
Why 90 is not the whole answer
A 90-plus score is a useful quality signal for the tested state, but it can coexist with problems:
- the URL has poor field Core Web Vitals from real mobile visits;
- a page-load test misses slow interactions later in the session;
- consent, ads, personalization, or authenticated content did not appear in the lab;
- a low-traffic URL has no field data;
- a fast page is inaccessible or does not satisfy the visitor's task;
- the home page is fast while product or article templates are slow.
The reverse can also happen. A lab score may fluctuate below 90 while the field data remains good. Investigate the underlying metrics and trace rather than treating the score as a release verdict by itself.
Mobile and desktop scores
Mobile and desktop Lighthouse runs use different scoring curves and simulated conditions. They should not be averaged. Mobile often exposes CPU, network, responsive-image, and JavaScript problems that a desktop run hides.
Set separate budgets and monitor real traffic distribution. A business with mostly mobile visitors should not declare success from a strong desktop score. At the same time, a desktop workflow with complex interaction deserves direct testing rather than being inferred from mobile.
When comparing changes, keep the URL, device mode, Lighthouse version, authentication state, consent state, region, and major third-party behavior as consistent as possible.
Why scores change between runs
Lighthouse and PageSpeed results can vary without a code deployment. Causes include:
- shared test infrastructure and network routing;
- origin or CDN cache state;
- third-party service latency;
- ads, experiments, or personalized content;
- background load on the server;
- browser extensions in local tests;
- dynamic images or API responses;
- differences in the Lighthouse version.
Run several equivalent tests and compare a representative median result. Save the individual metrics and trace. Do not select only the best run, and do not promise customers a permanently fixed score from a one-time audit.
For historical comparisons, IndieTools Speed can show how published measurements change over time. Those records are still observations of a URL and test configuration, not guarantees about every visit.
How to set a target
Use a hierarchy rather than one universal number.
First: protect the user journey
Measure the pages and interactions that matter: landing, listing, product, article, search, sign-up, cart, or dashboard. Performance on the home page cannot stand in for the whole site.
Second: pass field Core Web Vitals
Aim for good LCP, INP, and CLS at the 75th percentile, segmented by mobile and desktop. Track route templates in your own RUM when public CrUX data is too coarse or unavailable.
Third: use Lighthouse as a diagnostic and regression gate
A project may choose 90-plus as a lab budget for key public templates. Another may use metric budgets such as maximum LCP or JavaScript size because they are more actionable. Document the environment and allow a review path for justified product features.
Fourth: improve where evidence supports it
Once the experience is good, compare the next optimization with other work. A smaller image or removed third party may be valuable; weeks spent converting 99 to 100 may not be.
How to improve the score responsibly
Open the trace and fix the largest measured constraint. Common paths include:
- reduce server and redirect delay;
- expose the LCP resource in initial HTML;
- size and compress responsive images;
- remove render-blocking or unused CSS;
- reduce JavaScript and long main-thread tasks;
- load third-party features only where and when needed;
- reserve space for media and injected UI;
- limit font families, weights, and late swaps;
- cache immutable assets with versioned URLs.
Change one system at a time and retest. Do not hide content from Lighthouse, delay essential functionality only for the test, or serve a special page to measurement tools. Such tactics do not improve the visitor experience and can create correctness and trust problems.
Metric-specific diagnosis is more useful than generic advice. Use the FCP guide when the first visible content is late, and the CLS guide when content moves unexpectedly.
How to report performance
A professional performance report should include:
- exact URL and timestamp;
- mobile or desktop configuration;
- Lighthouse and browser versions where available;
- median plus range across repeated runs;
- individual metrics, not only the aggregate score;
- field-data source, scope, and date window;
- whether field data is URL-level or origin-level;
- relevant consent, authentication, cache, and third-party state;
- the change made and the release identifier;
- follow-up field results after the reporting window.
Say “the median mobile Lighthouse score improved from X to Y under this test configuration,” rather than “the site is now permanently Y.” That wording is precise, reproducible, and honest about what the measurement proves.
