The agency lead inherited twelve client repositories, each with a Lighthouse CI workflow that passed on Friday and missed a checkout regression by Monday. Reporting meant exporting JSON, pasting scores into slides, and hoping the account manager could explain why /cart turned red while the homepage stayed green.
That pattern is common in r/webdev and r/TechSEO threads: Lighthouse CI is the right starting point, then monitoring becomes a second job. Incumbent SaaS tools often price per site or push enterprise tiers, so teams keep patching YAML while client evidence stays messy.
This guide compares Lighthouse CI (build) with managed PageSpeed monitoring (buy) for agency portfolios. We are not arguing you should delete CI. We explain where DIY breaks at scale, what a managed layer adds, and how to keep both without turning web performance into unpaid operations work.
What is Lighthouse CI and why do agencies adopt it first?
Lighthouse CI runs Lighthouse inside your pipeline: collect scores on a preview URL, store history, and assert against budgets before a merge ships. It is open source, free to run on your runners, and familiar to developers who already gate tests in GitHub Actions, GitLab CI, or Jenkins.
Agencies adopt it for sensible reasons:
- Merge protection on home, pricing, or a heavy template before deploy.
- Reproducible lab numbers on a candidate build, not a one-off paste into PageSpeed Insights.
- No SaaS invoice while the portfolio is small and one engineer owns the scripts.
Our performance budgets in CI/CD guide walks through lighthouserc, assertions, and preview URLs. For a wider tool map, see best free PageSpeed monitoring tools, which places Lighthouse CI beside PageSpeed Insights, WebPageTest, and managed monitors.
Lighthouse CI answers: did this build pass the thresholds we configured on the URLs we added to the workflow? It does not, by itself, answer: which client URL regressed in production this week, and what do we send the sponsor?
Why Lighthouse CI maintenance becomes a full-time job for agencies
The friction rarely appears on client one. It appears when you add client five, then fifteen, each with different hosts, preview providers, authentication walls, and template sets.
Per-repository scripts do not scale across a portfolio
Lighthouse CI is repository-centric. Agencies are portfolio-centric. Copying lighthouserc into every client repository means version drift: one client pins Lighthouse 11, another still runs 10, assertions differ, and nobody knows which workflow is authoritative.
Preview URL patterns change when a client moves from Netlify to Vercel or adds staging basic authentication. A green CI run on / does not guard /checkout if that route never entered the configuration. Teams discover the gap when scheduled checks or a sponsor's manual PageSpeed Insights run shows red.
Flaky builds and muted alerts
Lighthouse in CI is sensitive to runner CPU, network, and cold caches. Intermittent failures train teams to re-run until green or silence the job. Once alerts are muted, the pipeline becomes theatre: it passes, but nobody trusts it.
Keeping intermittent failures down means engineering time: pinned Chrome channels, warm caches, median-of-N runs, relaxed thresholds that are too loose to catch real regressions, or strict thresholds that block merges on noise.
No client-ready reporting layer
CI output is for engineers. Client sponsors want a short narrative: what changed, on which URLs, against which budget, with field context where it exists. Exporting Lighthouse CI artefacts into slides each month does not scale. Account managers should not need terminal access to defend a retainer.
Field drift and CrUX are outside the pipeline
CI sees the candidate build in a lab environment. It does not track CrUX movement on production URLs after deploy, competitor content management system changes, or third-party script weight that shifts without a merge. Agencies need both merge gates and ongoing schedules on the URLs clients actually care about.
In our experience, the tipping point is often five to ten production sites with more than two templates each. Below that, a motivated engineer can babysit scripts. Above it, maintenance competes with billable delivery unless monitoring is a productised service line with its own tooling budget.
What managed PageSpeed monitoring adds for multi-site agencies
Managed monitoring products schedule Lighthouse and CrUX-backed checks across many URLs, retain history, fire alerts, and present a portfolio view. They are built for the questions CI leaves open.
| Job | Typical Lighthouse CI setup | Managed PageSpeed monitoring |
|---|---|---|
| Block a bad merge on a preview URL | Strong | Not the primary job |
| Track 50+ URLs weekly without editing YAML per client | Weak | Strong |
| Show lab + field context in one place | Manual export | Built in |
Alert when /checkout crosses a budget |
Only if wired and maintained | Schedule + threshold per URL |
| Client-facing evidence without custom scripts | Rare | Dashboards and exports |
| Onboard a new site in minutes | New repository work | Add domain, discovery, budgets |
Apogee Watcher is one managed option aimed at agencies: multi-tenant dashboard, automated discovery, performance budgets, lab plus CrUX on scheduled runs, and team roles without per-client API key juggling. It layers beside your stack; it does not replace Git, your content management system, or your existing CI gates.
For a feature-level comparison across vendors, read comparing PageSpeed monitoring tools: features agencies need. For the manual-vs-automated framing, see PageSpeed Insights vs automated monitoring.
Build vs buy: decision criteria for agency PageSpeed monitoring
Use this checklist when you are choosing between extending Lighthouse CI and buying managed monitoring.
1. Count the hidden engineering hours
Estimate monthly time on:
- Updating Lighthouse versions and runner images across repositories.
- Fixing preview URL or authentication breakage after client infrastructure changes.
- Tuning assertions when legitimate design work triggers false failures.
- Building reports for client quarterly business reviews from CI artefacts.
If that total exceeds the subscription cost of a managed monitor and still leaves reporting manual, buy is usually cheaper in margin terms.
2. Price at portfolio scale, not per repository
Lighthouse CI has no licence fee, but runners are not free. More repositories mean more minutes, more storage for artefacts, and more on-call context switching. Managed tools should be judged on cost at 10–20–50 sites, not on a single-project quote.
Agency tiers exist because per-site pricing from premium monitors (often cited in the $90–$500+/month range for enterprise-style real user monitoring stacks) breaks retainers. Watcher's positioning is multi-tenant first: one subscription for the portfolio, not a surprise line item per client domain.
3. Separate merge gates from production surveillance
CI should stay thin: a small set of URLs on the merge path, bundle limits, and assertions you are willing to enforce. Production surveillance belongs on a schedule across templates you will never add to every pipeline, including routes marketing does not own.
Trying to make CI do both produces either huge workflows or neglected configurations. Split the jobs explicitly.
4. Reporting is a product requirement, not a nice-to-have
If clients pay for performance oversight, the deliverable is evidence they understand. CI logs are not a deliverable. Before you commit to build, name who produces the monthly report and how long it takes. If the answer is "the lead developer, ad hoc," buy addresses the bottleneck.
5. Integrate, do not rip-and-replace
Keep Lighthouse CI where it already works. Add managed monitoring for portfolio schedules, CrUX drift, and alerts. Link findings back to tickets. This matches how mature teams use PageSpeed Insights for spot checks, WebPageTest for deep dives, CI for gates, and a monitor for ongoing defence.
When should agencies keep Lighthouse CI in the stack?
Keep Lighthouse CI when:
- You ship frequently on a defined preview URL and need hard merge blocks.
- Bundle or request-count budgets are part of your definition of done.
- A platform team can own one golden workflow template cloned to new repositories.
Reduce reliance on CI alone when:
- Clients change hosts or templates faster than you update workflows.
- Sponsors ask for field metrics and history CI never collected.
- Engineers describe monitoring as "another thing we maintain" rather than a service you sell.
Our automated PageSpeed monitoring setup guide covers schedules, discovery, and budgets on the managed side. Pair it with CI gates from the performance budgets CI/CD post so pre-merge and post-deploy responsibilities stay clear.
How to move from fragile CI-only monitoring to a managed layer
You do not need a single cutover migration. A practical sequence:
- Inventory URLs clients care about beyond the CI defaults: checkout, account, search, key landing pages. Use a site audit checklist during onboarding so the list is explicit.
- Leave CI on one or two gate URLs per repository with stable assertions. Remove noisy checks that teams already ignore.
- Add scheduled monitoring on the full URL set per client with shared budgets. Align thresholds with what you already assert in CI where it makes sense.
- Route alerts to owners using policies people follow. Fewer routes beat a flood of critical pings nobody answers. See from reactive to proactive smart alerts for routing patterns.
- Standardise client reporting from the monitor's dashboard or exports instead of rebuilding slides from Lighthouse CI JSON each month.
New clients should get the managed layer on day one; retrofit CI-heavy accounts during the next quarterly business review when reporting pain is already on the agenda.
Where incumbents leave gaps agencies still feel
Enterprise monitors invest in deep single-site real user monitoring and synthetic suites. That is valuable for product companies with one flagship application. Agencies running 10–50+ client sites routinely report different gaps in community threads:
- Per-site pricing or API key overhead that does not match retainer economics.
- Dashboards built for one product team, not a portfolio with separate sponsors.
- Slow roadmap movement on multi-tenant workflows, white-label reporting, or prospecting-friendly exports.
Watcher is positioned in that gap: monitoring-first, agency-shaped pricing, lab plus CrUX without you holding PageSpeed Insights API keys, and a path toward client-ready reporting. It is not a replacement for your CI system or for specialised real user monitoring where a client already instruments their application.
FAQ
What do agencies mean by a Lighthouse CI alternative?
Lighthouse CI is not a substitute for itself; it is the open-source path for CI gates. When teams look for an alternative, they usually want a managed monitor that covers portfolio schedules, alerts, and reporting without maintaining Lighthouse CI across dozens of repositories. Keep CI for merges; add managed monitoring for ongoing surveillance.
Can managed monitoring replace Lighthouse CI entirely?
We do not recommend that for most agencies. Managed monitoring is weak as a merge gate on ephemeral preview URLs unless the vendor integrates directly with your pipeline. Use CI to block bad builds; use managed monitoring to watch production templates and client-facing routes on a cadence.
How does this compare to DebugBear, SpeedCurve, or Oh Dear?
Those are SaaS monitors with their own pricing and depth trade-offs. Lighthouse CI is DIY on your runners. The build-versus-buy question here is engineering time versus subscription for portfolio workflows. For vendor-by-vendor feature rows, use the agency PageSpeed tools comparison and dedicated comparison posts where they exist.
What should we enforce in CI versus in monitoring?
CI: a small URL set on the merge path, bundle limits, and assertions you will actually fix before merge. Monitoring: full template coverage, CrUX-aware budgets, alerts, and history sponsors can see. Overlap is fine on critical URLs; duplication of every check in both places is not.
Does Apogee Watcher require ripping out existing scripts?
No. Watcher is designed to layer beside PageSpeed Insights, WebPageTest, CI, and client content management system workflows. Add domains, set budgets, and schedule tests; keep Lighthouse CI where it already protects merges.
Next steps for agency teams
If monitoring still feels like a full-time job built from scheduled cron jobs, YAML configuration, and slide exports, treat that as a build-versus-buy signal. Keep Lighthouse CI for merge protection. Add a managed monitor for portfolio schedules, field context, and client evidence.
Start a free trial and baseline your top client URLs, or run a free domain PageSpeed check on a prospect site before you scope the next retainer. For onboarding checklists and URL priorities, pair this article with how to onboard a new client for performance monitoring.
Top comments (0)