A Lighthouse 90 is the number every website builder quotes and almost nobody can explain. Here is the honest version: it is a useful floor for a small business site, and it is also a lab test run on a slow simulated phone, which means it tells you less than the sales pitch implies about what your actual customers experience. Both are true. This is what the number is made of, what it misses, and how to check your own site before you pay anyone.
What the number is
Lighthouse is a free, open-source tool from Google. It runs inside Chrome and at pagespeed.web.dev, and it scores a page out of 100 in four categories: Performance, Accessibility, Best Practices and SEO. When someone brags about “a 90”, they almost always mean the Performance score. The other three are separate numbers and separate conversations.
The bands are simple. 0 to 49 is poor, 50 to 89 needs improvement, 90 to 100 is good. Green is not perfect: Google’s own docs say a 100 is not expected, and that moving from 99 to 100 takes about the same improvement as moving from 90 to 94. Treat 90 as a floor, not a trophy.
What the Performance score is made of
Five measurements, weighted, with the weights published:
| Measurement | Weight | What it measures |
|---|---|---|
| Total Blocking Time | 30% | How long the page cannot respond to a click or tap because JavaScript is busy. This is the heaviest item, and it is why script-heavy sites score badly. |
| Largest Contentful Paint | 25% | How long until the biggest visible thing, usually the hero image, appears. Under 2.5 seconds is good. |
| Cumulative Layout Shift | 25% | How much the page jumps around while loading. Images without reserved space and late-loading fonts are the usual cause. Under 0.1 is good. |
| First Contentful Paint | 10% | When any content at all appears. |
| Speed Index | 10% | How quickly the visible content fills in. |
That is the whole recipe. Nothing else touches the score directly. The Opportunities and Diagnostics sections of the report are suggestions; they only move the number if these five move with them.
Where the score comes from
Lighthouse maps each raw measurement onto a curve built from real websites in the HTTP Archive dataset. The 25th percentile of that data scores 50, and the 8th percentile scores 90. So a 90 puts you ahead of roughly 92% of the sites in that dataset on the measured metrics. That is a strong result, not a vanity number.
The catch is the conditions. Lighthouse tests on a simulated mid-range phone with a 1.6 Mbps connection, 150ms of latency, and a CPU throttled to a quarter of its speed. It loads the page cold, empty cache, and waits patiently for everything to finish. Real customers on real phones, with faster connections and warm caches, usually see better numbers than the lab does. DebugBear, a monitoring company, documented one page at 8.2 seconds for LCP in the lab while real users saw 1.9 seconds. The lab test approximates your worst 5-10% of visitors, not your typical one.
The score also moves between runs for reasons that have nothing to do with your site: browser extensions, antivirus, the machine it runs on, ad networks swapping creative. One run at 92 and the next at 87 is normal noise. A builder quoting a single number from a single run is quoting you weather, not measurement. The professional version is three runs on mobile and the median.
What a 90 does not measure
Real users. Lighthouse cannot see them. Real-user data comes from the Chrome User Experience Report, collected from actual visitors and judged at the 75th percentile. Those are the numbers behind the three Core Web Vitals, LCP under 2.5 seconds, INP under 200ms, CLS under 0.1, which have been a confirmed ranking factor since June 2021, a tiebreaker when content quality is otherwise similar.
Here is the uncomfortable detail. The interactivity vital, INP, replaced First Input Delay in March 2024, and it cannot be measured in a lab at all, because it needs real clicks and taps. Lighthouse substitutes Total Blocking Time as a stand-in. The two correlate, but they are not the same number. A perfect 100 in Lighthouse does not guarantee passing the Core Web Vitals, and a mediocre score does not guarantee failing them. Google says so directly.
New sites have one more problem. CrUX only reports once real traffic has built up, which for a small business can take weeks or months. For the first stretch of a new site’s life, the lab score is the only proof you get that the site is fast. That makes it worth having, and worth getting in writing, even though it is not the whole story. The 2025 Web Almanac found only 48% of mobile pages pass all three Core Web Vitals, so a site that genuinely clears the bar is ahead of most of the web.
The takeaway, in one line: a claimed score is decoration. A measured score, run on mobile and re-runnable, is proof.
What to do about yours
Check the site you already have, and check any quote you are holding. Open pagespeed.web.dev, test on mobile, and test a landing page, not just the homepage. Mobile is the score that counts: desktop usually runs 15 to 25 points higher for the same page, and Google indexes mobile-first.
If the number is low, the fixes follow a boring order. Images first. A hero image over 1MB can add 2 to 4 seconds to LCP, and compression plus WebP is cheap. Then hosting: if the server takes more than 600ms to respond, that is a hosting problem, not a code problem. Then scripts: chat widgets and trackers loaded synchronously block the page. Fonts and plugins come after that.
The honest caveat: patches move most sites from the 40s to the low 60s. Getting from 65 to 90 usually means removing structural weight, which on WordPress means the page builder and the plugin pile, and that is a rebuild, not a tweak.
If a builder puts “90+” in a proposal, one sentence in the contract settles it: the report, run on mobile, attached at handover, with the URL and date on it. A measured score you can re-run yourself is proof. A claimed score is decoration. Run the test today, keep the screenshot, and compare it against whatever you get quoted.