How to Read a Lighthouse Report

Open a Lighthouse report and you're hit with scores, metrics, opportunities, diagnostics, passed audits, screenshots, and a filmstrip. It's a lot. This guide walks through every section and tells you what to look at first.

Section 1: The four scores

At the top, four big circular scores from 0–100:

• Performance — loading speed and Core Web Vitals
• Accessibility — automated WCAG checks
• Best Practices — security, modern APIs, console hygiene
• SEO — technical SEO basics

Color coding:

• 90–100: green (good)
• 50–89: orange (needs improvement)
• 0–49: red (poor)

What to do: Start with Performance — it's the hardest to improve and the most impactful for both UX and SEO. SEO and Accessibility should be easy 95+s once you've fixed the basics. Best Practices is usually quick wins.

Section 2: Metrics

Below the Performance score, you'll see six metrics with their actual measured values:

First Contentful Paint (FCP)

Time until anything visible appears. Good ≤ 1.8s. If this is slow, your CSS or hosting is the bottleneck.

Largest Contentful Paint (LCP)

Time until the biggest visible element loads. Good ≤ 2.5s. Usually a hero image or H1. See LCP explained.

Total Blocking Time (TBT)

Total time the main thread was blocked > 50ms during load. Good ≤ 200ms. This is the lab-only proxy for INP. Cut JavaScript to fix.

Cumulative Layout Shift (CLS)

Sum of unexpected layout shifts. Good ≤ 0.1. Almost always caused by images without dimensions or late-loading content. See CLS explained.

Speed Index

How quickly visible content fills the viewport, frame by frame. Good ≤ 3.4s.

Time to Interactive (TTI)

When the page becomes reliably interactive. Less emphasized in modern Lighthouse.

What to do: Find the red ones. Each metric has dedicated fixes. Don't be distracted by green metrics — they're already good.

Section 3: Screenshots and filmstrip

Lighthouse captures screenshots throughout the load and shows you a filmstrip. This is incredibly useful for seeing what slow looks like.

Look for:

• A long stretch of blank screens — your CSS or hosting is slow
• Hero image appearing late — LCP problem
• Content jumping — CLS problem
• Spinner that lingers — JavaScript-bound bottleneck

What to do: Use this to confirm what the metrics tell you. Sometimes a "passing" score still looks bad to humans.

Section 4: Opportunities

This is the most actionable section. Each opportunity is a specific change you can make, with an estimated time savings.

Common opportunities:

• Properly size images — your images are bigger than they display
• Serve images in next-gen formats — switch to WebP/AVIF
• Reduce unused JavaScript — code split, defer, or remove
• Reduce unused CSS — purge with PurgeCSS, etc.
• Eliminate render-blocking resources — defer non-critical CSS/JS
• Preload key requests — preload your LCP image, critical fonts
• Avoid enormous network payloads — total page weight is too high
• Properly size images — image dimensions exceed display size

What to do: Sort by estimated savings (Lighthouse does this for you). Tackle the top 3. Each typically yields a 3–10 point score gain.

Section 5: Diagnostics

Observations about your page that may or may not need action. They don't have estimated savings but provide context.

Common diagnostics:

• Avoid an excessive DOM size — over ~1500 nodes hurts rendering
• Avoid chaining critical requests — a long chain of dependent resources
• Largest Contentful Paint element — shows exactly what your LCP element is
• Avoid large layout shifts — lists elements that caused CLS, with screenshots
• JavaScript execution time — total ms spent running JS
• Minimize main-thread work — breakdown of what kept the CPU busy
• Reduce the impact of third-party code — which third parties cost the most

What to do: Use these for diagnosis. The "Largest Contentful Paint element" and "Avoid large layout shifts" diagnostics in particular tell you exactly what to fix.

Section 6: Passed audits

What you did right. Mostly informational, but skim it — you may discover an audit you didn't know existed.

What to do: Glance for things flagged as "Passed with warnings" — those are at risk of failing on a future run.

Section 7: Accessibility section

Each accessibility check either passes or fails. Failures show the specific elements that caused them with code snippets.

Common failures:

• Background and foreground colors don't have a sufficient contrast ratio
• Image elements do not have [alt] attributes
• Buttons do not have an accessible name
• Heading elements are not in sequential descending order
• Form elements do not have associated labels

What to do: Fix each one. Most are 5-minute changes. Aim for 100. Remember Lighthouse only catches about 30% of accessibility issues — see website accessibility score explained.

Section 8: Best Practices section

Pass/fail checks for modern web hygiene. See best practices score explained.

Common failures:

• Console errors
• Browser deprecation warnings
• Missing security headers
• Vulnerable JavaScript libraries

What to do: Open DevTools, watch console during page load, fix every error. Update dependencies. Add a Content Security Policy.

Section 9: SEO section

Pass/fail checks for technical SEO. See what is a good SEO score.

Common failures:

• Missing meta description
• Missing <title>
• Page blocked from indexing (often unintentional)
• Tap targets too small

What to do: Should be 100. Fixing failures here takes minutes.

Lab data vs field data

If you're running through PageSpeed Insights (not Lighthouse directly), you'll also see field data at the top:

• This is real-user data from the Chrome User Experience Report
• It's what Google uses for SEO ranking
• It updates with a 28-day rolling window

If lab data is great but field data is bad, real users are experiencing problems your audit can't reproduce — maybe slow CDN edges, specific device classes, or geography.

If lab is bad but field is great, your audit is testing a different version of your site than real users see.

Common report misreadings

"My score went down after making changes!"

Single audits have ~5 point variance. Run 3–5 times and average. Don't react to a single run.

"Lighthouse says my hero image needs to be 800px wide but it looks fine at 2000px on retina"

You can serve 2× the displayed size for retina via srcset. The Lighthouse savings estimate accounts for this.

"It says reduce JavaScript by 200KB but I need all of it"

You probably don't. Use Coverage tab in DevTools to see what's actually executed on the page. Most sites discover they ship 50% unused code.

"I have a 100 score but the site feels slow"

Field data probably tells a different story. Or your INP is bad (Lighthouse only measures INP in field data, not lab). Run a real-user test.

The 80/20 way to read a report

1. Look at the four scores. Identify the worst.
2. Scroll to Opportunities. Read the top 3.
3. Fix those. Re-run.
4. Repeat until satisfied.

You don't need to fix every flagged issue. Most "Diagnostics" are informational. Some "Opportunities" have trivial gains.

The bottom line

A Lighthouse report is a debugging tool. Use the screenshots to see what's slow, the metrics to know what's slow, and the opportunities to know how to fix it. Skip the rest.

Run a free audit to see your own report — we add letter grades and plain-English insights on top of the raw Lighthouse data.

For more, see what PageSpeed Insights actually checks and how Google measures website performance.