A Practical Guide to Lighthouse in Continuous Integration
Running Lighthouse automatically on each build so performance and accessibility regressions are caught before release.
Marcus Adeyemi
What is at stake
Performance work decays without automation, and CI checks make regressions visible when they are cheap to fix.
The playbook
- Run audits on key page templates
- Set budgets based on current performance
- Run several times and use medians
- Treat accessibility audits as a floor, not proof
- Review trends rather than single scores
Where it goes wrong
Avoid:
- Failing builds on noisy single runs
- Chasing a perfect score
- Auditing only the homepage
- Assuming automated checks cover accessibility
The numbers behind it
| Measure | Figure |
|---|---|
| Lighthouse CI | runs audits as part of a build pipeline |
| Budgets | builds can fail when metrics exceed limits |
| Variance | lab results vary between runs |
| Scope | Lighthouse tests pages, not whole user journeys |
Getting outside help
When to hand it over: Bring in help when performance regressions keep returning.
Where this comes from
- Chrome for Developers — Lighthouse CI
- web.dev — Performance budgets
The figures and practices above come from the sources listed.
Working on something like this?
We take on Performance & Accessibility work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
