Lighthouse is Google's open-source auditing tool that automatically scores a web page on performance, accessibility, best practices and SEO. Yet most people glance at that round performance score and panic. The score is only a summary of the real story. In this article I'll show you how to actually read the report, which metrics truly shape the user experience, and how to fix the bottlenecks you find, step by step.
How to run a Lighthouse report
There are several ways to reach Lighthouse; the right move is to pick the one that fits your use case:
- Chrome DevTools > Lighthouse tab: fast, visual and runs locally. The catch is that your machine's CPU and network affect the result.
- PageSpeed Insights (pagespeed.web.dev): uses the same engine but runs on Google's servers and also surfaces real-user data (CrUX / Field Data).
- CLI: ideal for automation. The command
npx lighthouse https://aslain.dev --viewgenerates the report and opens it in the browser.
One key point: always measure in an incognito window with extensions disabled. Ad blockers and other add-ons inject code into the page and skew the score. Don't trust a single measurement either; performance is variable, so run it 3-5 times and look at the median.
Lab data or field data?
Lighthouse offers two kinds of data, and mixing them up is the most common mistake. Lab data (DevTools/Lighthouse) measures a single load in a controlled, simulated environment; it's repeatable but artificial. Field data (Core Web Vitals) is anonymized measurements collected from Chrome for users who actually visited your site over the last 28 days. Field data is what Google considers for ranking. So even if your lab score is 100, poor field data means the real problem is still unsolved.
Which metrics matter: LCP, CLS and TBT
The performance score is a weighted average; these metrics contribute the most:
- LCP (Largest Contentful Paint): how long the largest element in the viewport (usually the hero image or heading) takes to render. Target: under
2.5 s. - CLS (Cumulative Layout Shift): unexpected movement of elements while the page loads. Target: under
0.1. - TBT (Total Blocking Time): how long the main thread is blocked from user interaction by JavaScript. Its field counterpart is INP. Target: under
200 ms. - FCP and Speed Index: the speed of first content and visual completeness.
Read the color next to each metric (green/orange/red) together with the "Opportunities" and "Diagnostics" sections. It's these items, not the score itself, that tell you what to do.
Fixing the LCP bottleneck
LCP usually stems from a large image or a late-loading web font. Practical steps:
- Convert the hero image to a modern format (WebP/AVIF) and serve it at the right size. Don't ship a 3000px-wide image into an 800px slot.
- Give the browser a hint so it discovers the critical image early:
<link rel="preload" as="image"
href="/img/hero.avif"
fetchpriority="high">For fonts, use font-display: swap so text doesn't stay invisible while the font downloads. Server response time (TTFB) directly affects LCP too; cache heavy queries and use a CDN where possible. These few items usually have a big impact, but the order varies per site — open the LCP element the report points to and find the real cause.
Lowering CLS and TBT
For CLS the golden rule is: reserve space for every element up front. Add width and height attributes to images (the browser computes the ratio and reserves space), give ad/embed slots a fixed height, and avoid late banners that push content down. To reduce shift caused by web fonts, size-adjust and a matched fallback font help.
TBT is almost always JavaScript overload. What to do:
- Strip out unused JS; take the "Reduce unused JavaScript" warning seriously.
- Load third-party scripts (analytics, chat, ads) with
asyncordefer, and defer them until after interaction when possible. - Break large bundles apart with code splitting; ship only the code each page needs.
<script src="/js/app.js" defer></script>
<script src="https://analytics.example.com/s.js" async></script>Making the audit a habit
Performance isn't a one-off task; every deploy can introduce a new image or script that causes a regression. So add Lighthouse to your CI pipeline. With Lighthouse CI you can set budgets on every pull request and break the build if the score drops. That way "why did the site get slower?" is answered during code review, before a user complains. Instead of chasing the score, chase the user: test on real devices under real network conditions.
Frequently Asked Questions
Why does my Lighthouse score change every time?
Because the lab measurement is affected by your machine's current CPU load, network conditions and background processes. That's why taking 3-5 measurements in an incognito window and using the median is far healthier than trusting a single score.
Do I have to hit 100?
No. 100 is a nice goal, but what really matters is passing the Core Web Vitals thresholds (LCP < 2.5 s, CLS < 0.1, INP < 200 ms) in field data. A site scoring 92 with "good" field data beats a 99-scoring site with poor field data.
Why are mobile and desktop scores so different?
Lighthouse simulates a slow device and a throttled network in the mobile test. Since most of your users come from mobile, you should improve the mobile score first.
Want to take your site's performance seriously? We can read your Lighthouse report together and fix the LCP, CLS and TBT bottlenecks for good. Get in touch and let's start your site's speed analysis.