Speed is not a vanity metric. A slow page costs attention before a visitor has read a single word, and on mobile networks the gap between a fast site and a slow one is felt immediately. Google's Core Web Vitals give us a shared, measurable definition of what "fast enough" means.
This guide explains the three metrics in plain language, shows you where to find trustworthy data, and walks through the fixes we reach for most often on real business websites.
The three metrics, in plain language
Core Web Vitals focus on three moments in a visit: when the main content appears, how quickly the page responds when someone interacts with it, and whether the layout stays still while it loads.
| Metric | What it measures | "Good" threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | How long the largest visible element (often a hero image or headline) takes to render | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page visually responds to clicks, taps, and key presses across the whole visit | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much visible content unexpectedly moves around | 0.1 or less |
Google evaluates each metric at the 75th percentile of page loads, separately for mobile and desktop. In other words, it's not enough for the page to be fast on your office Wi-Fi — three out of four real visits need to meet the threshold.
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was handled; INP looks at responsiveness throughout the visit, which makes it a much better reflection of how an interface actually feels.
Field data versus lab data
There are two kinds of performance data, and confusing them causes a lot of wasted effort.
- Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report (CrUX). It's what you see in Google Search Console's Core Web Vitals report and at the top of PageSpeed Insights. This is what counts.
- Lab data comes from a single simulated test, such as Lighthouse. It's excellent for diagnosing problems and testing fixes, but a perfect Lighthouse score does not guarantee good field data — and a mediocre one doesn't mean your users are suffering.
Smaller sites may not have enough traffic for CrUX to report field data. In that case, use lab tests as a proxy and consider adding real-user monitoring so you can measure your own visitors directly.
Fixing Largest Contentful Paint
Slow LCP is usually caused by one of four things: a slow server response, render-blocking resources, a late-discovered hero image, or a heavy hero element.
- Make the LCP element discoverable early. If your hero image is set as a CSS background or injected by JavaScript, the browser finds it late. Use a real
<img>element, and considerfetchpriority="high"on that image. - Serve appropriately sized, modern images. A 3,000-pixel-wide JPEG on a phone screen is a common culprit. Use responsive images and formats like AVIF or WebP.
- Reduce server response time. Caching, a CDN, and avoiding slow database queries on every page view help everything that follows.
- Trim render-blocking CSS and fonts. Inline critical CSS where it helps, preload key fonts sparingly, and use
font-display: swapso text doesn't stay invisible.
Never lazy-load the image that is most likely to be your LCP element. Lazy loading is for content further down the page.
Fixing Interaction to Next Paint
Poor INP almost always comes down to too much JavaScript running on the main thread at the wrong time.
- Audit third-party scripts. Chat widgets, tag managers loaded with dozens of tags, heatmaps, and A/B testing tools frequently dominate main-thread time. Remove what you don't use and delay what isn't needed immediately.
- Break up long tasks. Work that runs for more than 50 milliseconds blocks input. Splitting it into smaller chunks lets the browser respond to the user in between.
- Give immediate visual feedback. When an action takes time, update the interface first (a pressed state, a spinner) and do the heavy work afterwards.
- Be careful with large client-side frameworks. Hydrating a complex page can delay interactivity. Rendering more on the server and shipping less JavaScript tends to help.
Fixing Cumulative Layout Shift
Layout shift is the most fixable of the three because the causes are well known.
- Always reserve space for media. Set
widthandheightattributes (or an aspect ratio) on images, videos, and iframes. - Reserve space for anything injected later, such as cookie banners, embeds, and ads.
- Avoid inserting content above existing content unless it's in response to a user action.
- Manage web fonts carefully. Large differences between fallback and web font metrics can shift text when the font loads; matching fallback metrics reduces this.
A sensible order of work
If you're unsure where to start, this sequence works well for most business websites:
- Check the Core Web Vitals report in Google Search Console to see which page templates are affected.
- Run PageSpeed Insights on a representative URL from each failing template.
- Fix the issues that affect a whole template first — a slow homepage hero or a site-wide script fixes many pages at once.
- Re-check field data after a few weeks. CrUX reports a rolling 28-day window, so improvements take time to show.
How much do Core Web Vitals matter for SEO?
Google uses page experience signals, including Core Web Vitals, as part of its ranking systems — but relevance and content quality matter far more. Fast pages won't rank on speed alone. The stronger argument for performance is commercial: a faster, more stable site is easier and more pleasant to use, which supports every other goal your website has.
Treat performance as a feature of your product, not an SEO checkbox. Your visitors notice it long before search engines do.
If you'd like a second pair of eyes on your site's performance, our web development team can run an audit and turn the findings into a prioritized plan.