DEV Community: Apogee Watcher

Web experts needed!

Apogee Watcher — Fri, 03 Apr 2026 13:22:49 +0000

We're glad to announce that we have opened our free account plan!

Apogee Watcher is built for portfolio-wide web performance monitoring in one multi-tenant dashboard. We auto-discover pages (sitemap + crawl fallback), run scheduled PageSpeed tests, track Core Web Vitals with lab + field (CrUX) data, set performance budgets to catch regressions early, and generate client-ready PDF reports/white-label outputs without cobbling exports.

If you would like to join the free beta test group with higher limits and up to 5 sites, sign up with code DEVTO, and get access to a 3-month free Starter account in exchange for your feedback as we refine workflows for multi-site teams. Available to 50 users only.

Features you can see now are

managing sites and pages with autodiscovery,
running ad hoc tests or setting schedules,
setting performance budgets per site,
mail alerts when a scheduled test finds a problem,
a first version of our lead prospecting feature, which you can use to attract new clients.

Our roadmap includes a) white-label reports you can share with clients, b) AI-powered suggestions for fix c) grouping of test results per type of pages (homepage vs product, etc).

Happy to answer any questions!

GTmetrix vs Apogee Watcher: PageSpeed Monitoring for Agencies Compared

Apogee Watcher — Fri, 03 Apr 2026 12:14:13 +0000

If you run performance work for clients, you have almost certainly opened GTmetrix. It is fast to explain, the reports look familiar, and tests run in Chrome with a wide set of analysis options (region, connection speed, device profiles on PRO). GTmetrix’s Performance Score is Lighthouse-based (captured with GTmetrix’s browser, hardware, and your chosen options), and reports also include CrUX field data where available—see their report guide. That matters when you need to pick the test region and compare lab vs field in one report.

Apogee Watcher is a different kind of product. We use Google’s PageSpeed Insights API (Lighthouse lab data plus CrUX field data where available) inside a multi-tenant workflow: many sites, scheduled tests, budgets, and alerts—without treating every client URL as a separate science project. Beyond monitoring, we also ship Leads Management for prospecting—analyse a prospect URL with PageSpeed (mobile and desktop), one-page performance reports with shareable links, and score-band outreach with lead stages—capabilities GTmetrix does not productise (it stays in the lab-and-monitor lane). What is self-serve for each tenant role is spelled out on our product pages and in the Leads section below.

This article is for teams who are outgrowing ad-hoc checks and want a straight answer: where GTmetrix wins, where a multi-site monitor wins, and when to use both.

What GTmetrix is genuinely good at

GTmetrix’s headline is not “dashboard for fifty retainers.” It is deep, repeatable lab testing with waterfall charts, speed visualisation (frame-style load capture in the Summary tab), optional video of the load, and—on higher PRO tiers—access to many test locations. As of GTmetrix’s own locations page, there are 113 servers across 25 global locations; how many locations your plan can use depends on the tier (e.g. Lite and Core include fewer than 25—see PRO pricing). That matters when:

You are debugging a slow first paint and want waterfall, visual load breakdown, and optional video evidence you can share.
You suspect a geographic angle (CDN edge, routing, or third-party latency) and want to run the same URL from more than one place.
You need a single URL or a small set of monitored URLs with monitoring and alerts, PDF exports, and REST API access—documented in monitoring and alerts and the API docs.

PRO plans include full report PDFs. White-label PDF reports are called out for Enterprise / custom plans, not bundled on every tier. That Enterprise track is contact-for-quote—GTmetrix does not publish a price for white-label or other custom entitlements; you only get a number after sales. That is different from self-serve PRO (Lite, Core, Advanced, Expert), where USD prices are listed (yearly billing is shown on the same page). Many shops still deliver performance as audit + report: run the test, attach the PDF, move on. For that pattern, GTmetrix is a credible tool.

None of that is “wrong” for Core Web Vitals work. The question is whether your job is mostly diagnosis or mostly ongoing coverage across many properties.

Where agencies feel friction with GTmetrix-style workflows

When you move from “one client, one site” to ten, twenty, or thirty production sites, the bottleneck is rarely “can we run Lighthouse?” It is operational:

URL hygiene — Every new landing page, campaign path, or template variant needs a manually maintained list. Miss a URL and you do not monitor it. Automated discovery is not the core story.
Monitored slots — On GTmetrix, a monitored slot is one URL plus a full set of analysis options (test region, device profile, connection speed, and anything else that defines that monitor). This is not “one slot per site”: the same homepage from Seattle and London, or desktop and mobile, consumes multiple slots. Plans cap total slots (e.g. Expert lists 50 monitored slots on the customise page; lower tiers have fewer). So real portfolios shrink fast: a handful of clients × a few key URLs × more than one region or device can eat the whole allowance without covering every property you care about. GTmetrix explains the model in their “What is a Monitored Slot?” FAQ.
Flat structure — You can organise projects and monitors, but you are still managing slots and lists, not a first-class organisation → sites → roles model built for agencies who hand work between people. On GTmetrix self-serve PRO, Lite, Core, and Advanced are single-seat only (no additional team seats—primary account only). Expert is the first tier that lists five team seats on the customise page. Apogee Watcher publishes unlimited team members with Admin / Manager / Viewer roles on every tier on pricing.
Scaling headcount — More clients usually means more human steps to keep monitoring aligned with what actually shipped last week.

GTmetrix is often described as single-site at heart for a reason: it shines when you drill into one URL. Apogee Watcher is built for the opposite problem—many URLs across many clients, with scheduled runs and budgets so regressions surface before the next quarterly review.

A pattern we see in agency Slack channels: one person owns “the GTmetrix bookmarks,” another runs PSI for quick checks, and a third tracks releases in the CMS. None of that is wrong—it is what happens when the portfolio outgrows a single-tool habit. The fix is rarely “buy another login.” It is usually one system of record for scheduled scores and ownership, with room to drop into a debugger when the headline numbers look off.

What Apogee Watcher optimises for

We are not trying to replace WebPageTest or GTmetrix when you need a deep diagnostic session. We are trying to reduce the weekly work of “did any of our clients’ key pages drift out of budget?”

PageSpeed Insights API — Lab and field data (where CrUX has volume) in line with how Google surfaces performance signals. Transparent about methodology: Lighthouse-style lab data, not a substitute for your own RUM.
Multi-site, multi-organisation — Add sites to a portfolio, team roles (Admin, Manager, Viewer), and a single place to see status—built for agencies, not bolted on as a custom plan. Capacity is site and test quotas per tier on pricing, not a separate slot for every region/device permutation of the same URL (see monitored slots above).
Automated discovery — Sitemap + HTML crawl so new paths do not rely on someone remembering to paste a URL. For a longer product-side view, see how Apogee Watcher discovers pages automatically.
Leads Management (prospecting) — Use PageSpeed evidence in new-business workflows: analyse a prospect URL, build one-page reports (HTML and PDF), share time-limited public links, and move leads through stages with score-band campaign messaging. GTmetrix offers nothing comparable; synthetic monitoring competitors typically stop at scheduled tests and alerts. Context: From Monitoring to Pipeline: Why PageSpeed Data Works for Agency Prospecting and The PageSpeed Prospecting Workflow. Product truth: the Leads module is largely an internal/sysadmin MVP today; organisation-scoped lead access for every agency seat is on the roadmap—confirm the features page and changelog before you assume self-serve prospecting for every role.
Budgets and alerts — Set thresholds for LCP, INP, CLS (and related signals in the test output). Get email alerts when something crosses the line; Slack and webhook delivery are on the roadmap—check our current product pages for what is live when you read this.
Reporting — Client-facing reporting direction is aligned with agency plans; compare to GTmetrix’s PDF story, but judge us on what your tier includes today.

API and quota: Google’s PageSpeed relationship sits with us—your team does not manage API keys per client site. That is part of the “no DIY glue” positioning we repeat in why agencies need automated monitoring: fewer moving parts for the same PSI-backed scores.

If you want the broader “manual vs automated” framing first, read PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough. For setup patterns, How to Set Up Automated PageSpeed Monitoring for Multiple Sites walks through the same workflow we care about.

Side-by-side: what to compare on paper

Figures change—always verify pricing and limits on each vendor’s site before you buy. Use this as a decision grid, not a quote.

Topic	GTmetrix (typical positioning)	Apogee Watcher
Lab engine	Lighthouse-based Performance Score in Chrome; GTmetrix adds Structure Score and custom audits	PageSpeed Insights API (Lighthouse lab + CrUX where available)
Test locations	[25 global locations](https://gtmetrix.com/locations.html), 113 servers; lower PRO tiers use a subset	Centralised via Google’s PSI infrastructure—not a multi-region debugger
Multi-client portfolio	Monitors and projects; capacity is monitored slots (each URL + analysis options = one slot—see GTmetrix [FAQ](https://gtmetrix.com/pro/customize))	Multi-tenant: organisations, sites, roles
Team seats	Lite, Core, Advanced: single seat only; Expert: five team seats ([customise](https://gtmetrix.com/pro/customize))	Unlimited team members with roles on all published tiers ([pricing](/pricing))
Page discovery	Manual URL entry	Automated sitemap + crawl
Prospecting / new business	Not part of the product	Leads Management: prospect URL analysis, one-page reports, share links, score-band outreach, lead stages (GTmetrix has no parallel)
Best day-one use	Deep single-URL investigation	Scheduled cross-portfolio monitoring
Alerts	Email (and related features by plan)	Email; more channels in roadmap
Pricing (public list)	Self-serve PRO: Lite through Expert with published monthly USD on [customise](https://gtmetrix.com/pro/customize) (e.g. $4.99–$49.99/mo when billed yearly at time of writing—confirm before you buy). Enterprise / custom (white-label PDFs, priority support, POs): no public price—[request a quote](https://gtmetrix.com/contact.html?type=enterprise-quote).	Published tiers on [pricing](/pricing): $9 Personal, $29 Starter, $79 Professional, $199 Agency (USD/mo, features as listed on the page). Enterprise: custom pricing for bespoke limits and support—same “call for numbers” pattern as GTmetrix’s top tier.

Apples-to-apples on cost: GTmetrix PRO is not the same thing as Enterprise—PRO is the self-serve line with list prices; Enterprise is where white-label PDFs live, with no published fee. If you need branded client PDFs from GTmetrix, you are comparing an unknown quote to Apogee Watcher’s listed $199/mo Agency plan (white-label reporting on the pricing page) or $79/mo Professional (custom PDF reports there). For pure monitoring overlap, you can line up Watcher’s public tiers against GTmetrix’s self-serve Expert ($49.99/mo yearly on their site at time of writing) only if the capabilities match—still confirm both sites before you buy.

Mitigation we are open about: if your job is “prove this page in Tokyo vs London with a real browser,” GTmetrix’s location story is a fair advantage. If your job is “keep twenty client sites inside CWV budgets without a spreadsheet,” we bias our roadmap toward that.

When GTmetrix is the better primary tool

Choose GTmetrix (or keep it alongside) when:

You are debugging one or two URLs and need waterfall detail, speed visualisation or video, and choice of test region (where your plan allows).
Stakeholders want a PDF from a single deep run (self-serve PRO includes full report PDFs; white-label is Enterprise / custom on GTmetrix with no public price—compare to Watcher’s published Agency tier if branded client reports are the requirement).
You are not trying to run a weekly portfolio review—your cadence is “investigate when someone complains.”

When Apogee Watcher is the better primary tool

Choose Apogee Watcher when:

You manage enough sites that manual URL lists rot every month.
You need scheduled tests, stored history, and budgets so regressions do not wait for the next audit.
Team access and role separation matter more than a single shared login.
You want PageSpeed-backed prospecting in the same product as client monitoring (lead analyses, shareable reports, outreach stages)—GTmetrix does not offer that. Alongside multi-tenant structure, automated discovery, and team roles, Leads Management is an extra axis that general lab-and-monitor tools in this class typically skip.

Use both: diagnostics on top of monitoring

We do not pitch “rip and replace.” A practical stack often looks like:

Apogee Watcher — scheduled coverage, discovery, alerts, portfolio view.
GTmetrix or WebPageTest — when a single metric looks wrong and you need a deeper lab story.

That is the same “diagnostics vs monitoring” split we use in Best Free PageSpeed Monitoring Tools: PSI, WebPageTest, Lighthouse CI, Pingdom, and More: free or paid diagnostics answer why; monitoring answers whether it stayed fixed.

Practical next steps

Before you change tools, change the question from “which logo do we like?” to “who will own the cadence when we have twice as many sites next year?” The stack should make that person’s job smaller, not busier.

Write down your count — How many production sites, how many key URLs per site, how often releases ship.
Decide your failure mode — “We miss regressions” vs “we cannot deep-debug a single bad page.”
Trial the workflow — Run a week of scheduled tests on your noisiest clients and see whether alerts match how your team actually ships.

FAQ

Is Apogee Watcher a GTmetrix alternative for agencies?It is an alternative if your priority is multi-site monitoring, discovery, and budgets across a portfolio. It is not a feature-for-feature replacement for GTmetrix’s single-URL depth (waterfall, speed visualisation, optional video, and regional Chrome tests where your plan allows).

Does Apogee Watcher use the same data as PageSpeed Insights?We use the PageSpeed Insights API, so lab and field data align with the same sources Google’s public tools surface. GTmetrix also uses Lighthouse-derived lab scores for its Performance Score, but GTmetrix and PSI can still differ because of test region, hardware, throttling, and GTmetrix’s own Structure Score and grading—GTmetrix states this explicitly when comparing to PSI. Use both as signals, not as identical numbers.

Can we use GTmetrix and Apogee Watcher together?Yes. Many teams use a monitoring platform for coverage and a diagnostic tool for investigation.

Does GTmetrix “one monitored slot” mean one website?No. GTmetrix counts one slot per monitored configuration: the URL and the chosen options (region, device, connection speed, etc.). The same page under two regions or two devices uses two slots, which is why slot limits can cap how many sites and pages you can cover—see their monitored slot explanation.

Does GTmetrix offer lead prospecting or outreach workflows?No. GTmetrix is built around testing and monitoring URLs you configure. Apogee Watcher adds Leads Management for prospecting (analyse prospect URLs, reports, share links, score-band messaging, lead stages)—see the links in the main article. Availability per tenant role follows our current product and changelog.

What about Slack or webhook alerts?Email alerting is available today; Slack and webhook delivery are planned—confirm on the features and changelog pages before you rely on them for an SLA.

Where do I start with Core Web Vitals basics?Read What Are Core Web Vitals? A Practical Guide for 2026 and browse our Core Web Vitals category for deeper posts.

Apogee Watcher is multi-tenant PageSpeed monitoring and reporting for agencies and teams—scheduled tests, budgets, and discovery without the overhead of manual URL lists. See plans and sign up or explore automated monitoring on the blog.

Image Optimisation Strategies for Better LCP Scores

Apogee Watcher — Thu, 02 Apr 2026 07:58:48 +0000

On many marketing and product pages, Largest Contentful Paint (LCP) is not abstract. It is a hero photograph, a product shot, or a full-width banner. The metric tracks when that largest visible element finishes rendering; if the element is an image, your optimisation work is mostly bytes, dimensions, and discovery order—not another round of “general speed tips”.

This guide assumes you already know what LCP measures. If you need the full picture first, read What Are Core Web Vitals? A Practical Guide for 2026 and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. Here we go deep on image-specific strategies that move LCP toward the “good” band (≤ 2.5 seconds in the field), and how to pair them with performance budgets so improvements stick.

Start by identifying the real LCP element

You cannot optimise “the page” in the abstract. LCP is tied to one element in the viewport. In PageSpeed Insights or Lighthouse, open the diagnostics and note which node is reported as LCP—often an <img>, sometimes a text block or a background.

If the tool points at an image:

Confirm the URL you are actually serving (CDN vs origin, srcset winner, and any CMS transforms).
Check the file size after compression. A 2.5 MB hero on a 360 px wide phone viewport is a sizing problem first, not a format problem.
Trace load order: is something else blocking discovery (late CSS, client-rendered markup, or a lazy attribute on the hero)?

Skipping this step is how teams ship a perfect WebP pipeline and still fail LCP because the LCP element was a different image—or text—than they assumed.

Pick modern formats and tune quality deliberately

AVIF usually beats WebP on file size at comparable visual quality; WebP still beats most JPEG for photos. The practical approach for 2026:

Serve AVIF with WebP or JPEG fallbacks using <picture> or rely on your CDN’s automatic format negotiation if you trust its tests.
Avoid shipping a single giant JPEG “because it works everywhere” unless you have measured that the conversion pipeline genuinely cannot run yet.
For illustrations with flat colour, SVG or optimised PNG can win; for large photographic heroes, raster formats dominate.

Quality settings are not universal. A quality of 75 in one encoder is not the same as 75 in another. Pick a default (for example AVIF at a sensible quantiser, WebP at 75–80), then visually compare at real display widths. Automated tools help, but a human glance at banding on skies and skin tones still catches regressions.

When you change format, re-measure LCP on the same URL. Lab scores can move for reasons unrelated to user-perceived quality, so keep before/after filmstrips or screenshots for stakeholders.

Match dimensions to rendered size, not to the asset library

LCP often fails because the browser decodes a 4000 px image into a 400 px slot. Responsive design does not mean “one huge master file for all breakpoints”.

Export or generate variants at the maximum CSS width they will occupy, per breakpoint, with a small margin for DPR (device pixel ratio). A 2× retina asset should be roughly 2× the CSS pixels, not 5× “for safety”.
Strip metadata you do not need; it is wasted bytes on every request.
If your CMS offers “automatic resizing”, verify the actual output dimensions in Network, not the checkbox in the admin UI.

If you only do one thing after reading this section: open DevTools → Network, click the LCP image, and compare Intrinsic size (natural width/height) to Rendered size. If the intrinsic side is many times larger than rendered, fix that before touching anything else.

Use `srcset` and `sizes` so the browser picks a sane file

Giving the browser a range of widths beats a single src for almost all content images.

srcset lists candidate widths or descriptors (480w, 800w, …).
sizes tells the browser how wide the image will be in the layout at different viewport widths, so it can pick the right candidate before downloading the wrong one.

Common mistakes:

sizes="100vw" on an image that is only half the layout width—so the browser pulls an unnecessarily large file.
Omitting sizes when using w descriptors, which can lead to poor selections.
Using loading="lazy" on an image that is above the fold and is your LCP element. The browser may defer work you needed immediately.

For a full-width hero, sizes="100vw" is often correct. For a card grid, describe the column width at each breakpoint. MDN’s documentation on responsive images is worth bookmarking for copy-paste patterns you can adapt.

Loading order: preload, priority, and lazy boundaries

Preload the LCP image when you know the URL early in the document:

<link rel="preload" as="image" href="/images/hero-800.avif" type="image/avif">

Use this when the hero URL is stable and not swapped by heavy client-side logic. If the URL only appears after JavaScript runs, preload may fire too late—fix when the URL is known, not only how it is loaded.

fetchpriority="high" on the LCP <img> nudges the browser to fetch that image sooner relative to other images. Use it sparingly (setting high on more than one or two images is usually not helpful) and pair it with not marking that same image as lazy.

Lazy loading belongs on below-the-fold images. For anything in the first screen, omit loading="lazy" or you risk delaying the very resource that defines LCP.

Decoding: decoding="async" can help keep the main thread responsive; test on low-end hardware if you are borderline on LCP.

CSS background images and LCP

Background images set in CSS are not <img> elements. They are still eligible for LCP, but the browser can’t reliably discover the underlying image URL until after CSS is parsed—so you can end up with extra LCP resource load delay. You also lose straightforward alt semantics for critical content.

If your hero is purely decorative, a background can be fine—but you still pay the same byte and timing costs. If the hero carries meaning (product, banner text is not enough), prefer semantic <img> or <picture> so preload and priority hints map cleanly to the resource.

When you must keep a background, preload it explicitly (e.g. link rel="preload" with fetchpriority="high" or a matching Link header) so it starts fetching early, and make sure the CSS/JS that reveals it doesn’t block rendering.

Third-party CDNs and transforms

Image CDNs that resize, reformat, and cache at the edge can shrink time-to-bytes dramatically. When you adopt one:

Lock URL parameters (width, quality, format) so marketing edits in the CMS do not silently generate new uncached variants.
Watch cache hit ratios after deploys; a “small” config change can bust effective caching.
Align transforms with your srcset strategy—duplicating the same logical image under twenty unbounded parameter combinations is a recipe for cache fragmentation.

CMS uploads and the “full size” trap

Many CMS/theme setups default new uploads to full resolution and then display them small. The HTML still references a massive file unless your theme registers proper image sizes and the markup uses them.

If you inherit a WordPress or similar build, check: (1) registered image sizes for hero slots, (2) whether the template uses wp_get_attachment_image with a named size or blindly outputs the original, (3) whether page builders inject full URLs into inline styles. One corrected template often beats dozens of hand-compressed assets nobody uses.

Verify in the lab, then confirm in the field

After changes:

Run PageSpeed Insights (or Lighthouse) on mobile and note LCP and the LCP element breakdown (TTFB, resource load delay, duration, render delay).
Compare field data (CrUX) where available—lab wins do not always match real users on slow networks.
If you use automated monitoring, add or check budgets for LCP on key templates so regressions surface when someone ships a new hero asset.

For a before/after story, WebPageTest filmstrips or Lighthouse’s View Trace help show whether you shortened resource load duration or merely shifted work. If TTFB or render delay still dominates, image tweaks alone will not get you to green.

Document one baseline number (median LCP or Lighthouse LCP) per template so the next redesign has a reference point.

Tie optimisation to budgets and ownership

Image work is easy to undo: a new campaign drops a 4 MB PNG into the hero and nobody notices until Search Console complains. Add a simple budget per template: maximum dimensions, maximum encoded kilobytes, and allowed formats. Our Performance Budget Thresholds Template is a starting point if you do not have internal standards yet.

Assign who approves hero assets in the CMS—often a designer uploads once and the performance contract is forgotten. A short checklist in the handover doc beats a post-launch fire drill.

What to do next

Identify the LCP element on your top templates.
Resize and re-encode; wire srcset/sizes correctly.
Remove lazy loading from above-the-fold heroes; add preload or fetchpriority where appropriate.
Re-test in the lab and watch field metrics after release.

Small, measurable steps beat a sweeping “image audit” that never ships.

FAQ

Is the hero image always the LCP element?

No. LCP is the largest visible element in the viewport; it can be a headline block, a video poster, or another image. Always confirm in your tooling before optimising the wrong asset.

WebP or AVIF first?

Prefer AVIF with a WebP or JPEG fallback for broad support, or use CDN negotiation if you have verified behaviour across browsers you care about.

Does lazy loading hurt LCP?

Lazy-loading your actual LCP element can delay LCP. In practice, omit loading="lazy" for the first-screen hero (and for any image the diagnostics report as LCP).

Do I need a CDN to pass LCP?

Not always, but a CDN often cuts latency and improves repeat visits. If TTFB or download time dominates your LCP breakdown, origin geography and caching deserve attention alongside image bytes.

Site Audit Checklist: Onboarding a New Client for Performance Monitoring

Apogee Watcher — Wed, 01 Apr 2026 12:44:18 +0000

Most onboarding checklists are either too light ("run a test and send a report") or too heavy (a long enterprise worksheet no one follows). Agency teams need something in between: a practical checklist you can run repeatedly, with enough structure to avoid blind spots.

This guide is built for teams onboarding client sites into ongoing performance monitoring. The goal is clear: move from "new client handover" to "monitoring is live, scoped, and actionable" without spending two weeks in setup mode.

If you need the monthly review workflow after onboarding, pair this with Monthly Performance Review Template for Agency Teams.

What teams usually need from a site audit checklist

Most teams need three things from an onboarding checklist:

A template they can copy directly.
A sequence of actions in the right order.
Clarity on what matters most in the first week.

This article covers all three. It starts with a copy/paste checklist, then explains how to use each section so your first monitoring cycle produces decisions, not just numbers.

Before you touch tools: lock scope and ownership

Do not begin with a full crawl and a 200-row spreadsheet. Start with agreement.

For each client, lock these five items first:

Primary domain and critical subdomains
Priority templates (homepage, lead form, pricing, service/product, checkout)
Mobile and desktop coverage
Reporting cadence (weekly internal, monthly client-facing)
Alert recipients and first-response owner

If you skip this step, the first client conversation usually becomes "why are these pages here?" instead of "what do we fix first?"

Site audit checklist (copy/paste template)

Use this in your docs tool, ticketing system, or onboarding runbook.

// Site Audit Checklist — Performance Monitoring Onboarding
// Client: [NAME]
// Domain(s): [DOMAIN]
// Owner: [NAME]
// Date: [YYYY-MM-DD]

1) Access and context
- [ ] Confirm primary domain + environments (prod/stage)
- [ ] Confirm CMS / stack basics (WordPress, Shopify, custom, etc.)
- [ ] Confirm deployment owner / technical contact
- [ ] Confirm analytics and consent constraints

2) URL inventory
- [ ] Pull URLs from sitemap(s)
- [ ] Add business-critical URLs manually (pricing, lead form, key landing pages)
- [ ] Remove obvious noise pages (search params, utility pages, test paths)
- [ ] Group pages by template type where possible

3) Measurement setup
- [ ] Enable mobile + desktop testing
- [ ] Set test frequency by site priority
- [ ] Confirm test quota and page limits match plan
- [ ] Confirm data retention expectation (30/90/365 days or plan default)

4) Baseline capture (first run)
- [ ] Run initial tests for priority pages
- [ ] Record baseline LCP / INP / CLS and performance score
- [ ] Mark currently failing pages and highest-severity regressions
- [ ] Note pages with no field data so expectations are clear

5) Budgets and alerts
- [ ] Set initial thresholds (LCP, INP, CLS) per site/template
- [ ] Set alert channels (email / Slack / webhook where available)
- [ ] Confirm cooldown and escalation owner
- [ ] Confirm who receives alerts and who owns first response

6) Reporting readiness
- [ ] Decide client-facing summary format (call, email, PDF/report link)
- [ ] Define monthly review owner and calendar slot
- [ ] Draft first "what we monitor and why" note for client
- [ ] Confirm next review date

7) Handover
- [ ] Create top 3 actions from baseline findings
- [ ] Assign owner + due date for each action
- [ ] Log blockers (hosting, scripts, release dependencies)
- [ ] Share final onboarding summary internally

How to run each section without adding overhead

The checklist above is the scaffold. This section explains how to keep it efficient.

1) Access and context

This is where most onboarding delays begin. The most common blocker is not technical complexity; it is missing ownership.

Minimum acceptable output from this section:

one technical contact who can approve changes,
one business contact who can prioritise pages,
one statement on environment scope (production only, or production + staging).

If that is not settled, pause setup and resolve it before running baseline tests.

2) URL inventory

Start with sitemap URLs, then force-add business-critical pages. Sitemaps are useful, but they often miss campaign pages, dynamic pricing paths, or recently launched funnels.

A practical first pass for most sites:

1 homepage URL
2-5 conversion URLs (pricing, lead form, checkout, booking)
5-10 high-traffic content or service templates

That gives you enough coverage to catch meaningful regressions without drowning your team in low-value alerts.

3) Measurement setup

Always enable both mobile and desktop. Even if the client says "our users are mostly desktop", mobile regressions still affect search visibility and user experience on mixed traffic.

Set test cadence based on risk:

high-change sites: daily
medium-change sites: weekly
stable sites: weekly or monthly

Avoid a false precision setup where every site gets the same frequency. Match cadence to release behaviour and business risk.

4) Baseline capture

A baseline is not "export all scores". It is a snapshot you can compare against in four weeks.

For each priority page, record:

current LCP, INP, CLS
current performance score
current status (within threshold / out of threshold)
one likely cause if out of threshold
one likely business impact

That last two lines are what make the baseline usable in client calls.

5) Budgets and alerts

Budgets and alerts are where monitoring becomes operational.

Do not over-tune on day one. Set initial thresholds, then adjust after one month of data. The objective is a stable signal, not perfect thresholds in the first week.

When setting alert channels, define response paths explicitly:

who receives first alert,
who triages,
who communicates externally,
what counts as escalation.

Without this, alerts become noise and trust drops quickly.

6) Reporting readiness

If the client is onboarding, they need clarity more than polish.

First-cycle reporting should answer:

What we monitor.
What is currently failing.
What we will fix first.
What we need from you (if anything).

You can upgrade format later (dashboards, PDFs, branded summaries). Start with consistency.

7) Handover

A clean handover has only three mandatory outputs:

top three actions,
owner and due date for each action,
known blockers.

If you end onboarding without those, you have setup but not momentum.

Priority matrix for first-week triage

Use this quick matrix when multiple regressions appear at once:

Impact	Effort	Priority
High business impact	Low effort	Do first
High business impact	High effort	Plan this cycle
Low business impact	Low effort	Batch with other fixes
Low business impact	High effort	Backlog unless it trends worse

This keeps your first month focused on visible wins rather than interesting low-impact fixes.

Common onboarding mistakes and how to avoid them

Tracking too many pages too early

A long page list feels thorough, but it slows triage and increases alert fatigue. Start with the minimum meaningful set, then expand after your first review cycle.

No alert owner

Shared inbox alerts with no owner create silent regressions. Assign one response owner before the first scheduled run.

Baseline with no narrative

"LCP is 3.8s" alone is not useful. Pair every key metric with context:

page type,
suspected cause,
likely user/business impact.

That turns metrics into decisions.

Promise mismatch on reporting

Do not promise polished monthly packs before setup stabilises. First cycle should prioritise baseline clarity and top actions.

Mixing diagnosis with onboarding

Onboarding is not root-cause analysis on every issue. Capture the issue, assign severity, and create an action list. Deep diagnosis can run in delivery sprint time.

Suggested first-month cadence after onboarding

Use a straightforward rhythm:

Week 1: onboarding, baseline, first top-three action list
Week 2: ship highest-impact fixes
Week 3: verify against fresh runs
Week 4: run monthly review and reset priorities

If thresholds still feel loose, use Performance Budget Thresholds Template before your first full client review.

Example onboarding summary you can send to a client

Use this short format once setup is complete:

Subject: Performance monitoring onboarding complete — next steps

We have completed onboarding for [DOMAIN].

Monitoring scope:
- [N] priority pages across [template groups]
- Mobile and desktop tracking enabled
- Baseline recorded for LCP, INP, CLS, and performance score

Current status:
- [X] pages within thresholds
- [Y] pages needing attention
- Top risk: [short description]

Next three actions:
1) [Action] — owner [name], due [date]
2) [Action] — owner [name], due [date]
3) [Action] — owner [name], due [date]

This is usually enough for the first cycle. You can move to a fuller monthly format once trends are visible.

FAQ

How many pages should we include in the first onboarding pass?

Usually 10-20 priority URLs is enough for a reliable baseline. Expand only after your team can keep up with triage.

Should we onboard mobile first or both mobile and desktop?

Both. One-device monitoring hides regressions and creates reporting gaps.

Do we need complete page-type classification before monitoring starts?

No. Start with practical buckets (homepage, conversion pages, core templates), then refine over time.

What if the client has no clear target thresholds yet?

Use pragmatic starter thresholds, mark them provisional, and revise after one month of observed data.

How long should onboarding take per client?

For typical brochure/ecommerce sites, setup and first baseline can usually be done in 30-90 minutes if ownership and access are clear.

What should we do if alerts spike in week one?

Check whether scope is too broad or thresholds are too strict. Triage by business impact and fix ownership before widening coverage.

A good site audit checklist does more than capture URLs and scores. It creates operating rhythm: clear scope, clear owners, and clear next actions. That is what makes monitoring useful after month one.

Monthly Performance Review Template for Agency Teams

Apogee Watcher — Tue, 31 Mar 2026 20:39:36 +0000

Most agency teams do not struggle with data. They struggle with rhythm.

You already have scores, alerts, and test history. The friction starts when the month ends and you need to answer four questions quickly:

What improved?
What regressed?
What matters for the client right now?
Who is doing what next?

This template gives you a repeatable monthly review in 30-45 minutes per client—built for multi-site teams where consistency beats perfect slides.

If you need setup guidance before review cadence, use How to Set Up Automated PageSpeed Monitoring for Multiple Sites. If you need a client-facing deliverable, pair this with Client-Ready Core Web Vitals Report Outline.

What we mean by a monthly performance review

Many “monthly performance review” templates are built for HR one-to-ones. This one is for website performance: Core Web Vitals, regressions, and the work your team ships—so clients who pay for speed and stability get a steady rhythm instead of one-off updates when something breaks.

You need: a clear agenda, a small set of metrics you can defend, copy that works in a client email, and three actions with owners—not “we will keep an eye on it”. The script below is that meeting. Run it internally first; the next section covers the client conversation.

Use this template as a meeting script

The structure below works as:

an internal monthly review meeting
a client-facing performance call
a handover note between technical and account teams

Copy this into your docs tool and reuse it every month.

// Monthly Performance Review — [CLIENT / SITE]
// Period: [YYYY-MM]
// Meeting date: [DATE]
// Owner: [NAME]
// Participants: [NAMES]

1) Snapshot
- Overall status: [Healthy / Needs attention / Critical]
- Portfolio summary:
  - Sites monitored: [N]
  - Pages monitored: [N]
  - Tests run this month: [N]
  - Alerts triggered: [N]
  - Alerts resolved: [N]

2) Metric trend review (mobile + desktop)
- LCP: [value] (last month: [value], delta: [value])
- INP: [value] (last month: [value], delta: [value])
- CLS: [value] (last month: [value], delta: [value])
- Performance score: [value] (last month: [value], delta: [value])
- Comment: [What changed and why]

3) Biggest wins this month
- Win #1: [change made] -> [metric impact] -> [business impact]
- Win #2: [change made] -> [metric impact] -> [business impact]

4) Regressions and risks
- Regression #1: [page / template]
  - Detected: [date]
  - Suspected cause: [release, script, image, third-party, etc.]
  - Current impact: [SEO / UX / conversion]
  - Severity: [High / Medium / Low]
- Regression #2: [...]

5) Top 3 actions for next month
- Action 1: [task]
  - Owner: [name]
  - Due: [date]
  - Success metric: [target]
- Action 2: [...]
- Action 3: [...]

6) Decisions and dependencies
- Client decisions needed: [yes/no + details]
- Cross-team dependencies: [dev, content, design, hosting]
- Blockers: [list]

7) Client communication summary
- What we will tell the client this month (3 bullets max)
- Confidence level: [High / Medium / Low]
- Escalation needed: [yes/no]

Internal review first, then the client

Do not skip the internal pass. Half-explained metrics on a client call usually mean the team argues about interpretation in front of them—or nobody agreed what “green” meant before you dialled in.

Run sections 1–6 with tech plus account or delivery (15–20 minutes). Align on severity, strip noise, agree what you can say externally. Then use section 7 plus one executive line for the client call or email (20–30 minutes; account-only is fine for low-touch clients). Clients rarely need every alert ID—they need proof you are in control and a clear ask when their content, scripts, or hosting blocks progress.

On maintenance and monitoring retainers, this meeting is often the clearest proof of value. Still complete section 3 (wins). Stability after a heavy release month is a win worth naming.

Why this format works for agencies

It forces one pass from raw metrics to accountable actions.

Many reviews fail because teams stay in reporting mode: charts and discussion, then no owner. This template keeps one output in view: actions with names and deadlines. Keep budget targets visible in the room. If thresholds are still loose, set them with Performance Budget Thresholds Template before the next cycle.

A practical scoring model for monthly status

Use a simple status system so everyone speaks the same language:

Healthy: no high-severity regressions open; core templates stay within agreed thresholds
Needs attention: one or more key templates out of threshold, but impact is contained
Critical: high-impact regressions on revenue or lead pages, unresolved for multiple runs

Keep the labels simple. The goal is faster decisions, not a perfect classification scheme.

What to prepare before the meeting

Keep prep under 20 minutes per client:

Pull this month versus last month metric deltas
Export or copy the top alert events and resolution notes
Select the 2-3 most important pages (homepage, pricing, lead form, key product template)
Draft the three client-facing bullets in advance

Technical lead: confirm URLs, mobile and desktop, and budgets still match what you monitor. One line of suspected cause per regression; realistic effort for the top three actions.

Account or delivery lead: what the client already saw in tickets or Slack; promises in writing; whether section 7 reads like a service update, not a post-mortem.

If prep runs long, use the same export, comparison window, and three priority URLs every month.

After the meeting: outputs that close the loop

Tasks — three actions with owner and due date in your PM tool, not only in notes.
Client touchpoint — short email with section 7 bullets plus a dashboard or PDF link, or a call with the same content; depth should match the contract.
Threshold sanity — if the same template stays “Needs attention”, fix the budget, fix the page, or reset expectations in writing.

Optional: one line in your internal monthly business review—“Performance: [status] — top risk: [X]”—so web performance stays visible next to SEO and content.

Common mistakes this template avoids

1) Mixing diagnosis with decision-making

You can spend an hour debating why a metric moved and still leave without a plan. Keep root-cause deep dives separate when needed. The monthly review should end with owned actions.

2) Reporting averages only

Averaged scores hide broken high-value pages. Always include at least one section on key templates and business-critical URLs.

3) No link between performance and client impact

Clients do not buy "better Lighthouse numbers". They buy risk reduction, stability, and fewer surprises. Translate each major change into likely impact on user experience and search visibility.

4) Too many priorities

If every item is urgent, nothing is urgent. Keep the next-month action list to three items max.

Suggested monthly cadence

Week 1: run the review and lock actions. Weeks 2–3: ship fixes. Week 4: verify and draft next month’s notes. Busy sites can add weekly tactical checks; still hold one monthly reset.

If you are still deciding what to monitor, start with Core Web Vitals Monitoring Checklist for Agencies. If the same pages fail every month, read The Complete Guide to Performance Budgets for Web Teams and reset thresholds.

FAQ

How long should a monthly performance review meeting take?

30-45 minutes per client is enough if prep is done and the agenda is fixed. Longer meetings usually mean unclear ownership or too much ad-hoc debugging inside the call.

Who should attend from the agency side?

At minimum: one technical owner and one account owner. Technical owners explain causes and options; account owners align recommendations with client priorities and communication.

Is this the same as an HR performance review template?

No. This article is for website performance and delivery reviews with clients or internal delivery teams. It does not cover employee appraisals or performance improvement plans.

Should we include every monitored page in the review?

No. Review trends portfolio-wide, then focus discussion on business-critical templates and the highest-impact regressions.

What if nothing significant changed this month?

That is still a useful outcome. Record stability, confirm thresholds are still appropriate, and document one preventive action for next month.

How is this different from a client report template?

This template is for decision meetings. A client report is a polished output for stakeholders. Use this review first, then summarise outcomes in a client-ready report format.

What should I put in the calendar invite?

Title: “Monthly web performance review — [Client] — [Month YYYY]”. Body: link to the dashboard or report, four-bullet agenda (snapshot, trends, regressions, three actions), attendees.

Can we run this monthly review for a single site?

Yes—set section 1 counts to one site; the rest of the script stays the same.

Same agenda every month and every action owned—that is how monitoring reads as a service. Sign up for scheduled PageSpeed checks with less manual prep.

Watcher's Free plan rolling out ahead of full launch

Apogee Watcher — Sun, 29 Mar 2026 22:08:01 +0000

We are still in private beta, but as of today you can sign up without a credit card and start on the Free plan. You get a real organisation, one site, and the same PageSpeed Insights–backed testing as we will have on paid plans.

We want more real URLs and real feedback beyond our closed private beta testers and we'd love your feedback. However, this is not a test or a temporary offering, we will always have a free plan for developers, freelancers and people with no need for the features of paid plans.

What the Free plan includes

One website to monitor.
15 PageSpeed tests per month, including manual runs and scheduled checks.
14 days of result history.
Monthly schedules only. If you need weekly runs, you will need a paid plan.
Email alerts when budgets fail (no Slack or other channels on Free).
One user in the organisation—built for solo evaluation.
Fully working plan within those limits: you are not locked to read-only while your subscription is active.
Lab metrics and CrUX in results where Google provides field data, same as elsewhere in the product.

What the Free plan does not include

Free is for monitoring and alerts for a single domain with a basic set of features. It does not bundle PDF export, white-label branding on reports, REST API access, the leads prospecting tools, or AI Insights. You still get full PageSpeed Insights lab metrics and CrUX field data where Google provides it—the difference is the extras for export, client-ready delivery, integrations, and AI-guided next steps.

See the pricing page for which plan includes what. In short:

AI Insights — Prioritized, fix-oriented guidance from your PageSpeed results. Available from Personal upward; not on Free. Where your plan includes it, monthly usage follows the same ceiling as your PageSpeed test allowance for that tier.
PDF reports — Downloadable client-ready reports. From Professional upward (not on Personal or Starter).
White-label reports — Your branding on reports. From Professional upward, alongside PDF-capable tiers.
REST API access — Integrate monitoring data with your own systems. Agency and Enterprise on our public pricing; smaller tiers do not include API access.
Leads management — Prospecting pipeline (capture leads, analysis, campaigns). Agency and Enterprise.

Signup today

If you have more than one site, sign up today and you will be eligible for a time-limited trial on a paid tier as we make progress with our launch.

Best Free PageSpeed Monitoring Tools: PSI, WebPageTest, Lighthouse CI, Pingdom, and More

Apogee Watcher — Fri, 27 Mar 2026 09:54:12 +0000

Free PageSpeed tools are useful. Most of us started there.

The problem is not that these tools are bad. The problem is that teams often use a diagnostic tool as if it were a monitoring system. That works for one site and one person. It breaks when you have multiple sites, multiple stakeholders, and a release cadence that keeps changing the performance profile.

This guide compares popular free options so you can choose the right stack for your stage, avoid false expectations, and decide when “free” is still efficient versus when it has become expensive in team time.

Before the list: diagnostics vs monitoring

A quick definition saves a lot of confusion:

Diagnostics answer: “Why is this page slow right now?”
Monitoring answers: “Did something regress, where, and who needs to act?”

Many free tools are excellent diagnostics. Fewer are good monitoring systems on their own.

If you want the deeper manual-vs-automated decision framework, start with PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough and Automated vs Manual PageSpeed Testing: A Time and Cost Comparison.

What “best free” should mean

For this comparison, “best” is not just the prettiest report. It means:

You can run it consistently.
You can trust the output for decision-making.
Your team can act on it without glue-code chaos.

We assess each option on practical agency/team criteria:

Setup effort
Ongoing maintenance
Multi-site workflow fit
Alerting and historical tracking
Reporting usefulness for non-engineers

Tool 1: PageSpeed Insights (PSI)

What it is: Google’s free page analysis surface for Lighthouse lab data plus CrUX field data when available.

Where PSI is strong

Fast manual checks for a specific URL
Clear metric breakdown (LCP, INP, CLS)
Helpful opportunities and diagnostics
Useful for stakeholder education because people already recognise the interface

Where PSI falls short for monitoring

Manual by default; no built-in team workflow
History and change tracking are limited for operational monitoring
No native “portfolio view” for agencies
Alerting and escalation paths need extra tooling

Best use case: Spot checks, post-fix verification, and explaining individual pages.

Tool 2: WebPageTest

What it is: A powerful lab testing platform with rich waterfall data, filmstrips, and run configuration options.

Where WebPageTest is strong

Deep diagnostics when you need to understand what happened on the wire and render path
Multiple test locations and device profiles
Useful visual evidence for troubleshooting (filmstrip/waterfall)

Where it falls short for day-to-day monitoring

Rich output can overwhelm non-technical stakeholders
Teams can drown in one-off runs without a clear monitoring routine
Requires discipline to keep test definitions and cadence consistent

Best use case: Investigation and debugging, not full operational monitoring on its own.

Tool 3: Lighthouse CI

What it is: Open-source Lighthouse automation in CI/CD pipelines.

Where Lighthouse CI is strong

Excellent for build-time performance guardrails
Repeatable checks per commit or deploy
Great fit for engineering-led teams comfortable with CI ownership

Where it gets expensive (despite being free)

Ongoing maintenance of CI config, runners, and thresholds
Signal quality depends on stable environments and careful calibration
Non-engineer reporting is often weak unless you build extra layers

Best use case: Engineering quality gates inside an existing CI discipline.

Tool 4: Pingdom (free plan / free checks)

What it is: Historically known for uptime and synthetic checks, with some performance testing capability.

Where it is useful

Simple uptime-style visibility
Quick synthetic checks without heavy setup
Helpful for “is the site up / generally responsive?” style watchpoints

Where it is limited for modern CWV workflows

Not a complete Core Web Vitals monitoring workflow on its own
Limited depth versus dedicated performance diagnostics
Can become a fragmented stack when paired with multiple separate tools

Best use case: Lightweight synthetic checks as one input, not your only performance system.

Other free options teams often combine

Depending on your stack, teams also mix in:

Chrome DevTools Lighthouse for local debugging
Search Console CWV report for field trend visibility
CrUX data tools for broader field patterns

These are all valid, but the same warning applies: combining many “free” tools does not automatically produce one coherent monitoring workflow.

Comparison table (practical view)

Tool	Best at	Monitoring depth	Team/reporting fit	Typical failure mode
PSI	Fast URL checks and explanation	Low by itself	Good for ad-hoc sharing	Manual checking becomes routine fire-fighting
WebPageTest	Deep diagnostics and root-cause analysis	Medium for specialists	Medium; technical-heavy output	Great data, weak operational cadence
Lighthouse CI	Build-time guardrails	Medium to high in engineering contexts	Low without extra reporting layer	CI maintenance burden grows over time
Pingdom free checks	Basic synthetic watchpoints	Low for CWV-centric monitoring	Medium for simple status visibility	Becomes one more disconnected dashboard

The hidden cost of “free”

Free tools reduce licence cost. They do not remove process cost.

The hidden costs show up as:

Context switching — Data in one tool, alerts in another, reporting in a spreadsheet
Ownership gaps — Nobody knows who acts on regressions
Inconsistent methods — Different people run different test settings, so comparisons are noisy
Client friction — Evidence is technically correct but hard to present consistently

This is usually the point where teams say “our stack is free” but still spend hours each week stitching results together.

Apogee Watcher Free: the same “free”, different trade-off

“Free” in this article has mostly meant licence-free tools you run yourself (PSI, WebPageTest, Lighthouse CI, and similar). Apogee Watcher also has a Free plan (€0/month — see Pricing), but it sits in a different category: hosted PageSpeed monitoring with scheduled runs and email alerts, not a manual testing website.

In our product plan, Free means fixed limits so the tier stays sustainable: 1 site, 15 tests per month, monthly test frequency only, 14-day data retention, one team member, email alerts only, and no AI insights, PDF exports, API access, or white-label features. Paid tiers add capacity, more frequent schedules, longer retention, and team features.

When Watcher Free is a fair comparison to “free tools”: you have one production site, you want scheduled checks and history without maintaining Lighthouse CI or a spreadsheet ritual, and you accept monthly cadence and tight quotas.

When it is not a substitute for the tools above: multi-site portfolios (you need a higher tier), or “test everything daily” workloads. WebPageTest remains the specialist when you want its public lab setup: extra test locations, filmstrip, side-by-side comparisons, or a shareable WebPageTest URL outside your Watcher workflow.

That distinction matters: comparing Watcher Free to PSI is only useful if you are choosing between ad-hoc manual checks and hosted scheduling for a single URL scope—not between having a waterfall and not having one.

A practical stack by team stage

If you are deciding what to do this quarter, this is a useful starting map:

Stage A: solo developer or one-site team

Primary: PSI + occasional WebPageTest
Add: simple recurring calendar checks
Goal: catch obvious regressions and learn metric behaviour

Stage B: small team, regular releases

Primary: PSI + Lighthouse CI for critical templates
Add: field trend checks in Search Console
Goal: stop regressions from shipping unnoticed

Stage C: agency or multi-site portfolio

Primary: scheduled multi-site monitoring system
Add: WebPageTest for deep investigations
Goal: operational visibility, escalation workflow, and client-ready reporting

The transition from Stage B to C is where most “free-stack pain” appears.

When to move beyond free-only workflows

You do not need to replace free tools entirely. You need to recognise when they are no longer sufficient as your primary monitoring layer.

Common signals:

You manage multiple sites and cannot see portfolio-wide risk in one place.
You spend more time collecting evidence than acting on regressions.
Alerts depend on manual checks or personal memory.
Monthly reporting takes too long to prepare.
Different team members use different methods and produce conflicting results.

At that point, free tools still belong in the workflow, but mostly as diagnostics and validation layers rather than the core operating system.

How to evaluate a managed monitor without hype

If you compare a managed option, ask concrete questions:

Can it monitor multiple sites from one dashboard?
Can it keep historical trends without manual exports?
Can it support practical thresholds and alert routing?
Can you turn outputs into reports that non-engineers can use?
Can your team adopt it without building another internal platform?

Ask those questions before you commit budget, so you do not pay for another disconnected view that still leaves reporting and triage on your team.

Common mistakes in free-tool comparisons

Mistake 1: comparing feature lists without workflow context

A long list of metrics is not the same as a reliable monitoring process.

Mistake 2: ignoring maintenance time

“Free” tooling with weekly repair work is not free in practice.

Mistake 3: treating diagnostics as monitoring

WebPageTest and PSI are excellent for investigation. They are not automatic substitutes for portfolio monitoring workflows.

Mistake 4: assuming one tool must do everything

Healthy stacks combine tools with clear roles: monitor broadly, diagnose deeply, report clearly.

FAQ

Is PSI enough for free PageSpeed monitoring?

For one site and occasional checks, often yes. For multi-site teams and ongoing accountability, PSI alone is usually not enough because workflow, alerting, and historical operations are limited.

Is WebPageTest better than PSI?

They solve different problems. PSI is great for quick checks and communication. WebPageTest is better for deep diagnostics. Most teams benefit from using both for different jobs.

Is Lighthouse CI free monitoring?

It is free software and excellent for CI guardrails, but it still has maintenance cost and usually needs additional layers for cross-site reporting and non-technical stakeholder updates.

Can I run a fully free stack for an agency?

You can, but the process overhead usually grows quickly: setup drift, dashboard fragmentation, and manual reporting work become the bottleneck.

Should I stop using free tools after moving to managed monitoring?

No. Keep them as diagnostics and verification tools. The goal is not “free vs paid”; the goal is a workflow where each tool has a clear role.

How does Apogee Watcher Free compare to PageSpeed Insights?

PSI is free to use for manual checks; Watcher Free is free to subscribe to for scheduled runs on one site within the limits above. PSI does not give you a first-party monitoring history and alert workflow; Watcher does, within those caps. You still use PSI for a quick one-off look, or WebPageTest when you want its public lab matrix (locations, filmstrip, shareable run links) — Watcher already surfaces a waterfall in the test view for your own runs.

If your team is spending more time stitching free tool outputs than fixing regressions, split the work: keep PSI and WebPageTest for investigation, and put recurring checks somewhere they will actually run—whether that is Lighthouse CI, a hosted monitor, or Apogee Watcher Free for a single-site evaluation. Join the early-access waitlist if you want early access to the full product surface.

Mobile vs Desktop Core Web Vitals: Why You Need to Monitor Both

Apogee Watcher — Wed, 25 Mar 2026 14:57:28 +0000

Most teams treat Core Web Vitals like one scoreboard. They run a quick test, pick a single set of scores, and move on. The problem is that Core Web Vitals are defined per page load; device shows up in how you measure—mobile versus desktop in lab emulation, or in field data grouped by form factor. The same URL can therefore produce different LCP, INP, and CLS results across those contexts. Mobile and desktop travel different routes through your UI, assets, network conditions, and interaction patterns. If you monitor only one side, you will miss regressions that matter—and you will struggle to justify prioritisation when clients ask, “Why did this change?”

The trap: one device, one story

It’s easy to fall into a workflow like this:

Mobile is “important”, so you track mobile CWV only.
Desktop is “nice to have”, so you leave it until later.
When something breaks, you re-run tests and pick the latest scores to explain the incident.

This approach has two predictable failure modes:

Hidden regressions — A fix that improves desktop experience can still leave mobile failing (or vice versa).
Unclear communication — You end up explaining different symptoms with one set of numbers. Clients rightly lose confidence.

If you want monitoring that supports real delivery and client-ready reporting, you need a repeatable paired view: mobile + desktop for the same pages, the same cadence, and the same triage rules.

If you need a quick primer on the metrics themselves, start with What Are Core Web Vitals?.

Why mobile vs desktop Core Web Vitals diverge

Core Web Vitals can look “similar” at a headline level, but the underlying causes often differ. The most common reasons:

Different rendering and loading conditions

Mobile is constrained: less CPU headroom, different caching patterns, and more aggressive resource variation. That shows up strongly in:

LCP (Largest Contentful Paint): often driven by large images, fonts, or other heavy elements on the critical path (the LCP element can also be a text block or a video poster, depending on the page). If those pieces behave differently across breakpoints, LCP will diverge.

Different interaction patterns (INP)

INP captures interaction responsiveness, which often behaves differently by device due to:

Touch vs pointer interactions
Different event targets and UI density
Varying execution cost on lower-end hardware

If you only look at one device’s INP, you can miss “works on desktop” but “feels slow on phones” issues.

Different layout stability (CLS)

CLS is highly sensitive to responsive layout, late-loading elements, and dynamic components that appear only under certain breakpoints (ads, banners, late injected UI, etc.). A page can be stable on desktop and still shift on mobile.

For a deeper explanation of what each metric actually means, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It.

What to monitor in practice (beyond the total score)

Monitoring both devices is necessary, but it’s not sufficient by itself.

You also need to monitor the right dimensions:

1. Treat each device as its own budget

Instead of one “CWV target” for the page, define device-specific thresholds for the metrics you care about. A pass on desktop should not automatically compensate for a fail on mobile.

This keeps decisions defensible when you propose fixes to stakeholders.

If you want a structured way to set thresholds, use our Performance Budget Thresholds Template.

2. Compare by change, not by absolute numbers alone

Absolute CWV numbers can vary slightly run-to-run. What should drive action is:

What changed since the last known good period
Which metric moved first (LCP vs INP vs CLS)
Which device changed (mobile-first incidents vs desktop-only issues)

3. Triage using “worst metric per device”

A practical triage rule:

For mobile: focus on the single worst metric (LCP/INP/CLS) and the reason it is failing.
For desktop: do the same.

Then decide whether you have a shared root cause (both devices fail similarly) or breakpoint/device-specific problems.

A practical monitoring workflow for agencies

If you want this to work across clients and pages, keep it repeatable. Here’s a workflow you can run every week:

Choose pages that reflect real funnel risk
- Homepage (first impression)
- Key category or service pages (high intent)
- Conversion pages (where UX pain becomes business cost)
Run paired analysis for the same pages
- Mobile + desktop tests on the same cadence
- Stable analysis conditions (avoid mixing “random checks” with planned ones)
Record findings in the same order
- Mobile: LCP → INP → CLS (and a quick “what it likely affects” note)
- Desktop: LCP → INP → CLS
Assign device-specific priority
- If mobile fails and desktop passes, your “first fix” should usually start mobile unless you have a desktop-only user segment.
Set alerts that match the story
- Budget breaches on a device should trigger the device’s reporting, not just the overall page score.
Deliver client-ready reporting
- Give clients a paired narrative: “what you saw” and “what you changed next”.

For the setup side of automated monitoring across multiple sites, see How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

And if you’re turning this into deliverables, the Client-Ready Core Web Vitals Report Outline helps you package the evidence into something stakeholders actually read.

Interpreting results: three common scenarios

When you review mobile vs desktop CWV together, you’ll usually fall into one of these buckets:

Scenario	What it often means	How you should respond
Mobile failing, desktop ok	Mobile critical path or interactive cost is the bottleneck	Prioritise mobile-first fixes (hero/LCP and interaction latency)
Desktop failing, mobile ok	Desktop-only layout or heavy JS path	Focus on desktop breakpoints, scripts, and layout stability
Both failing consistently	Shared design debt or performance regressions	Treat it as a system-level problem, then verify with paired reruns

The important part is that you avoid the “one score explains everything” habit. Paired monitoring turns CWV from a vanity chart into a decision system.

What your client update should say (example wording)

When clients ask “why are there two scores?”, they usually want a single paragraph that explains what changed and what you will do next.

Here’s a simple template you can reuse:

Mobile-first incident (mobile fails, desktop ok):

“Mobile performance is out of budget right now (LCP/INP/CLS), while desktop is within budget. This pattern usually points to a mobile-specific bottleneck: hero rendering timing, touch interaction cost, or a late-loading component that behaves differently on smaller breakpoints.”
“Next step: we’ll apply a targeted first-fix on the affected mobile path, then re-run the same paired checks to confirm both the device budget and the user-story are improving.”

Shared incident (both devices failing in a similar way):

“Both mobile and desktop are currently out of budget for the same metric area. That usually means a shared component, shared asset, or shared build/deploy change rather than a single device quirk.”
“Next step: we’ll verify what changed in the release window, then test the fix with paired checks to ensure the improvement holds across devices.”

If you include field data (for example, when you do CrUX-aware reporting), keep the wording consistent: explain what your lab checks caught, and how the field view supports the same story. The goal is less debate and more action.

A quick consistency check for every report

Before you send your update, run this quick self-check:

Are you using the same page set for both devices (so the comparison is fair)?
Did you name the first metric to fail on each device (so the triage is clear)?
Does your next step match the device that is failing (or explain why you’re fixing something shared first)?
Did you state how you will verify after changes (re-run paired checks, not “we’ll look later”)?

Client-ready reporting: avoid confusion with one sentence

Clients often ask why you’re reporting two device scores.

Your answer should be simple:

“Mobile and desktop measure different experiences. We monitor both so we catch issues that only appear on one device and so our fixes stay prioritised and verifiable.”

When you present this in a consistent report format, it is easier for stakeholders to focus on the next actions instead of arguing over a single headline score.

Operational checklist for your next report

Pick the same set of pages every reporting cycle
Confirm mobile + desktop are both included in the schedule
Use device-specific thresholds for LCP/INP/CLS
Triage by worst metric per device, then explain likely root cause
Reference a repeatable next step (fix + verify, not just “we will look into it”)
Share a paired narrative that stakeholders can understand in under two minutes

FAQ

Do I need to monitor both mobile and desktop if mobile gets most traffic?

Yes. Even if mobile dominates, desktop still represents business risk for a portion of your audience. More importantly, fixes can improve one device while leaving the other failing. Paired monitoring prevents blind spots.

Which metric should I start with: LCP, INP, or CLS?

Start with the worst metric on each device (mobile and desktop separately). In many audits, improving LCP is the fastest high-impact win, while INP usually surfaces interaction pain and CLS highlights layout instability—but the right first lever depends on what is actually failing.

How often should we review paired CWV?

For most agency workflows, weekly review is a good starting point. For active releases or client campaigns, you may need tighter cadence to verify that fixes actually hold.

What if a page behaves differently by device (e.g. different layout/components)?

That’s exactly why paired monitoring helps. Explain the difference in your report: the breakpoint experience is part of the user journey, and device-specific findings lead to device-specific fixes.

Will paired monitoring slow down the workflow?

It shouldn’t. The operational cost should live in automation, not manual re-checks. If your monitoring is scheduled and your reporting is templated, you get more reliable evidence without extra churn.

If you want a repeatable way to monitor mobile and desktop Core Web Vitals across client portfolios (with paired evidence, budgets, and client-ready reporting), Apogee Watcher is built for that workflow. Join the early-access waitlist.

The PageSpeed Prospecting Workflow: Analyze, Report, Qualify, and Reach Out

Apogee Watcher — Tue, 24 Mar 2026 11:51:24 +0000

Prospecting for performance work usually breaks at the same point: you can run audits, but you cannot turn those audits into a consistent outreach system your team can repeat every week.

This guide gives you a practical workflow to do exactly that: analyse prospects, package evidence, qualify intelligently, and reach out with context rather than generic cold email.

Why most performance outreach stalls

Most agencies still do outreach in a one-off way:

Run PageSpeed checks manually
Paste scores into a spreadsheet
Write a custom pitch each time
Lose track of what was sent and what happened next

That approach can win an occasional reply, but it does not scale. You need a system where analysis, reporting, and outreach use the same source of truth.

In agency terms, the failure mode is simple: your technical work and your sales work live in different places. The technical lead has real findings, while the account side has a half-complete spreadsheet and old email snippets. A workflow fixes that gap.

The 4-stage prospecting workflow

The simplest version of a repeatable workflow is:

Analyse each prospect website (mobile + desktop)
Report findings in a one-page shareable format
Qualify using score bands plus metric-level context
Reach out with messaging that matches what you found

If you want the strategic background first, read From Monitoring to Pipeline: Why PageSpeed Data Works for Agency Prospecting. This post is the operational playbook.

Stage 1: Analyse prospects in a consistent way

Your analysis stage should answer one question: is this a lead we can help quickly and credibly?

For each prospect URL, run:

Mobile PageSpeed analysis
Desktop PageSpeed analysis
Core metric checks (LCP, INP, CLS and overall score context)

Use the same analysis pattern across all leads. Inconsistent inputs produce inconsistent outreach.

For setup details on the monitoring side, How to Set Up Automated PageSpeed Monitoring for Multiple Sites covers the technical flow.

Choose pages that reflect business risk

Do not analyse random URLs just because they are easy to fetch. Pick pages that map to real commercial value:

Homepage (first impression and navigation path)
A core service or category page (high-intent traffic)
A conversion page (contact, checkout, booking, or lead form)

When your outreach references these pages, the conversation moves from “your site is slow” to “this step in your funnel is likely costing attention and conversions”.

Keep analysis conditions stable

To make lead comparisons useful, run with stable assumptions:

Same strategy pair (mobile + desktop) for every lead
Similar analysis window each week (avoid comparing stale and fresh runs randomly)
Clear note when a result is an outlier (for example, a temporary script incident)

You do not need perfect lab science. You need enough consistency that your qualification decisions are trustworthy.

Stage 2: Turn raw results into a one-page report

A lead report should be easy to skim in under two minutes. The goal is not to impress with complexity. The goal is to make action obvious.

Your one-page report should include:

Current score snapshot (mobile and desktop)
Top failing metrics and why they matter
Recommended first actions
A clear "what happens next" suggestion

If you need structure, use the same narrative logic from the Client-Ready Core Web Vitals Report Outline: problem first, then practical fixes, then next step.

Stage 3: Qualify leads by score band and fit

Not every weak score is a good lead, and not every strong score is a bad lead. Qualification should combine score band with commercial fit.

A practical qualification model:

High priority: weak performance plus clear business relevance
Medium priority: mixed performance but visible upside
Low priority: limited upside, low-fit vertical, or poor service match

Then map each lead to a stage (prospecting, analysed, contacted, qualified, converted) so your team knows what to do next.

This is where many agencies leak pipeline: they keep re-analysing leads but do not advance stages.

Qualification signals beyond score alone

Use score bands as the first filter, then apply fit checks:

Does this prospect match your ideal service type (agency, ecommerce, SaaS, publisher)?
Is there an obvious high-value page where performance matters?
Can you identify decision-maker context or clear contact path?

A low score with no buying path can waste more time than a medium score with clear urgency and reachable stakeholders.

Stage 4: Reach out with score-aware messaging

Outreach works better when it sounds like you looked at the site, not like you blasted a template.

Use score-aware copy:

Critical issues: lead with risk and immediate fixes
Moderate issues: lead with opportunity and prioritisation
Strong baseline: lead with retention and regression prevention

Your opening line should reference one concrete observation from the report. Your CTA should be a small next step, such as a short review call or a scoped mini-audit.

If you are packaging this as a paid offer, How to Sell Performance Monitoring Services to Your Clients shows how to turn this workflow into clear service tiers.

Example outreach angles by lead condition

You do not need dozens of templates. You need a few strong patterns that fit the report.

Pattern A: severe mobile bottleneck

Opening: reference the observed issue on a key page
Body: explain why this likely affects user flow and paid/organic landing quality
CTA: offer a short call with a first-fix plan

Pattern B: mixed metrics, clear upside

Opening: acknowledge baseline is not catastrophic
Body: show the two improvements most likely to move experience and stability
CTA: propose a small scoped audit

Pattern C: strong baseline, regression risk

Opening: position as prevention, not rescue
Body: suggest monitoring plus alerting before future deploy regressions
CTA: propose a lightweight monitoring review

The best outreach is specific, short, and easy to act on.

Operational checklist for your first batch

Start with 10-20 prospects and run this loop:

Add URLs to your prospect list
Run mobile + desktop analysis
Generate one-page reports
Assign score band and stage
Send outreach by priority
Review outcomes and tighten copy for the next batch

The first batch is where you calibrate your qualification rules. Do not skip this review step.

Track simple outcomes in that review: outreach sent, reply rate, calls booked, and qualified opportunities created.

Common mistakes to avoid

Mistake 1: Treating all low scores the same

Two sites can have similar totals and very different root causes. Segment by failing metric, not just headline score.

Mistake 2: Sending reports without a narrative

A report without a recommended next step is just a file attachment.

Mistake 3: Mixing delivery and sales statuses

Track where the lead is in outreach separately from technical analysis status.

Mistake 4: Overbuilding before validating

Do not automate everything first. Prove the workflow on a small batch, then scale it.

Mistake 5: Writing outreach like a diagnostics report

Your first message is not the place for every metric. Use one concrete observation, one practical implication, and one next step.

FAQ

Do I need a full CRM to run this workflow?

No. You need a reliable way to store lead records, analysis results, report links, and stage changes. Keep it simple at first.

Should I include both mobile and desktop in outreach?

Yes. Mobile often reveals problems that stakeholders underestimate, while desktop helps frame broader UX impact.

How often should I re-analyse prospects?

For active opportunities, re-check before key follow-ups so your message reflects current performance.

What is the minimum viable report for cold outreach?

A score snapshot, top failing metrics, and three prioritised actions are enough to start useful conversations.

How many prospects should I include in one batch?

For most teams, 10-20 prospects is the practical range.

If you want to run this workflow without duct-taped spreadsheets and one-off scripts, Apogee Watcher is built to support this model from analysis through client-ready reporting. Join the early-access waitlist.

How to Sell Performance Monitoring Services to Your Clients

Apogee Watcher — Mon, 23 Mar 2026 06:47:34 +0000

Your team already knows how to run Lighthouse, read CrUX, and explain why LCP slipped after a deploy. The harder part is getting paid for ongoing performance work without it turning into unpaid firefighting or a vague “we’ll keep an eye on it” promise.

This post is about how to package and sell performance monitoring as a service: what to name it, what the client is actually buying, and how to back your fee with evidence they can show their boss.

What clients are really buying

Buyers rarely wake up asking for “a monitoring stack.” They want fewer surprises in search, fewer angry tickets after a release, and a clear story when leadership asks why the site feels slow.

Frame the service around outcomes and cadence, not tools:

Baseline and ownership — Who is responsible for Core Web Vitals on their side, and what “good enough” means for their traffic and template mix.
Regression detection — You will catch meaningful drops after deploys, campaigns, or third-party changes before they show up in revenue or rankings.
Reporting they can reuse — Summaries that fit a QBR or a Slack update, with lab and field data spelled out in plain language.

That lines up with the same rigour you would put into a Core Web Vitals monitoring checklist for agencies: repeatable steps, not a one-off PDF that ages in a shared drive.

Separate the audit from the retainer

A project sells a snapshot: baseline scores, a short fix list, maybe a follow-up verification run. A retainer sells continuity: scheduled tests, alert routing, and a monthly or quarterly review tied to their release calendar.

In conversations, be explicit:

The audit answers “where are we today?”
The retainer answers “how do we know nothing important broke last Tuesday?”

If you blur the two, clients assume the audit was the whole story—and you end up re-running PSI by hand every time they panic.

Give the package a clear scope

Name the tiers so procurement can file them. Example shape (adjust numbers to your reality):

Tier	What the client gets	What you need from them
Baseline	One structured assessment, prioritised fixes, optional verification run	Access to staging or tag manager, a named technical contact
Watch	Scheduled monitoring on agreed URLs, alerts to an agreed channel, monthly summary	List of business-critical templates; change notifications for major releases
Partner	Everything in Watch plus QBR-ready reporting, performance budget ownership, escalation path	Executive sponsor for trade-offs (ads, scripts, hero assets)

You do not need ten bullet points per cell. You need enough clarity that both sides know when the engagement has done its job.

Price against risk and attention, not against “number of tests”

Hourly billing for ad-hoc checks trains clients to minimise contact. A fixed line item for “performance monitoring” trains them to treat speed as infrastructure.

In our experience, agencies win when they tie the fee to:

Portfolio impact — How many properties and high-value templates sit inside scope.
Alert handling — Whether you triage alerts or only summarise monthly.
Reporting depth — Self-serve PDFs versus live walkthroughs.

If you already use a client-ready Core Web Vitals report outline, say so: it shows you are not inventing the narrative from scratch each month.

Proof beats adjectives

Prospects smell generic claims. Build your sales collateral from:

Before and after on a small set of URLs, with dates and deploy markers.
Field data when CrUX exists, with an honest note when traffic is too low for it.
One competitor or sector benchmark they recognise—used carefully, not as a guarantee.

Automated runs help here because they produce a time series. A single PSI screenshot is a postcard; a few weeks of scheduled lab data plus field trends is an argument.

Objections you should plan for

“We already use PageSpeed Insights.”

Agree—and position you as the team that operationalises it: URL coverage, schedules, ownership when scores move, and reporting that matches their meetings.

“Can’t our developers do this?”

Often yes, for one product. Your offer is coverage across sites and releases without pulling senior engineers into weekly manual checks.

“This sounds expensive.”

Compare it to one preventable incident: a paid campaign pointing at a slow landing page for a week, or an SEO-visible regression after a well-meaning A/B test. You are pricing early warning, not a licence fee.

When delivery has to scale with the pitch

The moment you sell monitoring to more than one active client, “I’ll run the tests when I can” stops working. You need shared workspaces, consistent URL sets, and reporting that does not depend on whoever had spare time that morning.

That is where a product-shaped setup helps. Our approach on web performance monitoring for agencies supports that reality: portfolio-scale coverage, scheduled PageSpeed-style testing, alerts, and client-ready outputs—so the service you sell is the same service your team can actually run. If you are wiring the technical side, how to set up automated PageSpeed monitoring for multiple sites walks through the moving parts in one place.

None of that replaces a clear scope and a price. It does make it easier to keep the promise you made in the proposal.

FAQ

What should I include in the first sales conversation?

Scope (which sites and templates), cadence (how often you report), who receives alerts, and what happens when a metric crosses the line. Leave tool logos for the appendix.

How do I avoid giving away monitoring for free?

Put “monitoring and alerting” in the SOW or retainer as its own line. If it is only in the footer of a build proposal, clients will treat it as goodwill.

Is white-label reporting worth offering?

For many agencies, yes—clients expect PDFs they can forward. Charge for the preparation and narrative, not for the export button.

When does automated monitoring become a must-have?

When releases are frequent, campaigns rotate often, or more than one team can change the same templates. That is when manual spot-testing misses regressions.

If you are standardising performance services across your portfolio, start with a clear tier structure, then make sure your delivery stack matches what you sold. Apogee Watcher is built for agencies who need that match—join the waitlist for early access when you are ready to put the workflow on a single platform.

Product Spotlight: How Apogee Watcher Discovers Pages Automatically

Apogee Watcher — Sun, 22 Mar 2026 10:26:41 +0000

You cannot monitor what you have not listed. For a single marketing site, that list might live in a spreadsheet. For an agency with dozens of properties, each with new landing pages, campaign paths, and refactors, the list rots within weeks. Someone adds /pricing/v2 and nobody updates the monitor. A client launches a seasonal URL and your Core Web Vitals monitoring checklist still points at last quarter’s sitemap export.

This post is a product spotlight on how Apogee Watcher discovers pages automatically so your PageSpeed coverage stays aligned with what is actually on the site—not with what someone remembered to paste into a config file.

The problem: static URL lists do not scale

Manual URL maintenance fails in predictable ways:

Onboarding friction — Every new client site means transcribing URLs from a crawl export or guessing priorities.
Drift — Product and marketing teams ship pages continuously; monitoring configs rarely keep pace.
Hidden risk — High-traffic templates (PLPs, hubs, key funnels) often live several clicks from the homepage. If they never make it into your test set, you will not see regressions until search, ads, or support tell you.

Automated PageSpeed monitoring only helps if the set of URLs under test reflects reality. Discovery is the bridge between “we run Lighthouse on a schedule” and “we run Lighthouse on the pages that matter.”

What “automatic page discovery” should mean

A serious discovery flow does more than grab the homepage:

Prefer structured sources — Read the site’s own inventory (sitemap.xml, sitemap indexes, nested sitemaps) before guessing from links.
Fall back gracefully — When sitemaps are missing, incomplete, or stale, follow internal links within the same domain with sensible depth and rate limits.
Stay within bounds — Cap how many URLs you ingest per run so large sites do not overwhelm quotas or your monitoring plan.
Make ownership obvious — Show which URLs were found automatically versus added manually, so teams can trust and prune the list.
Fit agency workflows — Discovery should support portfolios: many sites, each with its own rules, without a separate crawl script per client.

That is the bar we designed Apogee Watcher against.

How Apogee Watcher discovers pages

Apogee Watcher uses a sitemap-first, crawl-second pipeline for external sites (no access to your clients’ codebases required).

Sitemap discovery (primary)

For most production sites, the canonical list of important URLs already exists in XML:

Standard locations such as /sitemap.xml and sitemap index files.
Recursive handling of sitemap indexes so nested sitemaps are followed.
Support for compressed sitemaps where applicable.

When a sitemap is healthy, you get broad coverage quickly—often including sections marketing forgot to mention in the handover doc.

HTML crawling (fallback)

When sitemaps are absent, blocked, or incomplete, Watcher can crawl HTML using the same host:

Follow links that stay on the same domain so discovery does not wander onto third parties.
Respect depth and delay settings so crawls remain predictable.

Crawling is a safety net, not a replacement for a good sitemap—but in the real world, you need both.

Controlled scope

Discovery runs honour configuration for maximum URLs and maximum crawl depth, aligned with how agencies actually operate: you want coverage, not an accidental import of ten thousand tracking-parameter variants.

Syncing with your monitoring inventory

Discovered URLs are synced into your page list and marked as auto-discovered, so you can filter, review, and deactivate what should not be tested—without losing the audit trail of what the system found.

Together with scheduled PageSpeed Insights-based tests, performance budgets, and email alerts when scores breach thresholds, discovery closes the loop from “what exists on the site” to “what we measure continuously.”

Why this matters beyond monitoring

Reliable URL inventory is also the substrate for other workflows. Once pages are known and tested, the same performance signals can feed prioritisation—what to fix first, what to show a client, and how prospecting fits alongside monitoring. Our introduction to that pipeline is in From monitoring to pipeline: why PageSpeed data works for agency prospecting; this spotlight focuses on the discovery piece that makes the rest possible.

If you are new to how Core Web Vitals fit into the story, start with What are Core Web Vitals? A practical guide for 2026—then come back here for how Watcher keeps the URL list honest.

Running discovery in Apogee Watcher

From the site view in the admin, use the Discover Pages action. A modal lets you choose discovery method (sitemap or HTML crawl), caps for URLs and depth, whether to respect robots.txt, optional custom sitemap URL, and include/exclude patterns where you need tighter control. After the run, you see counts for discovered versus skipped URLs and any errors—then new pages appear in your inventory marked as auto-discovered, ready for scheduling alongside the pages you added by hand.

What you can achieve

You can move from brittle spreadsheets to a living inventory of URLs that updates when you run discovery—so your lab scores and trends track real site structure, not last month’s export. That is how agencies keep Core Web Vitals coverage credible without hiring someone to babysit URL lists.

Join the early-access waitlist if you want multi-site PageSpeed monitoring with automated discovery, budgets, and alerts built for agency portfolios.

FAQ

Does Apogee Watcher replace my SEO crawler?

No. Discovery is optimised to build and refresh a monitoring URL set, not to replace full SEO audits. Use your SEO tools for indexation and content strategy; use Watcher to keep performance tests aligned with the URLs you care about.

What if my client’s sitemap is wrong?

You can add or remove pages manually, adjust discovery settings, and re-run discovery when the site changes. Auto-discovered pages are labelled so you can audit the list.

Will discovery hit my PageSpeed API quota?

Discovery itself ingests URLs; scheduled tests consume PSI quota. Caps on URLs and crawl behaviour help keep both discovery and testing within plan limits—see API usage in the product for your tier.

Is crawling allowed on every site?

You should follow each client’s robots.txt policy and contractual terms. Watcher exposes options (including respect for robots rules in configuration) so teams can align discovery with site owner expectations.

From Monitoring to Pipeline: Why PageSpeed Data Works for Agency Prospecting

Apogee Watcher — Fri, 20 Mar 2026 14:17:32 +0000

The problem: prospecting with “screenshots and vibes” is slow

If you sell performance audits as an agency, your outreach often starts the same way:

Pick a target: an agency lead list, a competitor discovery list, referrals, or LinkedIn.
Open PageSpeed Insights for each prospect.
Copy numbers (and screenshots) into a doc.
Write a pitch that explains what you found and why it matters.

That works for a handful of leads. It breaks down when you want repeatability. You end up with inconsistent snapshots, you lose time, and you still don’t have a simple “report asset” you can reuse across email, follow-ups, and calls.

Why PageSpeed data works in prospecting

Generic cold emails say “we improve speed”. Your best prospects already hear that every day.

PageSpeed evidence is different because it gives you:

A consistent scoring baseline (so your pitch doesn’t look hand-wavy)
Clear, named targets (LCP, INP, CLS) that map to actual development work
A prioritisation story (“here’s what to fix first” based on what’s failing)
A deliverable you can share (a one-page snapshot with an expiring link)

In practice, you’re not “selling monitoring”. You’re using your monitoring capability as a repeatable way to produce audit-ready proof.

The workflow: from prospect → audit → outreach

A leads management workflow can turn the monitoring workflow into prospecting you can run on a batch.

Step 1: capture prospects (prospect records)

Start with a list of prospects (manual entry today). For each prospect, store:

Company name and website
Optional contact URL / email notes
A place to track where they are in your sales motion

The workflow stores the prospect record so you don’t lose context between audits and outreach.

Step 2: run automated PageSpeed analysis (mobile + desktop)

When a prospect is created (or refreshed), your system can run PageSpeed Insights for:

Mobile strategy
Desktop strategy

It stores the results so you can track performance over time and reuse the same dataset for reporting and outreach.

Step 3: generate a one-page lead report (HTML + PDF)

For each analysed prospect, generate a one-page report you can send or reference.

This gives you a consistent pitch asset with:

A performance snapshot
The metrics that matter (Core Web Vitals / PageSpeed score)
Suggested next steps

Step 4: qualify by score band (prospecting → contacted → qualified)

Instead of writing a different pitch from scratch, you qualify prospects by score band:

Excellent: keep it congratulatory and offer advanced monitoring
Good / fair: highlight the improvement path and what it unlocks
Poor: lead with urgency and ROI framing for fixes

Stage tracking keeps follow-up consistent, even when you refresh results.

Step 5: send score-based outreach (email templates)

Use score-band email templates and send through your email/outreach platform.

What to reuse from “monitoring” when you prospect

If you already monitor clients, you already have the hard part: consistency.

What you’re reusing is:

The habit of running scheduled audits (instead of one-off checks)
The habit of turning metrics into thresholds and next actions
The deliverable mindset: a report you can share confidently with stakeholders

Your prospecting workflow then becomes an extension of your monitoring delivery, not a separate channel you have to invent.

Practical CTA: your first 10 prospects

Want to try this without overbuilding?

Add 10 prospect URLs (pick the ones you can actually follow up on).
Run automated analysis for both mobile and desktop.
Generate the one-page lead report assets.
Send score-band outreach to the top opportunities first.
Track outcomes by stage so you can tighten messaging after your first batch.

If you want to try this, start with a small batch and iterate once you see what actually drives replies.

How to run this workflow as a batch

Prospecting becomes manageable when you run it like delivery, not like ad-hoc outreach. In each batch, aim for this loop:

pick 10–20 prospect URLs
run analysis (mobile + desktop)
generate lead report assets for the top opportunities
send outreach in score-band order
review replies, move stages, and tighten your messaging for the next batch

If your batch is too big, follow-up breaks and the workflow stops being a workflow.

What to capture per prospect (so outreach stays consistent)

The difference between a workflow and a spreadsheet is what you store for each lead. Your goal is to preserve context between analysis and outreach.

When you create a prospect record, store:

Company identity

Company name (for email personalisation)
Website URL (the anchor for PageSpeed analysis)

This is the minimum. Without it, every follow-up resets to “hi there”.

Contact context

Optional contact URL (e.g. a page where you can extract a contact email)
Lead notes you actually use (a short set of bullet points you can refer to later)

Keep lead notes short and purposeful. Write notes you can reuse later in a follow-up email.

Platform/CMS (used for pitch tailoring)

Platform/CMS detection can help you tailor your language. This is where you avoid the trap of treating every website as “custom”.

If you know it’s WordPress, you can mention themes/plugins more naturally. If it’s Shopify, you can talk about image handling and Liquid patterns more concretely. If it’s “custom”, you can still tailor by pointing at the most relevant diagnostics (scripts, render-blocking, and so on).

Score bands: the simplest qualification system that still feels personal

Your outreach should not depend on fragile gut feel. Score bands give you structure without making the email feel automated.

Use a score band system like this:

Excellent (90–100): “you’re doing well; here’s how to keep it that way”
Good / fair (75–89): “you’re close; here’s what to improve first”
Poor (0–49): “you’re losing speed; here’s the quick ROI framing”

Two important details:

1) Qualify by what failed, not just the final score

In your outreach, reference the top failing metric(s) from the report. Even when two prospects have the same overall score, the fix path differs.

If LCP is the main issue, your pitch should match that. Reference the metric(s) that are clearly failing in the report.

2) Keep your “next step” consistent with the score band

Good outreach always has an easy next step. For performance audits, that next step is usually:

a short call to confirm priorities, or
sending a follow-up audit plan after the prospect agrees to proceed

If a prospect is excellent, your next step might be “audit + monitoring for regressions”. If they’re poor, your next step might be “audit + remediation plan for the top bottlenecks”.

How to turn one-page lead reports into real outreach assets

The report is not just a PDF you attach. It’s the proof and the structure for the email you send.

A good lead report for outreach has:

a clear executive summary
a scorecard and the main failing metrics
recommendations that read like “what we would do first”

This avoids mismatches between your email, your report, and your follow-up questions.

Keeping the report and the outreach tied to the same dataset prevents drift. You don’t have to “re-explain your audit” at every step.

Practical follow-up: qualify leads through stages, not memory

Once you send outreach, the workflow needs to keep track of where leads are. The stages matter because they determine what you do next.

A practical stage ladder for performance audit outreach:

prospecting (created; not analysed yet, or analysed but not outreach-ready)
analysed (report generated; you know what to say)
contacted (email campaign sent; waiting for response)
qualified (response received and they fit your scope)
converted (they agree to work; now you transition into monitoring)
rejected (no fit; record the reason so you don’t waste time later)

What you can achieve with your first batch

If you run a small prospecting batch end-to-end, you get a predictable loop:

Build once, reuse often

You stop rebuilding the same pitch from scratch.

Tighten messaging from outcomes

Stage tracking tells you what to refine (which score band, which report narrative, and which next step).

Make prospecting a team habit

Instead of chasing leads manually, your team runs prospecting as a repeatable delivery workflow.

If you want to see what this looks like end-to-end, apply the workflow to your first batch of prospects.

FAQ

Is this post only for agencies (or also for freelancers)?It’s written for agencies, but freelancers can use the same workflow logic. If you manage more than a couple of prospects at a time, the batch approach and score-band structure save time and keep your messaging consistent.

Is this workflow available today, or do I have to build it?You can run the workflow with different levels of automation:

Fully automated: your tooling can batch-run PageSpeed analysis, generate report assets, and orchestrate outreach.
Hybrid: you automate analysis and reporting, then use your outreach tool manually for sends.
Manual: you run audits and build the one-page snapshot yourself. Pick the level that matches your time and team capacity, then standardise over time.

What if PageSpeed Insights scores vary between runs?Use the report as a prioritisation tool, not a perfect measurement. Base your pitch on the main failing metric(s) you can clearly see in the dataset, and send outreach once you have a consistent story for mobile + desktop.

Do I need CrUX (field data) to run this prospecting workflow?No. For outreach you mainly need consistent evidence and a narrative. CrUX can be helpful when available, but it isn’t required to run the workflow.

How do I choose which page to analyse for a prospect?Pick a page that represents the work you’ll actually improve. Common choices are homepage, a core landing page, and (when relevant) a conversion step page. If you’re unsure, start with the most important business funnel step and expand later.

Can I use the one-page lead report without sending the email campaign?Yes. Some agencies use the report as a standalone audit asset in DMs or follow-up calls. The value is the structured evidence and the “what to fix first” narrative.