A performance lead at a twelve-site agency told us their “daily monitoring” meant one person opened PageSpeed Insights on Mondays. Checkout on a retail client had been slow since the previous Thursday. The sponsor noticed first because nobody was scheduled to test that URL until the weekly marketing pass.
That is what happens when pagespeed monitoring is a calendar habit instead of a configured schedule. Frequency and priority are not fine print on a retainer. They decide whether regressions show up in your tools or in a client screenshot.
This guide is for teams who already run automated PageSpeed monitoring on some sites but still treat every URL the same. We cover how to pick cadence per site, which pages earn higher priority, and how monthly quotas force trade-offs you should document before sales promises outrun your test budget.
Why ad-hoc PageSpeed checks fail on multi-site portfolios
Manual PSI runs work for a single launch or a post-deploy sanity check. They stop scaling when each client has five to fifteen URLs and you test mobile and desktop separately.
At ten clients with eight URLs each, one full pass is 160 lab runs. At two minutes per tab, that is more than five hours of copying scores before the first site is stale again. Teams compensate by testing only homepages, testing monthly, or testing after someone complains. None of those choices are written down, which makes renewals awkward when a regression lived on /checkout for two weeks.
Automated vs manual PageSpeed testing is not about abandoning spot checks. It is about separating exploratory runs (debugging one URL after an alert) from scheduled runs (the portfolio baseline that runs without a human opening a browser).
Scheduled monitoring only helps if you answer two questions up front:
How often should each site be tested?
Which URLs should run first when time or quota is tight?
Skip those and you get either alert noise on low-risk sites or silence on the URLs that pay the bills.
What to include in a scheduled PageSpeed monitoring setup
Before you tune frequency, agree what “a test” means in your stack. For most agencies we work with, a useful scheduled run includes:
Lab metrics you can compare week to week (LCP, INP, CLS, performance score, and supporting Lighthouse data where available).
Mobile and desktop as separate series, because retail and publishing sites often diverge by device class.
The same URL set each cycle, so trends are real rather than an accident of which page someone remembered.
Stored history tied to deploy markers or change notes when you have them.
Budget checks after results land, so breaches can feed alerts without a separate manual export pass.
Discovery matters too. If your tool finds sitemap URLs automatically, you still decide which discovered paths are included in scheduled tests versus archived. A bloated URL list is how teams burn quota on tag pages nobody sells against.
Our Core Web Vitals monitoring checklist for agencies has a setup block for pages, budgets, and alert recipients. Use it as the intake template when onboarding a new domain.
How to choose PageSpeed test frequency per site
Cadence should follow business risk, not equality across clients. A brochure site for a local firm does not need the same schedule as a Shopify store in peak season.
Common frequency bands
Cadence | Fits when | Trade-off |
|---|
Hourly | High-traffic commerce, paid landing pages during campaigns, sites under active performance remediation | Highest quota use; best for short windows, not year-round on every client |
Daily | Core revenue sites, membership products, any domain with weekly deploys | Default many agencies expect in retainers; still heavy at scale |
Weekly | Stable marketing sites, B2B content hubs, clients on maintenance-only plans | Misses fast regressions on aggressive release trains |
Monthly | Low-traffic microsites, parked domains you must keep an eye on, legacy properties | Trend signal only; not enough for proactive alerts on conversion paths |
Plans often cap which frequencies you may select. Personal and starter tiers may allow weekly and monthly only; agency tiers add daily and hourly. That is not a marketing detail. It is the guardrail that stops you from promising hourly coverage on a plan that cannot bill the API cost.
Match frequency to how often the site changes and how costly a bad week is:
Deploys several times per week: daily (or hourly on checkout and top landers during a sale).
Monthly content updates, rare code releases: weekly on key templates, monthly on long tail.
Frozen microsite: monthly spot-check plus automated weekly on / only if the client still pays for monitoring.
Write the chosen cadence in the statement of work. “We monitor performance” is vague. “Daily lab tests on six URLs, mobile and desktop, with budgets on LCP and INP” is auditable.
How to prioritise URLs when queues and quotas fill up
Frequency decides when a site is due. Priority decides which page runs first when twenty URLs are due and the monthly quota is nearly spent.
Start with a short URL tier list per client
We use three buckets in onboarding workshops:
Tier | Examples | Monitoring stance |
|---|
Tier A | Homepage, primary conversion path (checkout, signup, booking), top paid landing pages | Highest priority score; both strategies; budgets tightest |
Tier B | Category or listing templates, flagship product detail, pricing | Medium priority; daily or weekly depending on site cadence |
Tier C | About, careers, long-tail blog, legal | Lower priority; weekly or monthly; budgets looser or score-only |
Map tiers to the priority field your monitoring tool exposes (numeric or labelled). Higher numbers run before lower numbers when the scheduler batches work. That prevents a /blog/2019-recap URL from blocking a checkout test when the queue backs up.
Exclude pages that should not burn tests
Not every discovered URL deserves a schedule line:
Staging or password-protected paths (unless you maintain separate credentials and accept flakiness).
Redirect chains you have not cleaned up.
Thin tag archives with no revenue role.
URLs that fail repeatedly until someone fixes the route.
In Apogee Watcher, the page toggle Included in scheduled tests is the practical gate. Turn it off for pages you do not want in the rotation. After sustained PSI failures, we auto-exclude a page until a human re-enables it, because scheduling broken URLs trains everyone to ignore red scores.
Revisit the list after discovery runs: sitemaps grow, campaign landers appear, and a quarterly URL audit takes about thirty minutes while saving quota for the rest of the quarter.
PageSpeed monitoring quota: coverage versus promises
Every automated platform bills against tests per month (or an equivalent credit). Your schedule design must fit inside that ceiling.
Rough planning maths:
Monthly tests ≈ S (pages per site × strategies per page × runs per month per site)
Example: four clients, each with six Tier A/B pages, mobile and desktop, daily cadence:
4 × 6 × 2 × 30 = 1,440 scheduled tests per month before manual reruns or discovery spikes.
Add two more clients on weekly cadence with ten pages each:
2 × 10 × 2 × 4 = 160 additional tests.
If the plan allows 2,000 tests, you still have headroom for manual investigations. If the plan allows 800, you must cut pages, drop a strategy, or lower frequency somewhere. Do that math before the sales deck claims “continuous monitoring on every page.”
When quota tightens, reduce in this order unless a contract says otherwise:
Tier C pages (drop to monthly or exclude).
Desktop strategy on sites where mobile carries most revenue (document the exception).
Frequency on stable brochure sites (daily → weekly).
Tier B long tail before Tier A conversion paths.
Never silently starve checkout because it was added last in the UI.
How to map agency client tiers to test frequency and URL priority
Standardise tiers so account managers do not negotiate bespoke monitoring in every deal.
Client tier | Typical cadence | URL cap (guided) | Priority focus | Reporting |
|---|
Platinum | Daily on Tier A/B; weekly on Tier C | 8–12 URLs | Checkout, signup, hero campaigns | Weekly internal review; monthly client report |
Standard | Weekly on Tier A/B; monthly on Tier C | 5–8 URLs | Homepage, top product, contact | Monthly client summary |
Light | Weekly on homepage + one conversion URL | 2–4 URLs | Single funnel path | Quarterly check-in |
Adjust for seasonality: an e-commerce client might move from weekly to daily for four weeks around Black Friday, then revert. Note the window in the ticket so finance understands the quota spike.
Pair tiers with performance budgets so scheduled tests produce action, not only charts. A page that is tested daily but has no threshold still depends on someone spotting regressions in a dashboard grid.
How to review scheduled PageSpeed monitoring daily, weekly, and monthly
Automation does not remove review. It changes what humans do.
Daily (five minutes): Scan alert digests. If none fired, move on. If one fired, confirm whether it is a real regression or a third-party blip.
Weekly (thirty minutes): Open portfolio trends. Look for slow drifts (LCP creeping up on a product template) rather than single red cells.
Monthly (per client): Export or generate the client report; compare budget compliance; adjust URL tiers if marketing launched new landers.
Align digest timing with test frequency. Hourly sites may need tighter cooldowns on alerts; weekly sites can batch violations into one email per run. That pairing is what keeps Slack alert policies workable.
When you onboard a site, use the site audit checklist for performance monitoring so frequency, URL tiers, and budgets are captured in one pass rather than spread across three calls.
FAQ
How often should you run PageSpeed monitoring on client sites?Match cadence to release velocity and revenue risk: daily or hourly on commerce and high-traffic conversion paths, weekly on typical marketing sites, monthly on low-traffic properties. Write the cadence in the contract.
What is the difference between test frequency and page priority?Frequency is how often a site’s scheduled runs are due. Priority is which URLs execute first when many pages are queued and quota is limited. You need both on portfolios above a handful of sites.
Can you monitor every page on every site daily?Usually not within typical agency quotas. Tier A URLs on critical clients first; reduce long tail or switch brochure sites to weekly before you drop checkout coverage.
Does hourly PageSpeed monitoring replace Real User Monitoring?No. Scheduled lab tests give repeatable baselines and regression detection. Field data (CrUX or RUM) shows what real users experienced. Use both; do not argue about which one “counts.”
What should you do when scheduled tests keep failing on one URL?Fix the route or remove it from the schedule until it is reliable. Scheduling broken URLs produces noise and teaches the team to ignore alerts.
Schedule one portfolio honestly this week
Export your current URL list per client. Mark Tier A, B, and C. Assign a frequency per site that your plan allows and your quota can sustain. Set priorities so checkout and signup paths run ahead of blog archives.
If the spreadsheet shows you are over quota, cut long tail before you cut conversion URLs, and update the client-facing scope before the next incident arrives by email.
To run schedules, budgets, and alerts from one dashboard, start with automated PageSpeed monitoring setup, then layer managing multiple client sites in one dashboard when the portfolio crosses ten domains.