Lighthouse Performance Audits — Complete Optimization Guide
In this tutorial, you will learn how to run Lighthouse performance audits, interpret the results, and systematically fix each diagnostic finding. Lighthouse is an automated auditing tool built into Chrome that scores pages on performance, Accessibility, best practices, SEO, and Progressive Web App readiness. DodaTech uses Lighthouse as the primary gate in its CI/CD pipeline to prevent performance regressions before deployment.
What You Will Learn
- How to run Lighthouse from Chrome DevTools, CLI, and Node.js API
- How to interpret performance scores and opportunity estimates
- How to fix the most common audit failures step by step
- How to integrate Lighthouse into a CI/CD pipeline for automated performance checks
Why It Matters
A poor Lighthouse score directly correlates with lower search rankings and higher bounce rates. Doda Browser users expect pages to load in under two seconds. By using Lighthouse audits proactively, the DodaTech engineering team catches slowdowns before they reach production.
Real-World Use Case
The DodaZIP landing page scored 54 on mobile performance. After addressing the three highest-impact opportunities, the score jumped to 88 and the conversion rate increased by 15 percent within one month.
Prerequisites
You should be comfortable with Chrome DevTools and understand HTML and CSS fundamentals. Previous experience with Core Web Vitals is helpful.
Step-by-Step Tutorial
Step 1: Run a Lighthouse Report
Open Chrome DevTools, navigate to the Lighthouse tab, select the Mobile device option, check the Performance category, and click Generate Report. Wait 15 to 30 seconds for the audit to complete.
You will see a score from 0 to 100 with color coding: red (0-49), orange (50-89), and green (90-100). Below the score, Lighthouse lists opportunities, diagnostics, and passed audits.
# Run Lighthouse from the CLI
npx lighthouse https://example.com --view --preset=desktop
Expected output: A report opens in the browser with performance scores and a list of actionable opportunities.
Step 2: Understand the Metrics Section
The metrics section shows LCP, TBT, CLS, Speed Index, and Time to Interactive. Each metric has a target range and a line graph showing how it changed during page load.
Focus on the metrics that are in the red or orange range. These are your biggest opportunities for improvement.
Step 3: Analyze Opportunities
Opportunities are specific, actionable recommendations with estimated time savings. Each opportunity shows how many milliseconds you could save by implementing the fix.
Common opportunities include:
- Serve images in next-gen formats (saves up to 60 percent of image weight)
- Remove render-blocking resources (saves 200-500ms on first paint)
- Preload key requests
- Reduce unused JavaScript (saves 100-300ms)
// Example: Check unused bytes with the Coverage tool
// Open DevTools > Coverage > Reload the page
// Red bars indicate unused code paths
Step 4: Fix the Top Opportunity
Start with the opportunity that saves the most time. For most sites this is image optimization. Convert JPEG and PNG images to WebP format with appropriate quality settings.
# Convert images to WebP using cwebp
cwebp -q 80 hero.jpg -o hero.webp
Expected result: Lighthouse re-audit shows the image opportunity resolved and the performance score increases.
Step 5: Eliminate Render-Blocking Resources
Lighthouse identifies CSS and JavaScript files that block the first paint. Inline critical CSS in the <head> and defer non-critical stylesheets.
<!-- Before: render-blocking CSS link -->
<link rel="stylesheet" href="styles.css" />
<!-- After: inlined critical CSS + preloaded non-critical -->
<style>
/* Critical above-the-fold CSS inlined here */
body { font-family: sans-serif; margin: 0; }
</style>
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'" />
Step 6: Reduce Unused JavaScript
Use the Coverage tool to find JavaScript that is loaded but never executed during page load. Remove or defer these scripts.
// Use dynamic imports to load non-critical modules on demand
import('./analytics.js').then(module => {
module.init();
});
Step 7: Implement Proper Sizing
Ensure images are rendered at the correct size. Lighthouse reports improperly sized images that waste bandwidth.
<!-- Before: oversized image -->
<img src="4000x3000.jpg" style="width:800px" />
<!-- After: properly sized image -->
<img src="800x600.jpg" style="width:800px" />
Step 8: Set Up CI/CD Integration
Add Lighthouse CI to your GitHub Actions workflow to prevent performance regressions.
# .github/workflows/lighthouse.yml
name: Lighthouse CI
on: [pull_request]
jobs:
lighthouse:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Lighthouse
uses: treosh/lighthouse-ci-action@v10
with:
urls: |
https://staging.example.com
budgetPath: ./lighthouse-budget.json
Expected output: The PR check passes or fails based on the performance budget defined in lighthouse-budget.json.
Learning Path
flowchart LR A[Core Web Vitals] --> B[Lighthouse Audits] B --> C[Performance Budgets] B --> D[Bundle Optimization] C --> E[CI/CD Integration] D --> F[Critical Rendering Path] style B fill:#4f46e5,color:#fff style A fill:#6366f1,color:#fff style C fill:#6366f1,color:#fff
Common Errors
Testing on localhost without throttling: Lighthouse scores on a local development server are misleading. Always use the mobile preset with simulated throttling.
Ignoring the diagnostics section: Opportunities show quick wins, but diagnostics like excessive DOM size and long tasks have a compounding negative effect.
Chasing a perfect 100 score: A perfect score is often not achievable or maintainable. Focus on reaching 90+ for mobile and desktop while delivering real value.
Running only one audit: Network conditions vary. Run three audits and take the median score for a reliable baseline.
Fixing opportunities without measuring impact: Apply one change at a time and re-audit. Some changes may not improve the user experience even if Lighthouse marks them resolved.
Caching artifacts between audits: Always incognito or clear cache before running an audit to simulate a first-time visitor experience.
Practice Questions
- What are the five categories Lighthouse audits?
- What is the difference between an opportunity and a diagnostic?
- How can you run Lighthouse from the command line?
- Why should you test with mobile throttling enabled?
- What is a performance budget and how does Lighthouse CI enforce it?
Answers: 1. Performance, Accessibility, Best Practices, SEO, Progressive Web App. 2. An opportunity provides estimated time savings; a diagnostic provides insights without time estimates. 3. Use the npx lighthouse <url> command. 4. Mobile devices have less CPU power and slower networks, representing a worst-case scenario. 5. A performance budget sets maximum thresholds for metrics like LCP and bundle size; Lighthouse CI fails a build if the budget is exceeded.
Challenge
Set up a Lighthouse CI pipeline for a sample site with a performance budget of LCP under 2.5 seconds and TBT under 200 milliseconds. Write a budget JSON file and configure GitHub Actions to run Lighthouse on every pull request.
FAQ
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro