A performance budget on every pull request

Everyone agrees a site should be fast, and it still gets slower, one handy dependency at a time. Reminding people in review doesn’t fix that, so I made the pipeline check it.

Every pull request on driftpilot.ca runs Lighthouse CI three times against a production build and checks the median run against the budget. A failure turns the pull request red. GitHub doesn’t stop a merge on red, but every pull request merged since the check went in has passed it.

The gate caught three things review missed: a WebGL shader path that hit 39 seconds of total blocking time on software renderers, a footer colour pair below the WCAG contrast minimum, and a third-party scheduling embed that pushed the script weight over budget without anyone noticing.

I did move one budget. The original 110 kB script ceiling was never realistic once the framework and the shader measured 237 kB together, so I raised it to 260 kB on purpose and wrote down why. That’s the line I hold: a measurement can justify moving a threshold, but deleting a failing check to get a green build can’t.

The site is 37 statically prerendered routes with no runtime database. Content sits behind typed async accessors, so a headless CMS could take over as the source without touching a page or component.

Leads go through Zod-validated Server Actions, then honeypot and time-to-submit spam checks, then a CRM webhook. The original build came in over 73 commits across 27 merged pull requests, and in it the webhook got one retry: if both attempts failed, the visitor still saw the thank-you page and the lead was lost. I fixed that in September. The webhook now gets up to three attempts within ten seconds. A lead that still fails goes in full to a Slack channel, and the visitor sees the failure with an email link that has their answers filled in. The site’s first tests cover that path and run in CI.