Most agency teams agree on the basics: monitor Core Web Vitals, set budgets, review weekly, and test before and after deploys. It gets harder when you run the same checklist across five client sites at once.
We follow a Core Web Vitals monitoring checklist for agencies for onboarding, weekly reviews, monthly deep dives, and deploy checks. The steps are written down. What follows are the eight questions we still talk through when a team starts using it for real.
If people on your team mix up LCP and INP, read the primer first, then come back to these choices:
Eight choices the checklist leaves open
The checklist says what to test. It does not choose how many URLs to watch, who gets alerts, or whether lab or field data should trigger action when they disagree. We see the same eight topics on every rollout.
1. How many URLs to monitor
The checklist says to test the homepage, main landing pages, and pages that drive sign-ups or sales. That sounds straightforward until someone asks whether twelve URLs per client is thorough work or too much time on the clock.
Others want only the homepage and checkout until a real slowdown shows up somewhere else.
What we do today: three to six URLs per client, listed in the setup template and reviewed each quarter. We do not quietly add URLs every time marketing ships a campaign page.
2. Lab data vs field data when they disagree
A lab test can look fine while Chrome User Experience Report (CrUX) still says "Needs improvement," especially right after a deploy or on a low-traffic site.
Some people want to fix what the lab shows on the next run. Others want to wait for field data because that is what Search Console uses.
For each client, write down which source triggers an alert. If you mix lab and field in the same report without saying which is which, the client often emails you before your dashboard makes sense.
3. Performance Score vs LCP, INP, and CLS
Clients like one headline number. Engineers know Performance Score can drop for reasons that do not match the three Core Web Vitals.
We still show Performance Score on slides, but alerts and budgets use LCP, INP, and CLS unless the contract says otherwise.
4. Google's "Good" band vs tighter internal targets
Google's thresholds are the minimum. Some account managers want stricter targets so an LCP of 2.4s (still "Good" in Google's band) still sends an alert.
Tighter targets help until people start ignoring alerts. We pick one published target per metric per client. If we want a stretch goal, we keep it in internal notes, not in the same Slack channel as real alerts.
5. Who owns the alert
Is it a developer, a project manager, or the account manager who forwards the worried client email?
If three people can clear an alert without opening a ticket, nobody owns the fix. We assign one role per client for performance drops, plus a named backup. Letting "whoever is online" handle it failed twice before we wrote roles down.
6. Weekly manual checks vs daily automated tests
The checklist assumes daily automated tests plus a human review. Smaller shops sometimes run PageSpeed Insights by hand once a week.
That can work for one or two sites. It breaks down around twenty. The debate is usually not about tools. It is whether the agency sells ongoing monitoring or one-off audits.
If you stay manual, use fewer URLs and accept that a problem might sit for days. Do not tell the client you offer the same response time as a team running daily automated tests.
7. Whether staging tests should block a deploy
Staging often does not match production. Some clients have no staging site. Others have staging where half the marketing tags never load.
We still ask whether a Lighthouse run on staging should block a Friday deploy. Our rule: run staging tests when staging exists and uses the same templates as production. If not, run production checks within an hour after deploy.
8. Too many alerts vs too few
Strict thresholds catch small changes. Loose thresholds mean the client calls you first.
Once a month per client, look at how many alerts fired and whether anyone opened them. No opens for six weeks usually means thresholds are too loose or alerts go to a channel people ignore. Noise every Tuesday means you should raise thresholds or lengthen cooldowns, and write down why.
Topics we rarely reopen
- INP replaced FID. We updated training docs and only revisit this if someone shares an old slide deck.
- Test mobile and desktop. Watching one device type alone hides problems on the other.
- Check third-party scripts during onboarding. Marketing tags cause many regressions; skipping that step costs more later.
Five minutes before the first weekly review
Before the weekly review section of the checklist starts for a new client, agree in writing on:
- The URL list and who owns each URL.
- Which metrics trigger action, and whether lab or field data counts.
- Who receives alerts and who covers absence.
- Whether you test staging before deploy or verify production within an hour after.
- How often the client hears about performance (a short weekly note vs a monthly report).
That short meeting takes less time than fixing alert settings after Search Console turns red.
Closing
The checklist gives you phases, checkboxes, and a per-client setup block. The slow part is agreeing on the eight choices above so the process does not turn into box-ticking.
When you are ready to implement, use the agency CWV monitoring checklist. If metric names are still unclear, use the CWV primer. Bring these eight topics to your next client onboarding meeting so the checklist becomes a weekly habit, not a PDF everyone signs off and forgets.
Top comments (0)