Core Web Vitals as an Engineering Budget

Performance is usually treated as something to fix before launch and then forget. Teams that treat it as an engineering requirement with a budget — the same way they treat correctness — ship faster sites and keep them fast.

Measure the field, not the lab

Lab tools run on a defined machine over a defined connection. Useful for debugging, misleading as a measure of reality. Your users are on worse hardware and worse networks than your laptop, and some share of them are on far worse.

Field data — what real users experienced — is the number that matters, and the distribution matters more than the median. If the 75th percentile is poor, a quarter of your visitors are having a bad time regardless of what your average says.

The three that matter, and what actually moves them

Largest Contentful Paint

Usually the hero image or the headline. The common causes of a slow LCP are mundane: the element is loaded lazily, it waits on JavaScript to render, it waits on a font, or it is simply too large.

Fixes in order of effect: serve the right size image in a modern format, do not lazy-load the element that is above the fold, render it server-side, and preload it.

A full-screen intro animation is an LCP of however long the animation runs. Teams add these deliberately and then wonder why the metric is poor.

Interaction to Next Paint

This is a main-thread problem. Long tasks block the browser from responding, and the usual culprit is too much JavaScript executing at once — hydration, analytics, third-party tags.

Ship less JavaScript. Break long tasks up. Defer anything that is not needed for the first interaction. Third-party scripts are frequently the single largest contributor and the easiest to defer, because nobody owns them internally.

Cumulative Layout Shift

Almost always images and ads without reserved dimensions, fonts swapping at different metrics, or content injected above existing content.

Set explicit width and height on images. Reserve space for anything that loads late. Use font-display and a metrics-matched fallback so the swap does not reflow the page.

Fonts deserve their own attention

They are render-blocking by nature and easy to get badly wrong. Shipping multiple weights in TTF or OTF, unsubsetted, is a common and expensive mistake — the same faces subset to woff2 are typically a fraction of the size with no visual difference.

Self-host rather than fetching from a third party: one fewer connection to establish, and no dependency on someone else's uptime.

Make it a budget, not a project

Set a limit — JavaScript bundle size, LCP target — and fail the build when a change exceeds it. Performance regressions arrive one small addition at a time, and without a gate each addition looks individually reasonable.

The alternative is the familiar cycle: a performance sprint, six months of gradual decay, another performance sprint.

Where it pays

Performance is a ranking input, but the stronger argument is conversion. On a slow connection the difference between a site that renders in one second and one that renders in five is the difference between a visitor and a bounce — and the visitors you lose this way are disproportionately the ones on the worst connections, which in many markets is most of them.