# How agencies report site performance to clients

> A good client performance report gives a plain-English summary, trends, the top fixes and their impact. Here is how agencies structure a monthly report.

Published: 2026-11-15 · Author: AiroPages

A good client performance report answers three questions in plain English: did the site get better or worse, why, and what happens next. Lead with a short summary, show the trend, list the top few fixes ranked by impact, and explain what each one means for users and search. Use Lighthouse scores responsibly, keep lab and field data separate, and automate the data collection so your time goes into the analysis.

## What clients actually want from a performance report

Most clients do not want a list of Lighthouse audits. They want to know whether their site is in good shape, whether it is improving, and whether the money they spend on it is working. A report that answers those questions in the first paragraph is more useful than one with 40 pages of charts.

In practice, clients look for four things:

1. **A plain-English summary.** Two or three sentences they can forward to their boss.
2. **The trend.** Better, worse or steady since last month, with one or two numbers to back it up.
3. **The top fixes.** What is holding the site back, in order of impact, and who needs to do what.
4. **The impact.** What each fix means in user and business terms: faster product pages, fewer layout jumps on mobile, pages that can now be indexed.

Technical detail still matters, but it belongs in an appendix or a separate developer section.

## How to structure a monthly report

A consistent structure makes reports faster to write and easier for clients to read. This outline works for most sites:

| Section | What goes in it | Length |
|---|---|---|
| Summary | Overall status, biggest change, one recommendation | 2 to 4 sentences |
| Scorecard | Performance, Accessibility, Best Practices and SEO on mobile and desktop, with change since last month | One table |
| Real-user experience | Core Web Vitals from field data, where available | One table or chart |
| Top issues | The three or four issues affecting the most pages, with impact and owner | Short list |
| Work completed | Fixes shipped this month and their measured effect | Short list |
| Next month | Planned fixes and anything you need from the client | Short list |
| Appendix | Per-page results and technical detail for developers | As long as needed |

### Write the summary last

Write the summary after everything else, and make it specific. "Mobile performance improved across all blog posts after the image fix in week two; product pages are still slow because of the review widget, which we recommend replacing" is far more useful than "Performance is improving".

### Report by template, not by page

Clients rarely care about URL number 247. They care about "blog posts", "product pages" and "the homepage". Grouping results by template also makes your work visible: one fix to a shared component can lift hundreds of pages at once, which is a much better story than a single page moving. The post on [template-level fixes](/blog/template-level-fixes) covers how to find those shared causes.

### Rank fixes by pages affected and impact

A list of 60 issues is not a plan. Pick the three or four that affect the most pages or hurt the most important templates, and say plainly who owns each one: your team, the client's developers, or a third-party vendor.

### Translate metrics into what users feel

Most clients will not remember what LCP stands for, and they do not need to. Describe each metric by its effect, and give the good threshold once:

- **LCP (Largest Contentful Paint):** how long the main content takes to appear. Good is 2.5 seconds or less.
- **INP (Interaction to Next Paint):** how quickly the page responds to a tap or click. Good is 200 milliseconds or less. It comes from field data only, because a lab test has no real user input.
- **CLS (Cumulative Layout Shift):** how much the layout jumps while loading. Good is 0.1 or less.

Then write findings in the same terms. "On mobile, product pages take about four seconds to show the main photo" lands better than "LCP 4.1 s on the product template". Keep the metric names in the table so the client's developers can find them, and keep the sentences for everyone else.

## Using scores responsibly

Lighthouse scores are useful, but they are easy to misuse in client reports. A few rules keep your reporting honest.

**Separate lab from field data.** Lighthouse is a lab test: one simulated load of a page on a throttled connection. [Chrome UX Report](/glossary/crux) field data shows what real Chrome users experienced over the past 28 days, measured at the 75th percentile. [Core Web Vitals](/glossary/core-web-vitals) are assessed on field data. Label which is which in every table, and explain the difference once. The post on [lab data vs field data](/blog/lab-data-vs-field-data) is a good reference to share.

**Show trends, not single runs.** Performance scores move between runs because of network and server timing. A drop from 82 to 79 on one page is not news. A drop across every product page is.

**Report mobile and desktop separately.** Mobile tests use heavier throttling, so mobile scores are usually lower. Mixing them hides problems.

**Note Lighthouse version changes.** A new Lighthouse version can shift scores without any change to the site. If a version change falls inside your reporting period, say so.

**Never promise a specific score.** Third-party scripts the client adds, hosting changes and Lighthouse updates can all move scores. Promise a process and a direction instead: "we will fix the top issues each month and keep mobile LCP under 2.5 seconds on key templates".

**Test the whole site, not just the homepage.** A homepage score says little about the other templates. The pillar post on why [Lighthouse only tests one page](/blog/lighthouse-only-tests-one-page) explains the gap.

## How to automate reporting across client sites

The manual way is to keep a sitemap-based URL list for each client, run Lighthouse on every page on a schedule with a script, store the results, and build a report template that pulls in the latest numbers and the previous month's for comparison. It works, but it is a lot of upkeep across many clients.

AiroPages handles this as a hosted service, and the [Agency plan](/agencies) is built for client portfolios:

- **Scheduled scans across client sites.** Up to 25 sites, with monthly or smart weekly schedules and re-scans on deploy, on mobile and desktop for every selected page. Eight parallel scan engines plus reserved Agency lanes keep large portfolios moving.
- **One combined weekly digest.** Instead of one email per site, Agency accounts get a single weekly email: sites that dropped first, then sites that improved, then a count of steady ones. It is on by default, and you can switch to per-site emails.
- **White-label PDFs.** Export reports with your logo, color and contact details, in one of five designs. Clients see your brand, with scores, grouped issues and plain-English explanations.
- **Share links and CSV.** Send a client a public share link to their results instead of a login, or export CSV to feed your own dashboards.
- **Team seats.** Invite up to five teammates, so account managers and developers work from the same results.
- **Fixes for developers.** Each grouped issue includes a technical fix for your developer, which can be copied as a prompt for a coding agent.

The plan includes 10,000 URL scans a month for $129.99. A URL scan is one page on mobile and desktop, so that covers, for example, weekly checks of about 2,000 pages across your portfolio. See [pricing](/pricing) for the other plans.

## A sample monthly workflow

With the data collected automatically, the monthly report becomes a review task rather than a data-gathering one:

1. **Week one:** read the latest scan for each client. Note templates that moved and new issues affecting many pages.
2. **During the month:** react to drops from deploy checks and the weekly digest. If a client's new tag or plugin caused a regression, tell them right away.
3. **Before the report:** check field data where available, confirm last month's fixes had the expected effect, and choose the top fixes for next month.
4. **Write and send:** fill in the summary, scorecard and lists, export the white-label PDF, and include a share link for anyone who wants to dig in.

Clients rarely remember individual scores. They remember whether you spotted problems early, explained them clearly and fixed them. A short, consistent report built on data from every page, with honest use of lab and field numbers, does that month after month.