Core Web Vitals explained for business owners
LCP, INP and CLS without the jargon: the current thresholds, how to measure your site for free, the six common causes, and what can be fixed without a rebuild.
Core Web Vitals are three measurements by which Google assesses how a person feels on your page. Not how fast it loads in a laboratory, but what a real visitor experiences, on their phone, on their connection. They are a confirmed ranking factor, but more importantly they measure exactly the things that make people close a page before seeing what you sell.
This article explains each of the three without jargon: what it measures, what the threshold is, what breaks it, and what can be fixed on an existing site. At the end there are real figures from an optimisation we carried out, so you can see the order of magnitude of the gain.
Contents
- What Google actually measures
- LCP: how long until the main thing appears
- INP: how long until the site responds
- CLS: how much the page jumps under your finger
- Are Core Web Vitals a ranking factor
- How to measure your site in ten minutes
- The six causes behind most problems
- Why images are almost always to blame
- Third-party scripts: the hidden cost of every widget
- Fonts, the cause nobody suspects
- What can be fixed and what needs a rebuild
What Google actually measures
The three measurements correspond to three moments every visitor goes through:
- Is it loading? — how long do I wait before I see something useful. (LCP)
- Does it respond? — I tap, and does something happen? (INP)
- Does it stay put? — or does the content jump and I tap something I did not mean to? (CLS)
Lab data and field data
There are two kinds of measurement, and the confusion between them causes a lot of pointless argument:
- Lab — a test run under controlled conditions, which gives a score. Useful for diagnosis.
- Field — data collected from real users over the last 28 days. These are what count for ranking.
A site can have a good lab score and poor field data, because real visitors have weaker phones and worse connections than the test machine.
The 75th percentile
Google does not look at the average user but at the 75th percentile: three quarters of visitors have to have a good experience. That is the right choice — an average hides exactly the users who are having trouble.
LCP: how long until the main thing appears
Largest Contentful Paint measures how long it takes from the start of loading until the largest visible element in the top part of the page appears — usually a large image or the heading.
| Threshold | Interpretation |
|---|---|
| under 2.5 s | good |
| 2.5–4 s | needs improvement |
| over 4 s | poor |
LCP is the metric most sites fail on mobile — only about 62% of mobile pages pass the threshold, against 77% for INP and 81% for CLS (corewebvitals.io(opens in a new tab)).
What breaks LCP
- The large image at the head of the page, unsized and in an old format.
- A slow server — if the response takes 800 ms, you have used a third of the budget before anything has begun.
- Fonts that block the display of text.
- JavaScript that has to be downloaded and executed before the content appears.
- An autoplaying background video. The most expensive thing you can put on a page.
INP: how long until the site responds
Interaction to Next Paint measures the time from a tap or click until the screen visibly updates. It replaced an older measurement that assessed only the first interaction; INP takes all of them into account.
| Threshold | Interpretation |
|---|---|
| under 200 ms | good |
| 200–500 ms | needs improvement |
| over 500 ms | poor |
INP is the most commonly failed metric: 43% of sites do not pass the 200 ms threshold (NitroPack(opens in a new tab)).
Why it is the hardest
Because it does not depend on how fast the page loads, but on how much code runs after it has loaded. A site with many scripts — chat, maps, tracking, animations, consent modules, review widgets — can look perfect and respond with a delay the user reads as “it’s frozen”.
What breaks INP
- Too many third-party scripts. Every widget added eats into the response budget.
- Tracking modules that execute on every interaction.
- Badly implemented animations that force the browser to recalculate the page.
- Menus and filters that process long lists on every tap.
CLS: how much the page jumps under your finger
Cumulative Layout Shift measures how much the content moves during loading. It is the frustration metric: you start reading a paragraph, an image loads above it, and the text moves down.
| Threshold | Interpretation |
|---|---|
| under 0.1 | good |
| 0.1–0.25 | needs improvement |
| over 0.25 | poor |
What breaks CLS
- Images without declared dimensions. The browser does not know how much space to reserve, so it reserves none, and when the image arrives it pushes everything below it down.
- Adverts or content loaded later, inserted between existing elements.
- Banners that appear over the content after a second.
- Fonts that switch on loading, with a large difference in size between the fallback and the final one.
The easiest to fix
Of the three, CLS is the simplest to resolve: declare the dimensions of images and reserve space for anything that appears later. It is mechanical work, with an immediate result.
Are Core Web Vitals a ranking factor
Yes, they are a confirmed ranking factor, folded into the page experience signals since 2021. But they are a secondary factor: the relevance of the content remains decisive. In practice, Core Web Vitals act as a tie-breaker between pages with content of comparable quality. A fast page with weak content will not overtake a slow page with excellent content.
The better reason to watch them
Not ranking, but behaviour. A page that loads slowly on a phone loses visitors before they see what you sell. Every extra second cuts into the number of people who reach the contact form.
In other words: optimise for people, and the ranking comes as a side effect. It does not work the other way round.
How to measure your site in ten minutes
PageSpeed Insights
Open pagespeed.web.dev, enter a page address, choose Mobile.
What to read, in order:
- The section at the top, “Discover what your real users are experiencing”. That is the field data, the only part that counts for ranking. If it is missing, the site does not have enough traffic for collection — use the rest of the report as a guide.
- The three values, in green, amber or red.
- The list of opportunities below, sorted by impact.
Test the home page, a service page and a portfolio page. They are different structures and can have different problems.
Search Console
The dedicated report shows the field data for the whole site, grouped by page type. That is the correct site-level view, where PageSpeed Insights is the page-level one.
What does not matter
The overall 0-to-100 score. It is a weighted average of several lab measurements and is not used for ranking. A site scoring 78 with all three field values green is in a better position than one scoring 95 with red field data.
The six causes behind most problems
| # | Cause | Metric affected | Effort to fix |
|---|---|---|---|
| 1 | Unmanaged images | LCP, CLS | small |
| 2 | Too many third-party scripts | INP, LCP | small–medium |
| 3 | Slow server | LCP | small (change host) |
| 4 | Fonts that block rendering | LCP, CLS | small |
| 5 | Excess plugins and modules | all | medium |
| 6 | A heavy theme, with a visual editor | all | large |
The first four are a few hours’ work. The fifth is a clear-out. The sixth is usually the reason the other five do not turn out to be enough.
Why images are almost always to blame
In a typical audit, images account for more than half the problem. Four mistakes, all of them common:
1. The original file is served. A photograph 2,000 pixels wide, displayed in a 400-pixel card, forces the phone to download an image far larger than it needs.
2. The wrong format. For many web images, JPEG and PNG files can be considerably larger than AVIF or WebP at comparable visual quality.
3. No declared dimensions. The main cause of content jumping.
4. Everything loads at once. The images at the foot of the page, which nobody will see without scrolling, download at the same time as the ones at the top.
Figures from a real optimisation
When we rebuilt this site, we applied exactly those four corrections to the portfolio grid. The measured result:
| Before | After | |
|---|---|---|
| Portfolio grid, 12 visible cards | ~2.4 MB | ~180–260 KB |
| Bytes for a card 400 px wide | 206 KB | ~18–28 KB |
A reduction of roughly 90%, with no visible loss of quality. Not one image was changed: variants were generated at the sizes actually used, in modern formats, with declared dimensions and deferred loading for anything below the first visible section.
Third-party scripts: the hidden cost of every widget
The second most frequent cause, after images, and the one that explains most INP problems.
How they accumulate
Nobody decides to put eight scripts on a site. They get added one at a time, in different months, each for a good reason:
| What gets added | The reason at the time |
|---|---|
| Traffic analytics | “we have to know how many visitors we get” |
| Consent banner | mandatory |
| Chat | “so they can ask quickly” |
| Social network pixel | “for the campaigns” |
| Embedded map | “so they can see where we are” |
| Review widget | “so people see we have good reviews” |
| Embedded video | “it’s easier than hosting it ourselves” |
| A form from an external service | “it was ready made” |
Eight scripts, each from a different domain. Each needs a new connection, downloads code and executes it. The effect is not additive, it is cumulative: they block each other on the browser’s main thread, and the result shows in INP.
Roughly what it costs
An ordinary chat widget adds a few hundred kilobytes of JavaScript and tens of milliseconds of execution. An embedded map is often the heaviest element on a contact page — heavier than all the images put together.
What to do
Take an inventory. In the developer tools, in the network section, sort by domain. You will see exactly what comes from whom.
For each one, ask: what does it bring, and who last checked whether it is used? Review widgets and pixels from finished campaigns stay on sites for years.
Replace what you can:
| Instead of | Use |
|---|---|
| An interactive map embedded on every page | a static image of the map, linking to the maps app |
| Embedded video, loaded automatically | a preview image that loads the player only on click |
| A review widget | the reviews as text on the page, updated periodically |
| An external font | the font hosted locally |
Defer what is not needed immediately. Chat, campaign pixels and additional analytics scripts do not have to start with the page. Loaded after the user interacts, they disappear entirely from the initial loading budget.
The connection with consent
Most third-party scripts set cookies and are not allowed to start before the visitor agrees. Implemented properly, that partly solves the performance problem too: for anyone who does not accept, the scripts never load at all. See Cookie banners and Consent Mode v2.
Fonts, the cause nobody suspects
A font is a file that has to be downloaded before text can be shown in its final form. Badly configured, it causes problems on two of the three measurements.
Invisible text
The default behaviour of some configurations is to hide the text until the font loads. The result: an empty page for a few hundred milliseconds, even though the text was ready to display. If the largest element at the top of the page is a heading, LCP grows directly by the font’s delay.
The fix: configure the font to show a fallback immediately and switch when the final one arrives.
The jump on switching
Switching produces a change in appearance. If the fallback font has very different widths, the text reflows and CLS increases. It is solved by choosing a fallback with similar metrics and adjusting the difference.
The four rules
- Host the fonts locally. A font from an external domain means an extra connection before the text appears — plus a consent problem.
- Load only the weights you use. A font with nine weights of which you use two means four times as many bytes for nothing.
- Narrow the character set to what you need. For Romanian: latin plus latin-ext — the diacritics ș, ț, ă, î and â are in the extension. Without it, they show in a fallback font.
- Preload the main font, the one used for the heading at the top of the page.
The quick check
In the network section of the developer tools, filter by fonts. How many files download? From where? How much do they weigh? More than three font files on a page is almost certainly too many.
What can be fixed and what needs a rebuild
Fixable on an existing site
- Optimising images and declaring their dimensions.
- Removing third-party scripts that bring nothing.
- Configuring fonts to display immediately.
- Turning on compression and caching on the server.
- Moving to better hosting.
- Removing unused plugins.
Realistic gain: LCP down by 30–50%, CLS often resolved entirely. A few days’ work.
Not fixable without a rebuild
- A theme that loads the libraries for every feature, whatever you use.
- A visual editor that generates layers of code for every section.
- An accumulation of plugins that overlap and block each other.
The sign: you have done everything above and LCP is still over 4 seconds on mobile. At that point, optimising further is money thrown away — the problem is the foundation.
What the alternative looks like
A site built as static files, with the images processed at build time and the dimensions known in advance, passes the thresholds by construction, not by later optimisation. It is not magic: it is the absence of code that should never have existed. The subject is discussed at length in WordPress or a static site.
Want to know where your site stands and what can be fixed without a rebuild? Send us the address — we will look at the field data and tell you concretely what there is to gain and at what effort.
Read next: The SEO structure of a business website, Web hosting: what really matters, and what a business website project includes.