Core Web Vitals on client sites are a different problem than Core Web Vitals on your own site. On your own site you can obsess over one page for a week. With twenty client sites you need the numbers to come out green because of how the sites are built, not because you went in and hand-tuned each one. Tuning does not scale. Defaults do.
Here is the version I actually use, including what we measure on a site running on our own platform.
The three metrics, and what counts as passing
There are three, and in 2026 the responsiveness one is INP, not the old FID. Largest Contentful Paint covers loading and needs to land at 2.5 seconds or under. Interaction to Next Paint covers responsiveness and needs to be 200 milliseconds or under. Cumulative Layout Shift covers visual stability and needs to stay at 0.1 or under.
The part most people miss is how Google actually grades you. It uses field data from the Chrome User Experience Report, at the 75th percentile, over a rolling 28 day window. So your score is what your slowest quarter of real visitors experience, on their real phones, and a fix you shipped this morning will not show up for weeks. Lab tools are for diagnosis. The field data is the grade.
Lab numbers tell you what to fix. Field numbers tell you whether you fixed it. Confusing the two is why agencies think they solved a problem they did not.
What a real site on the platform measures
Abstract advice is cheap, so here are numbers from a live site running on Seedly Sites, measured with Lighthouse on a mobile profile. I find it more useful to look at each metric as a share of its budget rather than as a raw number, because that shows you where the headroom actually is.
Lighthouse, mobile profile. Layout stability and responsiveness have enormous headroom because they are decided by how the pages are built. Loading is the one with real tension in it, and it is almost always about images.
Yes, that LCP is over its budget, on the exact metric this post is about. I am showing you the real number instead of a tuned one because the shape is the lesson. Layout shift and responsiveness are structural. Get them right once in the templates and every site inherits them. Loading is the metric that keeps fighting back, because every new site brings new images. The next section is exactly that fight.
Fixing LCP, which is the one you will actually fight
LCP is whatever large thing renders in the viewport first, and on a client site that is almost always the hero image. Four things move it more than everything else combined.
- Serve the hero at the size it actually renders. An oversized hero is the single most common cause of a failing LCP, and it is invisible until you measure, because the page looks fine
- Do not lazy-load the thing above the fold. Lazy loading is a win everywhere except on the element that defines your LCP, where it is a self-inflicted delay
- Preload the hero and let the fonts swap. A font that blocks text from painting turns a fast server into a slow-looking page
- Render on the server. Anything that makes the browser wait for JavaScript before it can paint the hero is spending your entire budget on nothing
Notice that none of those are clever. They are all the same idea, which is do not make the browser wait for the one thing the visitor is here to see.
CLS and INP are cheaper than you think
Layout shift comes almost entirely from elements that arrive without reserved space. Every image, video, iframe and ad slot needs explicit width and height. Third party widgets need a container with a minimum height, so if the widget never loads you get a bit of empty space instead of the whole page jumping. That is the entire fix, and it is a build-time decision rather than a cleanup pass later.
INP is mostly about not shipping piles of JavaScript that run on interaction. A static marketing site that is not carrying a page builder runtime tends to sit near zero without anyone trying. If your INP is bad on a brochure site, something on the page is doing work it has no business doing.
Why this is a platform problem, not a checklist
The reason I stopped treating this as a per-site task is that per-site work does not compound. You tune a site, you win for a month, then a client swaps the hero image for something enormous and you are back where you started, except now you have twenty sites and no idea which ones drifted.
Tuning site by site
- Every new build starts the fight over
- One client uploading a huge hero undoes it
- No way to see which sites drifted without checking each one
- The work never compounds
Fixing it in the platform
- Image sizing and dimensions handled at render time
- Static output with no builder runtime shipped to visitors
- Every future site inherits the fix for free
- One place to check, one place to repair
Join the Seedly owners community.
Owners trade setups, share add-ons, and swap playbooks. See what people are building before you commit.
How I would actually run this
Pick the metric that is in the poor band and fix that first, then leave the green ones alone. Optimizing a metric that already passes is the most common way agencies burn a week for nothing. Measure in the lab to find the cause, ship the fix, then wait out the 28 day window before you decide whether it worked. And if the same fix would help every site you run, put it in the platform instead of the site.
If you are moving a client off a slow stack, the loading side of this is mostly won during the migration, which I covered in migrating a WordPress site to a fast static site. The hosting side is in hosting client websites on Cloudflare Pages, and the per-launch checks live in the client website launch checklist.
Build it fast once. Ship it fast forever.
