WP Performance Budget Action
TYPESCRIPT · GITHUB ACTION
Performance work decays the moment it stops being measured. This is a CLI and GitHub Action that turns a declared budget into a pass/fail check on every pull request, so a regression is caught in review rather than after launch.
- Maintainer
- Pixy Puala
- Vertical
- Web performance · CI tooling
- Year
- 2026
- Role
- Open source
- Stack
- TypeScript
- Status
- ● Public repo
- Verified
- Source on GitHub
Problem
WordPress teams run Lighthouse once, screenshot the score, and ship. Three plugins later the score is gone and nobody can say which change caused it. A budget only works if something enforces it automatically on every change.
Constraints
Decisions
Injected HTTP client, fully offline tests
The Lighthouse parser, evaluator, formatter and comment poster are pure and injectable, so the entire pipeline is unit-tested without network access or a GitHub token.
PASS/FAIL is always in text
Status is never signalled by colour alone. A CI report that only a sighted user can read is an accessibility defect in a tool that claims to care about quality.
Update the comment, do not spam the PR
The action edits its existing comment instead of appending a new one per push, so the PR stays readable across a long review.
Build
Stack
- ▸ TypeScript · Node 20+ · pnpm
- ▸ Lighthouse JSON parsing
- ▸ Composite GitHub Action (action.yml)
- ▸ Injected HTTP client for testability
- ▸ Vitest · example workflow included
Tooling
- ✓ kept pnpm · Vitest · GitHub Actions
Results · Measured
A live Lighthouse run (v12.8.2, headless Chrome) against a real WordPress site with both exit codes is recorded in docs/RUNTIME-VERIFICATION.md, alongside a runnable example workflow.
Tradeoffs
The Lighthouse seam and the GitHub-API seam are each proven, but not yet together on a genuine pull request with pull-requests: write. Until that run exists, the PR-comment path is unit-tested rather than field-proven, and it is described that way.