The problem
You have found that a client's site takes four seconds to show its main content on a phone, that its scripts block interaction for over half a second, and that Google's field data marks every page as failing. You know this is costing them enquiries and rankings. You explain it with the acronyms and a Lighthouse screenshot, and the client nods and asks whether it is really worth the money.
The work is worth it. The explanation failed. Here is how to do it so the client understands what they are buying.
Lead with what they already know
Every business owner has abandoned a slow website on their phone. Start there. "You know when you tap a link and stare at a blank screen, and give up and go back? On a normal phone, your site does that for about four seconds. Most people leave at three." Now they have felt the problem, and every number after that has a reference point.
Translate the three metrics once
Do not use the acronyms. Give each metric a plain name and say it the same way every time.
- "How long until they see your page." (Largest Contentful Paint.) "Google says under two and a half seconds. Yours is four."
- "How long until the page responds when they tap." (Interaction to Next Paint.) "Under a fifth of a second feels instant. Yours is over half a second, so buttons feel broken."
- "Whether things jump around while loading." (Cumulative Layout Shift.) "You have probably tapped the wrong thing because a page moved. Yours does that on the contact page."
Then say what Google does with them: "Google measures these on real visitors and uses them as part of ranking. Yours are marked as failing on every page, which is a drag on your search position on top of the visitors you lose directly."
Connect it to their numbers
Pull two figures from their analytics: mobile share of visits, and mobile conversion rate versus desktop. On most local business sites mobile is most of the traffic and converts at a fraction of desktop. Then: "Most of your visitors are on phones, and they enquire at a third the rate of people on computers. Some of that is normal. A lot of it is the four seconds."
You do not need to promise a specific uplift. You need to make the connection between the speed and the enquiries visible. If you have a comparable project, cite its before-and-after in enquiries, not in scores.
Show the before-and-after, not the audit
A Lighthouse report is a wall of red and orange that means nothing to a client and invites the question "can you make it all green?", which is the wrong goal.
Instead, a video. Load their site and a fast competitor side by side on a throttled phone, screen-recorded, thirty seconds. The client watches their competitor's page appear while theirs is still white. Nothing you say will be as persuasive.
After the work, the same video, their site before and after. That is the deliverable they will forward to their business partner.
What to leave out
- Lighthouse scores. They are lab estimates, they fluctuate, and clients fixate on the number. Report the field metrics in plain words instead.
- The fix list. "Preload the hero image, defer the tag manager, add font metric overrides" is your work order, not their report. Summarise as "we fixed the images, removed the scripts that were slowing everything down, and stopped the page from jumping."
- Anything about frameworks, hosting stacks or caching layers, unless they ask.
- Blame for the previous developer. State what the site does, not who did it.
The one-page report
When a client is deciding whether to approve the work, give them one page:
- The problem in one sentence. "On a normal phone your site takes four seconds to appear and Google marks it as failing."
- The three plain metrics, yours versus Google's threshold, in a small table.
- The business link, two sentences, using their mobile share and conversion gap.
- What we will do, three bullets in plain words.
- What you will get, the target metrics in the same table, and the before-and-after video.
- What it costs and how long. Fixed.
Nothing else. If they want detail, the audit is available. Most do not.
After the work
Report the same three plain metrics, before and after, from real-user data once it has updated. Include the video. Note that Google's field data takes about a month to fully reflect the change, so the Search Console report improves gradually; say that in advance so the client does not think the work failed on day three.
Why this matters
Performance work is among the highest-return things a business can do to its website, and it is chronically under-bought because it is chronically badly explained. The engineer who can make a client feel the blank screen gets the work approved; the one who shows a Lighthouse screenshot does not. That is the shape of every Core Web Vitals proposal we send: plain words, their numbers, and a video.