How we measure Core Web Vitals in every deploy

Core Web Vitals are easy to celebrate on launch day and easy to ignore afterward. A hero image swap, a new chat widget, or a denser product grid can quietly tank LCP and INP — and nobody notices until Search Console turns red. By then you are debugging under traffic instead of catching the regression in a pull request.

We treat vitals as a deploy gate, not a quarterly audit. Speed is a product attribute: it affects conversion, crawl efficiency, and how trustworthy the site feels on a mid-range phone. Here’s the checklist that runs on every Build Me Web release, from lab CI through field RUM and the budgets we write into statements of work.

Lab checks on every pull request

CI runs Lighthouse (mobile, throttled) against the preview URL. Lab data is synthetic, but it is also repeatable — which makes it ideal for catching “we just added 400KB of JavaScript” before merge. We track:

• LCP — largest contentful paint for the primary landing template
• CLS — layout shift with fonts and above-the-fold media loaded
• INP proxy — lab interaction timing on key CTAs and nav

Hard fails block merge when scores regress past an agreed budget. Soft warnings flag trends so teams can fix before the next milestone. Thresholds are project-specific: a media-heavy brand site and a lean B2B lead-gen page should not share identical LCP ceilings, but both should have ceilings.

We run the lab suite against the templates that matter commercially — home, primary landing pages, product detail, cart, and checkout or lead forms — not a single vanity URL. A homepage that scores well while the PDP collapses under image galleries is not a win. Preview environments make this practical: each pull request gets a stable host, so CI does not fight over a shared staging box.

Lab interaction timing will never perfectly mirror field INP, but clicking primary CTAs and opening mobile nav under throttling still surfaces long tasks and heavy main-thread work. When those checks fail, the fix is usually obvious: defer a tag, split a bundle, or stop shipping an unused animation library on every page.

Field data after launch

Lab scores lie when real devices and networks disagree. We collect CrUX-compatible RUM on production pages, segmented by template (home, PDP, checkout, docs). Weekly digests compare p75 vitals to the previous release so regressions show up as soon as traffic arrives.

Segmentation is non-negotiable. Blended site-wide averages hide a slow checkout behind a fast blog. We also watch device and connection mixes when the data volume supports it — a campaign that suddenly skews traffic toward slower mobiles can look like a deploy regression when it is actually an audience shift. Digests call out both possibilities so teams do not thrash the wrong layer.

Field data also validates whether our lab budgets were honest. If lab LCP looks fine but field p75 sits above 2.5s on a key landing URL, we dig into image CDN behavior, cache hit rates, and third-party script timing under real geography. That feedback loop is how budgets stay useful instead of ceremonial.

Budgets that teams actually respect

Vague goals (“be fast”) don’t survive a marketing sprint. We write budgets into the statement of work:

• LCP ≤ 2.5s on mobile for key landing URLs
• CLS ≤ 0.1 on templates with ads or embeds
• JS payload ceilings for third-party tags

When a request would break a budget, we surface the tradeoff early — compress the creative, lazy-load the widget, or defer the experiment. Budgets turn performance from an opinion into a shared constraint. Design can still ask for a full-bleed video; they see the cost next to the request instead of discovering it in Search Console six weeks later.

Third-party ceilings deserve their own line item. Tag managers accumulate quietly: a pixel here, a heat-map there, a chat vendor “just for the campaign.” We inventory tags at kickoff, assign owners, and revisit quarterly on Managed retainers. If a new tag cannot fit the ceiling, something else leaves or the business accepts a documented exception with an expiry date.

Fixes that usually move the needle

Most regressions we see are not exotic. They cluster around media, layout stability, and script weight. Our default remediation list:

1. Reserve space for images and embeds to kill CLS
2. Prioritize the LCP element with fetchpriority and correct dimensions
3. Ship modern image formats (WebP/AVIF) with sensible fallbacks
4. Defer non-critical scripts; audit tag managers quarterly
5. Keep fonts lean — subset, font-display: swap, and avoid FOIT/FOUT thrash

Reserving space sounds basic until a late-loading testimonial carousel or cookie banner shoves the hero down after paint. Explicit width and height — or aspect-ratio boxes — stop that class of CLS. For LCP, identify the actual LCP node per template; it is not always the hero image you assume. Fetch priority and preload only help when aimed at the right asset.

Modern formats cut bytes without changing art direction. Fallbacks keep older browsers functional. Script deferral and tag audits are ongoing work, not a launch checklist item. Fonts are a frequent silent regressor: shipping full family weights for a single display heading can cost hundreds of milliseconds on mobile. Subsetting and disciplined font-display choices keep text visible without layout thrash.

When those five do not close the gap, we go deeper: critical CSS for above-the-fold templates, edge caching rules, server timing for origin TTFB, and whether a heavy client framework is doing work that belongs on the server. Those conversations happen with evidence from lab and field, not vibes.

Wiring vitals into the release process

Measurement without process is a dashboard nobody opens. On Build Me Web projects, vitals show up in three places: pull-request checks, release notes, and retainer reviews. PR checks catch acute regressions. Release notes include a short vitals snapshot so stakeholders see speed next to feature work. Retainer reviews trend the field data and propose backlog items when content growth or new integrations threaten the budget.

We also keep a lightweight “performance debt” list — known exceptions with owners and dates. Temporary campaign tags and experimental embeds are fine when they are labeled temporary. Unlabeled debt is how sites get slow.

Where this shows up for clients

Performance work is baked into Website, Commerce, and Cloud engagements. Launch builds establish baselines and CI gates. Growth projects usually add richer RUM segmentation and campaign-aware tag governance. Managed retainers include a monthly vitals review so speed doesn’t silently decay as content grows.

If you already have a live property, we can start with a field audit and a tag inventory before the next redesign. Fixing the worst regressions often unlocks more conversion than another homepage iteration — and it compounds with every deploy that follows.

Core Web Vitals are not a badge for the launch deck. They are a continuous constraint on how you ship. Measure in the lab, validate in the field, write budgets people can refuse to break, and fix the boring issues first. That is how page speed survives the roadmap.