Core Web Vitals: what they are and how to improve them
What Core Web Vitals are (LCP, INP and CLS), which values count as good, how to measure them and which concrete changes make your website faster.
Core Web Vitals are three metrics that Google uses to describe the real experience of the people who visit a page: how quickly the main content shows up, how quickly the page responds to interaction and how stable the layout is while it loads. They are part of the page experience signals and, beyond the search engine, they correlate with something you can feel: fast, stable sites keep people better.
This technical guide explains each metric, its thresholds, how to measure them and which actions improve each one. The reference documentation is on web.dev.
The three metrics
| Metric | What it measures | "Good" value |
|---|---|---|
| LCP (Largest Contentful Paint) | How long the largest content element takes to show | 2.5 seconds or less |
| INP (Interaction to Next Paint) | How quickly the page responds to clicks, taps and keys | 200 milliseconds or less |
| CLS (Cumulative Layout Shift) | How much the layout "moves" while it loads | 0.1 or less |
These thresholds are evaluated on the 75th percentile of real visits: for a page to be considered good, three out of four visits have to meet them. The details of each one are in the guides on LCP, INP and CLS.
Lab data and field data
- Lab data: a controlled test (for example, Lighthouse or PageSpeed Insights). It is useful for debugging, because it is repeatable.
- Field data: measurements from real visitors, aggregated. It is the one that counts when evaluating the experience. Search Console shows it in its Core Web Vitals report for your site (see how to connect it in the guide on Google Search Console).
A page can look perfect in the lab and have poor field data (slower devices, worse networks). Follow the field data and use the lab to find out why.
How to improve LCP
LCP is usually a large image or a large block of text near the top. The typical causes and their fixes:
- Slow server response. Reduce response time with good hosting, caching and a content delivery network (CDN).
- Heavy main image. Compress it, use modern formats (WebP or AVIF) and serve it at the size it is displayed, not a larger one.
- The LCP image loads late. Do not lazy-load it: that attribute is for what is below the fold. You can give it loading priority.
- Resources that block rendering. Heavy styles and scripts in the
<head>delay everything. Keep only what is critical and load the rest later. - Fonts that take long. Use few variants, preload the main one and define a fallback behavior while it loads.
How to improve INP
INP measures the latency of interactions: how much time passes from when you tap something until the screen responds. The problem is almost always JavaScript on the main thread:
- Reduce the JavaScript that is loaded and executed: remove libraries you do not use.
- Break up long tasks: any task longer than 50 ms can make the page sluggish. Split them so that the browser can respond in between.
- Load third-party scripts with judgment (chats, pixels, maps): each one adds work. Evaluate whether all of them are needed and load them deferred.
- Avoid expensive layout changes on interaction, such as recalculating large parts of the page.
How to improve CLS
CLS penalizes content that jumps while loading and makes you tap what you did not intend. The most effective fixes:
- Set
widthandheight(oraspect-ratio) on all images and videos, so that the browser reserves the space before they load. - Reserve space for ads, banners and embeds.
- Do not insert content above what the user is already reading (for example, notices that push the text down).
- Take care of fonts: an abrupt change of typeface while loading can move the text.
- Animate with
transforminstead of properties that change size or position in the flow.
A reasonable work plan
- Measure the most important page (normally the home page) with PageSpeed Insights and the whole site with Search Console.
- Identify the metric that fails and its main cause.
- Change one thing at a time and measure again.
- Prioritize what improves the most with the least effort: in practice, it is usually optimizing images and removing unnecessary scripts.
- Repeat periodically. Every plugin, banner or tool that gets added can worsen the result.
Common mistakes
- Optimizing only for the lab score and ignoring field data.
- Lazy-loading all images, including the main one.
- Adding plugins and scripts without measuring the cost of each one.
- Uploading images of several megabytes and letting the browser shrink them.
- Not testing on a real phone with an average connection.
Frequently asked questions
Do Core Web Vitals guarantee better rankings?
No. They are one signal among many and they do not replace good content. But a slow or unstable website loses visits and inquiries even if the search engine does not penalize it.
How often does the data change?
Field data builds up over several weeks, so improvements take a while to show.
How much does it cost to improve speed?
It depends on the starting point. Many times it is solved with image optimization and a review of scripts; other times it requires deeper changes.
What to do next
If you would like us to measure your site and tell you what to fix first, take a look at our website tune-up or get in touch. And if your site is a store, e-commerce optimization adds an analysis of the buying journey.