Performance reporting for client sites usually fails in one of two ways. Either nobody looks at it until a client forwards a PageSpeed screenshot with a worried question, or the agency tracks fifteen metrics and can explain none of them. Three numbers, checked monthly, cover almost everything you need to defend a care plan.
The three numbers
Google publishes the thresholds for a "good" experience in its Core Web Vitals documentation at web.dev/articles/vitals. At the time of writing they are:
- Largest Contentful Paint (LCP): the main content should appear within 2.5 seconds of the page starting to load.
- Interaction to Next Paint (INP): 200 milliseconds or less between a tap or click and the next visual update.
- Cumulative Layout Shift (CLS): 0.1 or less, meaning the page does not jump around while loading.
That is the whole list. Everything else, whether Time to First Byte, total blocking time or the overall lab score, is a diagnostic you reach for when one of these three goes wrong. Do not put diagnostics in the client report.
Why these three and not the big score
The headline number in most speed tools is a composite. It moves when you add a chat widget, it moves when the tool changes its weighting, and it moves between two runs on the same page. Clients fixate on it because it is a single number, and then you spend a call explaining why 91 became 84 with no change to the site.
The three vitals are more stable and each maps to something a human notices. LCP is "how long until I see the page." INP is "does it respond when I tap." CLS is "did the button move as I pressed it." You can explain each to a client in a sentence, and each points to a different kind of fix.
Lab data versus field data
This is the distinction that catches agencies out. Lab data comes from a synthetic test: one device profile, one network condition, one moment. Field data comes from real visitors' browsers over a period of weeks. Google's ranking-related assessment uses field data, not your lab run.
Two consequences follow:
- A lab test is what you use to diagnose and to verify a fix the same day.
- Field data, where the site has enough traffic to produce it, is what you report as the trend, because it is what visitors actually experienced.
Low-traffic sites, which describes a good share of small business clients, often do not have enough field data to show up at all. For those, track the lab numbers consistently under the same settings and say so in the report. A trend from a fixed test is still a trend, provided you never change the test.
Test the pages that matter
Testing only the homepage is a habit worth breaking. A brochure site's homepage is often its best-optimised page because someone cared about it once. The pages that lose money are the others.
Pick three per site and keep them fixed:
- The homepage.
- The highest-traffic landing page, which your analytics will name.
- The page where money changes hands: checkout, booking form, quote request.
Three pages times three metrics is nine numbers per site per month. For 40 sites, that is 360 data points, which is only manageable if something collects them for you. Collected by hand, it is an afternoon you will skip by month three.
What usually moves each number
You do not need a performance engineering degree to fix most client sites. The usual suspects are well known.
LCP is mostly a hero image problem. An oversized, unoptimised image, lazy-loaded when it should load first, or a slider that waits on JavaScript. Slow hosting and no page caching contribute the rest.
INP is a JavaScript problem. Heavy page builders, tag manager scripts, chat widgets and cookie banners compete for the main thread. The fix is usually removal, not tuning.
CLS is images and embeds without dimensions, fonts that swap late, and banners injected above content after load. It is the cheapest of the three to fix and the most annoying to visitors.
Notice what these have in common: the causes are usually things added after launch. Which is why the monthly check matters more than the launch audit. Performance decays through additions, one plugin and one script at a time.
Set thresholds that trigger action
A trend nobody acts on is decoration. Decide in advance what a number has to do before you open the site:
- Any of the three moves from "good" into the range Google calls "needs improvement": look this month.
- A metric worsens noticeably in one month with no deliberate change: check what was installed or updated.
- A fix you shipped has not shown up in field data after several weeks: check whether it was cached, or whether the fix actually reached the tested page.
Write the rule down. When it is a rule, checking becomes a routine instead of a judgment call about whether this month's dip is "worth mentioning."
Report it like a cost, not a grade
Clients rarely care about milliseconds. They care about the quote form that takes six seconds to become tappable on a phone. Frame the finding in those terms: "the quote page became slow to respond after the chat widget was added; removed it, response time is back within range."
Then connect it to your plan. If the fix is in your maintenance scope, say it was done. If it is out of scope, for instance replacing a heavy theme, quote it as a project, with the trend chart as the evidence. Performance data is one of the few care plan outputs that regularly turns into paid work, because the problem is visible and the cause is specific.
Where this leaves you
Track LCP, INP and CLS on the same three pages per site, use the same test settings every month, and decide in advance what movement triggers a look. Keep everything else as a diagnostic. WPClientHub keeps performance trends per site alongside uptime and update history, and it is free for 3 sites if you want to try this on a real client site: start a free account.