Performance budget gates in GitHub Actions are free until someone owns twelve client workflows, Chrome drift, and client reporting. How agencies split Lighthouse CI from managed PageSpeed monitoring.
The Slack thread started with a screenshot of a green GitHub Actions run. By the third reply someone had pasted a Lighthouse JSON artefact, a link to a Chrome release note, and a question nobody wanted to own: "Which client repository still pins Lighthouse 10?"
That is the week Lighthouse CI stopped being a merge gate and became a second job. The pipeline still passed and the portfolio still needed evidence, but the difference was who paid in hours: the developer shipping a feature, or the one person who inherited every lighthouserc file across client repositories.
When does Lighthouse CI maintenance outgrow a CI/CD pipeline?
Lighthouse CI earns its place early. You wire assertions on a preview URL, block a CLS regression, and the team trusts the red build. The cost is front-loaded configuration, not ongoing calendar time.
The shift happens when success creates obligations a CI/CD pipeline was never designed to carry:
- Every new client repository needs a copied workflow, pinned Chrome, and preview URL rules that match their host.
- Assertions need tuning after flaky LCP on cold runners, so thresholds loosen until they barely catch real regressions.
- Account managers ask for client-ready reports, and the only export is a CI/CD artefact someone must turn into slides.
- Production URLs outside the two preview paths regress while the job stays green.
At that point you are not "running Lighthouse CI in a pipeline." You are operating a small internal product: version pins, runner hygiene, assertion policy, and reporting glue. For a single product team that can be fine. For an agency portfolio it competes with billable delivery.
How do you know Lighthouse CI in CI/CD became an unpaid side role?
We treat these as signals to shrink CI/CD scope or add a managed monitoring layer, not as moral failure. Teams hit them around five to fifteen client sites, sometimes sooner when preview hosts differ wildly.
Flaky Lighthouse CI runs on GitHub Actions
Engineers merge after the third "Re-run failed jobs" click because INP moved six points on a shared runner. When the gate is noise, people route around it.
@lhci/cli and Lighthouse version drift across repositories
One repository uses @lhci/cli 0.13, another 0.14, Lighthouse 11 on one client and 10 on another. Nobody can say which assertion set is authoritative without opening six pull requests.
Preview URL versus production: green CI/CD, red PageSpeed Insights
The CI/CD job guards / on a Netlify preview while production serves /checkout from a different CDN rule. Sponsors see red on PageSpeed Insights; developers point at a green pipeline run and both sides are partially right.
Monthly retainers need a short narrative: which URLs broke budget, when, and what changed. If the answer lives in downloaded JSON and a manual chart, someone is doing monitoring work outside the pipeline, unpaid.
One engineer as the default Lighthouse CI maintainer
One senior developer becomes "the Lighthouse person," fixes workflows between client calls, and resents every Chrome update. That is a job description, not a YAML tweak.
If three or more patterns sound familiar, Lighthouse CI is already a second job. The fix is not deleting the pipeline check. It is deciding which hours belong in merge protection and which belong in scheduled monitoring with client-ready output.
We keep the CI/CD slice thin on purpose. Merge protection should answer a narrow question: did this candidate build break budgets on the one or two preview URLs we trust for this repository?
Keep as errors when the check is stable and the developer on the pull request can fix the cause:
- CLS on in-scope templates where layout is the likely regression.
- Bundle or script byte ceilings when the build exposes an artefact.
- Total blocking time or main-thread proxies when the change touches JavaScript entry points.
Warn, do not block, when preview parity is weak: cold CDN LCP, ads on staging, INP without enough repetitions to trust a median.
Do not ask CI/CD to replace production monitoring: field CrUX exports, full sitemap crawls, rank proxies, or every revenue template on every docs-only commit. Those checks belong on a schedule against production URLs, with alerts that account managers can forward.
The wiring patterns, assertion keys, and GitHub Actions sketch live in our step-by-step guide: How to set up performance budgets in CI/CD pipelines. Use that guide to implement a small gate; use the criteria above to decide how small.
Lighthouse CI versus managed monitoring: why agencies hit build-versus-buy pressure early
Lighthouse CI is open source and runner-native, which makes it the default first step. Managed PageSpeed monitoring adds invoice line items, which makes teams delay the decision until the hidden invoice arrives: senior hours spent keeping workflows honest.
The build path scales poorly across repositories because CI/CD is repository-centric and agencies are portfolio-centric. Copying configuration per client multiplies drift. Preview URL changes when a client moves hosts. Authentication on staging breaks collection until someone scripts login. Each exception lands on the same maintainer.
The buy path trades some control for repetition: scheduled lab runs across many URLs, history, thresholds shared with client reports, and alerts when production templates cross budget. It does not replace merge gates on preview; it absorbs the work a pipeline should never have carried: full URL lists, post-deploy cadence, and evidence sponsors can read without terminal access.
We wrote the comparison for agency leads evaluating that trade explicitly: Lighthouse CI versus managed monitoring: build versus buy for agencies. The headline question is not "free versus paid." It is whether your team wants to operate monitoring infrastructure or operate client sites.
How to shrink Lighthouse CI scope in CI/CD pipelines without losing merge protection
When CI/CD became a second job for us, the recovery plan had four moves. None required removing Lighthouse from the pipeline entirely.
Limit Lighthouse CI to two preview URLs per client repository
Two preview paths maximum on small retainers: homepage plus one revenue or app-shell template agreed in the statement of work. Everything else lives in scheduled monitoring.
Copy numbers from the same budget document monitoring uses. If CI/CD gates and the client report disagree on thresholds, engineers ignore both.
Demote flaky LCP to warnings; keep CLS and bundle size as errors
Demote flaky LCP to warnings until preview matches production behaviour on paper. Keep CLS and bundle ceilings as errors people act on.
Document pre-merge CI/CD versus post-deploy monitoring in the README
CI/CD answers pre-merge; monitoring answers post-deploy. Write that split in the repository README so account teams stop asking the pipeline to prove checkout on Friday's release.
Layer managed monitoring beside the CI/CD job rather than inflating YAML until every pull request waits ten minutes on Chrome. Multi-tenant monitors exist precisely because portfolio evidence does not belong inside each client's GitHub Actions bill.
Lighthouse CI in CI/CD versus scheduled PageSpeed monitoring: agency split for one repository
For a typical agency client on a modern JavaScript stack, we aim for under ten minutes of CI/CD web performance time and zero manual JSON exports per month.
| Phase | Tooling | Question |
|---|
| Pre-merge | Lighthouse CI plus one bundle guard | Did this branch regress CLS or script weight on the two preview URLs in scope? |
| Post-deploy | Scheduled PageSpeed monitoring | Are production templates still inside budget on the cadence we promised? |
| Reporting | Monitoring product export | What do we send the sponsor without opening a terminal? |
Green in CI/CD and red in the Friday report means the split failed, not that someone lied. Either preview parity is wrong, the URL list in monitoring is right and the pipeline was too narrow, or the regression shipped through a path CI/CD never watched. All three are operational fixes, not reasons to add a fourth Lighthouse run on every push.
Audit Lighthouse CI maintenance before you copy the workflow to another client
Pick the client repository where the CI/CD job failed most often last quarter. Answer honestly:
- Who last updated
lighthouserc and the Chrome pin?
- How many hours went to flaky re-runs versus feature work?
- Which production URL regressed while the pipeline stayed green?
- What did the sponsor receive that was not a raw artefact?
If the maintainer has a name and the sponsor answer is "a screenshot from PageSpeed Insights," you already have a second job. Implement the thin CI/CD template from performance budgets in CI/CD pipelines, then read Lighthouse CI versus managed monitoring before copying the workflow into client seven.
Merge gates should block merges you would roll back. Everything else belongs on a schedule, with owners, on the full URL list the retainer names.
Originally published on Hashnode.