Published on · By the IT LABS PRO team
Visitors do not measure your website in milliseconds; they feel it. Does the main content appear quickly? Does the page react when they tap? Does the layout jump around while it loads? Google turned these three feelings into three measurements, the Core Web Vitals, and uses them as part of the page experience signals in search. Here is what they mean and how to improve them.
Test a page now with our free website speed test: it shows the Core Web Vitals of real Chrome users when available, plus Google’s lab measurements and the main improvements to make.
The three Core Web Vitals
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | When the main content (big image or text block) appears | 2.5 s or less | over 4 s |
| INP (Interaction to Next Paint) | How quickly the page reacts to taps, clicks and key presses | 200 ms or less | over 500 ms |
| CLS (Cumulative Layout Shift) | How much the layout moves unexpectedly while loading | 0.1 or less | over 0.25 |
Google assesses each metric at the 75th percentile of real visits: a page passes when at least three visits out of four are in the “good” range. INP replaced the older FID (First Input Delay) metric in March 2024.
LCP: “is it here yet?”
LCP is the moment the largest element in the visible part of the page has been displayed, usually the hero image or the main heading. Common causes of a slow LCP:
- a slow server (long time to first byte);
- a heavy hero image, not compressed or not in a modern format such as WebP;
- the hero image loaded late (lazy-loaded, or discovered only after CSS and scripts);
- render-blocking CSS and JavaScript in the head of the page.
Quick wins: compress and resize the hero image (our WebP converter helps), preload it, never lazy-load it, and check your hosting’s response time.
INP: “does it react?”
INP measures the delay between an interaction (tap, click, key press) and the next visual update, across the whole visit. A poor INP feels like a button that does nothing for a moment. It is almost always caused by too much JavaScript running on the main thread: heavy themes, sliders, tracking scripts, chat widgets, page builders.
Quick wins: remove scripts and plugins you do not really need, load third-party tags after the page is interactive, and break long scripts into smaller tasks.
CLS: “stop moving!”
CLS adds up unexpected layout movements: text that jumps down when an image or a banner appears, a button that moves just as you tap it. Typical causes:
- images and videos without width and height attributes;
- ads, embeds or cookie banners inserted above existing content;
- web fonts that change the size of text when they load.
Quick wins: give every image its dimensions, reserve space for banners and embeds, and use font-display settings and fallback fonts with similar metrics.
Reading our speed test
The performance score
The score out of 100 comes from a Lighthouse test run by Google’s PageSpeed Insights, on a simulated mid-range phone with a slow connection (or on desktop if you choose). 90+ is good, 50–89 needs improvement, under 50 is poor. It is a lab score: useful to compare versions of a page, but it varies a few points from one run to the next.
Real Chrome user data (last 28 days)
When your website has enough traffic, Google publishes the real LCP, INP and CLS of Chrome users over the last 28 days (the Chrome UX Report). This is what Google uses for its page experience signals. Smaller websites often see “not enough traffic”: then only lab data is available, which is fine for diagnosis.
Lab data
The lab section adds diagnostic metrics: FCP (First Contentful Paint, when the first content appears; good under 1.8 s), TBT (Total Blocking Time, a lab stand-in for responsiveness; good under 200 ms) and the Speed Index (how quickly the page fills visually; good under 3.4 s on mobile).
Top improvement opportunities
The list at the bottom gives the changes with the biggest estimated savings: images to compress, unused CSS or JavaScript, render-blocking resources. Start at the top.
What to fix first
- Server response time: if the server is slow, nothing else will be fast. Good hosting and page caching come first (see our guide to web hosting).
- The hero image: size, format, preload. It is often half of a poor LCP.
- Third-party scripts: each tracking tag, chat or widget costs responsiveness. Keep the useful ones and delay them.
- Layout stability: dimensions on images, reserved space for banners.
- The theme or the build: if a page builder or heavy theme is the cause, the lasting fix may be a lighter template or a rebuild (see WordPress or custom website).
Do Core Web Vitals affect rankings?
Yes, as part of Google’s page experience signals, but relevance still comes first: a slow page that answers the search perfectly can outrank a fast one that does not. Think of speed as a tie-breaker in search and as a strong factor in conversion: visitors leave slow pages before they read anything.
Frequently asked questions
Why is my score different every time I test?
Lab tests depend on network and server conditions at that moment; variations of a few points are normal. Compare averages of several runs, and rely on real user data when it is available.
My desktop score is great but mobile is poor. Why?
The mobile test simulates a slower processor and connection. Heavy images and JavaScript hurt much more there, and Google indexes the mobile version first.
How long before improvements show in the real user data?
The real user data covers the last 28 days, so changes appear gradually over about four weeks.
In short
Aim for LCP under 2.5 s, INP under 200 ms and CLS under 0.1 for three visits out of four. Fix the server and the hero image first, then scripts, then layout stability. Measure with our speed test, and if your website needs deeper work, our website development team builds fast websites from the start.
Sources
- web.dev, “Web Vitals”: web.dev
- web.dev, “Interaction to Next Paint becomes a Core Web Vital on March 12”: web.dev
- Google Search Central, “Understanding Core Web Vitals and Google search results”: developers.google.com