How to Read a Lighthouse Report: Scores, Metrics and What to Fix First

You run Lighthouse, a circle turns orange, and below it sits a long list of audits with numbers in seconds and milliseconds. Learning how to read a Lighthouse report is mostly learning what to ignore. The score at the top is a summary, the five metrics behind the performance score decide it, and the audits underneath are leads to follow, not a to-do list to clear.

This guide walks through a report from top to bottom: the four category scores, how the performance score is built from weighted metrics, the lab thresholds for each metric, what the insight and diagnostic sections are, and how to turn them into an order of work. It is for site owners, marketers and developers who have a report in front of them and want to know what it actually says. You will finish able to explain a report in a minute and name the first two things worth fixing.

Short answer: A Lighthouse report gives 0 to 100 scores for performance, accessibility, best practices and SEO. The performance score is a weighted mix of five lab metrics: First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift. Treat audits as leads, and confirm with real-user data.

Before you begin

Lighthouse is an open-source auditing tool. You can run it in the Lighthouse panel of Chrome DevTools, from the command line, as a Node module, or through the PageSpeed Insights web page. A DevTools run takes roughly 30 to 60 seconds.

Pick the page deliberately. Test a page that represents a template (an article, a product page), not only the home page. Lighthouse's own variability notes say that other apps, browser extensions, antivirus software and even other Lighthouse runs compete for CPU, memory and network and change results, so use a clean browser profile if you can. Nothing in a Lighthouse run changes your site, so there is no risk. If you want the real-user side of the story, read Lighthouse score vs real user data: which matters? alongside this guide.

Step-by-step instructions

Step 1: Run the test and note the conditions

Run an analysis and write down what you tested: the exact URL, mobile or desktop, the date, and the Lighthouse version shown with the report. These details matter because mobile and desktop use different simulated devices and different scoring thresholds, and because Lighthouse changes between versions. If you use the PageSpeed Insights API, the response includes the Lighthouse version and the test environment inside its lighthouseResult object.

What success looks like: You have a report you can describe in one line, such as "example.com/blog/post, mobile, 4 November 2026".

Step 2: Read the four category scores

A report scores categories separately. Google's PageSpeed Insights documentation lists the lab categories as Performance, Accessibility, Best Practices and SEO, and the Lighthouse documentation says plugins can add more. Scores are 0 to 100 with fixed bands: 0 to 49 is red (poor), 50 to 89 is orange (needs improvement) and 90 to 100 is green (good). What each category does and does not tell you:

Performance measures how the page loads in a simulated environment. It is the category this guide spends most time on.
Accessibility runs automated accessibility audits. Automated testing cannot cover everything, so a high score does not mean the page works for everyone. See Website Accessibility Audit: Fix the Most Common Problems.
Best Practices covers general web-health audits; the Lighthouse 13 notes, for example, mention HTTPS and viewport insights in this category.
SEO runs basic, mechanical page-level audits. It cannot tell you whether the content is good or whether the page will rank.

What success looks like: You can say which category is weakest and why a 100 in any one category proves little.

Step 3: Understand how the performance score is built

The performance score is not an average of everything on the page. It combines five metric scores with fixed weights. Lighthouse's scoring documentation lists these weights for Lighthouse 10:

Metric	Weight
First Contentful Paint (FCP)	10%
Speed Index (SI)	10%
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	30%
Cumulative Layout Shift (CLS)	25%

The Lighthouse 13 release post says there were no changes to performance scoring in that version, and that scoring depends on metrics, not on the audits listed below them. Check the scoring page for the weights in the version you are running. Each raw metric is converted to a 0 to 100 score on a curve based on real-site data from the HTTP Archive. Per the documentation, the 25th percentile of that data maps to a score of 50 and the 8th percentile maps to 90. Scores flatten near the top, so the last few points need much larger improvements than the first ones. A perfect 100 need not be your target.

Two consequences follow. First, TBT, LCP and CLS together carry 80% of the score, so they are where effort pays off in the score. Second, an audit with a red warning does not necessarily move the score at all.

What success looks like: You can name the three metrics that carry most of the weight.

Step 4: Read each metric against its threshold

Lighthouse shows each metric with a colour. These are the lab thresholds from Chrome's documentation:

Metric	Fast (green) mobile	Fast (green) desktop	Slow (red) mobile	Slow (red) desktop
FCP	0 to 1.8 s	0 to 0.9 s	over 3 s	over 1.6 s
Speed Index	0 to 3.4 s	0 to 1.3 s	over 5.8 s	over 2.3 s
LCP	0 to 2.5 s	0 to 1.2 s	over 4 s	over 2.4 s
TBT	0 to 200 ms	0 to 150 ms	over 600 ms	over 350 ms

What each one measures:

FCP: how long until the browser renders the first piece of content, such as text, an image or an SVG.
Speed Index: how quickly content is visually displayed. Lighthouse records a video of the load and measures visual change between frames.
LCP: when the largest content element in the viewport is rendered. If the LCP element is an image, Lighthouse splits the time into time to first byte, load delay, load time and render delay, which tells you which stage is slow. See Fix Largest Contentful Paint (LCP) on Mobile.
TBT: the sum of the blocking parts of long tasks (the time beyond 50 ms) between FCP and Time to Interactive. A 70 ms task contributes 20 ms.
CLS: how much visible content shifts unexpectedly. Google's field target is 0.1 or less. See Reduce Cumulative Layout Shift (CLS) Step by Step.

Lighthouse cannot measure Interaction to Next Paint (INP) because a lab run has no real user input. Google's web.dev guidance says TBT serves as a lab proxy for it. That is why a report can look fine while real users still find the page sluggish.

What success looks like: For each of the five metrics you know the value, the colour and the threshold it crossed.

Step 5: Find the cause in the insights and diagnostics

Under the score, Lighthouse lists audits. Recent Lighthouse versions show "insights" by default, which merge several older performance audits and align with the Insights in Chrome DevTools' Performance panel. Audits that were not changed remain under "Diagnostics". Lighthouse 13 removed the replaced audits from the report and the JSON, and dropped a few without replacement, including offscreen-images, preload-fonts and uses-rel-preload. If a tutorial tells you to fix an audit you cannot find, it may be from an older version.

Read the audits in this order:

Anything that names the LCP element or the LCP breakdown, because it points at the slowest stage.
Audits about main-thread work, long tasks and JavaScript, because they drive TBT. See Remove Render-Blocking CSS and JavaScript Safely and Third-Party Scripts and Performance: Measure and Tame Them.
Layout shift culprits, which name the elements that moved.
The estimated savings shown on audits. Treat them as estimates from one simulated run, not a promise of what you will gain.

What success looks like: You have two or three audits that explain your weakest metrics.

Step 6: Decide what to fix first

Work from the metric to the cause to the fix, and choose by weight and effort.

Observation in the report	Likely first move
LCP is red and the LCP element is an image	Check how and when that image loads, then size and format
TBT is orange or red	Look for long tasks from scripts; remove or defer what you do not need
CLS above 0.1	Reserve space for images, embeds and late-loading elements
High time to first byte in the LCP breakdown	Look at hosting, caching and server response, not the front end
Accessibility or SEO items failing	Quick fixes, but they do not change the performance score

Before you start, check whether real users have a problem. Open the same URL in PageSpeed Insights and read the field data, because Google recommends prioritizing field data to decide what to fix, with lab data for debugging. PageSpeed Insights Explained: Field Data, Lab Data and Why They Differ shows how. Crawvix takes its Lighthouse results from the PageSpeed Insights API for mobile and desktop and lists audits that fall below the good mark, but the same reasoning applies to any report: a finding is only worth fixing if it affects a visitor.

What success looks like: A short ordered list of fixes, each tied to a metric.

Step 7: Rerun, compare and expect noise

Lighthouse results vary between runs. The project's variability guide names page nondeterminism (A/B tests, ads), local network, client hardware and resource contention as high-impact sources, and recommends running several times and using the median. It says a median of five runs is about twice as stable as a single run. After each change, run the same page under the same conditions and compare medians. Do not celebrate or panic about a single run. To catch regressions automatically, see Lighthouse CI and Performance Budgets: Catch Regressions Early.

What success looks like: You compare medians of repeat runs, not single scores.

Worked example

This example is invented for illustration. A mobile report for https://example.com/blog/post shows Performance 58, Accessibility 91, Best Practices 96 and SEO 100.

Metric	Value	Colour	Reading
FCP	2.4 s	Orange	Slow but not the main issue
Speed Index	4.2 s	Orange	Follows the slow load
LCP	4.8 s	Red	Biggest problem, weight 25%
TBT	450 ms	Orange	Heavy scripts, weight 30%
CLS	0.02	Green	Fine

The accessibility and SEO scores are not the story. The LCP breakdown shows a long load delay for a hero image, and the diagnostics show large script work. The first two fixes are therefore: load the hero image earlier and trim unneeded scripts. Then rerun five times and compare medians.

Final verification checklist

You recorded the URL, device, date and Lighthouse version for the report.
You can state the four category scores and explain what each does not prove.
You know the five metrics in the performance score and which three carry the most weight.
Each metric has a value and a colour checked against the mobile or desktop thresholds.
Two or three audits are linked to the weakest metrics.
You checked field data for the same URL before deciding what to fix.
Your fix list is ordered by metric weight and effort.
You compare median results from several runs after changes.

Common mistakes to avoid

Chasing 100. Scores flatten at the top and a perfect score does not guarantee better search results.
Fixing every red audit. Many do not affect the score or real visitors.
Comparing a mobile and a desktop report. They use different devices and thresholds.
Judging a change from one run. Use the median of repeats.
Testing with extensions and downloads running. They skew the numbers.
Following advice for audits that no longer exist. Check your Lighthouse version.
Ignoring real-user data. The lab is one device on one network.

Frequently asked questions

What is a good Lighthouse score?

Lighthouse marks 90 to 100 as good, 50 to 89 as needs improvement and 0 to 49 as poor. A green score is a useful signal but not a promise about rankings or visitor experience.

Why is my Lighthouse score different every time?

Lab runs vary with network conditions, hardware, resource contention and page changes such as ads or A/B tests. Run it several times and use the median.

Why does Lighthouse not show INP?

INP needs real user interactions, which a lab run does not have. Lighthouse reports Total Blocking Time as a proxy. For INP itself you need field data; see Improve Interaction to Next Paint (INP) on JavaScript Sites.

Is Lighthouse the same as PageSpeed Insights?

No. PageSpeed Insights runs Lighthouse for its lab section and adds real-user data from the Chrome User Experience Report when enough exists. Lighthouse alone has lab data only.

Does a better Lighthouse score improve SEO?

Google recommends good Core Web Vitals, but they are field metrics and Google does not promise a ranking change from good scores. Lighthouse's SEO category checks basic mechanics only.

Official references

Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.