Speed is a feature. Google's Core Web Vitals put numbers on something users already feel — how quickly a page becomes usable and how stable it is while they interact with it. The specific metrics evolve, but the underlying goal doesn't: pages that respond fast keep more visitors and convert better. This guide covers what the vitals measure today and, more usefully, what actually moves them.
The three metrics that matter
Core Web Vitals distill page experience into three measurable signals:
- LCP (Largest Contentful Paint) measures perceived load speed — how long until the biggest visible element (usually a hero image, heading, or banner) renders. Aim for under 2.5 seconds.
- INP (Interaction to Next Paint) measures responsiveness — how quickly the page reacts when a user taps, clicks, or types, across the whole visit. Aim for under 200 milliseconds. INP replaced the older First Input Delay because it captures the full interaction experience, not just the first one.
- CLS (Cumulative Layout Shift) measures visual stability — how much content jumps around as the page loads. Aim for under 0.1.
Together they approximate the question every user asks subconsciously: did this page load fast, respond instantly, and stay put?
Why Core Web Vitals affect revenue, not just rankings
It's tempting to treat the vitals as an SEO obligation. They are a ranking signal — but the bigger story is the business one. Every study of real traffic tells the same story: as load time climbs, conversion falls and bounce rate rises. A page that feels sluggish loses people before they ever see your offer.
So the vitals are worth improving even if Google ignored them entirely. Better scores mean more visitors who stay, read, and act. The SEO benefit is a bonus on top of a genuinely better experience.
Practical fixes for LCP
LCP problems almost always come down to the hero element loading slowly. The highest-impact moves:
- Optimize the LCP image. Serve modern formats (WebP or AVIF), size the image to its actual display dimensions, and compress it. The hero image is often the single biggest file on the page.
- Preload critical resources. Tell the browser to fetch the hero image and key fonts early instead of discovering them late.
- Render on the server and cache at the edge. Server-side rendering with edge caching gets meaningful content to the browser fast, rather than shipping a blank page that fills in via JavaScript.
- Eliminate render-blocking resources. Defer non-critical CSS and JavaScript so the browser can paint the important content first.
Practical fixes for INP
INP is about the main thread — the single lane where your JavaScript runs. When it's congested, interactions stall.
- Ship less JavaScript. The cheapest interaction is the one that doesn't run heavy code. Audit your bundles and cut what you don't need.
- Break up long tasks. A single 300ms function blocks every interaction for 300ms. Split heavy work into smaller chunks, or move it off the main thread with web workers.
- Defer non-essential work. Analytics, third-party widgets, and below-the-fold logic don't need to run during the user's first interaction.
- Audit third-party scripts. Chat widgets, tag managers, and ad scripts are frequent INP offenders. Load them lazily and question whether each one earns its cost.
Practical fixes for CLS
Layout shift is usually caused by content that loads after the page has already painted and pushes everything down.
- Reserve space for images and embeds. Always set width and height (or an aspect ratio) so the browser holds the space before the asset arrives.
- Handle fonts carefully. Use
font-display: swapand preload key fonts to avoid text reflowing when the custom font loads. - Avoid inserting content above existing content. Banners, cookie notices, and late-loading ads should reserve their space rather than shove the page around.
Measuring in the field vs. the lab
Two kinds of data matter, and they answer different questions:
- Lab data (Lighthouse, local profiling) is reproducible and great for debugging a specific change. But it runs on one simulated device and won't reflect your real audience.
- Field data (Chrome User Experience Report, real-user monitoring) reflects actual visitors on actual devices and networks. This is what Google uses for ranking, and it's the truth that matters.
Use lab tools to diagnose and iterate; trust field data to tell you whether it worked. A change that looks great in Lighthouse but doesn't move your field numbers hasn't helped the people you care about.
Where to start
If you only do three things: serve your hero image in a modern format at the right size, cut or defer the heaviest JavaScript, and set dimensions on everything that loads asynchronously. Those alone fix the majority of vitals problems we see.
Performance isn't a one-time project — it's a property you maintain as the site grows. But the payoff compounds: a fast site ranks better, converts better, and respects your visitors' time.
Want a faster site that ranks and converts? See how we approach web development, or browse our work.