Core Web Vitals for Agencies: Shipping Fast Client Sites at Scale

You know how to build a fast site. The problem is not the first build. The problem is the tenth client, the redesign that regresses, the marketing tag a client adds without telling you, and the fact that a site you shipped green last quarter is quietly failing its vitals today. For an agency, Core Web Vitals are not a technical footnote on one project. They are a repeatable service you can package, price, and run across a whole client book, if you build the system for it. This is how to turn site speed into a productized line: what the vitals mean, how to sell them, how to deliver them across many sites without drowning, and how to keep them green after launch.

#Why speed is an easy line to sell and a hard one to keep

Speed sells because you can show it. Run a client's homepage through a public tool on the discovery call and the gap is right there on screen, in numbers they can read without a translator. There is no arguing with a red field score. That makes site speed one of the lowest-friction performance offers an agency can put in front of a prospect, because the pitch is a live demo, not a deck.

It is hard to keep because a site's vitals are never done. Google grades on the real experience of your client's actual visitors over a rolling window, so a fix you shipped today shows up weeks from now, and a regression a client introduces next month shows up just as slowly and just as invisibly. An agency that treats speed as a one-time build task ships a fast site, moves on, and gets a confused email six months later asking why rankings slipped. An agency that treats it as a program keeps the site green, keeps the client, and keeps a retainer running. The full mechanics, retold for the firm actually running the site, live in the Core Web Vitals guide. Your job is to package that into an offer.

#The three vitals, in the words you will use with a client

You cannot productize what you cannot explain in one breath. Core Web Vitals are three measurements of how a page feels to a real visitor: how fast the main content shows up, how quickly the page reacts when they tap, and whether things jump around while it loads. Pass all three and the site feels instant. Fail them and it feels cheap, no matter how good the design looked in the mockup you presented. Here is the version you hand a client, and the version your team works to.

Largest Contentful Paint (LCP): how long until the biggest thing on screen, usually the hero image or headline, has finished loading. Good is under 2.5 seconds. Killed most often by oversized hero images and scripts that load ahead of content.
Interaction to Next Paint (INP): how fast the page reacts when a visitor taps the menu, opens an FAQ, or starts a form. Good is under 200 milliseconds. It is almost always heavy JavaScript tying up the browser. INP replaced First Input Delay in 2024 and is stricter, so sites that used to pass can quietly fail it now.
Cumulative Layout Shift (CLS): how much the page jumps around as it loads, the thing that makes a visitor tap the wrong button. Good is under 0.1. Fixed by reserving space for every image, ad, and embed so nothing shoves the content down when it arrives late.

Google buckets every measurement into good, needs improvement, or poor. The goal you sell is not a perfect score, it is landing every page template in the good band across mobile and desktop. Google's own definitions live at web.dev, and that is the page to send a client who wants the source.

#The trap that will burn you in a client meeting

The 90-something score a client screenshots from a PageSpeed test and emails you is a lab result: one simulated device, one moment, one fast connection. Google ranks on field data instead, the real vitals of the client's actual visitors over the trailing 28 days, collected in the Chrome User Experience Report. A great lab score and a failing field score sit side by side constantly, and only the field score touches rankings. If you let a client believe the lab number is the one that matters, you will spend a call defending a green score against slipping traffic, and you will lose that call.

#The productized speed offer, in three tiers

Do not sell speed as vague hours inside a generic retainer. Sell a ladder where each rung earns the next, the same audit-to-sprint-to-retainer shape we structure engagements around in our own solution set. Most agencies should offer all three.

Speed audit (fixed fee, one week). Pull the client's field data from PageSpeed Insights and Search Console, test the key templates on a real mid-range phone, and deliver a prioritized report: which templates fail, which vital, and the two or three fixes that move each most. This is your low-friction entry offer, and it qualifies the client for the sprint.
Speed sprint (fixed scope, two to four weeks). Ship the fixes. Right-size images, defer or drop third-party scripts, reserve layout space, cut page-builder bloat, put the site behind a content delivery network. Priced against the outcome, not your hours, because the work templatizes across clients.
Speed retainer (thin, monthly). Continuous field-data monitoring across every template, a monthly vitals report, and a fast fix when a client's new tag or embed regresses a page. Small dollar figure, high retention, because vitals drift and someone has to own catching it.

Anchor the sprint price to what the client's traffic is worth, not to a day rate. A site that loads a second and a half slower is leaking the most expensive visitors, first-timers, mobile users, and anyone the client paid to send there. For a client whose signed customer is worth thousands, closing that leak is worth far more than a typical technical deliverable, and your price should say so.

#Where the seconds go, and which fixes to templatize first

Almost every vitals failure across your book traces back to the same short list. Learn it once and you diagnose any client site in minutes. In rough order of how often it shows up:

Oversized hero images and unoptimized photography. A four-megabyte banner is the single most common LCP killer, and the easiest fix. Templatize an image pipeline once and it fixes this on every client automatically.
Third-party scripts loaded eagerly: chat widgets, scheduling embeds, review carousels, tag managers, analytics. Each is someone else's JavaScript on the client's critical path, and INP is where it shows. Build a house rule for how these load and apply it everywhere.
Page-builder and theme bloat. Drag-and-drop templates ship code for dozens of features the client never uses, and the browser downloads all of it. This is the argument for a lean platform as your default build, not a per-client decision.
Web fonts that block text from appearing until they finish downloading, so the page looks empty longer than it needs to.
Images, ads, and embeds with no reserved space, which is exactly what drives layout shift as they pop in late. A single CSS convention in your house standard kills this class of bug for good.
No caching or content delivery network, so every visitor waits on the client's origin server wherever it sits, instead of a copy served from nearby.

Notice how many of these are fixed by construction rather than by hand. That is the whole margin story. An image pipeline, a script-loading rule, a layout-space convention, and a fast default platform turn six recurring fixes into four things you build once and reuse on every client site you ship.

#Delivering speed across a book of clients without drowning

The difference between site speed as a one-off and site speed as a real agency line is systematization. Three moves make it scale.

Templatize the repeatable 80%. The image pipeline, the script-loading rule, the layout-space CSS convention, the report format, the default fast platform. Build each once and apply per client. A site that starts fast by construction is a site you rarely have to rescue.
Batch the manual 20%. Do every client's field-data check in one weekly block, not scattered across the week. The context-switching cost of hopping between client dashboards is what quietly kills margin on a multi-client service.
Govern a house standard. One internal doc that defines what a shipped-fast site looks like: the vitals thresholds every template must hit, the approved way to load a third-party script, the image budget, the CDN setup. Any developer or junior can then deliver to the same bar, which is what lets you hire against the service instead of doing every build yourself.

#Reporting speed to a client who wants a rank report

A client does not care about milliseconds. They care about traffic and leads. So report speed in a way that ties to those, and teach the instrument in one slide. Track four things, mostly from Search Console and PageSpeed, and it is worth the fifteen minutes a week per client.

Field vitals by template, mobile and desktop. Of the client's page templates, how many sit in the good band right now? This is the headline number, and it comes straight from the Core Web Vitals report in Search Console.
Trend, not snapshot. Because the field score is a 28-day average, the story is the direction over weeks. Show the line moving into the green after a sprint, so the client sees the delayed win land instead of doubting the fix.
Regressions caught. When a client's new tag or embed pushes a template out of the good band, log it, show it, and show the fix. This is the single clearest proof of why the retainer exists.
Speed against lead quality. Watch whether faster templates convert better, and tie it back to cost per qualified lead so the client sees revenue, not vanity. Speed is one of the cheapest levers on their lead-to-consult rate, and this is where you prove it.

#Sizing the program to the client, not the other way around

The right speed engagement depends on how big and how busy the client's site is. Match the offer to the site or you will over-scope a small client and under-serve a large one.

Solo and micro clients: the killer is almost always a bloated template plus three marketing widgets. A lean rebuild passes all three vitals with room to spare, so sell the sprint, ship it once, and offer a light monthly check rather than a heavy retainer. Do not over-scope monitoring they do not need. The DIY version of this, for the owner-operator handling it themselves, is in the micro businesses guide, and it is worth reading so you know exactly what you are saving them from doing.
Small and medium clients: the risk is third-party scripts nobody owns. Every tool a department bolts on can cost INP, and the total creeps up unwatched. Sell the sprint plus a real retainer, because this is where governance earns its fee. The internal-team version of that repeatable process is in the SMEs guide.
Large clients with many properties: this is monitoring, not a one-time fix. A redesign, a new tag, or one bad embed can regress vitals overnight across thousands of pages. Sell continuous field-data monitoring across templates as the core of the engagement. The in-house governance view of that same problem is in the mid-market teams guide.

#Where agencies get speed wrong

Selling the lab score. If you report the green PageSpeed number and the client's field score is red, you have set yourself up to lose the trust when rankings slip. Report field data or nothing.
Shipping it once and walking away. Vitals drift. A build with no monitoring line is a build that fails silently six months later, on the client's watch and blamed on you.
Fixing pages instead of templates. On a real site, one fix should land across every page that uses a template. If you are hand-fixing URLs one at a time, you have not built the system yet.
Folding speed into a generic retainer and eating the cost. The audit and the monitoring are the deliverables a client cannot get from a cheaper vendor. Name them and price them, or you train the client to think they are free.
Ignoring the platform. If you keep rescuing vitals on heavy page-builder sites, you are paying, in your own hours, for a build decision you could have made once. Fix the default stack.

#White-label the platform, or build your own

You do not have to build the image pipeline, the fast default platform, and the field-data monitoring layer from scratch. That is what Frontend Horizon's platform layer is for: the agency owns the client relationship and the strategy, and the platform handles the repeatable fast build and the continuous measurement underneath, so a green site is the default state, not a thing you fight for on every project. If you would rather own the whole stack, the fixes above are the full playbook. Either way the strategic part, knowing the client's traffic, their money pages, and what a slow site is actually costing them, stays with you, because that is the part clients pay for. See where the platform fits across the full solution set, and how we partner with the firms behind these sites on professional services.

#Questions agencies ask us about selling speed

#How fast can I show a client results?

You can show a lab improvement the same day you ship the fix. The field score, the one that ranks, moves over the following weeks because it is a 28-day rolling average. Set that expectation in writing at the start, report the lab win immediately as a leading indicator, and report the field trend a month later as the real result. Both are true, and saying so up front is what keeps a client patient through the window.

#What if the client's developer keeps regressing the vitals?

Common, and it is exactly why the retainer exists. A new marketing tag or a redesign can push a template out of the good band overnight. Your monitoring line catches it, your report shows it, and your fix restores it. Frame this to the client honestly: speed is not a one-time build, it is a thing that drifts, and the retainer is the seatbelt. That framing sells the recurring line better than any feature list.

#Can I sell this to clients who are not professional services firms?

Yes. The three vitals and their thresholds are the same for any site: home services, healthcare practices, retail, B2B software. The vertical only changes which pages are the money pages and how much a slow one costs. The audit-to-sprint-to-retainer ladder and the templated fixes carry across your whole book, whatever industries it spans.

Site speed is not separate from the rest of what you sell a client. It feeds their rankings, their conversion, and the leads they judge you on. The full mechanics live in the Core Web Vitals guide, and the same shift retold for the operators actually running the sites is in the micro businesses, SMEs, and mid-market teams versions. Google's own definitions and thresholds are documented at web.dev, and you can test any client URL at PageSpeed Insights.

Want to package speed as an agency line without building the fast-platform and monitoring stack yourself? Run the estimator and we will show you the white-label deliverables, the pricing ladder, and the reporting your clients will actually read. Or talk to us about a partner engagement.