Core Web Vitals explained: a plain-English guide for business owners
Three numbers decide whether Google sees your site as fast, responsive and stable. Here is what LCP, INP and CLS mean, the thresholds to hit, how to read your report and what to ask your developer to fix.
By the Zuptek team · Published 31 October 2026
Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors. Largest Contentful Paint (LCP) measures loading and should be 2.5 seconds or less. Interaction to Next Paint (INP) measures responsiveness and should be 200 milliseconds or less. Cumulative Layout Shift (CLS) measures visual stability and should be 0.1 or less.
If you own a business website, you have probably seen a red or orange score in PageSpeed Insights, or an email from Search Console about “poor URLs”. This guide has Core Web Vitals explained without the jargon: what each metric means for a customer on a phone, the current pass thresholds, how Google actually measures them, how much they matter for rankings, and the specific fixes to ask your developer for. It is written for owners and marketers, not engineers. If you would rather have someone check your site, our website development team includes a Core Web Vitals review in every free audit.
Key takeaways
- The three Core Web Vitals in 2026 are LCP (loading), INP (responsiveness) and CLS (visual stability). INP replaced First Input Delay (FID) on 12 March 2024.
- A page passes when 75% of real visits meet the “good” threshold for all three: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less.
- Google judges your site on field data from real Chrome users over the last 28 days, not on a single PageSpeed test score.
- Good Core Web Vitals support rankings but do not replace relevance and content. Their bigger payoff is usually more enquiries and sales from the same traffic.
- Most failures come from a handful of causes: slow hosting, heavy hero images, too many scripts and plugins, and images or banners without reserved space.
What are Core Web Vitals?
Core Web Vitals are part of Google’s wider idea of page experience. Each one answers a question a visitor asks without thinking about it:
| Metric | Visitor’s question | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|---|
| Largest Contentful Paint (LCP) | “Is this page loading?” | Time until the largest image or text block in view is shown | 2.5 s or less | 2.5 s to 4 s | Over 4 s |
| Interaction to Next Paint (INP) | “Did my tap work?” | Delay between a tap, click or key press and the screen visibly responding | 200 ms or less | 200 ms to 500 ms | Over 500 ms |
| Cumulative Layout Shift (CLS) | “Why did that jump?” | How much content moves around unexpectedly while the page is used | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Thresholds are from Google’s web.dev documentation for LCP, INP and CLS. Search Console uses the same bands.
Largest Contentful Paint: does the page load fast enough?
LCP is the moment the main thing on screen appears. On most business sites that is the hero image, a banner, or the main heading paragraph. According to web.dev’s LCP guide, the elements that count include images, video elements, elements with a CSS background image and block-level text elements.
LCP also includes everything that happens before the page starts drawing: redirects, the connection to your server and the server’s response time. That is why cheap hosting and long redirect chains hurt LCP even when the page itself is light.
Interaction to Next Paint: does the page respond when tapped?
INP measures how quickly the page reacts when someone does something. The web.dev INP guide is specific: only mouse clicks, taps on a touchscreen and key presses count. Scrolling, hovering and zooming do not. Each interaction has three parts: the input delay before the browser can start handling it, the processing time of the code that runs, and the presentation delay before the next frame is shown.
INP looks at interactions across the whole visit, not just the first one. That is why it replaced First Input Delay, which only measured the first interaction. Google confirmed that INP officially became a Core Web Vital and replaced FID on 12 March 2024.
In practice, poor INP shows up as a menu that takes a moment to open, a form field that lags while typing or an “Add to cart” button that seems to do nothing. The usual cause is too much JavaScript: chat widgets, tracking scripts, sliders and page builder add-ons all competing for the phone’s processor.
Cumulative Layout Shift: does the page stay still?
CLS scores how much visible content moves unexpectedly. You have experienced it: you go to tap a link and an advert or cookie banner pushes it down, so you tap the wrong thing. The web.dev CLS guide explains that a shift is only bad if the user is not expecting it. Shifts within 500 milliseconds of a tap, click or key press are excluded, because the visitor caused them.
CLS groups shifts into “session windows” of up to five seconds and reports the worst window. Common causes are images or videos without set dimensions, web fonts that render at a different size from the fallback font, and ads, embeds or widgets that resize themselves after loading.
Core Web Vitals explained: how does Google measure them?
This is the part most business owners miss, and it explains why your developer and your Search Console report can disagree.
Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report (CrUX). PageSpeed Insights shows this data for the previous 28-day collection period. This is what Google uses to assess your pages.
Lab data comes from Lighthouse running one simulated test. The 0 to 100 performance score in PageSpeed Insights is lab data. Google describes lab data as useful for debugging, because it is collected in a controlled environment, but it is not what your real visitors experienced.
Three rules decide whether you pass:
- The 75th percentile. A page passes a metric when at least 75% of visits meet the “good” threshold. A fast test on office Wi-Fi does not help if a quarter of your customers are on slower phones and patchy 4G.
- Mobile and desktop are assessed separately. If most of your visitors arrive on phones, as they do for many consumer-facing businesses, the mobile result is the one to watch.
- All three must be good. In the Search Console Core Web Vitals report, a group of similar URLs takes the status of its worst metric. Good LCP and CLS with poor INP means the group is “Poor”.
Search Console groups pages that share a template, such as all blog posts or all product pages, so one fix to a template can move hundreds of URLs at once. Low-traffic sites may not have enough field data to appear in the report at all. In that case use the lab data as a guide and judge by how the site feels on a mid-range Android phone.
Do Core Web Vitals affect Google rankings?
Yes, but less than many sales pitches suggest. Google’s Core Web Vitals documentation for Search says it highly recommends site owners achieve good Core Web Vitals for success with Search, and that they, along with other page experience aspects, align with what Google’s core ranking systems seek to reward. Google does not present them as a shortcut to page one. A slow page with exactly the answer a searcher needs can still outrank a fast page with thin content.
The stronger business case is conversion. In a Vodafone A/B test published on web.dev, an optimised landing page with a 31% better LCP (5.7 seconds against 8.3 seconds) produced 8% more sales, a 15% better lead-to-visit rate and an 11% better cart-to-visit rate than the unoptimised version. The changes were ordinary ones: less render-blocking JavaScript, server-rendered critical HTML and smaller, better-handled images. Results will differ for every site, but the direction is consistent: when pages load and respond faster, more visitors finish what they came to do. That matters most on paid traffic, where you have already paid for every click. Our landing page design work is built around this.
How to check your Core Web Vitals in 15 minutes
- Open Search Console and go to Experience, then Core Web Vitals. Look at the mobile report first. Note how many URLs are Poor, Need improvement and Good, and which metric is the problem.
- Click into an issue (for example “LCP issue: longer than 2.5 s (mobile)”) to see example URLs and the template they belong to.
- Run that example URL through PageSpeed Insights. The top section shows field data for the URL or the whole site. The lower section shows lab diagnostics with specific suggestions.
- Test on a real phone. Open the page on a mid-range Android phone over mobile data. Watch for the hero image arriving late, buttons that lag and content that jumps.
- Write down the template, the failing metric and the likely cause before talking to your developer. “Service page template fails LCP because the hero image is 1.8 MB” is a brief anyone can act on.
After a fix goes live, you can click “Start tracking” on the issue in Search Console. Google then monitors for 28 days. If the issue is not present during that window, it is marked fixed. Starting tracking does not trigger a recrawl; it only starts the clock.
What usually causes poor scores, and what to ask for
| Symptom | Likely causes | Fixes to ask your developer for |
|---|---|---|
| Poor LCP | Slow server response; huge hero images; slider as hero; render-blocking CSS and JavaScript; hero image lazy-loaded | Better hosting or server caching; compress and resize the hero, serve WebP or AVIF; replace sliders with one static image; load the hero image early, never lazy-load it; defer non-critical scripts |
| Poor INP | Too many third-party scripts; heavy page builder widgets; chat, popup and tracking tools all loading at once; long JavaScript tasks | Remove unused plugins and widgets; load chat and non-essential tags after interaction; trim tracking to what you use; break up long tasks |
| Poor CLS | Images and embeds without width and height; cookie or offer banners inserted at the top; late-loading web fonts; ads | Set dimensions on all media; reserve space for banners and embeds; preload fonts and use matching fallbacks; place banners as overlays at the bottom |
On WordPress, a few patterns cause most problems: cheap shared hosting, 30 or more plugins, a multipurpose theme loading features you never use, and uncompressed images uploaded straight from a phone. A custom-coded site can fail for the same reasons, plus heavy client-side JavaScript. Platform choice matters less than build discipline, as we explain in WordPress vs custom-coded websites.
A Core Web Vitals checklist for business owners
Use this before you approve a new site, a redesign or a monthly report:
- [ ] The Search Console Core Web Vitals report for mobile shows mostly Good URLs, or a plan exists for each Poor group.
- [ ] Field data for the home page and main service or product templates meets all three thresholds.
- [ ] The hero image on key pages is under a few hundred kilobytes, in a modern format and not lazy-loaded.
- [ ] No auto-playing sliders above the fold.
- [ ] Chat widgets, popups and non-essential tracking load after the main content.
- [ ] Every image, video and embed has fixed dimensions or reserved space.
- [ ] Hosting has server-level caching and a server location close to your customers.
- [ ] Plugins and scripts are listed, and each one has a clear purpose.
- [ ] Speed is re-checked after every major update, new plugin or new marketing tag.
If you want this handled end to end, our website speed optimisation service fixes the causes on real phones and reports before and after field data, and our technical SEO service covers crawling, indexing and structured data alongside speed.
Frequently asked questions
What are the three Core Web Vitals in 2026?
The three Core Web Vitals are Largest Contentful Paint (LCP), which measures loading; Interaction to Next Paint (INP), which measures how quickly the page responds to taps, clicks and key presses; and Cumulative Layout Shift (CLS), which measures how much content moves unexpectedly. INP replaced First Input Delay as a Core Web Vital on 12 March 2024.
What is a good Core Web Vitals score?
A page is good when, for at least 75% of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. Poor means LCP over 4 seconds, INP over 500 milliseconds or CLS over 0.25. Anything in between needs improvement. All three must be good for the page to pass.
Why is my PageSpeed score different from Search Console?
The PageSpeed performance score comes from one simulated Lighthouse test, while Search Console uses field data from real Chrome users over 28 days. A site can score well in the lab and still fail in the field because real visitors use slower phones and networks. Google assesses Core Web Vitals on field data, so trust Search Console first.
Are Core Web Vitals a ranking factor?
They are part of the page experience signals that Google’s ranking systems reward, and Google recommends achieving good scores. They do not outweigh relevance and content quality, so fixing them alone will not lift a weak page to the top. Their more reliable benefit is that faster, stable pages convert more of the visitors you already have.
How long does it take for Core Web Vitals fixes to show?
Field data covers a rolling 28-day window, so improvements appear gradually over about four weeks after the fix goes live. In Search Console you can start tracking a fixed issue, and Google monitors it for 28 days before marking it fixed. Lab tests in PageSpeed Insights show the effect of a change immediately.
Can a WordPress site pass Core Web Vitals?
Yes. WordPress sites fail mostly because of slow hosting, heavy themes, too many plugins and oversized images, not because of WordPress itself. A lean build with server-level caching, compressed images, few plugins and deferred third-party scripts can pass all three metrics on mobile.
Want to know which of your pages fail, and why? Our website development team will check your field data, test your key templates on a real phone and send you a prioritised fix list. Request a free audit or contact us.