Apogee Watcher

Most agencies do not lose clients because they did no work. They lose clients because the client cannot clearly see what happened, why it mattered, and what happens next. That gap is usually a reporting gap, not a delivery gap.

White-label performance reports solve that when they are done properly. White-label does not mean adding your logo to a PDF at month end. It means turning monitoring data into a branded, repeatable communication process your clients can trust.

A useful report answers four questions quickly: what changed since last period, whether that change is good or bad for user experience, why it changed, and what happens next with a named owner.

What a client-ready white-label structure includes:

• Executive summary with status, top mover, and next-step focus

• Compact trend view for agreed metrics (LCP, INP, CLS) with stable thresholds

• Incidents and regressions documented as an operating record, not forward-and-forget emails

• Completed work tied to impact, plus prioritised next actions with owners

Read more: white-label performance reports for agencies

Most agencies already say they care about speed. The failure mode is different: performance becomes a one-off audit before launch, a ticket someone opens after a client forwards a bad PageSpeed score, or a single developer's interest instead of a delivery standard.

When the one senior developer who "owns performance" is busy or leaves, the standard slips. Account managers cannot explain LCP in plain language. Designers do not know a hero image can dominate LCP as much as server response time.

Performance-first does not mean every site hits 100 on Lighthouse. It means your team agrees on what "good enough" is for a given client, when you measure it, and who is accountable when a regression ships. Launch checklists include a performance sign-off, not only UAT.

What we standardise first:

• Written thresholds by site type (e-commerce, lead-gen, publisher), not a private spreadsheet

• Performance in intake, during build, and after launch, not only launch week

• Shared visibility: account teams see the same numbers delivery sees

• Small rituals that fit existing meetings: a five-minute slot in weekly project review, a no-new-third-party rule in tickets

Read more: how to build a performance-first agency culture

Most performance projects start with images and fonts. The pages that still feel slow after the hero is optimised often have a different problem: third-party JavaScript. Tag managers, chat widgets, A/B tests, and social embeds compete with your first paint and the interactions INP measures.

We start with a cold inventory: view source for external script hosts, DevTools Network grouped by domain, and tag manager preview logs per template. Lighthouse's third-party audit ranks transfer size and main-thread blocking by origin. DevTools Performance shows when those scripts run, not only how large they are.

• Map every external host before you debate which tag to cut

• Rank offenders by CPU and blocking time, not only kilobytes

• Delay or fence tags that do not need the first paint

• Re-run lab and scheduled monitoring after one change at a time

Read more: how to identify and fix the worst third-party scripts

Most performance projects start with images and fonts. The pages that still feel slow after the hero is optimised often have a different problem: third-party JavaScript. Tag managers, chat widgets, A/B tests, and social embeds compete with your first paint and the interactions INP measures.

We start with a cold inventory: view source for external script hosts, DevTools Network grouped by domain, and tag manager preview logs per template. Lighthouse's third-party audit ranks transfer size and main-thread blocking by origin. DevTools Performance shows when those scripts run, not only how large they are.

• Map every external host before you debate which tag to cut

• Rank offenders by CPU and blocking time, not only kilobytes

• Delay or fence tags that do not need the first paint

• Re-run lab and scheduled monitoring after one change at a time

Read more: how to identify and fix the worst third-party scripts

Past five client sites, the performance stack stops being one bookmark. You have Client A's PageSpeed tab, Client B's exported PDF, and a spreadsheet someone updated in March. The person who owned the API key for Client C left last year. Multi-site monitoring becomes credential archaeology before it becomes ops.

Apogee Watcher mirrors how agencies already think: one organisation, many sites, pages under each hostname. You configure schedules and budgets per site without pasting a different Google API key for every domain. The dashboard is the shared control plane for scheduled PageSpeed runs and history.

• One org workspace with team billing and a portfolio site list

• Per-site schedules, budgets, and alert settings

• Run history tied to the site object for monthly client reviews

• Page lists from manual adds or sitemap discovery

Read more: multi site performance monitoring from one dashboard

"Automated vs manual" is not a religious choice. It is a question of how many hours your team spends clicking run test, how often releases change performance, and whether clients expect proof that someone is watching.

Manual PageSpeed testing rarely means no computers. It means human-triggered runs: someone opens PageSpeed Insights, pastes URLs, exports screenshots, and files them in a spreadsheet. History lives in Notion tables until the owner is on leave and nobody can find last month's LCP.

The visible work is a one-to-three-minute PSI run. The multiplier is everything else: client sites, key templates, mobile and desktop, reruns after a deploy, and the account lead who needs a summary before Friday's call. Ten clients with three pages each, both strategies, is already dozens of runs before anyone explains a bad number.

Automation buys repeatability when manual checks stop fitting the calendar: multiple clients on different stacks, frequent deploys, retainers that mention Core Web Vitals in writing, or leadership asking for evidence that performance is under management.

A rough monthly manual ledger:

• Sites × key pages × strategies × runs per month

• Minutes per run including export, filing, and note-taking

• Reporting and client meeting time already spent on performance

• Interruption cost when a client forwards a "Google says we are slow" email with no recent baseline

Strong teams often hybridise: WebPageTest for deep dives, scheduled synthetic monitoring for portfolio coverage, CI budgets before merge.

Read more: automated vs manual PageSpeed testing (time and cost comparison)

The CFO did not ask for Lighthouse scores. They asked which line on the P&L moved when the homepage got slower.

That question shows up in agency stand-ups more often than teams admit. Marketing has Search Console exports. Engineering has PSI tabs from Monday. Nobody has one sentence finance can paste into a business case.

Published research keeps returning to the same pattern. Google and Deloitte's Milliseconds make millions work tied small speed gains to measurable funnel shifts in retail. Yottaa's 2025 index reports roughly 3% higher mobile conversions per second saved across large e-commerce samples. Those numbers are retail-heavy, but the shape holds elsewhere: delay shows up in bounce before it shows up in revenue models.

Core Web Vitals give teams a shared vocabulary. LCP for loading, INP for interaction latency, CLS for visual stability. They do not replace your analytics, but they connect engineering work to behaviours that correlate with abandonment.

What we track when building the case internally:

• Map cost to URLs that earn the next step (pricing, checkout, key landers), not only sitewide averages

• Quote CrUX percentiles where coverage exists; use synthetic schedules where it does not

• Segment paid landing pages by speed band before blaming creative

• Translate metrics into journeys ("signup flow INP", "PDP mobile LCP") for client and finance conversations

Read more: the real cost of poor web performance (data-driven analysis)

A performance budget in production is a line you refuse to cross. In CI it is the same line, enforced before a merge or deploy lands. Done well, the pipeline fails fast when a change regresses Core Web Vitals proxies, bundle weight, or your own custom thresholds, so you fix it in the branch instead of shipping first.

Most teams start with Lighthouse CI: controlled Lighthouse runs, stored results, and assertions against numeric ceilings. Pair lab gates with bundle size limits when regressions come from dependency drift rather than layout alone. CI answers whether this build broke your thresholds on the URLs you chose; scheduled monitoring answers whether you are still inside budget next week across the pages you track in production.

Before you write YAML, pick URLs and environments that are deterministic enough to trust. Preview deploys from Netlify, Vercel, or Cloudflare Pages work if the job waits until HTTP 200. Document home, a heavy template, and checkout or app shell if those differ. One URL with a loose budget hides regressions on another.

A credible CI budget checklist:

• List representative URLs, not only the homepage

• Set numeric thresholds aligned with your team policy or client contract

• Run at least two Lighthouse passes per URL to reduce cold-start noise

• Probe preview URLs with retries before lhci autorun

• Add at least one JS or CSS bundle guard alongside LCP and CLS gates

• Separate error vs warn assertions until baselines settle

If you already use performance budgets and email alerts in Apogee Watcher, treat CI as the pre-merge gate and Watcher as the continuous check on real site inventories. Same vocabulary, different phase of the lifecycle.

Read more: how to set up performance budgets in CI/CD pipelines

A performance budget on paper is only a policy. In production it needs thresholds your scheduled tests actually enforce, and notifications people will read without muting the sender. We wrote this spotlight after watching agency teams agree LCP caps in a kickoff deck, then discover breaches only when a client forwarded a screenshot from PageSpeed Insights.

Apogee Watcher connects site-level budgets to email digests tied to each scheduled PageSpeed run. You set separate mobile and desktop rows per site: performance score floors, LCP ceilings, INP, CLS, FCP, TBT, Speed Index. When a run finishes, the product compares stored lab results against those thresholds and records breaches with the metric, threshold, and observed value.

Alerts are digests, not one email per URL. When violations exist and the budget channel is email, each active organisation admin gets one message per site per run: summary counts, a breakdown by metric, and up to ten pages ranked by weakest score first. Cooldown logic limits repeat noise while a page stays broken.

What lands in the inbox after a breach:

• How many pages failed and how many individual metric breaches occurred

• Which metrics drove the spike (LCP vs INP vs CLS)

• Up to ten URL rows, worst scores first, with totals if more pages failed

• Timing aligned to your scheduled test cadence, not a real-time CDN push

Pair budgets with a page list that matches what you sell: discovery keeps the inventory honest; budgets judge the URLs you chose to measure. For client retainers, time-stamped breaches after scheduled runs beat arguing from a one-off Lighthouse tab.

Read more: performance budgets and email alerts in Apogee Watcher

A retail client's homepage LCP looked fine in PageSpeed Insights. The same week the account lead forwarded a message: shoppers were dropping at checkout on mobile. The sitewide average had buried the page that takes the money.

E-commerce is a sequence, not one URL. Product listing, product detail, cart, and checkout each carry different assets and failure modes. A slow PLP costs discovery; a slow PDP costs consideration; sticky checkout costs payment. Third-party tags for reviews, chat, and A/B tests stack on top, and most traffic arrives on mobile networks that punish heavy galleries.

Published research keeps pushing the same point. Google and Deloitte's Milliseconds make millions work tied a 0.1 second improvement to higher PDP-to-basket progression in retail. Yottaa's 2025 index linked roughly 3% more mobile conversions per second saved, and put third parties at about 44% of load time on average. Those are order-of-magnitude signals, not a promise for your baseline, but they explain why finance cares when INP on checkout drifts.

What we watch on storefronts:

• LCP on PLP and PDP (product images dominate the paint)

• INP on cart and checkout (filters, variants, form fields)

• CLS where banners and late embeds shift Add to cart

• Mobile and desktop runs on the same key URLs, with budgets per template rather than one global score

• Checkout and cart in the synthetic list even when marketing only cares about campaign landers

Synthetic PageSpeed runs catch regressions across releases; CrUX tells you what Chrome users actually see when coverage exists. Together they beat a single Monday PSI screenshot when you run multiple storefronts.

Read more: e-commerce performance monitoring metrics