Guide

How to read a Lighthouse audit and fix what matters

A Lighthouse report throws a lot of numbers at you. This guide explains what the four category scores mean, how the Performance number is put together, and which fixes are worth your time.

By Roger Campos · Last updated: September 2026

TL;DR

Lighthouse scores a page in four categories: Performance, Accessibility, Best Practices and SEO. The Performance score is a weighted blend of five lab metrics, and three of them — Total Blocking Time, Largest Contentful Paint and Cumulative Layout Shift — carry 80% of it. Treat the score as a diagnostic, not a target: fix what the Insights flag, and confirm with real-user field data.

Start free See the API

Free plan, no credit card. 1,000 credits a month.

The basics

The four things Lighthouse scores

A Lighthouse report grades a page in four independent categories. Each is scored 0–100; they don't roll up into a single number.

Performance — how fast the page loads and becomes usable. The one people obsess over, and the most nuanced.
Accessibility — automated checks for contrast, labels, ARIA and semantics (a floor, not a guarantee).
Best Practices — security, correct APIs, console errors, image aspect ratios.
SEO — crawlability basics: meta tags, valid HTML, mobile-friendliness, link text.

The score

What the Performance number actually measures

The Performance score is a weighted blend of lab metrics, not a single stopwatch. Lighthouse loads the page on a simulated device and network, records a handful of timings, and combines them. A few metrics dominate the weighting, so those are where you should look first.

Metric	Measures	Weight	Good
Total Blocking Time (TBT)	Main-thread blocking during load	30%	≤ 200ms
Largest Contentful Paint (LCP)	When the main content is visible	25%	≤ 2.5s
Cumulative Layout Shift (CLS)	How much the layout jumps around	25%	≤ 0.1
First Contentful Paint (FCP)	When anything first renders	10%	≤ 1.8s
Speed Index	How quickly content is visually filled in	10%	≤ 3.4s

TBT, LCP and CLS carry 80% of the weight. If you only have time for three things, improve those. Time to Interactive, which older guides still mention, is not part of the score — Lighthouse 10 took it out.

Real users

Lab vs. field: why your score wobbles

Lighthouse runs a lab test: one synthetic load on a simulated device. That's reproducible and great for debugging, but it isn't what your real users experience across different devices, networks and locations.

Field data (also called RUM, or the Chrome UX Report) is the real-user picture, and it's what Google uses for Core Web Vitals in ranking. Treat the lab score as a diagnostic to find and fix issues, and confirm the win with field data. And because lab runs vary with CPU and network noise, take the median of a few runs rather than trusting a single number. The lab vs. field guide goes deeper.

Take action

How to prioritize fixes

Ignore the score itself for a moment and open the Insights. Lighthouse 13 folded most of the old Opportunities and Diagnostics audits into these, the same insights Chrome DevTools' Performance panel shows; a few diagnostics remain alongside them. Each insight names a concrete problem (an LCP image discovered late, render-blocking requests, a slow document request, layout shift culprits) and the metric it hurts. Work top-down by impact:

1
Fix render-blocking resources and oversized images — usually the biggest LCP wins.
2
Cut and defer JavaScript — the main lever on Total Blocking Time.
3
Reserve space for images, ads and embeds — the direct fix for layout shift (CLS).
4
Serve modern formats and compression — WebP/AVIF images, text compression, caching.
5
Re-audit and compare — confirm each change moved the metric it targeted.

Rule of thumb

Don't chase 100. A page can score 100 in the lab and still feel slow on a real phone. Fix the specific, high-impact opportunities and validate against real-user data.

FAQ

Frequently asked questions

What's a good Lighthouse score?

90–100 is considered good, 50–89 needs improvement, and below 50 is poor. But the score is a relative diagnostic — a page can score 100 in the lab and still feel slow for real users on slow networks. Use the score to find issues, then verify with field data.

Why does my score change every time I run it?

Lab audits run on a simulated device and network, and small variations in CPU contention, network timing and third-party scripts cause run-to-run variance. Run it a few times and look at the median, or use field (real-user) data for a stable picture.

What are Core Web Vitals?

Three real-user metrics Google emphasizes: Largest Contentful Paint (loading — when the main content appears), Cumulative Layout Shift (visual stability — how much the layout jumps), and Interaction to Next Paint (responsiveness — how quickly the page reacts to input). Lighthouse measures LCP and CLS directly in the lab; INP needs a real person interacting, so a lab run uses Total Blocking Time as its stand-in.

What happened to the PWA category?

Lighthouse dropped it in version 12. Installability is checked in Chrome DevTools' Application panel rather than scored, so a current report has four categories.

Should I audit on mobile or desktop?

Both, but prioritize mobile — it usually scores lower and reflects the harder real-world case (slower CPU and network). The default Lighthouse profile is mobile for exactly this reason.

Try it yourself

Free tools for this

No signup — run these on a real page right now, then call the same endpoint from your code.

/lighthouse API docs

Keep reading

Core Web Vitals: lab vs field Find JavaScript errors on any site HTML to Markdown for LLMs Rendered vs. raw HTML Extracting page metadata All guides

Put this into practice.

Each of the eight kinds of data URLpipe returns has a free, no-signup tool — try the ideas from this guide on a real page, then grab an API key to run them from your code. 1,000 credits a month, no card.

Start free Email the team