Understanding Lighthouse Performance Scores | PageSpeed Analyzer

Master Google Lighthouse scoring methodology, understand what metrics impact your score, and learn proven strategies to achieve a 90+ performance score.

What is Lighthouse?

Lighthouse is an open-source, automated tool developed by Google for improving web page quality. It runs audits for performance, accessibility, progressive web apps, SEO, and best practices.

Where to Run Lighthouse

Chrome DevTools: Built into Chrome browser (F12 → Lighthouse tab)
PageSpeed Insights: Google's web interface with field data
Lighthouse CI: Automated testing in CI/CD pipelines
Command Line: npm install -g lighthouse

How Lighthouse Performance Score is Calculated

The performance score is a weighted average of 6 key metrics. Each metric is scored from 0-100, then combined using specific weights.

Metric Weights (Lighthouse 10+)

First Contentful Paint (FCP)

When first content appears

10%

Largest Contentful Paint (LCP)

When main content loads

25%

Total Blocking Time (TBT)

Time main thread is blocked

30%

Cumulative Layout Shift (CLS)

Visual stability

25%

Speed Index

How quickly content renders

10%

Note: TBT (30%) and LCP (25%) have the highest impact on your score. Focus optimization efforts here for the biggest improvements.

Lighthouse Score Ranges

90-100

Good

Excellent performance. Site delivers a fast, smooth user experience. Continue monitoring to maintain this score.

50-89

Needs Improvement

Room for optimization. Focus on metrics with the lowest scores. Follow Lighthouse recommendations.

0-49

Poor

Critical performance issues. Users likely experiencing slow load times. Immediate optimization required.

Understanding the 6 Key Metrics

1. First Contentful Paint (FCP) - 10% weight

Measures when the first text or image appears on screen. Good FCP creates perception of fast loading.

Good

< 1.8s

Needs Work

1.8s - 3s

Poor

> 3s

How to improve:

• Eliminate render-blocking resources
• Inline critical CSS
• Use font-display: swap
• Minimize server response time

2. Largest Contentful Paint (LCP) - 25% weight

Measures when the largest visible element (hero image, heading) loads. Most important Core Web Vital.

Good

< 2.5s

Needs Work

2.5s - 4s

Poor

> 4s

How to improve:

• Preload hero images with <link rel="preload">
• Optimize images (WebP, responsive sizing)
• Use a CDN for faster delivery
• Reduce JavaScript execution time

3. Total Blocking Time (TBT) - 30% weight

Sum of time the main thread is blocked from responding to user input. Highest impact on score.

Good

< 200ms

Needs Work

200ms - 600ms

Poor

> 600ms

How to improve:

• Code split and lazy load JavaScript
• Remove unused JavaScript
• Minimize third-party script impact
• Use web workers for heavy computations

4. Cumulative Layout Shift (CLS) - 25% weight

Measures visual stability. Unexpected layout shifts frustrate users and hurt conversions.

Good

< 0.1

Needs Work

0.1 - 0.25

Poor

> 0.25

How to improve:

• Always specify width/height for images and videos
• Reserve space for ads and embeds
• Use CSS aspect-ratio for dynamic content
• Avoid inserting content above existing content

5. Speed Index - 10% weight

Measures how quickly content is visually displayed during page load. Lower is better.

Good

< 3.4s

Needs Work

3.4s - 5.8s

Poor

> 5.8s

How to improve:

• Optimize above-the-fold content delivery
• Minimize main-thread work
• Reduce JavaScript execution time
• Lazy load below-the-fold images

Common Issues That Lower Scores

⚠️ Large JavaScript Bundles

Single biggest cause of low scores. Large JS files increase TBT and delay interactivity.

javascript

// Use code splitting to reduce bundle size
const HeavyComponent = lazy(() => import('./HeavyComponent'));

// Dynamic imports for route-based splitting
const route = await import(`./routes/${routeName}`);

⚠️ Unoptimized Images

Large images hurt LCP and overall page weight. Always optimize and use modern formats.

html

<!-- Use modern formats with fallback -->
<picture>
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Hero" width="1200" height="600" loading="lazy" />
</picture>

<!-- Preload critical hero image -->
<link rel="preload" href="hero.webp" as="image" />

⚠️ Render-Blocking Resources

CSS and JavaScript that blocks rendering delays FCP and LCP.

html

<!-- Inline critical CSS in <head> -->
<style>
  /* Critical CSS for above-the-fold content */
  body { margin: 0; font-family: sans-serif; }
</style>

<!-- Load non-critical CSS asynchronously -->
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'" />

<!-- Defer non-critical JavaScript -->
<script src="app.js" defer></script>

⚠️ Third-Party Scripts

Analytics, ads, and social widgets can significantly impact TBT.

html

<!-- Load third-party scripts with defer or async -->
<script src="https://analytics.example.com/script.js" defer></script>

<!-- Delay non-essential scripts until after page load -->
<script>
  window.addEventListener('load', () => {
    // Load non-essential scripts
    loadScript('https://chat.example.com/widget.js');
  });
</script>

How to Achieve a 90+ Score

Proven Optimization Strategy

1. Reduce JavaScript execution time (30% weight)
- • Code split by route and component
- • Remove unused JavaScript
- • Defer non-critical scripts
- • Target: <200KB total JS (gzipped)
2. Optimize Largest Contentful Paint (25% weight)
- • Preload hero images
- • Use WebP/AVIF formats
- • Implement responsive images
- • Target: <2.5s LCP
3. Fix Layout Shifts (25% weight)
- • Set explicit width/height on all images
- • Reserve space for dynamic content
- • Use CSS aspect-ratio
- • Target: <0.1 CLS
4. Eliminate Render-Blocking Resources
- • Inline critical CSS
- • Defer non-critical CSS
- • Use font-display: swap
- • Remove unused CSS
5. Test Regularly
- • Run Lighthouse after each deployment
- • Test on mobile (slower devices)
- • Use "Slow 4G" throttling
- • Set up Lighthouse CI for automated checks

Lab Data vs. Field Data

Lab Data (Lighthouse)

Controlled, simulated environment with consistent conditions.

✓ Consistent, reproducible results
✓ Useful for debugging specific issues
✓ Available before deployment
✗ May not reflect real user experience
✗ Single network/device configuration

Field Data (CrUX)

Real user measurements from Chrome users worldwide.

✓ Reflects actual user experience
✓ Used by Google for ranking
✓ Shows performance across devices
✗ Requires 28 days of data
✗ Can't debug specific issues

Best Practice: Use Lab data to identify and fix issues during development. Monitor Field data to verify real-world improvements and track user experience over time.

Test Your Lighthouse Score

Get a detailed Lighthouse performance report with AI-powered recommendations to improve your score and Core Web Vitals.

Analyze Your Performance