There’s a phrase that sums up the problem well: your website can have the best content in the world, but if it takes four seconds to show anything, the user is already gone. And if on top of that the button they were trying to tap moves just as they’re about to click, the frustration is total.
Google measures that experience with three metrics it grouped under the name Core Web Vitals. They aren’t a technical whim: they’re a ranking signal and, above all, they reflect something your visitors feel on every visit. In this guide we look at what each one measures, what makes them worse and how to fix them.
What Core Web Vitals are
They’re a set of metrics Google uses to measure users’ real experience on your site. They’re calculated with real browsing data (field data), not with lab tests: they reflect what your visitors experience on their devices and with their connections, not what happens in a controlled environment.
The three current metrics are LCP, INP and CLS. Google evaluates them separately for mobile and desktop, and uses the 75th percentile as the reference: to pass, at least 75% of visits must meet the threshold.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long it takes for the main content to appear | 2.5 s or less | More than 4 s |
| INP (Interaction to Next Paint) | How long the site takes to respond to a click, tap or keypress | 200 ms or less | More than 500 ms |
| CLS (Cumulative Layout Shift) | How much the content moves while loading | 0.1 or less | More than 0.25 |
LCP: how fast the main content appears
What it measures. The time it takes for the largest element visible on the initial screen to show up. It’s usually the main image, a large headline or a video thumbnail.
Why it matters. It’s the metric that most resembles the feeling of speed: if the user sees something useful right away, the site feels fast even if other elements finish loading later.
Common causes of a high LCP
LCP breaks down into four phases: the time to first byte (TTFB), the delay in starting to load the resource, the download time and the delay in rendering it. Optimizing only one doesn’t guarantee improving the total.
- Slow server (high TTFB). If the server is slow to respond, LCP will hardly drop below 2.5 seconds. Usual causes are inadequate hosting, a lack of caching or heavy database queries. We look at it in What is web hosting.
- Poorly optimized main image. A multi-MB uncompressed PNG takes a while to download and delays everything else.
- Render-blocking resources. Stylesheets and scripts in the
<head>that prevent showing anything until they’re downloaded and processed. - JavaScript that delays rendering. The browser downloads and runs scripts before showing the main element, even if that script isn’t needed to draw it.
How to improve LCP
- Prioritize the main image. Add
fetchpriority="high"to it or preload it with<link rel="preload" as="image">so the browser requests it as early as possible. - Optimize it. Convert it to WebP or AVIF, resize it to the maximum size at which it’s displayed and compress it without visible loss of quality.
- Remove lazy loading from it. Deferred loading is for off-screen images, but applying it to the main image is counterproductive.
- Reduce TTFB. Use page caching, a CDN and hosting that responds fast.
- Lighten critical CSS and JavaScript. Load up front only what’s needed for the first glance and defer the rest.
INP: how fast your site responds to clicks
What it measures. The time between the user interacting (click, tap, keypress) and the browser showing the next frame with the visual result. It records one of the slowest interactions of the whole visit, not an average.
Why it matters. It replaced FID in March 2024 because FID only measured the first interaction and that didn’t reflect the full experience. INP evaluates all of them, and so it says a lot more about whether your site “feels” fluid.
Common causes of a high INP
INP breaks down into three parts: input delay (the browser is busy when the user clicks), the event’s processing time and the delay until the result is drawn.
- Long tasks blocking the main thread. If the browser is running a heavy script when the user taps, that tap waits. It’s the most frequent cause.
- Too many third-party scripts. Tracking tags, chat widgets, analytics, advertising pixels: each one adds latency and competes for the browser’s resources.
- Heavy event handlers. If what runs when a button is tapped does too many things at once (updating several sections, calling the server, calculating), the response is delayed.
How to improve INP
- Break up long tasks. Instead of running 500 ms of code all at once, split it into small chunks and yield the main thread between them (with
setTimeoutorscheduler.postTask()). - Defer non-critical scripts. Analytics, chat and marketing don’t need to run immediately: load them with
deferor when the browser is idle. - Do the minimum in the event. Update first what the user needs to see and schedule the rest for later.
- Audit third-party scripts. Every so often, review which ones you’re loading and remove the ones you don’t use. It’s one of the improvements that pays off most, and it’s part of the work of web support and maintenance.
CLS: how much your page moves while loading
What it measures. The sum of unexpected shifts of visible elements during the page’s lifetime. It isn’t measured in seconds: it’s a unitless score that combines how much the content moved and over what distance.
Why it matters. It’s one of the most frustrating experiences on the web. You’re reading and suddenly the text drops because an ad loaded. Or you go to tap “Add to cart” and a banner appears right then and you end up tapping something else.
Common causes of a high CLS
- Images without dimensions. If
widthandheightaren’t specified, the browser doesn’t know how much space to reserve and the content jumps when the image finishes loading. It’s the most common cause and the easiest to fix. - Ads, embeds and iframes without reserved space. The same thing happens as with images.
- Web fonts that change the text on load. If the custom typeface is slow, the text first appears in a system font and then changes, shifting the layout.
- Dynamically injected content. Cookie banners, pop-ups or notice bars inserted after loading without reserving space.
How to improve CLS
- Define dimensions on images and videos. Always set
widthandheightin the HTML, andaspect-ratioin CSS for responsive images. - Reserve space for ads and embeds. Use a
min-heightor a placeholder with the likely dimensions of the content that will appear. - Take care of font loading. Preload the main typeface and choose a
font-displaythat doesn’t cause a visible jump. - Don’t insert content above what the user is already viewing. If you need to show a notice, do it outside the document flow or reserve the space in advance.
How to measure your Core Web Vitals
The most important distinction is between field data (what your real users experience) and lab data (controlled tests that are useful for diagnosis).
Field data
- Google Search Console, Core Web Vitals report. It’s the official report: it shows which groups of URLs fail each metric, with real data from the last 28 days.
- PageSpeed Insights (top section). It shows real-user data if your site has enough traffic.
Lab data
- PageSpeed Insights (bottom section) and Lighthouse. They tell you which specific elements cause the problems.
- Chrome DevTools, Performance panel. It lets you record an interaction and diagnose INP frame by frame.
The golden rule: prioritize the problems that show up in field data, because they’re the ones that affect your users and your rankings. Use lab data to understand how to fix them.
If your whole site feels slow and you don’t know where to start, My website is slow: what can I do? goes through the general causes, and What is technical SEO explains where these metrics fit within the rest of the technical foundation. If you’d like us to review your numbers, write to us through our SEO, GEO & AI service.