notes
Jun 29, 2025 · 1 min read

Making Lighthouse Part of the Build, Not an Afterthought

I used to run Lighthouse the way most people probably do: open DevTools, click the button, glance at the score, close the tab. It caught regressions eventually, in the sense that I’d eventually notice a page felt slower and go looking for why. “Eventually” is not a great regression detection strategy.

Making it a gate, not a habit

Lighthouse CI runs the same audits against the actual built output, on every pull request, and fails the check if a score drops below a threshold I set — 90, across performance, accessibility, best practices, and SEO. That turns a habit I had to remember to do into a gate I can’t skip past without noticing.

The first time it actually caught something was almost immediate: a hero image I’d added without dimensions, which Lighthouse flagged as a layout shift risk before I’d even opened the preview deploy myself. Manually, I probably wouldn’t have run a Lighthouse audit on that specific PR — it was “just adding an image,” the kind of change that doesn’t feel worth a manual performance check.

What changed about how I write changes

Knowing the gate exists changed the way I write CSS and markup a little, in a good way. I think about whether an image has explicit dimensions before I ship it, not after Lighthouse tells me it doesn’t, because I know the check is coming either way. The gate isn’t really there to catch mistakes — it’s there so I don’t have to hold “did I remember to check performance” in my head on every single change.