DEV Community: Apogee Watcher

Lighthouse CI vs Managed Monitoring: Build vs Buy for Agencies

Apogee Watcher — Fri, 12 Jun 2026 05:42:11 +0000

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.

Performance Monitoring for SaaS: Metrics That Matter for Product Teams

Apogee Watcher — Thu, 11 Jun 2026 07:02:51 +0000

A SaaS product team opens the observability dashboard and sees healthy API latency. Signup still drops after a frontend deploy. Marketing reports strong traffic on pricing, but trials do not convert. The gap is familiar: backend APM measures services and databases. It does not tell you whether the pricing page, signup flow, or logged-in shell feels fast in Chrome on a mid-range phone.

SaaS performance monitoring for product teams starts on the web surfaces users actually load: marketing sites, documentation, authentication routes, and the JavaScript-heavy app URLs you can test on a schedule. This guide separates front-end web monitoring from backend APM, lists the metrics worth tracking first, and shows how to layer scheduled PageSpeed monitoring beside the tools you already run.

What does SaaS performance monitoring mean for product teams?

For product and growth leads, performance monitoring means catching regressions on revenue paths before they show up in funnel dashboards. That includes:

Public marketing URLs (home, pricing, comparisons, security pages).
Acquisition flows (signup, trial activation, invite acceptance).
High-traffic app entry routes (dashboard home, project list, first-run onboarding).
Documentation and help centres that support activation and reduce support load.

It does not mean replacing Datadog, New Relic, or OpenTelemetry on APIs. Those tools answer whether the server responded quickly. Core Web Vitals and scheduled lab tests answer whether the page rendered and responded in the browser.

SaaS teams that monitor only backend metrics often discover UI regressions late: a new analytics bundle slowed INP on signup, a chart library pushed LCP on the dashboard, or a hero video on pricing hurt mobile conversion. Product teams need both layers, with clear owners.

Front-end web performance vs backend APM for SaaS

Question	Backend APM / tracing	Web performance monitoring
Did the API return in time?	Yes	No
Did the browser paint and respond?	No	Yes
Works without app instrumentation on public URLs?	Partial	Yes (synthetic + CrUX)
Catches third-party script weight on marketing?	Rarely	Yes
Ties to SEO and page experience?	No	Yes (field CWV)

Use APM for service health, database queries, and queue backlogs. Use web performance monitoring for URLs where marketing, SEO, and product UX meet.

If your SaaS is a single-page application, many "product" screens still load as URLs. Monitor the routes that matter for activation and retention, not only api.example.com health checks.

Agencies managing SaaS clients follow the same split. The retainer covers marketing and key app URLs; the client's platform team owns service-level APM. Reports should say which layer moved, not blend them into one green dashboard.

Core Web Vitals metrics SaaS product teams should track

Google's field programme centres on LCP, INP, and CLS at the 75th percentile. For SaaS web applications, we treat all three as first-class, with stricter INP expectations on interactive product surfaces.

Largest Contentful Paint (LCP)

LCP measures loading of the largest visible element. On SaaS sites it often maps to hero content on marketing pages, skeleton states on dashboards, or the first meaningful chart/table in app shells. Slow LCP on pricing or signup hurts consideration before a user reaches your APM-instrumented API.

Interaction to Next Paint (INP)

INP is usually the metric product teams feel first. Signup forms, command palettes, filters, drag-and-drop boards, and inline editors all depend on main-thread responsiveness. Our INP guide covers debugging; for SaaS, prioritise INP on routes where hesitation costs trials or daily active use.

Cumulative Layout Shift (CLS)

SaaS UIs load dynamic components: toast notifications, modals, async tables, and banner slots. CLS spikes cause mis-clicks on mobile and erode trust during payment or permission steps. Budget CLS tightly on onboarding and billing templates.

For metric definitions and fix patterns, see LCP, INP, and CLS explained.

Supporting lab metrics for JavaScript-heavy SaaS UIs

SaaS front ends ship large JavaScript bundles. Field INP may lag a week after a deploy. Lab metrics from scheduled Lighthouse runs help you catch regressions earlier.

First Contentful Paint (FCP) shows when the UI first paints. Total Blocking Time (TBT) estimates main-thread blocking during load. Both appear in PageSpeed Insights lab output. They are not Core Web Vitals ranking signals on their own, but they often move before field INP updates on heavy React or Vue apps.

Our FCP and TBT guide explains when to add them to budgets. For SaaS dashboards and settings pages, TBT regressions frequently predict INP pain on filters and modals.

Which SaaS URLs and flows to monitor first

You cannot monitor every route on day one. Start with URLs tied to money and activation:

Marketing home and pricing (SEO and paid landing traffic).
Signup, login, and password reset (conversion and support load).
First-run onboarding or empty-state dashboard (activation).
One high-traffic in-app list or report view (retention signal).
Documentation index and top help article (reduces tickets, supports SEO).

Run mobile and desktop strategies on each. SaaS INP often fails on phones while desktop looks fine; see mobile vs desktop CWV monitoring.

Add routes when releases touch them. A quarterly manual audit misses the deploy that broke signup on Tuesday.

Performance budgets for SaaS web applications

A performance budget turns "slow" into a threshold your team can enforce. Without numbers, product debates drift into subjective "it feels fine on my laptop."

Our performance budget guide explains the model. The budget thresholds template includes a SaaS / web applications row. Typical starting points from that template:

Metric	Mobile budget (starter)	Desktop budget (starter)	Priority
LCP	2,500 ms	2,000 ms	High
INP	100 ms	75 ms	Critical
CLS	0.05	0.05	Critical
FCP	1,500 ms	1,200 ms	High
TBT	150 ms	100 ms	Critical

Record a baseline month before tightening. SaaS apps with heavy client-side routing may need slightly looser lab score targets than marketing-only sites, but INP and CLS should stay strict on signup and billing.

Alerts and scheduled tests make budgets operational. Our performance budgets and alerts product overview describes how we implement site-level thresholds and notifications in Apogee Watcher.

Synthetic scheduling vs field data in SaaS release cycles

SaaS teams ship weekly or daily. Field CrUX updates on a rolling window. Scheduled synthetic tests give you a comparable number every run on the same URL and device profile.

Use field data (CrUX, Search Console) when you have volume on public marketing URLs and need SEO-aligned reporting. Use scheduled lab tests when:

a URL is new or low-traffic;
you need same-day feedback after a frontend release;
you compare mobile and desktop on identical scripts;
you monitor staging or preview URLs before promotion.

PageSpeed Insights vs automated monitoring covers why spot checks fail at SaaS cadence. Manual PSI runs are useful for debugging; they are not a monitoring programme.

Product analytics (trial starts, activation steps) remains the business ground truth. Web performance metrics explain why a funnel step worsened after a deploy. Connect them in reviews: "signup INP regressed 40 ms; trial completions down 6% on mobile."

How agencies monitor performance across multiple SaaS clients

Agencies running retainers for SaaS marketing sites or product marketing microsites face portfolio scale problems: different stacks, different release cadences, one reporting template.

Patterns we see work:

One organisation per client, shared page groups by template (marketing vs app shell).
Standard starter URL sets per vertical (pricing, signup, docs landing).
Paired mobile/desktop strategies with the same schedule.
Client reports that separate marketing CWV from "app URLs we monitor" without claiming backend APM coverage.
Automated monitoring setup once, then clone patterns per new SaaS client.

When prospects ask for SaaS performance monitoring, clarify whether they mean public URLs, logged-in RUM, or API latency. Our tools comparison for agencies explains where scheduled synthetic monitoring fits beside RUM vendors.

Where Apogee Watcher fits in a SaaS monitoring stack

Apogee Watcher monitors web and mobile-web URLs on a schedule: PageSpeed lab results, CrUX where available, vitals and optional FCP/TBT budgets, portfolio alerts, and multi-tenant organisation structure for agencies.

We do not replace SaaS APM, error tracking, or session replay. Layer Watcher on marketing and priority app URLs. Keep Datadog, Sentry, PostHog, or your RUM vendor for logged-in behaviour and API traces.

In the app, you configure sites, discovery rules, mobile/desktop strategies, budgets, and alert channels per client or per product line. Export and API access keep data portable.

If poor performance is already hurting pipeline, translate metrics into business language using our cost of poor web performance guide before you present charts to leadership.

FAQ

What is SaaS performance monitoring?

For product teams it usually means tracking how fast marketing and app web URLs load and respond in browsers: Core Web Vitals (LCP, INP, CLS), optional lab metrics (FCP, TBT), and trends over scheduled tests. Backend APM is complementary, not a substitute.

Which SaaS performance metrics matter most?

Start with LCP on acquisition URLs, INP on signup and core product interactions, and CLS on dynamic layouts. Add FCP and TBT in lab monitoring when JavaScript weight is high. Tie changes to funnel steps you already measure in product analytics.

Should SaaS teams use stricter INP budgets than marketing sites?

Often yes on authenticated app routes. Interactive surfaces should feel immediate. Use the SaaS row in our performance budget template as a starter, then adjust from baselines.

Does SaaS performance monitoring require RUM instrumentation?

Not for public URLs. Scheduled synthetic tests and CrUX field data cover marketing and many app routes without a browser snippet. Logged-in-only flows may still need RUM from your analytics or observability vendor for session-level proof.

How often should SaaS teams run performance tests?

Match release risk: weekly at minimum on priority URLs, daily or post-deploy on signup and pricing during active frontend work. Test frequency and priority scheduling helps portfolios avoid testing everything equally.

Can Apogee Watcher monitor SaaS API performance?

No. Watcher monitors web URLs via PageSpeed schedules and vitals budgets. Use APM for APIs and services. Use Watcher for marketing sites, docs, and key app URLs across clients or product lines.

SaaS product teams need web performance monitoring on the URLs that drive trials and daily use, not only green API dashboards. Track Core Web Vitals on priority routes, add lab metrics when JavaScript is heavy, set SaaS-shaped budgets, and layer scheduled monitoring beside APM and RUM.

Start a free Apogee Watcher account to schedule mobile and desktop tests with vitals budgets on marketing and app URLs, or run a free domain check on a SaaS pricing or signup page that regressed after the last frontend release.

Core Mobile Vitals: What Web Performance Teams Should Know (and What to Monitor Today)

Apogee Watcher — Thu, 11 Jun 2026 07:02:33 +0000

Your portfolio probably mixes responsive sites, hybrid apps with WebViews, and native iOS or Android products. Sponsors ask for "mobile vitals" in one breath. The metrics behind that phrase depend on where the user actually loads content.

Google's Core Web Vitals apply to pages in Chrome. Native apps use different instrumentation, different release cycles, and different failure modes. Embrace and SpeedCurve are now promoting Core Mobile Vitals as a user-focused framework for native experiences.

Web performance teams need a clear split: what is settled on mobile web, what is still forming for native apps, and what you can monitor this quarter without inventing thresholds that do not exist yet.

What are Core Mobile Vitals?

Core Mobile Vitals (CMV) is an initiative led by Tammy Everts (SpeedCurve) and Embrace. The goal is a shared vocabulary for mobile app experience quality, similar to what Core Web Vitals did for the web.

Embrace describes CMV as user-focused and tied to business outcomes, not developer-only timings. The framework is still taking shape. Embrace publishes posts on Core Mobile Vitals and why mobile deserves an equivalent to CWV. There is no Google-style public threshold table for CMV yet.

That matters for planning. You cannot copy LCP or INP pass bands into a native app RFP and call it done. CMV starts with experience pillars and goals. Metrics follow as the community agrees on definitions and field collection.

Web teams should follow the conversation, especially when clients ship both a marketing site and a store app. CMV is not a replacement for CrUX on URLs.

Do not confuse CMV with mobile Core Web Vitals. Mobile CWV means LCP, INP, and CLS on phone form factors in Chrome: field data from CrUX, lab data from Lighthouse mobile emulation. Same three metrics, different device profile.

This post uses "Core Mobile Vitals" for the native-app framework and "mobile CWV" for vitals on mobile web unless the context is obvious.

Why Core Web Vitals gave web teams a shared language

Before CWV consolidated around LCP, INP, and CLS, performance meetings drifted. One week it was Time to Interactive. The next it was Speed Index, custom RUM percentiles, or whichever Lighthouse score someone ran that morning. Sponsors could not compare templates. Agencies could not write one monitoring clause.

CWV fixed the vocabulary problem for public web content:

Three field metrics at the 75th percentile, reported in CrUX and Search Console.
Lab companions in Lighthouse for debugging, not for ranking pass/fail on their own.
A clear split between SEO page experience (field vitals) and engineering diagnostics (lab output).

That shared language is why mobile vs desktop CWV monitoring is a portfolio question, not a philosophical one. You still monitor LCP, INP, and CLS. You run paired mobile and desktop strategies because the numbers diverge.

Our LCP, INP, and CLS guide stays the technical anchor for fixes once monitoring shows a regression.

Native mobile never inherited that consolidation. App teams still juggle cold start, frame drops, ANRs, crash-free sessions, and screen-level traces from their APM or RUM vendor. Product and engineering can agree that "the checkout screen feels slow" without agreeing on which metric proved it.

CMV is an attempt to standardise that vocabulary for apps, not for websites.

Why native mobile apps still lack an equivalent framework

Several structural differences slow a single "mobile vitals" standard for native apps.

Platforms and runtimes differ

iOS and Android expose different lifecycle hooks, threading models, and GPU behaviour. A metric that is straightforward on UIKit may need a different definition on Jetpack Compose. Web CWV benefits from one rendering pipeline in Chrome. Native apps do not.

Session shape differs

Users background apps, resume mid-flow, and move through stacks of screens rather than linear page loads. Screen Load in CMV language maps to view-controller timing, not to a single HTML document. Responsiveness includes gestures, animations, and offline queues that INP on a URL never sees.

Distribution and measurement differ

CrUX samples real Chrome users at scale. Native RUM depends on SDK instrumentation, sampling rates, and privacy rules in each store ecosystem. You can standardise definitions. You cannot assume a free public dataset like CrUX for every app's screens.

Ownership differs on mixed portfolios

Agencies often own the WordPress or headless storefront but only advise on the companion app. Web retainers cite Search Console. App work sits with mobile engineering and a different vendor contract. Without a shared framework, quarterly reviews compare incomparable charts.

CMV does not remove those splits. It gives native teams a shared target for measurement conversations. Web teams still need an explicit lane for mobile web.

Embrace's four experience pillars for native apps

Embrace groups early CMV thinking around four experience pillars. Treat these as goals, not final published metrics with universal thresholds. Embrace and partners are still defining how each pillar maps to field measurements across iOS and Android.

Screen Load

How quickly a user sees meaningful content after navigating to a screen: view loading, first render, and time until the screen is usable. Native SDKs can instrument UIViewController lifecycle stages (for example viewDidLoad through viewDidAppear) and correlate slow screens with abandonment.

This is the app analogue to caring about LCP on web. It is screen-scoped, not URL-scoped.

Smoothness

Frame pacing and jank: scrolls, transitions, and animations that drop frames or hitch. Web CLS captures layout shift. Native smoothness is closer to GPU and main-thread frame budgets during motion. Teams already using mobile RUM often have jank or slow-frame reports under different names.

Responsiveness

Tap-to-feedback latency across the session, not only the first interaction. It parallels INP in intent (did the app feel slow after I touched it?) but must cover native controls, gestures, and offline retries. Hybrid apps may need both INP on WebView URLs and native responsiveness on shell screens.

Stability

Crashes, hangs, and broken flows that end the session or block completion. Web CLS and vitals do not replace crash-free rate or ANR counts. Sponsors still ask for stability even when LCP is green.

In our experience, the useful takeaway for web-led teams is directional. When a client cites CMV in a workshop, ask which pillar they mean and whether the pain is on a native screen, a WebView, or the mobile browser site. Do not invent CMV "good" bands in contracts until Embrace and the community publish them.

Core Web Vitals on mobile web: what to monitor today

For responsive sites and mobile-browser traffic, mobile CWV is the settled standard. Monitor LCP, INP, and CLS on a mobile strategy alongside desktop on priority URLs.

Use field data when CrUX has volume. Use scheduled lab runs when a URL is new, low-traffic, or you need week-to-week comparability.

Practical checks we see in agency portfolios:

Home, category, and article templates on mobile and desktop with the same cadence.
Checkout or logged-in flows where INP on phones often fails first.
Third-party and tag weight that hurts mobile LCP before desktop moves (supporting lab metrics like FCP and TBT often shift on mobile first).
CMS-driven properties where plugins defer assets differently per breakpoint; WordPress performance monitoring is a common example.

PageSpeed Insights and CrUX both expose mobile form factor data where Google publishes it. Your monitoring tool should store strategy per URL (mobile vs desktop), apply budgets per strategy, and alert when either side regresses.

Many "core mobile vitals" searches actually mean mobile web. That is the operational baseline above.

How web performance teams should combine web monitoring and native RUM

Think in three layers rather than one blended score:

Layer	What the user opens	What to use today
Mobile web	Chrome (or in-app browser) on a URL	CWV field + lab on mobile strategy; CrUX in PSI
Hybrid WebView	App shell loads your URL	Mobile CWV on the URL plus native traces for shell navigation
Native screens	Swift/Kotlin UI	Vendor RUM/APM (Embrace, etc.); watch CMV pillar definitions as they mature

Apogee Watcher fits the web and mobile-web layer: scheduled PageSpeed tests, LCP/INP/CLS and optional FCP/TBT budgets, multi-tenant sites and pages, portfolio alerts, and CrUX in test results where available.

We do not ship a native app SDK or CMV dashboards in-product. Layer Watcher beside native observability. Do not replace an app RUM stack because a web monitor covers marketing URLs.

For mixed retainers, split the report. Show mobile CWV trends for public URLs and native pillar notes from the app team's vendor. Call out when a WebView URL fails mobile INP while the native shell scores well on Screen Load. Clients trust that honesty more than a single blended "mobile score."

What agencies should document in retainers

Until CMV thresholds exist, write contracts in plain terms:

Mobile web: field LCP, INP, and CLS at agreed percentiles on a mobile test strategy; reference Search Console where SEO is in scope.
Native app: reference the client's chosen RUM vendor and CMV pillar goals when the mobile team adopts them; avoid copying CWV numbers into app SLAs.
Hybrid: list which URLs are monitored as web properties and which screens stay with the app team.

Revisit the doc when Embrace publishes firmer CMV metric definitions. Link internally to your Core Web Vitals monitoring checklist and onboarding guides so delivery teams configure both strategies on day one.

FAQ

Are Core Mobile Vitals the same as Core Web Vitals on phones?

No. Mobile Core Web Vitals are still LCP, INP, and CLS, measured on mobile form factors in Chrome. Core Mobile Vitals is a separate, emerging framework for native app experiences from Embrace and SpeedCurve. Hybrid products may need both.

Does Google rank native apps on Core Mobile Vitals?

No. CMV is not a Google Search ranking programme. Google's page experience signals apply to web content in Search. Native app discovery and store policies use different signals.

What mobile app performance metrics should we track while CMV matures?

Keep your existing native stack: cold start, screen timing, crash-free sessions, ANR rate, and key funnel completion. Map them informally to Screen Load, Smoothness, Responsiveness, and Stability when talking to sponsors. Do not rename vendor metrics to CMV in contracts until definitions stabilise.

Should we monitor mobile and desktop Core Web Vitals separately?

Yes. Run paired strategies on priority URLs. Mobile often fails first on LCP and INP even when desktop looks healthy. See our mobile vs desktop CWV guide.

Can Apogee Watcher monitor Core Mobile Vitals in native apps?

No. Watcher monitors web and mobile-web URLs via scheduled PageSpeed tests and supports vitals plus optional FCP/TBT budgets per mobile or desktop strategy. Use native RUM for app screens; use Watcher for URL portfolios and client sites.

Where can we read more about Core Mobile Vitals?

Start with Embrace's posts on Core Mobile Vitals and their broader mobile performance guides. Pair that with our Core Web Vitals primer and supporting lab metrics guide for the web side.

Web teams already have a standard for mobile browser experience: Core Web Vitals on a mobile strategy, monitored beside desktop. Core Mobile Vitals is the parallel conversation for native apps, organised around Screen Load, Smoothness, Responsiveness, and Stability until shared metrics and thresholds catch up.

Monitor what is defined today. Layer tools instead of forcing one score across web and app.

Start a free Apogee Watcher account to schedule mobile and desktop PageSpeed tests with vitals budgets across client URLs, or run a free domain check on a mobile strategy that regressed after the last release.

Outgrowing GTmetrix: what agencies ask next

Apogee Watcher — Wed, 10 Jun 2026 21:35:03 +0000

The Slack message is familiar: "Can you run GTmetrix on the homepage and send the PDF?" For one client, that habit works. The report is legible, the waterfall helps when LCP looks wrong, and stakeholders recognise the format.

At ten or fifteen retainers, the same request starts to sound like a coverage plan. Nobody intends to monitor three URLs forever, but the bookmarks multiply, the monitored-slot maths gets awkward, and the person who "owns GTmetrix" becomes a bottleneck. In our experience, agencies do not outgrow GTmetrix because the product failed. They outgrow the workflow of treating every performance question as a one-off lab run.

Below is what teams ask once spot checks stop scaling, what we still send people to GTmetrix or WebPageTest for, and how we add scheduled PageSpeed monitoring on top without a rip-and-replace pitch.

When "run GTmetrix" stops matching how your agency works

The break point is rarely a bad score. It is operations.

You add a campaign landing page on Tuesday. By Friday, nobody has added it to the monitored list. A developer ships a cache change on a category template; the homepage still looks green because that is the URL everyone tests. A new account manager asks for "the performance report" and receives three different PDFs from three different tools, each from a different week.

That is the moment the conversation changes from "which tool has the prettier waterfall?" to "how do we know what shipped last week actually stayed in budget?" Spot-check tools answer the first question well. They do not, by themselves, answer the second across a portfolio.

We hear four follow-up questions in agency channels once that gap is visible. They are less about Lighthouse versions and more about who maintains lists, who gets alerted, and what clients see without another manual run.

What GTmetrix-style spot checks still do well

GTmetrix, WebPageTest, and a fresh PageSpeed Insights tab are still the right call when you need depth on one URL. Regional test locations, connection profiles, filmstrips, and waterfall detail matter when you are debugging routing, third-party weight, or a template that behaves differently in Chrome than in your headless CI job.

That work is diagnosis. Portfolio monitoring is coverage. Confusing the two is how teams end up with excellent reports on five URLs and silence everywhere else.

We keep spot-check tools for deep-dive debugging on one URL. We stop expecting them to carry weekly accountability across every client property. The shift is intentional: GTmetrix or WebPageTest for "why is this page slow right now?" and scheduled monitoring for "did any priority URL drift since we last looked?"

Multi-site PageSpeed monitoring: four questions agencies ask next

These questions show up in different words, but the shape is consistent.

Do we have coverage without multiplying monitored slots?

On slot-based monitors, each URL plus region, device, and connection profile can consume its own slot. A handful of clients, each with a homepage, a lead form, and one campaign path, in two regions, eats a plan quickly. The maths is not mysterious; it is just not how agencies think about retainers. They think in sites and templates, not permutations.

The ask becomes: can we monitor priority paths across many sites without negotiating slot arithmetic every quarter? That is where multi-tenant monitors and discovery (sitemaps, crawls) come up. Manual lists rarely survive busy release weeks without automation behind them.

Who maintains the URL list after every deploy?

In small teams, one senior developer keeps a spreadsheet of "URLs we care about." That works until holidays, handovers, or a rush of microsites. The question is really about ownership: when a new template ships, does monitoring update automatically, or does someone need to remember a paste step?

Agencies that solve this assign monitoring updates to the same rhythm as release notes, not to whoever has five minutes before a client call. Scheduled runs with stored history make that handover easier than a folder of PDFs with mismatched dates in the filename.

Can we report without another manual test run?

Client reporting often reuses the audit pattern: run a test, export, attach, repeat next month. It is credible; it is also labour-heavy at scale. The next question is whether leadership can see trend lines and budget breaches without booking another lab session for every site on the roster.

That does not mean automated reports replace explanation. It means the account team starts from "here is what changed since baseline" instead of "hang on, I will run the test again."

Will anyone notice a regression before the client does?

Bookmarks do not alert. They wait. Teams that outgrow spot checks usually want thresholds on LCP, INP, or CLS (and supporting lab signals where field data is thin) with a route that reaches a human who can open a ticket.

The bar is low and specific: not "AI tells us everything," but "we do not learn about a deploy problem from the client's support inbox." Email alerts, Slack routes, or webhooks are implementation details. The decision is whether performance is operational like uptime, or ceremonial like a quarterly slide.

Free PageSpeed tools vs paid monitoring in a growing portfolio

Free tiers are not the wrong place to start. PageSpeed Insights, Lighthouse in CI, and generous free quotas on lab hosts cover a lot of ground for a single product or an early agency bench.

The friction appears when free tools stay on manual triggers while the portfolio grows. PSI is authoritative for a URL you paste today; it does not tell you which client path regressed on a quiet Tuesday. Lighthouse CI belongs in the merge path; it does not replace field drift on production URLs you did not model in the build.

Our Watcher roundup of free PageSpeed monitoring tools separates what we keep in the free layer (PSI, WebPageTest, CI budgets) from what we expect a paid monitor to carry (schedules, portfolios, alerts, client-ready history). The point is not "pay for everything." It is "name which job each layer owns so free tools do not pretend to be a portfolio system."

How to compare GTmetrix alternatives without a feature matrix audit

Procurement and technical leads both want comparisons. A fifty-row feature spreadsheet is rarely what changes the decision. In our experience, three workflow tests work better:

Add two new URLs that shipped this month. How many manual steps until they are on a recurring check?
Pick one regression you missed last quarter. Would your current setup have alerted someone, or would you have needed a calendar reminder?
Ask who produces the client-facing report today. Count the minutes from "open tool" to "send PDF."

Those tests show which tool fits faster than scoring checkmarks for white-label PDFs or API access. When a team wants a structured GTmetrix vs multi-tenant monitor split, we point them to our GTmetrix vs Apogee Watcher for agencies article on the Watcher blog. It is honest about where lab hosts win and where portfolio workflows win. This post is the earlier stage: recognising you have reached the question.

Layer, do not rip-and-replace. Keep GTmetrix or WebPageTest for deep dives. Add scheduled monitoring and budgets for the URLs that would hurt if they drifted unnoticed. Keep CI gates for bundles and templates you control at build time. You add tools; the decision does not have to become a vendor turf war.

A two-week portfolio exercise before you buy tools

If you are past the "one bookmark per client" stage, try a lightweight portfolio exercise before you buy anything:

List every client with a production URL you would be embarrassed to see red in a stakeholder call.
Mark which of those URLs received a lab test in the last fourteen days.
Note who would get paged if LCP moved from "good" to "poor" on a path not on that list.

The gaps on that page are your requirements document. They usually mention discovery, schedules, and alerts more than waterfall cosmetics.

Pick ten URLs that matter, set budgets, and run scheduled checks for a month. Keep your GTmetrix login for the afternoons when you need waterfall detail. If you want a multi-tenant workflow built for that pattern, start a free trial of Apogee Watcher and map one organisation per client group. The goal is not another dashboard. It is fewer surprises between audits and a reporting trail that does not start with "let me run the test again."

FCP and TBT: Supporting Metrics Beyond Core Web Vitals

Apogee Watcher — Tue, 09 Jun 2026 21:22:13 +0000

Your client opens PageSpeed Insights and asks about two numbers that are not in the Core Web Vitals row: First Contentful Paint (FCP) and Total Blocking Time (TBT). LCP, INP, and CLS are in the contract. FCP and TBT are not ranking signals on their own, yet they appear in every scheduled Lighthouse run and often change before the vitals do.

This guide explains what first contentful paint and total blocking time measure, how they relate to the three Core Web Vitals, and when to track them in performance budgets across a portfolio. For the vitals themselves, start with What Are Core Web Vitals? and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It.

Are FCP and TBT Core Web Vitals?

No. Google's Core Web Vitals programme includes only three field metrics at the 75th percentile: LCP, INP, and CLS. FCP and TBT appear in Lighthouse and PageSpeed Insights lab output. They help you find causes, but they do not replace CrUX field scores for pass or fail in Search Console.

That distinction matters in client conversations. Sponsors sometimes treat every red Lighthouse metric as a ranking emergency. You can say plainly: vitals come from real Chrome users in the field; FCP and TBT come from lab runs and help explain why a template might fail LCP or INP after the next deploy.

What First Contentful Paint measures

First Contentful Paint records when the browser first paints any text, image, non-white canvas, or SVG from the DOM. It tells you the page has started to render, before the largest element (LCP) finishes.

FCP measures a different moment than LCP. LCP waits for the biggest visible content. FCP records the first visible paint. On a hero-image landing page, FCP might be a headline or skeleton while the image still loads; on a text-heavy article, FCP and LCP are often similar.

Lighthouse and PageSpeed Insights report FCP in milliseconds. Google's lab thresholds match the universal table in our Performance Budget Thresholds Template:

Rating	FCP (lab)
Good	≤ 1,800 ms
Needs improvement	1,800–3,000 ms
Poor	> 3,000 ms

CrUX does not report FCP the same way it reports LCP, INP, and CLS. You see FCP in lab runs, synthetic monitoring, and developer tools. Agencies track it because scheduled tests return FCP on every run, even when CrUX has little or no data for a new URL.

What Total Blocking Time measures

Total Blocking Time sums main-thread blocking time after First Contentful Paint and before Time to Interactive in a Lighthouse run. A "long task" is any main-thread task longer than 50 ms. TBT adds the portion of each long task above 50 ms during that window.

TBT is a lab metric. It estimates how much the main thread is blocked while the page is still loading and becoming interactive. It does not measure a specific user click; it measures blocking during load and early hydration.

Google's TBT documentation treats the metric as related to, but not the same as, Interaction to Next Paint (INP). INP is a field metric for responsiveness across the visit. TBT is main-thread blocking during load in a controlled lab test. Both often worsen when JavaScript blocks the main thread, especially on pages with many tags, but you can pass TBT in lab and still fail INP on post-load interactions (menus, carts, client-side routes). Our third-party scripts guide explains that difference with examples.

Lab thresholds (same source as the budget template):

Rating	TBT (lab)
Good	≤ 200 ms
Needs improvement	200–600 ms
Poor	> 600 ms

How FCP relates to LCP in diagnosis

LCP and FCP share parts of the loading path. Slow server response (TTFB), render-blocking CSS, and font loading can hurt both. They differ when the LCP element is a heavy image or video while something lighter renders first.

Typical patterns we see in agency audits:

FCP poor and LCP poor: slow loading across the page (server, critical CSS, early JavaScript blocking render).
FCP good, LCP poor: first paint is fast but the hero image or largest block is delayed (image weight, lazy-loading mistakes, CDN cache misses). See image optimisation for LCP.
FCP good, LCP good, TBT poor: LCP and FCP pass but the main thread is busy; INP may still fail on interactions after load.

When you report to clients, show FCP and LCP for the same URL and device strategy. "FCP improved 400 ms" is useful context when LCP is still poor because the hero image loads slowly.

How TBT relates to INP in diagnosis

INP replaced First Input Delay in March 2024 as the responsiveness Core Web Vital. Teams use TBT in lab when CrUX INP is missing or when scheduled synthetic runs need a comparable number week to week.

Use TBT when:

you are debugging main-thread JavaScript during load and early hydration;
you want a budget on marketing sites that share one tag manager across dozens of clients;
you are comparing lab runs week to week on the same URL and throttling profile.

Fixing TBT does not guarantee an INP pass. Post-load handlers, single-page transitions, and third-party scripts that run after load can hurt INP without changing TBT much. The INP guide covers that gap in detail.

For ecommerce and app-heavy flows, see e-commerce performance monitoring for how we prioritise INP, TBT, and LCP on checkout templates.

When agencies should track FCP and TBT in monitoring

Track vitals first. Add FCP and TBT when they help you catch regressions earlier or explain why LCP, INP, or CLS changed to non-technical sponsors.

Practical cases:

Content and publishing sites: FCP on article templates shows when a CMS change added render-blocking CSS or a slow web font. LCP on the hero image may change later; FCP often changes first.
Marketing sites with heavy tags: TBT increases when analytics, chat, or A/B scripts grow without review. One tag change can affect every page using the same container.
Multi-site portfolios: the same third-party bundle on twelve clients means one regression can raise TBT on every property. Portfolio monitoring reports that without opening PageSpeed Insights for each site.
Performance budgets in retainers: when clients ask for thresholds beyond LCP, INP, and CLS, FCP and TBT give lab numbers you can enforce on scheduled runs. Copy starter values from the budget thresholds template and mark them provisional for the first month.

In Apogee Watcher, site-level budgets can include FCP and TBT alongside vitals on mobile and desktop strategies. Alerts send when lab results exceed the thresholds you set. That supplements CrUX in test results; it does not replace field INP.

Common causes of poor FCP and TBT

FCP regressions

Slow TTFB or cold cache on HTML.
Render-blocking stylesheets and synchronous scripts in <head>.
Web fonts that delay first text paint (FOIT).
Large inline critical CSS or server-side work before first byte.

TBT regressions

Large JavaScript bundles parsed on the main thread during load.
Long tasks from tag managers loading many vendors at once.
Framework hydration on top of marketing scripts.
Synchronous layout or style work before load completes.

The same fixes often help vitals: reduce JavaScript, defer non-critical scripts, split code, and audit third parties. Poor FCP or TBT often means LCP or INP will slip next if you do not fix the underlying issue before CrUX updates.

Lab vs field: what to tell stakeholders

PageSpeed Insights shows lab Lighthouse data and CrUX field data when Google publishes it for the URL. FCP and TBT appear on the lab side only. LCP, INP, and CLS can appear in both, but only field percentiles count for Core Web Vitals pass rates in tools that use CrUX.

A clear client line: "We track FCP and TBT in scheduled lab tests to catch regressions early. We judge SEO page experience on field LCP, INP, and CLS." That matches Google's page experience documentation without treating lab metrics as ranking signals.

For setup across many sites, use the Core Web Vitals monitoring checklist for agencies and automated PageSpeed monitoring setup.

FAQ

Is First Contentful Paint a Core Web Vital?

No. FCP is a Lighthouse lab metric. It shows when the page first renders and often correlates with LCP, but Google does not include FCP in the Core Web Vitals set used for page experience evaluation.

Is Total Blocking Time the same as INP?

No. TBT is a lab metric for main-thread blocking after FCP during load. INP is a field metric for responsiveness across user interactions during the visit. Improving TBT often helps INP when JavaScript blocks the main thread early, but post-load interactions need separate testing.

What is a good FCP score?

In Lighthouse lab terms, FCP at or below 1,800 ms is "good", using the same bands as our performance budget template. Adjust thresholds per site after you record a baseline.

What is a good TBT score?

Lab TBT at or below 200 ms is "good" on the same scale. Sites with heavy JavaScript may need stricter internal budgets even when the public band says "good."

Should we add FCP and TBT to client reports?

Yes, as supporting metrics under the vitals summary, not as replacements. One line each on what changed and whether it points to loading (FCP) or main-thread JavaScript (TBT) is enough for most quarterly reviews.

Does CrUX show FCP and TBT?

CrUX reports Core Web Vitals and related field metrics. FCP and TBT come from lab and synthetic tests. Use scheduled PageSpeed or Lighthouse runs to track them over time.

Can we set performance budgets on FCP and TBT?

Yes. Many teams set provisional FCP and TBT limits per template alongside LCP, INP, and CLS. Tighten after a month of scheduled runs so alerts stay useful.

FCP and TBT are supporting lab metrics beside LCP, INP, and CLS: early render time and main-thread blocking during load. Add them to budgets when they help you explain score changes and catch regressions before CrUX field data updates.

Start a free Apogee Watcher account to schedule PageSpeed tests with vitals plus FCP and TBT budgets across client sites, or run a free domain check on a URL that scored worse in a recent Lighthouse run.

When the performance budget line item scares procurement (and what to send instead)

Apogee Watcher — Mon, 08 Jun 2026 10:34:11 +0000

Procurement once sent back a signed SOW because the line item said "performance budget monitoring" and the reviewer asked whether that was a marketing tool, a security product, or an SEO subscription they had already paid for elsewhere.

The work was real. The client wanted LCP and INP thresholds on key templates. Engineering wanted alerts before deploy regressions reached production. Procurement wanted a category, a deliverable list, and something that did not sound like three vendors rolled into one vague retainer.

That delay is common when agencies sell web performance as expertise without documents procurement recognises. Below is what we send instead: how we name the line item, what we attach, and how we separate monitoring from remediation so finance can approve the part they are actually buying.

Why procurement pushes back on performance budget line items

Procurement teams are not grading Lighthouse scores. They are matching invoices to purchase categories, checking for duplicate tooling, and making sure scope does not expand without a change order.

Performance work draws extra review when the proposal sounds like:

A second SEO retainer ("Core Web Vitals", "page experience", "Google rankings" in the same paragraph).
A tool nobody budgeted ("we will use our monitoring platform" with no deliverable list).
Unbounded engineering ("optimise site speed" with no URL list, schedule, or clear end point).
Jargon without a thresholds document (LCP and INP named, nothing the client can attach to the contract).

The fix is not dumbing down the technical work. It is translating the line item into deliverables procurement can map: scheduled tests, agreed thresholds, reports, alert response, and explicit exclusions.

Performance budget vs SEO spend: how we keep them separate

Clients often already pay for SEO or paid media. When performance monitoring is described in the same breath as "rankings," finance assumes overlap.

We separate the conversation for finance and procurement:

Topic	What we say it is	What we say it is not
Performance budgets	Agreed limits on LCP, INP, CLS (and related lab signals) with breach alerts	A guarantee of search position
Monitoring retainer	Scheduled tests, stored history, reports the client can share	Unlimited development hours
Remediation	Scoped fixes when budgets break; change order or separate sprint	Included in every monitoring invoice by default

Procurement approves faster when monitoring is scheduled tests and reporting with numbers attached, and fixes are optional or priced separately. The technical detail stays in the thresholds; the invoice wording stays narrow.

For the full performance budget strategy (types of budgets, enforcement, automation), our Watcher guide covers the how-to: The complete guide to performance budgets for web teams. This post covers what we put in front of procurement.

What to send procurement for a performance budget line item (not a Lighthouse export)

When a line item is delayed, we attach a short pack (PDF or shared doc, four to six pages max):

Scope summary: number of sites, URL groups monitored (homepage, templates, checkout, etc.), mobile and desktop, how often tests run (weekly, daily, after each deploy).
Threshold appendix: one table of agreed limits per template, copied from our client-facing budget doc (not a raw PSI screenshot).
Deliverables list: example monthly report, who receives alerts, how often you meet to review results, who responds and by when.
Exclusions: no unlimited dev hours, no content rewrites, no rank guarantees, no new third-party licences unless pre-approved.
Tooling note: monitoring runs through our agency stack; client does not procure separate PSI API keys unless their policy requires it.

Procurement rarely reads INP definitions. They do read "12 URLs, twice weekly, report on the first business day, breaches triaged within one business day." Numbers beat adjectives.

Performance budget template: the document finance can file

The threshold table is what turns "performance budget" from jargon into a contract appendix.

We use a site-type baseline (e-commerce, brochure, SaaS marketing, etc.), then mark client-specific overrides in a second column with a one-line reason ("checkout INP stricter after Q4 incident"). That table becomes Appendix B or similar in the SOW.

If you need starting numbers and site-type bands, the printable structure is on our blog: Performance budget thresholds template. Here we only stress the procurement job: thresholds the client can attach to the contract, not another theory post.

Account managers keep a client-facing version without internal early-warning levels. Engineering keeps warning and critical tiers inside the monitoring tool. Procurement sees the contract thresholds and how often you report. Same numbers, three views.

Performance budget line items: how we phrase them on the invoice

Labels that cleared review more often than "performance optimisation":

Core Web Vitals monitoring and reporting (N sites, schedule as per SOW appendix)
Scheduled PageSpeed monitoring and performance budget reporting
Web performance regression monitoring (synthetic tests; excludes development remediation)

We avoid "SEO performance package" on the same line as monitoring. If SEO and performance are sold as one package, we split line items anyway so procurement can approve monitoring even when SEO is questioned.

For renewal conversations, we lead with breaches caught and resolved and reports delivered, not Lighthouse points gained. Finance cares whether the service continues; engineering tracks metrics.

Change orders when performance budgets break

Monitoring contracts pass review faster when remediation is defined up front:

Included: triage, reproduce, classify (deploy vs third party vs content), summary in the monthly report.
Change order: code changes, theme work, tag-manager rebuilds, optimisation on templates you add later.

Clients understand "we will tell you within 48 hours why LCP regressed" as monitoring. They understand "we will refactor the hero pipeline" as project work. Procurement can price and approve each separately.

Performance budget checklist before procurement review

Before we submit a performance budget line item for procurement review, we confirm:

Threshold table exists and matches what is configured in monitoring.
URL list is named (not "key pages TBD").
Test schedule and report format include dates (not "regular check-ins").
SEO rank language is absent from the monitoring exhibit.
Remediation is excluded or priced on its own line.

Missing any of those five is usually why the line item stays in "clarification requested" for two weeks.

Next step: build a one-page performance budget appendix for one client

Pick the client whose renewal is held up on vague performance language. Copy your threshold table into a one-page appendix: metrics, limits, URLs, test schedule, deliverables, exclusions. Attach it to the draft SOW before the next procurement call.

If you still need baseline numbers by site type, start from the performance budget thresholds template. If you need the longer enforcement and automation guide for engineering, pair it with The complete guide to performance budgets.

Procurement approves clarity. Performance budgets give engineering clarity; the appendix gives finance something to sign.

How to Onboard a New Client for Performance Monitoring

Apogee Watcher — Thu, 04 Jun 2026 21:02:19 +0000

You sold performance monitoring on the proposal, and the contract is signed. Now delivery has three days before someone asks why nothing is live yet.

Onboarding is where many retainers wobble. Teams either rush a PageSpeed screenshot into Slack, or disappear into setup for two weeks and lose the client's attention. A repeatable workflow fixes that because every client moves through the same phases, owners, and outputs.

This guide is the process layer. For a copy-and-paste audit list, use our Site Audit Checklist: Onboarding a New Client for Performance Monitoring. Here we cover who does what, in what order, and what "done" looks like before the first monthly review.

What successful onboarding produces

Before you open a tool, agree on the finish line. For most agency retainers, onboarding is complete when you can show:

A written scope (domains, environments, priority templates, mobile and desktop).
Scheduled tests running on priority URLs without manual PSI tabs.
A baseline snapshot with three named actions, not a score dump.
Budgets and alerts with one internal owner and one client-facing contact.
A client note that explains what you monitor, what is failing, and what happens next.

If you cannot tick those five, you are still in setup. That distinction keeps account managers from promising monthly packs before the signal is trustworthy.

Phase 1: Align scope before kickoff (sales to delivery handoff)

The fastest onboarding failures start in sales. Delivery inherits a vague line like "monitor Core Web Vitals" with no page list, no cadence, and no alert owner.

Run a fifteen-minute internal handoff while the deal is fresh. Capture:

Production domain(s) and whether staging is in scope.
Business-critical URLs (homepage, pricing, lead form, checkout, booking).
Reporting promise (weekly internal, monthly client-facing, or alert-only).
Whether the client expects fixes, monitoring only, or both.
Quota reality: how many URLs, how often, mobile plus desktop.

If the sale included monitoring but not remediation, say that in writing before kickoff. Clients who expect you to fix every regression on day three will treat alerts as broken delivery.

For positioning and packaging, see How to Sell Performance Monitoring Services to Your Clients. For why automation belongs in the retainer at all, see Why Agencies Need Automated Performance Monitoring in 2026.

Phase 2: Kickoff call (day 0 to 2)

Keep the client kickoff under forty-five minutes. You are confirming facts, not performing a full audit live.

Attendees

Client: one business owner (priorities) and one technical contact (access, releases).
Agency: delivery lead plus whoever owns alerts and reporting.

Agenda that works

Confirm domains and environments (production only unless staging is contracted).
Confirm priority templates and any excluded paths (search, preview, admin).
Confirm consent and tag constraints if they ever ask for real-user monitoring later.
Confirm alert recipients and who responds first internally.
Confirm first client-facing summary date (usually end of week one).

End with a single follow-up email listing decisions. Ambiguity here becomes "why is that URL monitored?" in week two.

Phase 3: Configure monitoring in the app (day 2 to 5)

Tool steps differ by vendor. The sequence below matches how we see agencies run Apogee Watcher; adapt if you use another stack.

Create the client site in your organisation

Add the client as a site under your agency organisation so quotas, roles, and history stay separate from other clients. If several account managers need access without billing rights, assign team roles and access control before the first scheduled run: the Admin role configures, the Manager role tunes budgets, and the Viewer role reads dashboards in the app.

Build the URL inventory

Start from the sitemap, then force-add URLs the sitemap misses. Automated page discovery reduces paste-and-forget gaps when marketing publishes new landers, but you still curate what enters the scheduled set.

Practical first pass for most clients:

One homepage.
Two to five conversion URLs.
Five to ten template representatives (service pages, product grids, key articles).

Resist monitoring every tag archive on day one. Expand after triage stays manageable.

Set test frequency and priority

Match cadence to release risk, not equality across clients. A Shopify store in peak season earns more frequent runs than a stable brochure site. Our guide on scheduling test frequency and priority across a portfolio walks through hourly-to-monthly bands and quota trade-offs.

Enable mobile and desktop as separate series. Sponsors still ask about desktop even when analytics skew mobile.

Run the baseline

Trigger an initial run on priority URLs. Record LCP, INP, CLS, and performance score, plus one line of context per failing URL: likely cause and business impact. A number without context does not survive the first QBR.

For a fuller setup walkthrough across many sites, see How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

Phase 4: Budgets, alerts, and internal response (day 5 to 7)

Monitoring becomes operational when thresholds and owners exist.

Set starter budgets

Use pragmatic thresholds on the first pass. Tighten after you have a month of noise and signal. The Performance Budget Thresholds Template gives starting bands you can mark provisional in the client file.

Wire alerts to a human

Email alerts are enough for many teams today. Define:

who receives the first alert,
who triages (dev vs account manager),
who talks to the client,
what counts as escalation versus backlog.

Without that path, alerts land in a shared inbox and regressions age quietly. For alert philosophy and cooldown thinking, read From Reactive to Proactive: How Smart Alerts Change Performance Monitoring.

Log the internal runbook

One page in your wiki is enough: scope, owners, budget notes, link to the site in the app, and the three current actions. Future you will not remember why /pricing is on high priority.

Phase 5: Client-facing onboarding (end of week one)

Clients do not need a forty-slide deck. They need clarity.

Send a short onboarding complete note:

what URLs and devices you monitor,
baseline status in plain language (how many URLs pass, which matter most),
top three actions with owner and date,
when the first monthly review happens.

The checklist post includes a ready-to-send email skeleton you can adapt.

If the client bought monitoring to prove value before optimisation work, be explicit: week one is measurement and prioritisation, not every fix shipped.

Phase 6: First thirty days and handoff to steady state

Treat the first month as calibration, not perfection.

Week	Focus
1	Finish setup, baseline, client note, alert owner confirmed
2	Ship the highest-impact fix on a failing priority URL
3	Re-run tests; confirm the regression moved or document blockers
4	Run the first monthly review; adjust budgets and URL scope

Use the Monthly Performance Review Template for Agency Teams in week four so the client sees rhythm, not a one-off fire drill.

After day thirty, onboarding is "closed" internally. Ongoing work is fixes, reporting, and scope changes when they add templates or microsites.

Onboarding across multiple clients without chaos

Agencies that onboard well run the same phases in parallel, not custom theatre per logo.

One organisation in your monitoring tool with a site per client.
A standard role map (who is Admin vs Manager vs Viewer).
A standard starter URL set per vertical (brochure, ecommerce, SaaS marketing).
A standard week-one email and week-four review slot.

Portfolio visibility matters when you have more than a handful of sites. Managing multiple client sites in one dashboard is the product shape we built for that; the onboarding phases stay the same whether you use one dashboard or several logins.

Common onboarding mistakes

Skipping the sales-to-delivery handoff

Delivery discovers staging was never in scope, or the client expected unlimited URLs. Fix scope on paper before schedules run.

Monitoring everything on day one

Large URL lists create alert noise and burn quota. Start narrow, expand with intent.

No named alert owner

Shared responsibility is no responsibility. One internal name on the runbook.

Confusing onboarding with full remediation

Capture issues, prioritise, assign. Deep dives belong in delivery sprints, not in the kickoff call.

Promising polished reporting before signal stabilises

Month one is baseline plus top actions. Polished packs come after trends exist.

How this guide relates to the site audit checklist

Think of two layers:

This article: phases, owners, timelines, client comms, handoff to month one.
Site audit checklist: tick boxes for access, URLs, measurement, budgets, reporting, handover.

Run the process here; execute ticks from the checklist inside each phase. For ongoing CWV operations after onboarding, keep the Core Web Vitals monitoring checklist for agencies nearby.

FAQ

How long should onboarding take per client?

With clear access and a standard URL set, many teams finish setup and a baseline in one to two working days. The full first-month cadence is four weeks.

Should we onboard staging and production together?

Only if the contract includes staging. Otherwise you alert on environments the client does not care about publicly.

What if the client has no performance budget yet?

Use provisional thresholds, label them as starters, and revise after four weeks of runs.

Can we onboard before the new site launches?

You can baseline a preview URL, but schedules on production should start at launch or you will chase the wrong environment.

We already use a checklist. Do we need this workflow too?

Yes, if teams still drift on owners and client comms. The checklist records tasks; this guide records sequence and outcomes.

Does onboarding differ for WordPress or ecommerce?

URL priorities differ (checkout, category templates, plugin-heavy pages), but phases stay the same. Platform-specific measurement notes live in guides like WordPress performance monitoring and e-commerce performance monitoring.

Onboard with the same five outputs every time: scope, schedules, baseline with actions, alerts with an owner, and a client note that sets expectations. Run the site audit checklist inside that frame, then move into monthly reviews once week four lands.

If you are standardising onboarding across a growing roster, start a free Apogee Watcher account or run a free domain check on the client's production host before kickoff so the baseline conversation starts with data, not promises.

Portfolio dashboards: what multi-tenant changes day to day

Apogee Watcher — Wed, 03 Jun 2026 21:31:32 +0000

"Multi-tenant" shows up on every SaaS pricing page. For agency performance work, the useful question is narrower: what changes on Tuesday morning when twelve client sites live in one workspace instead of twelve browser profiles and a shared spreadsheet?

We asked that after migrating a small dev team off the "one free PSI account per client" pattern. The product features (organisations, sites, pages, schedules) are documented on our main blog. This post is the habits layer: what multi-tenant multi site performance monitoring actually changes in standup, handoffs, and fire drills.

What multi-tenant means on an agency performance dashboard

In our usage, multi-tenant means one team login, many monitored properties, shared rules with per-site exceptions. Not "your client gets their own product account." Not "we paste the same API key into twelve cron jobs."

Before that model, portfolio web performance was a reconciliation task. Someone exported CSVs, someone else merged them, and the Monday question "who is red on mobile LCP?" took forty minutes before anyone fixed code.

After it, the question is a screen scan: which sites missed runs, which pages breached budgets, who owns follow-up. The dashboard is the system of record; the spreadsheet is optional export.

If you want the object model (organisation → site → page) and what the product surface looks like, read the multi-site dashboard spotlight. This piece stays on behaviour.

Monday standup: from client tabs to portfolio questions

Our standup used to open with "any fires?" and drift into whoever shouted loudest. With a portfolio view, we fixed a short script:

Any site with no test in the last scheduled window? (stale data, not stale client.)
Any budget breach still open from last week?
Any new site added without an owner name in the notes?

That third item sounds administrative. It prevented the classic multi-tenant failure: fifty sites in the list, twelve people on the team, and three "mystery" properties nobody will touch in retro.

Portfolio questions also surface patterns single-client tabs hide. Three retail clients drifting on INP after the same tag manager update is a platform decision. One client's tab only shows one brand panicking.

Multi site performance monitoring: naming sites for humans

Multi-tenant only works if the site list reads like your retainer list, not like DNS archaeology.

We renamed entries to what account managers say on calls ("Northwind retail", not northwind-prod-uk). We archive sites when contracts end instead of leaving ghosts that turn every portfolio scan into noise. We add one line in site notes: primary contact and what "done" means for alerts (fix code vs email client vs wait for their deploy).

Those conventions are boring. They are also what separates a agency performance dashboard you trust from a dumping ground of hostnames you are afraid to delete.

Per-site exceptions without losing global discipline

Multi-tenant does not mean one threshold for everyone. A brochure site and a checkout-heavy shop should not share the same LCP budget. The operational shift is where those exceptions live: next to the site object, visible when you scan the portfolio, not in a wiki page titled thresholds_final_v7.md.

We set global defaults once (mobile + desktop schedule, baseline budgets, alert channel). We document exceptions at the site level with a reason ("client requested weekly only", "staging hostname, alerts off"). When someone goes on holiday, the substitute engineer reads the site note instead of paging the wrong client.

For setup steps and schedule choices, the automated PageSpeed monitoring for multiple sites guide covers the procedural side. Day to day, the win is exceptions you can see without opening five tools.

Handoffs: account team vs engineering

Multi-tenant dashboards fail when only engineers look at them. Our account leads do not tune Lighthouse configs. They do need to know whether last week's report still reflects reality.

We agreed a lightweight split:

Engineering owns schedules, budgets, alert routing, and regression triage.
Account owns site list hygiene (live vs archived), client comms when a breach is client-visible, and scheduling review calls when trends move.

The shared artifact is the site list plus last-run timestamps. Account can open a site, see green/red at a high level, and ask sensible questions. Engineering is not screenshotting PSI into Slack anymore.

That handoff is what "monitor multiple websites performance" means in practice. One portfolio, two roles, same numbers.

Fire drills: shorter path from email to URL

When a client emails "checkout feels slow", the old path was: find which PSI bookmark, guess mobile or desktop, wonder if anyone tested since the deploy.

The new path: open the named site, filter to checkout URLs, read last run and deploy notes, compare mobile vs desktop on the same row. Multi-tenant shortens the search phase. It does not replace debugging.

We still open deeper tools for traces and filmstrips. The dashboard answers "is this an ongoing regression or a stale test?" in under two minutes. That alone cut duplicate fire drills where two people ran the same manual PSI check unaware of each other.

Automated pagespeed monitoring setup: what we stopped doing

Moving to one workspace killed a few rituals that felt productive but did not scale:

Rotating "PSI hero" weeks where one developer manually tested everyone's homepage.
Per-client folders of PDF exports with no link to current schedules.
Shared inbox alerts with no site name in the subject (mute follows quickly).

We kept weekly portfolio review as a calendar event. We dropped the pretence that everyone maintains their own bookmark bar as governance.

When multi-tenant is not enough

Honest limits:

Deep diagnostics still need purpose-built tools.
Full RUM still lives in analytics if the client pays for it.
Client-facing logins may still be exports or shared reports until access controls mature.

Multi-tenant changes how your team operates internally. It does not replace every stakeholder view. We position it as the control plane for scheduled synthetic tests, not the entire observability strategy.

Next step: run one portfolio review with names and owners

Before you add site number thirteen, run this once:

Open your site list (or build one if you are still on bookmarks).
Mark each property active or archived; delete ghosts.
Assign a human owner per active site.
Note one per-site exception that matters (schedule, budget, or alert route).
Ask the portfolio question: any site with no recent run or open breach?

If that review takes more than twenty minutes, your multi-tenant surface is probably fine but your naming and ownership rules need work, not another tool.

For product detail on organisations, sites, and pages, see Managing multiple client sites in one dashboard. For schedules, discovery, and budgets when you configure the portfolio, use How to set up automated PageSpeed monitoring for multiple sites.

Multi-tenant is the architecture. Tuesday morning is the proof.

Comparing PageSpeed Monitoring Tools: Features Agencies Need

Apogee Watcher — Tue, 02 Jun 2026 05:18:37 +0000

Agency leads rarely ask for another Lighthouse score. They want to know whether the stack still works at fifteen client sites, whether account managers can read the reports, and whether anyone will catch a /checkout regression before the sponsor screenshots PageSpeed Insights.

A useful pagespeed monitoring tools comparison answers those questions. Vendor feature grids are easy to skim and forget. Retainers break on stale URL lists, per-site licence maths, noisy alerts, and monthly reporting that takes longer than the fix.

This guide is for teams running many production sites. We sort tools by the job they do, list what to demand before you buy, and link to deeper comparisons where one product needs its own article. Prices and limits change; check each vendor’s site before you sign.

Diagnostics vs monitoring: what to decide first

Before trials, agree which problem you are solving.

Diagnostics answer: why is this URL slow right now? They give waterfalls, one-off runs, and evidence you can forward in Slack.

Monitoring answers: did performance change on the URLs we defend, and who acts? That needs schedules, history, thresholds, and a named owner.

Stacks fail when diagnostics pretend to be monitoring, or when monitoring runs on a URL list nobody maintains. If that line is still fuzzy, start with PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough.

For agencies, also score four operational points:

Portfolio visibility: can you see risk across clients without separate logins?
Running cost: licence fees plus hours spent on scripts, URL lists, and reports.
Evidence quality: lab metrics, CrUX field context, and outputs a client understands.
Governance: roles, quotas, and who can change budgets without breaking billing.

Miss those and you compare scores as if they were interchangeable.

Four types of PageSpeed monitoring tools agencies combine

No single product covers every workflow. Mature teams mix types and keep roles explicit.

Free diagnostics and field reports

PageSpeed Insights, WebPageTest, Chrome DevTools Lighthouse, and Search Console Core Web Vitals reports are strong for quick checks, post-fix proof, and teaching sponsors what LCP or INP mean.

They are weak as the only system for ten retainers: little portfolio history, alerting, or shared workflow. Keep them; do not expect them to run the portfolio.

Longer treatment: Best Free PageSpeed Monitoring Tools.

CI pipelines and custom scripts

Lighthouse CI and cron jobs calling PSI or Lighthouse suit teams that already own deploy pipelines. Thresholds per build work well on templates you control.

The cost shifts to engineering time. Cross-client reporting and account-manager-friendly output usually need another layer. Forum threads often describe “monitoring became a part-time job” once URL counts and client decks enter the picture.

Synthetic monitoring SaaS (scheduled lab, often CrUX)

GTmetrix, DebugBear, Calibre, Oh Dear, SpeedCurve, PageVitals (WordPress-oriented), and Apogee Watcher sit here. You get scheduled runs, charts, alerts, and reports without hosting runners yourself.

Trade-offs are depth per URL versus breadth across sites, whether RUM needs your script on the client site, and how price scales when site counts grow.

Product analytics with Web Vitals (RUM-first)

PostHog Web Vitals and similar stacks read real sessions where instrumentation is allowed. That helps logged-in SaaS flows synthetic tests cannot fully mirror.

On agency retainers, consent, tag managers, and subdomain politics often block one snippet everywhere. Synthetic coverage still matters for public URLs you cannot instrument.

We treat analytics as adjacent: Apogee Watcher vs PostHog Web Vitals.

PageSpeed monitoring feature checklist for agencies

Use this when you compare performance monitoring tools across a portfolio. Every row need not be “yes” on day one; gaps should be conscious.

Feature	Why agencies care	What good looks like
Multi-site / multi-tenant dashboard	One login for the portfolio	Organisations, sites, or projects, not one account per client
Scheduled tests	Monitoring without calendar rituals	Hourly to monthly per site; mobile and desktop as separate series
URL inventory hygiene	CMS and campaigns add routes	Automated discovery (sitemap/crawl) or owned manual lists
Lab + field context	Sponsors ask about real users	Lighthouse lab plus CrUX where published for the URL
Performance budgets	Scores become pass/fail	Thresholds on LCP, INP, CLS, or scores; breaches trigger alerts
Alert routing	Regressions reach a human	Email at minimum; Slack or webhooks if your stack uses them
Historical retention	Trends beat screenshots	Enough history for monthly reviews and post-deploy checks
Roles and permissions	Managers vs viewers vs billing	Clear RBAC; viewers who cannot burn quota
Quota visibility	Sales can outrun API limits	Transparent test counts; per-site or portfolio caps you can plan
Client-ready reporting	Renewals need proof	Exports or share links account managers can open alone
Prospecting / audits (optional)	New business reuses performance data	One-page domain reports before onboarding, if you sell that way
Pricing at 10–50 sites	Per-site fees eat margin	Predictable tiers; clear rules for staging vs production

Pair the table with How to Schedule Test Frequency and Priority Across Your Portfolio if you are fixing cadence before you buy.

How GTmetrix, DebugBear, PSI, and managed monitors compare for agencies

Read this as workflow fit, not a winner table. Confirm limits on each pricing page.

Tool / category	Best when your job is…	Typical friction at agency scale
PSI / WebPageTest	Explain one URL; debug after an alert	Manual portfolio passes; no native multi-client model
Lighthouse CI	Block regressions on owned templates in CI	Config ownership; weak default client reporting
GTmetrix	Deep lab runs, regions, waterfall evidence	Per-account patterns; depth vs portfolio breadth (see GTmetrix vs Watcher below)
DebugBear	Premium synthetic + optional RUM	Higher entry price; depth shines; many sites need discipline (see DebugBear vs Watcher below)
SpeedCurve / Calibre	RUM + synthetic with budget	Often praised and priced in roughly $90–$500+/mo bands in community threads
Oh Dear	Uptime + Lighthouse + crawl together	Per-site cost hurts as client count climbs
PageVitals	WordPress optimisation + monitoring	Different focus than portfolio-first monitors; PageVitals vs Watcher post on the calendar
Apogee Watcher	Scheduled PSI monitoring across many sites, no per-client API keys	No first-party RUM; add RUM elsewhere when you must

We favour Watcher for portfolio monitoring and still send people to GTmetrix or WebPageTest for location matrices or waterfall forensics on one URL. Deeper splits: GTmetrix vs Apogee Watcher, DebugBear vs Apogee Watcher.

PageSpeed monitoring pricing when you manage 5–20 client sites

The invoice line is half the picture.

Per-site or per-monitor fees compound. A tool that felt fine for three domains can double when you add staging, microsites, and campaign landers.

Seat limits bite when account managers need read-only access but must not touch API quotas. “Five seats” often means shared logins or skipped governance.

Test quotas decide whether your monitoring schedule is real. Daily mobile and desktop on twenty URLs is not one test.

Hidden time shows up as spreadsheet exports, Monday PSI rituals, and rebuilding URL lists after CMS migrations. Automated vs Manual PageSpeed Testing: A Time and Cost Comparison puts that in hours.

Ask vendors what month two costs when you add six sites and two viewers. If only sales can answer, note that.

When agencies should keep free PageSpeed tools

Do not drop PSI or WebPageTest when you buy a monitor. Split roles instead:

Monitor: scheduled baselines on retainer URLs.
Diagnose: deep runs after a budget breach or a one-off sponsor question.
Report: monthly narrative tied to thresholds, not a folder of unrelated PDFs.

Core Web Vitals Monitoring Checklist for Agencies templates that split.

When to switch from free tools to managed PageSpeed monitoring

Free and DIY layers are no longer enough as your main system when:

You run many production sites and cannot see portfolio risk in one place.
Alerts depend on someone remembering to test.
URL lists drift after launches while dashboards stay green.
Client reporting takes longer than fixing the worst regression.
Different people use different test settings, so trends disagree.

Keep free tools for investigation. Pay for schedules, history, budgets, and roles. Why Agencies Need Automated Performance Monitoring in 2026 covers the operational case.

How Apogee Watcher compares for multi-site agencies

We built Watcher for breadth first: many sites, scheduled PageSpeed Insights runs (Lighthouse lab plus CrUX where Google publishes field data), performance budgets, email alerts, automated page discovery, and organisation-scoped roles. We hold the PSI API relationship so your team is not juggling Google keys per client.

Gaps we state plainly: no first-party RUM, no DebugBear-style third-party experiments in-product, and integration depth (Slack, white-label PDFs, other channels) depends on tier. Confirm what is live on Features and Pricing.

Optional Leads Management adds one-page performance reports and share links for prospects. It supplements monitoring; it does not replace a CRM.

Need session-level proof on one instrumented SaaS app? Pair us with a RUM vendor or lean on DebugBear or SpeedCurve for that lane. Need coverage across many client origins without snippets? That is the problem we optimise for.

Try multi-page reporting without an account at apogeewatcher.com/check.

Deeper PageSpeed tool comparisons on the blog

Use this article to pick categories; use these posts when you are down to two vendors:

PageVitals vs Apogee Watcher is on the calendar for WordPress-heavy shops.

FAQ

What is the best PageSpeed monitoring tool for agencies?

There is no universal winner. WordPress-heavy teams weigh PageVitals differently from teams that need fifteen unrelated domains on one dashboard. Use the checklist above, then pilot two weeks on your noisiest sites.

How is synthetic monitoring different from RUM?

Synthetic runs hit URLs on a schedule (lab, often plus CrUX). RUM reads sessions where your script runs. Most agencies use synthetic for portfolio coverage and add RUM only where instrumentation is approved.

Is weekly PageSpeed Insights enough for monitoring?

For one site, sometimes. For many sites, weekly manual PSI stays fragile: URLs drift, alerts live in people’s heads, and reporting piles up. Keep PSI; rarely rely on it alone.

Should Lighthouse CI be replaced by a SaaS monitor?

Usually no. CI guards templates you ship; SaaS watches production URLs and client-owned stacks. Use both with clear roles.

How does Apogee Watcher compare on price?

We publish tiers from freelancer to agency scale on Pricing. Premium synthetic/RUM tools often start higher; free tools cost time. Compare licence plus maintenance hours.

Can Watcher run alongside GTmetrix or DebugBear?

Yes. Many teams monitor broadly in Watcher, diagnose in GTmetrix or WebPageTest, and add DebugBear where RUM is required on a flagship site.

Choose the tool type first, then score vendors on the agency checklist. Keep free tools for investigation; put schedules, budgets, and history where regressions cannot hide.

For hosted multi-site monitoring without CI upkeep or per-client API keys, start a free Apogee Watcher account and schedule a baseline this week. For a no-signup domain sample, use the free domain check.

PageVitals vs Apogee Watcher: RUM, CI/CD, and Agency Portfolio Monitoring

Apogee Watcher — Mon, 01 Jun 2026 20:49:41 +0000

PageVitals often appears right after a broader pagespeed monitoring tools comparison. You may be evaluating it as a pagevitals alternative for the whole portfolio, or wondering whether another product should carry the long tail while PageVitals handles the sites that need RUM or pipeline gates.

We compare PageVitals and Apogee Watcher on workflow fit, not on who charges less. Both schedule synthetic tests, return Lighthouse-style lab data, and surface Chrome User Experience Report (CrUX) context where Google publishes field data. The real fork is how you onboard URLs, whether you need first-party pagespeed monitoring with RUM, and whether your constraint is depth on a few properties or multi-site performance monitoring across many client hosts.

Plans and integrations change. Check PageVitals and our features page before you sign.

Is PageVitals the right pagevitals alternative for your stack?

Short answer: it depends whether RUM, CI/CD, and multistep journeys are contract requirements, or whether you mainly need reliable synthetic coverage at portfolio scale.

PageVitals is strongest when you want lab and field signals in one product you control per URL list. Apogee Watcher is strongest when you want many sites under one organisation, with less manual URL maintenance and no snippet on every domain. The sections below spell out both sides; the comparison table is for trial planning, not declaring a winner.

What PageVitals includes for synthetic monitoring, RUM, and CI/CD

PageVitals describes itself as monitoring, analysis, and optimisation in one place. From public product and pricing pages, teams typically get:

Synthetic monitoring: scheduled Lighthouse runs, waterfalls, performance budgets, and history.
Field testing / RUM: a script on the site records visits; LCP, INP, CLS, and TTFB breakdowns can come from those sessions, not only aggregate CrUX.
CrUX reporting: Google’s public field dataset, alongside your own RUM where the script is installed.
Multistep tests: flows across several URLs (checkout, signup, publishing) that a single-URL synthetic run may miss.
Eleven synthetic regions: useful when CDN, ads, or locale change behaviour by geography.
CI/CD, API, and webhooks: on Growth plans and above, beside Slack and email alerts.
Tests behind login: Growth+ can target authenticated views once configured.
Unlimited users: all tiers; granular website access for larger teams.

Freelancers often say PageVitals helps them track Lighthouse scores over time instead of one-off checks at launch. That fits a site-owner model: one dashboard, lab plus field on the URLs you add.

Onboarding stays page-centric. Docs walk you through adding pages; you choose what to watch rather than importing an agency-wide crawl on day one. Plans also limit how many websites you can attach (two on Starter, up to twenty-five on Pro on pricing at the time of writing).

What Apogee Watcher offers as a pagevitals alternative for agencies

Apogee Watcher is multi-tenant PageSpeed monitoring for teams running many production sites in one organisation. We schedule tests through Google’s PageSpeed Insights API (Lighthouse lab plus CrUX when Google returns field data for that URL). We do not ship first-party RUM: field context in each result is CrUX, not session telemetry from your snippet.

Where we focus effort:

Organisation → sites → pages, with Admin, Manager, and Viewer roles, so client work stays in one workspace without a new login per domain.
Automated page discovery from sitemaps and crawl paths (how discovery works), so new templates and campaign landers are less likely to drop off the list because nobody pasted a URL.
Performance budgets and email alerts on scheduled runs, with portfolio visibility across onboarded sites.
Agency-scale site counts on published tiers (including unlimited sites on Agency; confirm on pricing).

We state limits plainly: no multistep journey recorder, no eleven-region synthetic picker in-product (PSI uses Google’s lab profile), and no in-app substitute for PageVitals-style RUM breakdowns or Lighthouse CI-style pipeline gates today. When those are required, PageVitals or a dedicated CI/RUM tool still belongs in the stack.

A WordPress plugin is on our roadmap (coming soon). Until then, WordPress teams often monitor the public site URL in Watcher and use theme or host tools for wp-admin work. For platform context first, see WordPress Performance Monitoring: A Complete Guide.

PageVitals vs Apogee Watcher: feature comparison for agencies

Use the table to structure a pilot. Verify rows on each vendor’s site before purchase.

Topic	PageVitals (typical positioning)	Apogee Watcher
Primary signal	Synthetic Lighthouse + optional first-party RUM + CrUX	Synthetic via PSI (Lighthouse lab + CrUX where published)
Real-user depth	Session-level RUM with breakdowns and sampling (Growth+)	CrUX in test results; no site snippet
Onboarding	Add pages/URLs manually; multistep and tags per project	Sitemap-first discovery + crawl
Portfolio breadth	Website caps per plan (max 25 on Pro at time of writing)	Many sites per org; Agency tier unlimited sites (verify live limits)
Geography	11 synthetic regions	PSI lab profile (no in-product region picker)
Pipelines	REST API, webhooks, CI/CD on Growth+	Email alerts today; confirm Slack, webhook, and CI on the <a href="https://apogeewatcher.com/features">features page</a>
Team model	Unlimited users; per-website permissions	Unlimited users; Admin / Manager / Viewer per organisation
Strong fit	Owned stacks needing RUM, CI, multistep	Agencies covering many hosts without RUM everywhere

When to choose PageVitals for RUM, CI/CD, and multistep monitoring

Choose PageVitals as the primary monitor when first-party RUM is in scope, not optional.

Typical cases:

You must report INP or LCP on logged-in routes CrUX rarely covers well.
Stakeholders want breakdowns from your traffic, sample rates, and custom tags, not only URL-level CrUX percentiles.
CI/CD integration or webhooks should warn or block on regressions before merge, using Growth-tier automation.
Multistep tests matter for checkout, signup, or publishing flows you cannot reduce to one URL.
You need synthetic runs from multiple regions in one product.

DebugBear is another RUM-capable option; differences sit in experiments, reporting connectors, and portfolio shape. See DebugBear vs Apogee Watcher if both are on your list.

When to choose Apogee Watcher for multi-site synthetic monitoring

Choose Watcher when coverage and governance across many sites matter more than maximum instrumentation on one flagship app.

That usually means:

You run dozens of client domains and want one organisation, role separation, and scheduled checks without winning a RUM snippet on every origin (consent, tag managers, and security reviews often block that).
URL inventory moves faster than spreadsheets; discovery reduces “we only watch the homepage” gaps.
CrUX plus a steady synthetic schedule answers most QBR questions; you add RUM only where it pays for itself.
You want budgets and alerts on portfolio monitoring, not tied to a single-site project alone.

For manual PSI versus schedules, read PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough. For many sites at once, use How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

Can you use PageVitals and Apogee Watcher on the same portfolio?

Yes, and many agencies do.

A common split: PageVitals (or similar) on two or three high-stakes properties where RUM, multistep tests, or CI gates justify the setup cost; Watcher on the rest for scheduled synthetic coverage, discovery, budgets, and client-ready trends without per-site instrumentation.

Different sites carry different risk. A WooCommerce rebuild may need RUM and pipeline checks; a dozen brochure sites may only need CrUX-aware synthetic monitoring and an alert when /pricing slips. Layering tools is a portfolio decision, not a failure to pick one vendor.

FAQ: PageVitals alternative, RUM, and WordPress monitoring

Does Apogee Watcher replace PageVitals RUM?

No. If sponsors need session-level proof or sampled field volumes from your traffic, keep PageVitals (or another RUM product) on those URLs. Watcher adds scheduled PSI runs and portfolio workflow; it does not read visitors’ browsers.

Is CrUX enough if we skip RUM?

Often yes on public marketing URLs. CrUX reflects real Chrome users at URL or origin level. Expect thin data on new URLs, weak coverage for niche browsers, and gaps on heavy logged-in surfaces. Say that aloud in client meetings so nobody treats CrUX as full RUM.

We only run WordPress: which tool fits wordpress pagespeed monitoring?

PageVitals suits teams that want RUM, multistep, and CI in one product and will maintain page lists per site. Watcher suits teams that want many WordPress and non-WordPress sites on one agency dashboard with less manual URL entry. Neither replaces theme or plugin optimisation in wp-admin.

Where does the general tools roundup fit?

Start with Comparing PageSpeed Monitoring Tools: Features Agencies Need for categories and a checklist. Return here when PageVitals is the named finalist.

If manual URL lists are the bottleneck, review pricing and run a two-week pilot on the sites that alert most often. Keep PageVitals where RUM and CI/CD are non-negotiable; use Watcher for portfolio synthetic monitoring everywhere else.

Monitoring data as outreach evidence (without being creepy)

Apogee Watcher — Sun, 31 May 2026 20:04:24 +0000

A prospect replied to one of our score-band emails with a single line: "How long have you been watching our site?"

They were not angry about the LCP number; they were angry about the vibe. The audit was accurate and the mobile score was poor, but the message still read like surveillance because we named three URLs they had never shared with us, opened with "we noticed," and offered no obvious way to opt out.

That reply forced a policy conversation we should have had before the first batch went out. Monitoring data and prospecting data overlap, but ethical boundaries do not follow automatically. Public PageSpeed results are not private intelligence. How you frame them in performance audit outreach still decides whether you sound like a consultant or a stalker.

Below is the line we draw now: what monitoring evidence is fair to use, what we leave out of website speed audit cold email, and how we keep PageSpeed prospecting repeatable without feeling predatory.

Performance audit outreach: public evidence vs private inference

Most PageSpeed prospecting starts from URLs you could type into a browser yourself. Lab scores, Lighthouse diagnostics, and often CrUX field summaries for high-traffic origins are observable without credentials. That is the legitimate foundation.

Where teams cross into "creepy" is not the PSI run. It is the story around it:

Implying you tracked them over time when you ran one lab test yesterday.
Referencing pages that look like you crawled their entire sitemap for ammunition.
Naming internal staging hosts, preview URLs, or employee-only paths that should never appear in cold mail.
Claiming field data you do not have ("your customers are abandoning checkout") when you only saw a lab INP spike on a generic homepage.

We treat outreach evidence as what a prospect could verify in five minutes with PageSpeed Insights, plus our one-page report that shows the same source. If we cannot point to that shared surface, it does not go in the first email.

PageSpeed prospecting: lines we will not cross

After the "how long have you been watching" reply, we wrote explicit don'ts for anyone sending automated performance reports in outreach:

No contact scraping in the first touch. If we do not have a lawful basis to email someone, we do not email them because their homepage scored 40. Performance data is not consent.
No fake familiarity. Ban openers like "I was just on your site" when the sender never was. Say "we ran a PageSpeed audit on [URL]" instead.
No batch-size bragging. Do not mention how many sites you analysed this week. It signals batch outreach even when the observation is valid.
No competitor dunking by name in cold mail unless the prospect raised competitors. Compare metrics to thresholds, not to "Brand X."
No re-send loops on rejection. A "not interested" or spam complaint moves the record to rejected with a reason. Refreshing the score and emailing again is harassment dressed up as diligence.

These rules live in your playbook, not in the product settings. The workflow on our blog covers analyse → report → qualify → reach out; this post covers what humans agree not to say while they use it.

Website speed audit cold email: helpful vs surveillance tone

The same LCP figure can read two ways:

Surveillance tone: "We noticed your mobile LCP is 4.8s across /pricing, /demo, and /blog/category/updates. Your users are suffering."

Consultant tone: "We ran PageSpeed Insights on your homepage (mobile). LCP is 4.8s in lab, above the 2.5s guideline. That usually means hero or font load on first paint. Worth a look if mobile traffic matters to you."

Same data. Different trust outcome.

Patterns that helped replies without feeling invasive:

One URL in the opener, the URL you would defend on a call, not the whole crawl list.
Name the tool (PageSpeed Insights / Lighthouse lab) so they know how you know.
Attach or link one report, time-limited, instead of pasting every failing metric into the body.
One next step, low friction: reply, book 15 minutes, or ignore with no follow-up guilt trip.

If you need score-band templates as a starting point, the Watcher workflow post walks through qualification and messaging bands. This Hashnode piece is the tone guardrail on top.

One-page outreach reports: what belongs in the PDF

A one-page lead report works in outreach when it behaves like a gift, not a dossier.

Include:

Mobile and desktop snapshot for the agreed URL(s).
Top failing Core Web Vitals or lab metrics with plain-language "what this means."
Three prioritised fixes you would actually propose.
Your agency name, date, and how to reply.

Omit:

Full sitemap tables unless the prospect asked for a portfolio audit.
Weeks or months of history that imply you monitored them before contact.
Traffic or revenue guesses from third-party estimators.
Screenshots of their site with red circles on branding elements (reads like a shaming slide deck).

Share links should expire. Public share URLs are convenient; they also feel less like you dropped a permanent file in their inbox uninvited when the link has a visible expiry.

Core web vitals lead generation without manufactured urgency

Poor scores tempt exaggeration: "Your SEO is doomed" and "you are losing thousands daily" are easy sentences, and they are also why performance audit outreach gets lumped with spam.

We qualify by score band, but the email must match what the report actually shows:

Poor band: cite the failing metric and one business-adjacent consequence you can defend (slow first paint on a landing page, not "Google will delist you tomorrow").
Fair band: frame as prioritisation, not catastrophe.
Strong band: offer regression monitoring, not fake problems.

If CrUX field data is missing for the URL, say so. Lab-only outreach is still valid when you label it lab-only, but implying real-user certainty you do not have is the fastest way to lose technical buyers.

For the full batch workflow (analyse, report, qualify, reach out), see The PageSpeed prospecting workflow. For why monitoring habits transfer to prospecting at all, start with From monitoring to pipeline.

Sell performance audits agency teams: who sends, who reviews

Creepy outreach often comes from a handoff gap, not malice. An analyst generates fifty reports; a junior SDR blasts templates without reading them; a technical lead would never have sent half the observations.

Our fix was boring and effective:

Analyst owns accuracy: URL choice, mobile + desktop run, report generation.
Sender owns tone: they must read the report before send; one concrete observation in their own sentence.
Lead reviews first batch weekly: flag messages that sound like surveillance; update the banned phrase list.

We also stopped letting prospecting run on a different domain list than we would show the prospect on a call. If you would not walk a CEO through a URL on screen, it should not appear in line one of cold email.

Opt-out, rejection, and when to stop follow-up

Ethical PageSpeed prospecting needs an exit ramp:

Unsubscribe or "not interested" → rejected stage, no score refresh emails.
No reply after agreed sequence → stop. Note outcome; do not restart because LCP moved 0.2s.
Wrong contact → delete personal email from notes; do not swap in another address from LinkedIn scraping.

Rejected is a success state when it prevents a complaint. Document the reason in the lead record so the next person on the team does not repeat the mistake.

Internal checklist before the next batch goes out

Run this on ten draft emails before you hit send:

Could the prospect reproduce our main claim with PSI in five minutes?
Did we cite one URL, not a sitemap dump?
Did we name the tool and strategy (lab mobile/desktop)?
Is there a single CTA and an honest opt-out?
Would we be comfortable if they forwarded the email to their legal team?

If any answer is no, rewrite the opener, not the report.

Next step: write your "we do not" list before your next score-band templates

Copy the five don'ts from this post into your prospecting doc. Add two that match your market (regulated verticals, EU contacts, etc.). Then open your score-band templates and delete every phrase that implies ongoing surveillance.

Run one batch of ten with a human read on every send. Track reply quality, not just reply rate. The goal of monitoring data in outreach is credible evidence, not discomfort.

For the strategic case and step-by-step workflow, use the two Watcher posts linked above.

Evidence in public. Respect in the message. Stop when they say stop.

Free Domain PageSpeed Check: Multi-Page Performance Reports for Any Domain

Apogee Watcher — Sun, 31 May 2026 05:46:43 +0000

Many teams still judge a site from one URL, usually the homepage, or from a folder of PageSpeed Insights screenshots that are hard to compare and out of date a week later. That is enough for a quick impression. It is not enough when a launch adds twenty new routes, when a client asks whether performance is a site-wide problem, or when you need evidence before a first call.

We have added two related capabilities to Apogee Watcher: a free domain PageSpeed check anyone can run at apogeewatcher.com/check, and domain aggregated reports for customers who already monitor sites in the app. Both use the same reporting engine we ship for domain reports on monitored sites and for leads prospecting.

Why a homepage PageSpeed score is not enough for the whole domain

A fast homepage with slow product, checkout, or campaign landers tells a different story than a site that is weak everywhere. Mobile and desktop often diverge as well, so a single PSI tab on one strategy hides half the picture.

Domain-level reporting answers a narrower question: across representative URLs on this hostname, what do lab metrics look like, and where do the same Lighthouse themes repeat?

Watcher keeps mobile and desktop separate in the summary so you do not average away a breakpoint-specific regression. The report includes average scores and lab metrics per strategy, how results spread across pages, and grouped optimisation themes drawn from Lighthouse data. One weak template on many URLs reads differently from one outlier page on an otherwise healthy site.

What the free domain PageSpeed check includes

The public check is open to any domain with no account and no credit card.

Open https://apogeewatcher.com/check.
Enter the domain you want to evaluate.
Watcher discovers pages from the site (up to 20 URLs for the scan).
PageSpeed Insights-backed tests run on each selected page for mobile and desktop.
You receive an email with a link to a single aggregated report you can share.

The report is the same shape subscribers see for domain roll-ups: averages, per-page context, and recurring themes, not a pile of disconnected PSI exports. A strong homepage with weak checkout paths shows up clearly. A site that is slow across templates shows up too, which changes how you prioritise work and budget.

We built the flow for evaluation, not as a replacement for scheduled PageSpeed monitoring. It is the fastest way to see whether a domain deserves a deeper programme before you commit to tooling or a retainer.

How agencies use the free domain scan before a first client call

For agencies and consultants, the check is a practical opener with evidence instead of a generic performance pitch.

You can point to real LCP, INP, and CLS context across multiple URLs, send one link rather than a chain of browser tabs, and qualify whether the prospect needs an isolated fix or a broader engagement. That aligns with how many teams already use Watcher inside the product for prospecting; the public check puts similar proof in reach for anyone evaluating a domain before they sign up.

Pair the link with your usual discovery questions: release cadence, commerce vs brochure templates, and who owns front-end changes. The report gives you a shared artefact for the first technical conversation.

How site owners use the free check before a redesign or retainer

In-house teams and founders can use the scan as a low-friction baseline before a redesign, a platform migration, or a conversation with an external partner. If the numbers are acceptable, you have a dated record; if they are not, you know which parts of the site deserve attention first without paying for a full audit on day one.

When you are ready to continue, you can create a free Watcher account and import the scan into monitoring so scheduled tests and performance budgets pick up from the same pages and results. You do not need to rerun the entire discovery pass from zero.

Domain aggregated reports for teams already monitoring in Watcher

Customers who already monitor sites in the app can generate domain aggregated reports from the site screen whenever they need a client-facing snapshot.

Each report pulls the latest scheduled test results across active pages on that site (up to 20 URLs in the roll-up) and presents them in the same format as the public scan. You get a shareable link stakeholders can open without logging in. Your team can renew access when the link expires while keeping the report history in the app. White-label branding applies on plans that include it.

The goal is to stop rebuilding the narrative before every QBR or post-deploy update. The monitoring work you already run becomes the source for one structured summary, consistent with the share and email layouts described in Changelog #9.

Open a site in the app, generate the domain report from the reports area, and send the link when a sponsor asks what changed this month.

Why we launched the free domain PageSpeed check

We built this because homepage scores mislead people. A single URL can look fine while the rest of the site struggles. Agencies told us they were tired of stitching PSI exports into slides. Site owners wanted to know if they had one bad template or a wider problem. The free scan lets anyone answer that in minutes. For Watcher subscribers, the same report turns ongoing monitoring into something you can send to a client when they ask what changed, without starting from scratch.

Nektar Baziotis, Managing Director, Apogee Information Systems

Apogee Watcher sits alongside Apogee's broader web performance work: optimisation projects and technical audits when you need hands-on delivery. The free check is open to any domain; customer domain reports are for teams already using Watcher for scheduled monitoring.

Run a free domain scan or sign in to generate a report

Try the free domain check (no signup): https://apogeewatcher.com/check

Already monitoring sites: Sign in and open a site to generate a domain report from your latest test results.

New to Watcher: Create a free account (no credit card required), import a scan if you started on /check, then add budgets and alerts on the pages that matter.

If you manage a portfolio, continue with PageSpeed monitoring: how to schedule test frequency and priority once the domain check shows where to focus first.