How to Read a Lighthouse Report and Fix the Issues

What a Lighthouse report actually tells you

Lighthouse is an automated audit built into Chrome DevTools. It loads your page in a simulated environment and grades it in four categories: Performance, Accessibility, Best Practices and SEO. Each category gets a score from 0 to 100, but the useful part is underneath: the metrics and the list of failed audits with concrete elements and files.

The key thing to remember: Lighthouse produces lab data. It is one load, on one simulated device, at one moment. Real users are measured by field data (for example, the Chrome UX Report shown in PageSpeed Insights). Use Lighthouse to find causes, and field data to confirm that real users got faster.

Performance: the metrics that matter

The Performance score is a weighted mix of several metrics:

Below the metrics you will find Opportunities (estimated savings) and Diagnostics (details). The most common audits:

• Properly size images / Serve images in next-gen formats — convert to WebP or AVIF and use srcset.
• Eliminate render-blocking resources — inline critical CSS, add defer to scripts.
• Reduce unused JavaScript — split code, remove unused libraries.
• Largest Contentful Paint image was lazily loaded — never lazy-load the hero image.
• Avoid an excessive DOM size — simplify heavy lists and nested wrappers.

Accessibility, Best Practices and SEO

These categories are mostly pass/fail checklists, so they are easier to bring close to 100.

• Accessibility: low color contrast, images without alt, buttons and links without accessible names, form fields without labels, wrong heading order. Note that automated checks catch only part of real accessibility problems; keyboard and screen reader testing is still needed.
• Best Practices: errors in the console, mixed HTTP/HTTPS content, deprecated APIs, images with the wrong aspect ratio, libraries with known vulnerabilities.
• SEO: missing title or meta description, page blocked by robots.txt or noindex, links without descriptive text, tap targets too small, no lang attribute.

Why the score changes between runs

It is normal to see different numbers on the same page. The reasons:

• Browser extensions inject scripts and slow the page.
• Your machine is busy — other tabs, builds, video calls.
• Network and server variability — cold caches, CDN routing, A/B tests, ads.
• Throttling is simulated, so small differences in timing get amplified.

How to run it correctly

1. Open the page in an Incognito window or a clean Chrome profile without extensions.
2. Test the production build, not the dev server — dev mode is much slower by design.
3. Choose Mobile as the main target; it is stricter and closer to most real visitors.
4. Run 3-5 times and look at the median, not the best result.
5. For CI, use Lighthouse CI with performance budgets so regressions are caught before release.

Which fixes give the biggest real improvement

Prioritize by impact on real users, not by the size of the "savings" number:

1. Optimize the LCP element: compress the hero image, serve the right size, add fetchpriority="high" and preload it if it is discovered late.
2. Cut JavaScript: remove unused dependencies, load third-party widgets (chats, analytics, maps) after interaction or with defer.
3. Reserve space for everything: set width/height or aspect-ratio on images and embeds, use font-display: swap with similar fallback fonts.
4. Speed up the server response: caching, CDN, fewer redirects.
5. Fix accessibility and SEO audits — usually quick wins that are fully under your control.

<img src="/hero-1200.webp"
     srcset="/hero-600.webp 600w, /hero-1200.webp 1200w"
     sizes="100vw" width="1200" height="600"
     fetchpriority="high" alt="Product dashboard">

Common mistakes

• Chasing a perfect 100 instead of improving field metrics.
• Testing only the home page while users land on product or article pages.
• Lazy-loading everything, including the image above the fold.
• Comparing desktop and mobile scores as if they were the same test.