Core Web Vitals: what they are, how to measure them and how to really improve them

Core Web Vitals are three measures Google uses to judge the real experience of someone visiting a page: how quickly the main content appears, how it responds to clicks and how stable it stays while loading. If an agency or a technician looks after your site, these are the numbers they will ask you to improve; if you handle it yourself, it is enough to understand what they mean and where to start.

The three indicators in plain words

LCP: when the main content appears

LCP stands for Largest Contentful Paint. It measures the time before the largest element on the first screen (usually the opening image or the headline) is visible. For Google it is good if it arrives within 2.5 seconds.

INP: how responsive the page is

INP stands for Interaction to Next Paint. It measures the delay between a user action (a click, a tap, a key press) and the page's visible response. It is good if it stays under 200 milliseconds. It replaced the old FID as the responsiveness indicator.

CLS: how much the page moves

CLS stands for Cumulative Layout Shift. It measures sudden shifts of elements while the page loads: when you are about to tap a button and a banner pushes it further down. It is good if it does not exceed 0.1.

Lab data and real data

Understanding the difference avoids a lot of frustration.

• Lab data comes from a simulated test, with a preset device and connection. It is repeatable and useful to check an intervention right away.
• Real data (also called field data) comes from actual visitors, with their phones and their connections. It is what Google uses for the assessment, calculated at the 75th percentile.

If your site does well in the lab but the real data is poor, the problem is often tied to less powerful devices or slow connections.

How to measure them

1. Search Console, Core Web Vitals report: it shows which groups of pages have problems, separating mobile and desktop.
2. PageSpeed Insights: enter the address of a page and read both the real data and the test diagnostics.
3. Browser developer tools: the Performance tab shows what happens millisecond by millisecond.

Always start from mobile: that is where the thresholds are missed most often.

How to improve LCP

LCP depends on how quickly the server responds and how heavy the main element is.

• Server and hosting: a high response time penalises everything. Page caching and suitable hosting make a big difference.
• Main image: resize it, use a modern format such as WebP or AVIF and do not apply lazy loading to it, because it is exactly the one that has to appear first.
• Loading priority: tell the browser that this image is important.
• Render-blocking resources: reduce the stylesheets and scripts loaded before the content.
• Fonts: load only the ones you need and make sure text is readable while the font arrives.

How to improve INP

A high INP means the browser is busy running JavaScript when the user tries to interact.

• Reduce scripts: every extra library is work for the processor, especially on cheap phones.
• Defer what is not needed straight away: chat, pixels and widgets can start later.
• Break up long tasks: an operation that blocks the browser for more than 50 milliseconds should be split into parts.
• Simplify the page: fewer elements on the page means less work for every update.

How to improve CLS

Shifts almost always come from elements that appear without reserved space.

• Image and video dimensions: always set width and height, so the browser reserves the space.
• Banners and ads: give them a fixed area instead of inserting them above content that is already visible.
• Fonts: a font swap after loading can move the text; choose a fallback typeface with similar proportions.
• Dynamically inserted content: add it below, not above, what the user is already looking at.

A sensible order of work

1. Measure the starting values of the home page and most important pages, on mobile.
2. Fix LCP, which usually gives the most visible results.
3. Remove the most obvious shifts (CLS), often with quick interventions.
4. Work on INP by reducing scripts, which is the most technical job.
5. Measure again and wait for the real data to update.

Keep in mind that it takes about four weeks for real data to reflect the changes.

How much weight they really have on SEO

It is right to be clear-headed, without alarmism or underestimation. Core Web Vitals are part of the page experience signals Google considers, but they are one factor among many. Relevant, useful and well-structured content counts more. Their weight is felt mostly in two cases: when two pages are similar in quality, and when a truly poor experience (a page that jumps around, that does not respond) drives visitors away before they even read.

The more practical reason to care, then, is not only ranking: a fast, stable site converts better, because people stay and complete what they came to do.

The most frequent mistakes

• Optimising the test, not the visitors. A score obtained in the lab means nothing if the real data stays poor.
• Applying lazy loading to the main image. It makes it slower, not faster.
• Adding "optimisation" plugins by the dozen. Each one adds code; the result can get worse.
• Ignoring mobile. The thresholds are missed more often on smartphones, and that is where Google judges more strictly.
• Stopping at the home page. Product, article or service pages often have different problems from the front page.

How to keep them under control over time

A site gets worse without you noticing: a new banner, a script added by marketing, an updated plugin. That is why a periodic check is worthwhile.

1. Every month, look at the Core Web Vitals report in Search Console.
2. After every important change, check the pages you touched again.
3. Ask whoever adds external scripts or tools to warn you before publishing them.
4. Keep a simple log of changes, with date and reason: it helps you understand what a drop depends on.

When it is worth asking for help

The simplest interventions, such as optimising images, can be done on your own. When you need to touch the theme, reduce scripts or work on the server, a technician is worth it, because a wrong change can make things worse or break site features. If you have a WordPress site, you will also find the most common causes in Slow WordPress site: the 7 most common causes.

Why entrust it to me

I have been in web development since 1999, with more than 300 projects delivered, and I have worked as an external developer with about 30 agencies. I work from Rome and remotely.

In my Technical SEO and site speed service I start with an analysis and a report you can understand, hand you the interventions in order of priority and measure again at the end to show you before and after. If you want to know where your site stands against the thresholds, write to me: a chat of about 20 minutes, no strings attached, is enough to understand where to start.