When I tell a client that their website has a slow Largest Contentful Paint, I usually get a blank stare. When I tell them their homepage takes 4.2 seconds to show meaningful content and that this is directly costing them search rankings and customers, the conversation changes.

Core Web Vitals are Google's way of measuring the user experience of a page. They've been ranking signals since 2021, and they matter more now than ever. But beyond rankings, they measure something genuinely important: whether your site feels fast and stable to the people using it.

The three metrics that matter

Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on the page to load. Think: the hero image, the main heading, the feature photo. Google's threshold is 2.5 seconds — above that, you're in the "needs improvement" zone. Above 4 seconds is poor.

This is the metric I see fail most often, and usually for the same reasons: unoptimized images, render-blocking resources, or a server that's just too slow.

Cumulative Layout Shift (CLS) measures visual instability — how much the page layout jumps around as it loads. You've experienced bad CLS when you go to tap a button and it shifts just as you tap it, and you accidentally tap something else. Google's threshold is a score of 0.1.

CLS failures are almost always caused by images or ads without explicit dimensions, or by web fonts loading and swapping in after the page has already rendered.

Interaction to Next Paint (INP) replaced First Input Delay in 2024 and measures responsiveness — specifically, how long it takes the page to visually respond after any user interaction. The threshold is 200 milliseconds.

High INP usually points to JavaScript doing too much work on the main thread, blocking the browser from responding to user input.

What I actually fix

I approach Core Web Vitals the same way I approach every technical problem: measure first, then fix. I don't guess at what's slow — I use PageSpeed Insights, Chrome DevTools, and field data from the Chrome User Experience Report (CrUX) to find the actual bottlenecks.

Here's what most fixes come down to:

For LCP:

  • Convert images to WebP or AVIF — typically 30–70% smaller than JPEG at equivalent quality
  • Add <link rel="preload" as="image" fetchpriority="high"> for the LCP element so the browser discovers and fetches it immediately, not after parsing the full stylesheet
  • Eliminate render-blocking scripts and stylesheets
  • Use loading="eager" on the LCP image and loading="lazy" on everything below the fold
  • Optimize server response time — TTFB (Time to First Byte) is the foundation that everything else is built on

For CLS:

  • Add explicit width and height attributes to every <img> tag — this alone eliminates most CLS
  • Add font-display: swap to web font declarations and preconnect to font CDNs to minimize layout shifts from font loading
  • Reserve space for dynamic content (ads, embeds) before they load

For INP:

  • Audit and split large JavaScript bundles — load only what's needed for the current page
  • Move expensive computations off the main thread using web workers
  • Defer non-critical scripts with async or defer
  • Avoid long tasks (anything over 50ms) in event handlers

The business case

Google has published data showing that as page load time goes from 1s to 3s, the probability of a visitor bouncing increases by 32%. From 1s to 5s, it's 90%. These aren't abstract numbers — they're customers leaving before they see your offer.

Beyond bounce rates, Core Web Vitals are a direct ranking factor. Two pages with equivalent content will be ranked differently based on their performance. If your competitors have faster sites, they outrank you even with comparable SEO effort.

I saw this directly when working on performance optimization for e-commerce and service clients: fixing the LCP cut bounce rates, and the combination of better rankings plus better on-site experience compounded into measurable revenue improvement.

Performance and advanced features aren't in conflict

One thing I want to push back on: the assumption that adding rich, interactive features to a site means accepting slower performance. It doesn't have to.

When I build 3D and immersive web experiences, I apply the same performance budget discipline I use on every project — progressive enhancement, lazy-loaded assets, and aggressive preloading for what matters most. A Three.js scene and a 90+ PageSpeed score aren't mutually exclusive. They just require more careful architecture.

Getting a performance audit

If you're not sure where your site stands, the starting point is always PageSpeed Insights at pagespeed.web.dev. Paste your URL and read the Opportunities and Diagnostics sections — that's where the actionable issues are listed.

If you want me to run a proper audit and fix the issues I find, I do this as a standalone engagement. The scope and cost depend on what the site is built on and what the audit uncovers.

Reach out and tell me about your site — I'll give you an honest assessment of what's worth fixing and what to prioritize.