Core Web Vitals, and why most corporate sites fail them

Core Web Vitals are worth caring about for a reason that has nothing to do with Google: they measure things that make people leave. A slow page loses sessions whether or not it costs you a ranking position.

The three metrics

Largest Contentful Paint (LCP) — how long until the largest visible element renders. Target: under 2.5 seconds. This is usually a hero image or headline.

Interaction to Next Paint (INP) — how long the page takes to visibly respond after a user interacts. Target: under 200 milliseconds. This replaced First Input Delay because it measures every interaction, not just the first.

Cumulative Layout Shift (CLS) — how much content moves around unexpectedly during load. Target: under 0.1. This is the metric behind clicking the wrong thing because an ad loaded.

All three are measured on real visitors, not in a lab. A perfect Lighthouse score with poor field data means your lab conditions do not resemble your users.

Why corporate sites fail

The site is a client-rendered SPA. The browser downloads JavaScript, executes it, fetches data, then renders. LCP waits for all of it. This also makes the site invisible to AI answer engines, which mostly do not execute JavaScript at all — so you lose the ranking and the citation.

Fonts block text. A web font without font-display: swap hides text until the font arrives. Loading fonts from a third-party origin adds a DNS lookup, a TLS handshake and a round trip before anything can render.

Images are unsized and unoptimised. A 2MB hero JPEG with no width and height attributes damages LCP and CLS at the same time.

Too much JavaScript on the main thread. Analytics, chat widgets, tag managers, A/B testing tools. Each one competes for the same thread that handles the click the visitor just made. Chat widgets are the most common single cause of poor INP we find.

Animation that touches layout. Animating width, height, top or margin forces layout recalculation every frame. Animating transform and opacity does not.

The fixes, in order of return

1. Render on the server. Static generation or server-side rendering. The single largest improvement available, and it also makes your content readable by every crawler on the first request.

2. Self-host fonts, subset them, preload the critical ones. Removes a third-party origin from the critical path entirely. Always set font-display: swap.

3. Fix images. Modern formats (AVIF with WebP fallback), responsive srcset, explicit dimensions on every image, lazy-load everything below the fold, and never lazy-load the LCP image.

4. Audit third-party scripts. List every one and ask what it earns. Load what survives with defer or on interaction rather than on page load. A chat widget that loads on first scroll instead of immediately often fixes INP by itself.

5. Reserve space for anything that loads late. Explicit dimensions or aspect-ratio on images, embeds and ad slots. Never insert content above existing content after load.

6. Animate only transform, opacity and filter. These are composited and never touch layout.

Measure the right thing

Lighthouse is a lab tool. It is useful for catching regressions in CI, but it does not tell you what your users experience.

Use the Chrome User Experience Report through Search Console or PageSpeed Insights for field data. Field data lags by 28 days, so fixes take a while to show — do not conclude a change did nothing after a week.

A realistic target

For a content-led corporate site, sub-2-second LCP and sub-100ms INP on mobile are achievable with static generation, self-hosted fonts, optimised images and disciplined third-party scripts. None of that requires a redesign.

If the site is a client-rendered SPA, the rendering architecture is the fix, and everything else is marginal until it changes.

---

We build sites with a performance budget enforced in the build rather than audited afterwards. See our website development services, or ask us to look at your site.