Websites

Core Web Vitals in plain language: LCP, INP and CLS

Three abbreviations that decide whether your website feels pleasant to visitors. We explain them with examples from a shop, without technical jargon.

Eduard Hirjak

MeaOvis founder

  • Published
  • 6 min read
Article contents

Google measures how pleasant your website is for real people. It does so with three metrics behind the cryptic abbreviations LCP, INP and CLS, which together make up Core Web Vitals (the core quality metrics of a website). We explain them with examples from a shop, without the technical jargon.

Why this should matter to you

For two reasons. The first: Core Web Vitals are among the signals Google takes into account when ranking pages. They are not the most important factor (good content wins), but between pages of similar quality they can decide it.

The second reason matters more: these metrics measure exactly what annoys visitors. Slow loading, a page that does not react to a tap, and content that jumps just as you are clicking something. Even if Google did not track them, they would be worth getting right.

LCP: how fast you see the main thing

LCP (Largest Contentful Paint, the painting of the largest content) measures how long it takes for the biggest element on the first screen to appear. Usually that is the main photo or a large headline.

An example from a shop: You walk into a store and for a moment it is dark. Until the lights come on, you do not know whether you are in the right place. LCP measures how long it takes for the lights to come on.

Good LCP is up to 2,5 seconds. Over 4 seconds is poor.

What most often hurts LCP

  • a huge main photo or video at the top of the page,
  • a slow server response,
  • scripts and fonts the browser has to wait for before it shows anything,
  • a slider (a rotating set of several photos) on the homepage.

How to improve LCP

  • shrink the main photo and use the WebP or AVIF format,
  • tell the browser to load the main photo first,
  • turn on caching on the server or choose faster hosting,
  • replace the slider with one strong photo and a clear headline.

INP: how fast the site reacts

INP (Interaction to Next Paint, the response to an interaction) measures how long it takes from a click or a tap until the page visibly reacts. A menu opens, an item goes into the cart or a form error appears. In 2024, INP replaced the older FID metric.

An example from a shop: You ring the bell at the counter and nobody comes. After a while you ring again, and then once more. That is exactly how people behave on a website that does not respond: they click over and over until they give up.

Good INP is up to 200 milliseconds (a fifth of a second). Over 500 milliseconds is poor.

What most often hurts INP

  • a lot of JavaScript (the code that does the interactive things in the browser),
  • third-party scripts: chats, ads, tracking codes, social media,
  • very long pages with thousands of elements.

How to improve INP

  • remove scripts that bring nothing,
  • load less important scripts only later, the chat after a while, for example,
  • split heavy tasks in the code into smaller ones (that is a job for a developer).

CLS: whether your content jumps around

CLS (Cumulative Layout Shift, the total amount of layout movement) measures how much the content of a page shifts unexpectedly while it loads.

An example from everyday life: You go to tap “Cancel”, but at the last moment a banner loads above the button, everything jumps down and you tap “Order”. Or you are reading an article and the text jumps half a screen away under your finger.

Good CLS is up to 0,1. Over 0,25 is poor. This is not about seconds, but about the amount of movement: the smaller the number, the calmer the page.

What most often hurts CLS

  • images and videos with no size set (the browser does not know how much room to leave them),
  • banners, cookie bars and ads that get inserted into the page and push the content away,
  • fonts that load late and change the size of the text.

How to improve CLS

  • give images their dimensions (width and height),
  • reserve space for elements that load later,
  • show the cookie bar as an overlay, not as a block that pushes the page down.

All three metrics in a table

MetricWhat it measuresGoodNeeds improvementPoor
LCPhow fast the main content appearsunder 2.5 s2,5 to 4 sover 4 s
INPhow fast it reacts to a clickup to 200 ms200 to 500 msover 500 ms
CLShow stable the page layout isup to 0,10,1-0,25over 0,25

Google does not judge a single visit, though, but the so called 75th percentile. Put simply: to be in the green, at least three out of four visits have to show good values. One quick test on your own computer is therefore not enough.

Lab and real world measurements

With Core Web Vitals you will come across two kinds of numbers:

  • Lab measurements: a simulation of the page loading on a “model” device. This is how PageSpeed Insights measures, for example (its Lighthouse part). The upside: you get the result right away. The downside: it is a simulation.
  • Real world measurements: data from real visitors that Google collects from the Chrome browser. It only appears for websites with enough traffic. You will find it in PageSpeed Insights and in the Core Web Vitals report in Google Search Console.

INP cannot be measured in a lab, because nobody clicks there. Lab tools therefore show a substitute value, TBT (Total Blocking Time: how long the page is “stuck” while loading). When TBT is high, INP probably will not be good either.

Tip: Do not chase a score of 100. A visitor will not feel the difference between 92 and 100, but they will feel the difference between 40 and 90. The goal is to have all three metrics in the green band, especially on mobile.

How to check Core Web Vitals yourself

  1. PageSpeed Insights: a free Google tool. Enter the address of the page. The top part shows data from real visitors (if there is enough of it), the bottom part a lab measurement with specific recommendations.
  2. Google Search Console: the Core Web Vitals report shows which groups of pages on the site are fine and which need fixing. It is most useful for larger websites and online stores.
  3. Our Free audit: measures speed on mobile and desktop and explains the results in plain language, together with further SEO and security checks.

How we approach Core Web Vitals

On every website we build, the goal is a Google PageSpeed score of 90 or more on mobile and desktop alike. We do not get there with tricks, but with what is not on the site: no unnecessary libraries and no unnecessary scripts from other people's servers, only the essential cookie-free traffic measurement. On top of that, images in the right size and fonts stored directly on the website's own server. We used the same approach on the website of the salon Runway Care & Beauty.

If you have a website and want to know where it stands:

  • Free audit measures the speed of your homepage on mobile and desktop in a minute,
  • Complete Audit for 350 € measures speed and Core Web Vitals for every type of page and prepares a guide for fixing them,
  • you will find the most common things that slow websites down in the article 10 mistakes we find during an audit.

And if you are planning a new website, see how much a website costs in 2026 and what should be included in the price.

Did the article help you? Send it to a colleague or to whoever looks after your website.

Send by e-mail

FAQ

Questions on this topic

Does my website have to score 100?

No. What matters is that Core Web Vitals are in the green band for real visitors. A customer will not feel the difference between a score of 92 and 100, but they will feel the difference between 40 and 90.

Why are my results worse on mobile than on a computer?

In the mobile test, tools like PageSpeed Insights simulate a weaker processor and a slower connection. Heavy photos and scripts show up there far more. Since Google judges mainly the mobile version of a website, mobile matters more.

You will find more answers in the section FAQ.

Eduard Hirjak

About the author

Eduard Hirjak

Founder of MeaOvis, senior full-stack developer

He has been building websites and apps for more than 20 years and has 100+ projects behind him: from presentation websites through online stores to booking systems and iOS apps. On the blog he explains technical things so that every business owner understands them.

Read on

Related articles

All articles
Websites7 min read

What a website costs in 2026 and what should be included

A presentation website from 1,999 €, a website with a content management system from 3,000 € and an online store from 3,500 €+. We explain what makes up the price and what comes after launch.

Read the article

Free audit

How is your website doing?

Enter your address and in a minute you will see what is slowing your website down on mobile and desktop, with an explanation in plain language.

mobiledesktopSEO for AIresult in 1 minute

Want it handled without the worry?

Tell us what you need. The first consultation is free and within 1 business day you get an estimate of the price and the timing.