The Lighthouse score is a 0-100 performance rating built from five lab metrics measured in one simulated page load on a throttled phone: Total Blocking Time, Largest Contentful Paint, Cumulative Layout Shift, First Contentful Paint and Speed Index. It tells you how the page behaved in that test, not how real visitors experienced it, which is why a page can score 100 and still fail Core Web Vitals, or score 60 and pass them. This guide explains how the score is calculated, how Lighthouse relates to PageSpeed Insights, which number Google uses, and how to read them together. It is one part of the page speed guide, which maps the whole topic.
Quick answer
- The Lighthouse performance score weights TBT 30 %, LCP 25 %, CLS 25 %, FCP 10 % and Speed Index 10 %, from one lab run. 90-100 is good, 50-89 needs improvement, 0-49 is poor.
- PageSpeed Insights runs Lighthouse on Google's servers with fixed settings and adds real-visitor data from the Chrome UX Report. Lighthouse in Chrome DevTools runs on your computer, so its score varies more.
- Core Web Vitals (LCP, INP, CLS) come from real Chrome users at the 75th percentile over 28 days. That field data is what Google's ranking systems use; the Lighthouse score is not a ranking factor.
- INP has no lab version. Total Blocking Time is the closest proxy, and a good TBT does not guarantee a good INP.
- Past about 90, extra points cost a lot and rarely change what visitors feel.
- The speed test shows the score, the lab metrics and the field data side by side.
How the Lighthouse score is calculated
Lighthouse loads the page once, on simulated hardware, and measures five metrics. From Lighthouse 10 to the current Lighthouse 13, the weights are:
| Metric | Weight | Good |
|---|---|---|
| Total Blocking Time (TBT) | 30 % | ≤ 200 ms |
| Largest Contentful Paint (LCP) | 25 % | ≤ 2.5 s |
| Cumulative Layout Shift (CLS) | 25 % | ≤ 0.1 |
| First Contentful Paint (FCP) | 10 % | ≤ 1.8 s |
| Speed Index (SI) | 10 % | ≤ 3.4 s |
Each metric is turned into a 0-100 sub-score on a log-normal curve built from real-world site data, then the weighted sub-scores are added up. The weights have changed between versions (Lighthouse 10 dropped Time to Interactive and gave its share to CLS), so scores from different versions are not comparable. Lighthouse 13, released in October 2025, replaced many of the old audits with "insights" shared with the DevTools Performance panel, but did not change the weights.
The mobile run emulates a mid-range Android phone (a Moto G Power, 412 × 823 px) on a slow 4G connection with a CPU four times slower than the test machine. It is one visit, with an empty cache, no consent choice, no logged-in state and no interaction. Run it twice and the score moves by a few points.
PageSpeed Insights vs Lighthouse
They are not competing tools: PageSpeed Insights is a web page that runs Lighthouse for you and adds field data. The differences that explain most "why is my score different" questions:
| PageSpeed Insights | Lighthouse in Chrome DevTools | |
|---|---|---|
| Where it runs | Google's servers, fixed hardware | Your computer and your connection |
| Throttling | Simulated slow 4G and 4× CPU slowdown | The same simulation, but your CPU and browser extensions still affect the result |
| Real-visitor data | Yes, Core Web Vitals from CrUX when available | No |
| Lighthouse version | Google's current release | Whatever your Chrome ships |
Use PageSpeed Insights (or a tool built on its API, such as getReport's speed test) for numbers you compare over time or share with others. Use DevTools when you need to change something and re-measure in seconds, and read its score as relative, not absolute.
What Core Web Vitals are
Core Web Vitals come from the Chrome UX Report (CrUX): anonymous measurements from Chrome users who opted in, collected on real devices and networks. Each metric is reported at the 75th percentile over a rolling 28 days, so three out of four visits were at least that good. The thresholds, from web.dev's Core Web Vitals page:
| Metric | Good | Poor |
|---|---|---|
| Largest Contentful Paint | ≤ 2.5 s | > 4 s |
| Interaction to Next Paint | ≤ 200 ms | > 500 ms |
| Cumulative Layout Shift | ≤ 0.1 | > 0.25 |
A lab run does not tap anything, so INP, which measures responses to taps, clicks and key presses over the whole visit, cannot be measured there at all.
Does the Lighthouse score affect SEO?
Not directly. Google's Search documentation on Core Web Vitals says its ranking systems use Core Web Vitals, and Search Console's Core Web Vitals report is built from the same field data. The Lighthouse score is not part of that. A perfect score does not help rankings on its own; good field data does, as one signal among many, and relevance still comes first. The Lighthouse SEO category is a separate checklist (titles, crawlability, link text) and is not a ranking score either. Core Web Vitals and SEO covers how much the field data weighs.
Optimising the wrong number costs weeks: a 100 is easy to show a client while the checkout still freezes after every tap on a mid-range phone, and a site with fast real visitors gets rebuilt because a lab test said 58.
How getReport checks it
The speed test asks Google PageSpeed Insights for a mobile and a desktop Lighthouse run and shows them next to the field data PSI returns from CrUX. The Speed module's score ring is the Lighthouse score for the report's device, mobile by default; the other device's score is in the line above the tables.
The lab table lists six numbers; five of them feed the score, and Time to First Byte is there for diagnosis. The Lighthouse version is printed next to the table.
The field column shows each Core Web Vital as a bar with its 75th percentile and the share of good, needs-improvement and poor visits. The header line says whether the data is for "this page" or the "whole site": when a page has too few visits of its own, getReport falls back to the origin's data. When neither exists, the column says so, and the lab numbers are the best estimate.
INP is never scored in the lab. Without field data the INP finding reads "not measured yet" and costs no points. If Google's measurement is unavailable (quota or an outage), the report can fall back to a local Lighthouse run and labels the result "lab estimate" rather than "Google PageSpeed".
Step by step
1. Start with the field column
Look at the field column before the score. Three cases:
- Page-level data. The best case: these are your real visitors on this URL. Any metric in "poor" or "needs improvement" is your priority, whatever the score says.
- Whole-site data. The numbers describe the whole domain, weighted by traffic. They tell you whether the site has a problem; they do not prove this page has it.
- No field data. Common for small sites and new pages. Work from the lab run, and use the lab vs field guide to understand what the lab can and cannot predict.
2. Read the two together
Three situations that come up again and again:
Score 95, field INP poor. The page loads fast in the lab, then real visitors interact with it while a chat widget, a consent script and a tag manager are still running, or every tap triggers heavy JavaScript. Lighthouse stopped measuring when the load was quiet. Look at TBT and the long-tasks finding for hints, then at which scripts run on interaction: delayed scripts that all start on the first tap are a classic cause.
Score 60, field data good. Real visitors are mostly on desktop or fast phones, many come back with a warm cache, or the heavy part of the page is below the fold. The lab's slow phone on slow 4G is harsher than your audience. Fix what the lab names if it is cheap, but the site is not failing its visitors.
Score 61, no field data (the screenshot above). TBT is 0 ms, so the main thread is fine. The points are lost to LCP (10.5 s) and CLS (0.271). The waterfall shows why: a 1.8 MB image takes most of the bandwidth on the simulated connection, and the image-formats finding estimates 9.4 s of savings. Compress and resize it, give images their width and height, and both metrics move. This is where the lab earns its keep: it names the file.
3. Use the lab to find the cause
Field data says what is slow for visitors; it never says why. Once you know which metric to work on, the lab findings under it name the LCP element, the render-blocking files, the long tasks and the third-party scripts. Reading your PageSpeed score walks through the rest of the result, and reading a waterfall chart shows where the time goes.
4. Treat TBT as an INP hint, not a promise
Total Blocking Time adds up how long the main thread was blocked during the load. A page with 2 s of TBT will almost certainly have slow interactions too. A page with 0 ms of TBT can still have poor INP if the work happens on interaction (a filter that re-renders 500 products) or after the load (scripts that start late). Only field data confirms INP.
5. Measure changes properly
- Compare runs from the same Lighthouse version (it is printed in the panel) and the same device.
- Run the test several times and look at the spread, not one number. getReport caches a report for 12 hours per URL, so use the report's "Check again" button for a fresh measurement.
- Expect field data to move slowly: it is a 28-day window, so a fix shows fully about four weeks later. The Core Web Vitals history tool shows the weekly trend for up to 40 weeks.
6. Decide when to stop
Once field data is green and the mobile score is in the 90s, spend the time on content or conversion instead. Mobile and desktop differ for good reasons; mobile vs desktop scores explains why mobile is always lower.
Tip
When a client asks why the score is not 100, show the field column first. "Three out of four real visits load the main content in under 2.5 seconds" is a sentence a client can act on; a lab score is not.
Platform notes
WordPress
Optimisation plugins with "delay JavaScript until interaction" can lift the lab score dramatically, because Lighthouse never interacts and the scripts never run. Real visitors do interact, and on the first tap every delayed script starts at once, which can make INP worse. After enabling such a setting, keep checking field INP over the following four weeks, and exclude scripts that the first interaction needs (menus, add to cart, search).
Verify
- You can say which Core Web Vital is the page's weakest, from field data if the page has it.
- The fix you made moved that metric in the lab run, from the same Lighthouse version and device.
- Four weeks later, the field column shows the metric at or below the "good" threshold, for the page or the whole site.
Common mistakes
- Optimising for the score. Symptom: a 100 in the lab and complaints about a slow checkout. Fix: start from field data and the metric that fails.
- Quoting the desktop score in a mobile world. Most sites get most visits from phones, and Google indexes the mobile version. Report the mobile number.
- Celebrating the score while INP fails. The lab cannot see interactions. If field INP is poor, the page is slow where it matters most, whatever the score says.
Questions people ask
Does PageSpeed Insights run the same test as Lighthouse?
Yes. PageSpeed Insights runs Lighthouse on Google's servers, with the same five weighted metrics and the same simulated phone, and then adds real-visitor Core Web Vitals from the Chrome UX Report above the lab result. Scores still differ from a Lighthouse run in your own Chrome, because your computer's CPU, extensions and network change the timing. Use PageSpeed Insights for numbers you compare over time.
Why can a page score 100 in Lighthouse and still fail Core Web Vitals?
Because the score comes from one simulated load with an empty cache and no interaction, while Core Web Vitals come from real visitors over 28 days. Real visitors tap menus while scripts are still running, see ads and banners that load late, and use slower phones than the lab. Slow taps (INP) and late layout shifts never appear in the lab, so the score can be perfect while the field data fails.
Why did my Lighthouse score drop when nothing on the site changed?
Usually because of normal run-to-run variation, a new Lighthouse version or a third party. Scores move a few points between runs as server response and network timing vary. A new Lighthouse release can re-weight or re-score metrics, and a changed ad, chat or analytics script changes your page without a deploy. Check the version printed next to the lab table and compare the individual metrics before looking for a cause.
Should I aim for a Lighthouse score of 100?
No, aim for passing Core Web Vitals in the field and a mobile score in the 90s. Above that, the scoring curves are flat: taking LCP from 1.8 s to 1.3 s earns few points and visitors barely notice. The last points often mean removing things people value, such as product video or reviews. Spend that time on the metric real visitors fail, or on content.