Core Web Vitals: The Metrics That Actually Matter
Your website might look great, but if it's slow, Google knows. And Google penalizes slow sites. Not dramatically, but enough to cost you rankings over time.
The metrics Google cares about are called Core Web Vitals. They measure three specific things about how your pages perform for real users. Let's break down what each one means and how to fix them when they're broken.
The Three Metrics
Google's Core Web Vitals measure:
- LCP (Largest Contentful Paint) - How fast does your main content load?
- INP (Interaction to Next Paint) - How quickly does your page respond when someone clicks?
- CLS (Cumulative Layout Shift) - Does stuff jump around while loading?
That's it. Three numbers. But getting them right requires understanding what's actually happening on your pages.
LCP: The First Impression
Largest Contentful Paint measures how long it takes for your main content to appear. Usually that's a hero image, a headline, or a large text block.
Google wants LCP under 2.5 seconds. Anything over 4 seconds is considered poor.
What Kills LCP
The usual suspects:
- Huge images. A 4MB hero image will destroy your LCP. Every time.
- Slow server response. If your server takes 2 seconds to respond, you've already lost.
- Render-blocking resources. CSS and JavaScript that must load before content appears.
- Client-side rendering. If your page is blank until JavaScript runs, LCP suffers.
How to Fix It
Start with your largest element. For most sites, that's the hero image.
Optimize it:
- Use WebP or AVIF format instead of PNG or JPEG
- Set explicit width and height attributes
- Use
loading="eager"for above-the-fold images - Consider using a CDN for faster delivery
Then check your server. Time to First Byte (TTFB) should be under 200ms. If it's not, look at your hosting, caching, and database queries.
Finally, inline your critical CSS. The styles needed to render above-the-fold content should be in your HTML, not in a separate file that has to load first.
INP: The Responsiveness Test
Interaction to Next Paint replaced FID (First Input Delay) in 2024. It's stricter because it measures all interactions, not just the first one.
When someone clicks a button, how long until the page visually responds? Google wants that under 200ms. Over 500ms is poor.
What Kills INP
JavaScript is almost always the culprit:
- Long tasks. Any JavaScript that runs for more than 50ms blocks the main thread.
- Too many event listeners. Each click triggers code. Too much code means delays.
- Heavy frameworks. Some JavaScript frameworks add hundreds of milliseconds of overhead.
- Third-party scripts. Analytics, chat widgets, ad scripts. They all compete for processing time.
How to Fix It
This one's harder because it often requires code changes.
Start by measuring. Chrome DevTools has a Performance tab that shows exactly what's running when you click. Look for long tasks (highlighted in red).
Then prioritize:
- Break up long JavaScript tasks using
requestIdleCallbackorsetTimeout - Lazy-load non-critical scripts
- Audit your third-party scripts. Do you really need all of them?
- Consider lighter alternatives for heavy libraries
One client had a chat widget adding 400ms to every interaction. We replaced it with a lighter option. INP dropped from 450ms to 120ms overnight.
CLS: The Stability Metric
Cumulative Layout Shift measures how much stuff moves around while your page loads. You've experienced bad CLS: you're about to click a link, and suddenly an ad loads above it, pushing the link down. You click the ad instead.
Google wants CLS under 0.1. Over 0.25 is poor.
What Causes Layout Shift
- Images without dimensions. The browser doesn't know how much space to reserve.
- Ads and embeds. They load late and push content around.
- Web fonts. Text renders in a fallback font, then shifts when the custom font loads.
- Dynamic content. Elements inserted by JavaScript after initial render.
How to Fix It
The fixes are usually straightforward:
Always set image dimensions. Every <img> tag should have width and height attributes. CSS aspect-ratio works too.
Reserve space for ads. If you have ad slots, give them a minimum height so they don't push content when they load.
Handle fonts properly. Use font-display: swap in your @font-face rules. Better yet, use font-display: optional to avoid shifts entirely.
Don't inject content above existing content. If you need to add something dynamically, add it below the viewport or use CSS transforms instead of changing layout.
How to Measure Your Vitals
Google provides several ways to check your scores:
PageSpeed Insights - Enter any URL and get a full report. Shows both lab data (simulated) and field data (real users).
Google Search Console - The Core Web Vitals report shows issues across your entire site.
Chrome DevTools - The Lighthouse tab gives detailed recommendations.
Web Vitals Extension - A Chrome extension that shows vitals in real-time as you browse.
Start with PageSpeed Insights. It'll tell you exactly what's wrong and suggest fixes.
The Real-World Impact
Do Core Web Vitals actually affect rankings? Yes, but it's not massive. Google has said it's a tiebreaker. If two pages are equally relevant, the faster one wins.
But here's what matters more: user experience affects conversions. Amazon found that every 100ms of latency cost them 1% in sales. Your site might not be Amazon, but the principle holds. Faster sites convert better.
One e-commerce client improved their LCP from 4.2 seconds to 1.8 seconds. Rankings improved slightly. But conversion rate jumped 23%. That's the real payoff.
Start Here
You don't need to fix everything at once. Here's the priority:
- Run PageSpeed Insights on your homepage and top landing pages
- Fix CLS issues first (usually the quickest wins)
- Optimize your largest images
- Audit your JavaScript and third-party scripts
- Set up monitoring so you catch regressions
Core Web Vitals aren't going away. Google keeps adding them to more ranking systems. The sites that nail performance now will have an edge for years to come.