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 five category scores mean, how Core Web Vitals are measured, and which fixes are worth your time.

By Roger Campos · Last updated: July 2026

TL;DR

Lighthouse scores a page in five categories (Performance, Accessibility, Best Practices, SEO and PWA). The Performance score is a weighted blend of lab metrics — mostly Largest Contentful Paint, Cumulative Layout Shift and Total Blocking Time. Treat the score as a diagnostic, not a target: fix the specific opportunities it flags, and confirm with real-user field data.

Start free See the API

Free plan, no credit card. 50 AI + 500 web operations / month.

The basics

The five things Lighthouse scores

A Lighthouse report grades a page in five 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.
PWA — whether the page meets Progressive Web App installability criteria.

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	Good
Largest Contentful Paint (LCP)	When the main content is visible	≤ 2.5s
Total Blocking Time (TBT)	Main-thread blocking during load	≤ 200ms
Cumulative Layout Shift (CLS)	How much the layout jumps around	≤ 0.1
First Contentful Paint (FCP)	When anything first renders	≤ 1.8s
Speed Index	How quickly content is visually filled in	≤ 3.4s

LCP, TBT and CLS carry most of the weight. If you only have time for three things, improve those.

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.

Take action

How to prioritize fixes

Ignore the score itself for a moment and open the Opportunities and Diagnostics sections — that's where Lighthouse tells you what to actually do, with estimated savings attached. 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 approximates them in the lab.

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.

Run a Lighthouse audit on any URL
Paste a link and get a real Google Lighthouse audit — performance, accessibility, best practices and SEO scores, plus Core Web Vitals — measured against the live page.
Try it free

/lighthouse API docs

Keep reading

HTML to Markdown for LLMs Rendered vs. raw HTML Extracting page metadata All guides

Put this into practice.

Every URLpipe endpoint 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. 50 AI + 500 web operations a month, no card.

Start free Email the team