[jbspeakr]

Why

283 CI runs in the last 30 days at ~8.6 minutes each. The repository is public, so this costs no quota, but 5.8 of those minutes are Lighthouse — 12 URLs × 3 runs — sitting at the end of the job behind the end-to-end tests, so every pull request waits almost nine minutes for a verdict that is mostly available after three.

What changes

• Lighthouse gets its own job that builds the site itself (seconds) and runs in parallel with the checks. Expected wall time for a pull request: ~3 minutes instead of ~8.6.
• Pull requests audit each URL once; main keeps three runs. Main's scores become the commit status and gate the site and scanner deploys, so the noise tolerance stays where a flaky failure would hurt. On pull requests a borderline score shows up as a single failing run that a push can retry.
• Playwright's Chromium is cached on the lockfile in ci.yml and screenshots.yml. The lockfile pins the Playwright version and with it the Chromium build the screenshot baselines depend on, so a cache hit can never hand a test a different browser than a fresh install would. A hit skips the download and the apt run of --with-deps (~0.6 min per run).
• docs/development.md describes the new shape.

Check names

The checks job keeps its name (Validate, lint, test, build). The new job is Lighthouse budgets; if main has a required-checks rule, it may want adding there. Both deploy workflows trigger on the CI workflow conclusion, which covers both jobs, so nothing changes for them.

---

Generated by Claude Code