Lighthouse performance score
The Lighthouse performance score is a number from 0 to 100 that summarizes how quickly a page loads and becomes usable. We get it from Google PageSpeed Insights (PSI), which loads your page in a controlled lab environment: an emulated mid-range phone on a throttled mobile connection. The score is a weighted blend of several lab metrics, each covered in its own guide.
Why it matters
The score is a quick health indicator. A low score almost always means real visitors on phones wait for content, see the layout jump, or tap buttons that do not respond. Slow pages lose visitors before they read anything, and Google uses real-user page experience data (the Core Web Vitals) as one of its search signals.
Keep in mind what the score is not: it is a lab test of one load, on one simulated device, from one location. It is a diagnostic tool. What your actual visitors experience is captured by the field data from the Chrome UX Report, when Google has enough of it.
How the score is calculated
Lighthouse converts each metric into a 0–100 sub-score against reference values, then combines them with fixed weights. In current Lighthouse versions the weights are:
| Metric | Weight |
|---|---|
| Total Blocking Time | 30% |
| Largest Contentful Paint | 25% |
| Cumulative Layout Shift | 25% |
| First Contentful Paint | 10% |
| Speed Index | 10% |
Total Blocking Time, Largest Contentful Paint and Cumulative Layout Shift make up 80% of the score, so they are where improvements pay off most. Server response time (TTFB) is not part of the score directly, but a slow server delays every other metric.
What we check
| Check | Result |
|---|---|
| Lighthouse performance score | Good at 90–100, needs attention at 50–89, poor below 50 |
| Top improvement opportunities | Up to five failing Lighthouse audits with the largest estimated time savings |
| Desktop results | When included in your scan, the score, LCP, CLS and TBT from a desktop-profile run |
The main score and every metric guide on this site use the mobile run. The opportunities list is informational: it does not pass or fail, it tells you where to start.
How to fix
There is no single setting that raises the score. Work through it in this order:
- Start with the opportunities list. Each item shows the estimated savings. The first one or two items usually matter more than the rest combined.
- Fix the heaviest metric. Look at which of TBT, LCP or CLS is worst and follow its guide.
- Cut JavaScript. Large bundles and third-party scripts (tag managers, chat widgets, A/B
testing, social embeds) are the most common cause of a poor mobile score. Remove what you do not
need and load the rest with
deferor after user interaction. - Optimize the hero image. Serve it in AVIF or WebP at the size it is displayed, and do not lazy-load it.
- Reserve space for images, embeds and late-loading content so the layout does not shift.
Typical fixes that come up in the opportunities list:
- Eliminate render-blocking resources: inline critical CSS,
deferscripts. - Reduce unused JavaScript / CSS: split bundles per page, drop unused libraries.
- Properly size images / serve images in next-gen formats: use
srcsetand modern formats. - Reduce initial server response time: cache HTML and use a CDN.
Why the score changes between runs
Running the same page twice can give scores a few points apart. Server response time, network conditions, third-party scripts, ads and A/B tests all vary from load to load. Treat a change of a few points as noise. Look at the trend over several scans, and at the individual metrics, rather than chasing a single number.
Mobile and desktop
Desktop scores are usually much higher because the desktop profile uses a faster CPU and network. A good desktop score does not mean mobile visitors are fine. Prioritize the mobile result: most web traffic is mobile, and Google indexes the mobile version of your pages.