Core Web Vitals are three metrics defined by Google to measure what real visitors experience: how fast the main content appears (LCP), how quickly the page responds to interactions (INP) and how visually stable it is (CLS). They are part of the page experience signals Google takes into account, but above all, they reflect how your visitors feel when using your site. Understanding them tells you where to focus your efforts to improve your site speed.
The three Core Web Vitals at a glance
- LCP (Largest Contentful Paint): the time it takes to display the largest element visible on load, often the main image or the headline. Target: 2.5 seconds or less.
- INP (Interaction to Next Paint): the delay between an interaction (click, tap, typing) and the visible update of the page. It replaced the older FID metric. Target: 200 milliseconds or less.
- CLS (Cumulative Layout Shift): how much the layout shifts unexpectedly, like a button that moves just as you click it. Target: 0.1 or less.
To be rated “good”, a page must meet these thresholds for at least 75% of visits, on both mobile and desktop.
Measuring: field data versus lab data
There are two kinds of measurements, and mixing them up is the most common mistake. Field data comes from real visitors using Chrome: this is what Google takes into account. You will find it at the top of the PageSpeed Insights report and in the “Core Web Vitals” report in Search Console. Lab data (Lighthouse, at the bottom of the PageSpeed Insights report) simulates a page load: it is useful for diagnosis, but the score out of 100 is not a Core Web Vital. A site can show an average Lighthouse score and pass all three thresholds in the field, or the other way round. A low-traffic site sometimes lacks field data altogether, in which case you rely on lab data and your own measurements.
Improving LCP
- Reduce server response time: suitable hosting, page caching, a recent PHP version.
- Do not lazy-load the main image, and give it priority with the
fetchpriority="high"attribute. - Compress images, serve them as WebP or AVIF, at the size they are actually displayed.
- Limit the stylesheets and fonts that block rendering.
Improving INP
A poor INP is almost always caused by JavaScript: while the browser is busy running code, it cannot respond to the click.
- List your third-party scripts (chat widgets, ad pixels, analytics tools, carousels) and remove the ones you no longer need.
- Defer non-essential scripts.
- Break up long-running work (tasks over 50 ms block the browser) and be wary of page builders that load a lot of code on every page.
Improving CLS
- Set the
widthandheightattributes on images and videos so their space is reserved. - Reserve space for banners, ads, embeds and the cookie banner.
- Control font loading (
font-display, preloading) to avoid text jumping around. - Never insert content above what is already displayed, unless in response to a visitor action.
Where to start
Start from the field data in Search Console to identify the groups of pages that are struggling, then analyse one representative page from each group. Fix one metric at a time and be patient: field data is calculated over a rolling 28-day period, so improvements do not show up in the reports straight away.
Is your site built on WordPress? WordPress speed optimisation (€490 excl. VAT, 50,000 DZD in Algeria) covers caching, images, scripts, the database and Core Web Vitals, with before-and-after measurements. For another technology or a broader diagnosis, see the performance and security audit.