The Essentials
- Three thresholds: Google considers a page good when LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 (web.dev: LCP, 2024).
- INP replaces FID: Since March 12, 2024, Interaction to Next Paint has replaced the old FID value as the official Core Web Vital metric (web.dev: INP launch, 2024).
- Only 43 percent of mobile sites pass: According to the HTTP Archive Web Almanac 2024, with INP included, only 43 percent of mobile origins meet all three vitals; on desktop, it is 54 percent (HTTP Archive: Almanac 2024 Performance, 2024).
- Mobile-first pays off: Mobile origins perform noticeably worse than desktop. If you honestly measure your setup at the 75th percentile of mobile field data, you will spot the optimization headroom directly in the Search Console Core Web Vitals report.
Optimizing Core Web Vitals is not about polishing microseconds. It is about hitting three clear thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. According to the HTTP Archive Web Almanac 2024, only 43 percent of mobile origins clear that bar, and 54 percent on desktop. Teams that measure cleanly and prioritize ruthlessly secure a measurable ranking and conversion advantage.
What are Core Web Vitals in 2026, really?
Core Web Vitals are three user-centric performance metrics Google uses to measure the real experience on a page. As of 2026, those are LCP, INP and CLS. INP has officially replaced the older FID value since March 12, 2024. The data comes from the Chrome User Experience Report, meaning real browser sessions, not lab numbers.
Important: Google evaluates the 75th percentile. That means three out of four of your visitors must experience the thresholds, not just the average. This definition is stated in the official web.dev articles on LCP. It also explains why good lab values can still produce a red PageSpeed report.
The vitals are also part of the broader Page Experience signal from Google. They do not work in isolation. Secure HTTPS, mobile friendliness and intrusive interstitials all count.
Which three metrics you need to know
Three values, three questions.
LCP, short for Largest Contentful Paint, answers: when does the user see the main content? Usually that is a hero image, a headline or a banner. Target value: 2.5 seconds or faster.
INP, Interaction to Next Paint, measures responsiveness across the entire session. Click, tap, keyboard input. Maximum target: 200 milliseconds.
CLS, Cumulative Layout Shift, checks visual stability. Does the button jump away during loading? Does text shift because of late-loading ads? Acceptable values are ≤ 0.1, documented on web.dev: CLS.
How do I measure Core Web Vitals correctly?
The most reliable source is field data from the Chrome User Experience Report (CrUX). It reflects what real users experienced over the past 28 days, evaluated at the 75th percentile. Lab tools like Lighthouse, by contrast, simulate a single device under default conditions. Both belong together, but for Google what counts is the CrUX field data, including the documented 28-day methodology.
In my performance audits at Evelan, I see the same mistake again and again: teams optimize until Lighthouse turns green and then wonder why Search Console still reports "needs improvement." The reason is the 75th percentile across real devices, not a single test on a fast laptop.
Which tools do I actually use?
A pragmatic stack selection for small to mid-sized businesses:
- PageSpeed Insights for fast diagnostics. Delivers field and lab data in one view.
- Google Search Console, "Core Web Vitals" section. Here you see aggregated URL groups with status "poor," "needs improvement," "good."
- Lighthouse or the DevTools Performance panel in Chrome for the deep analysis of a single page.
- CrUX Dashboard or the CrUX API for trend lines over several months.
The key is not to keep switching between tools. Pick one source as your "single source of truth," typically Search Console, and use Lighthouse only to test specific hypotheses. If you want to go deeper into how speed affects conversions, the article Lightning-Fast Website Turns Visitors Into Buyers offers additional case numbers from our practice.
Which values are actually good in 2026?
The official threshold table has not changed since the INP launch in March 2024. Google distinguishes three rating tiers per metric and checks the 75th percentile separately for mobile and desktop. Source: web.dev/articles/lcp, web.dev/articles/inp, web.dev/articles/cls.
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s | ≤ 4.0 s | > 4.0 s |
| INP | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS | ≤ 0.1 | ≤ 0.25 | > 0.25 |
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s | ≤ 4.0 s | > 4.0 s |
| INP | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS | ≤ 0.1 | ≤ 0.25 | > 0.25 |
A page must score "good" on all three values for Google to mark the URL group as "good" overall. That raises the bar. According to the HTTP Archive Web Almanac 2024, with INP in scope, only 43 percent of mobile origins meet all three values, and 54 percent on desktop.
What many overlook: "needs improvement" is not a neutral middle ground. Google treats it like a warning in Search Console reports. If you sit in that zone permanently, you lose ground in competitive keywords against faster-optimized competitors. Practically speaking: aim consistently for the green band, not the yellow one.
Why does Google reward fast pages in the first place?
Google wants to get users to a result quickly. A page that takes three seconds noticeably loses clicks and conversions. The official PageSpeed Insights documents show how tightly load time, bounce rate and visibility are linked. A slow page does not lose users only after seconds; it loses them in the first fractions of a second. That directly changes search income.
This creates a double effect. First, Core Web Vitals feed into the Page Experience signal, which is a documented ranking signal. Second, fast pages influence dwell time, bounce and conversion. Both effects reinforce each other, but they are measurable independently.
What does this mean for SMB websites?
From more than 60 SMB projects, I know this: pushing LCP down by one second typically produces an immediate improvement in click-through rate from Google Discover and Mobile Search. Individually, the effects are not spectacular, but they add up across quarters. B2B sites with long sales cycles benefit most, because returning visitors perceive the faster site as "higher quality."
There is also an aspect many underestimate. Performance is a proxy for diligence. A page that loads with a hero image, clean typography and no layout jumps signals competence before the first word is read. The effect is especially strong in B2B, where decisions rarely happen on the first visit.
What are the most common causes of poor Core Web Vitals?
Three causes show up at the top of my audits over and over: unoptimized images, JavaScript overhead and a slow server. Addressing those three areas typically covers the biggest bottlenecks before you start fine-tuning details. The official optimization guides Optimize LCP and Optimize INP on web.dev name the same key topics: Time to First Byte, render-blocking scripts, large images and long main thread tasks.
How do images and media affect things?
Unoptimized hero images are the most frequent LCP killer. A 3 MB JPEG straight out of a DSLR camera measurably blocks rendering. Solution: modern formats like AVIF or WebP, correct srcset directives, lazy loading for images below the fold and the fetchpriority attribute set to "high" for the LCP element.
Video embeds also have an impact. An embedded YouTube player loads several hundred kilobytes of JavaScript before anything visible happens. A lite-embed variant with click-to-load is usually the better choice.
How much damage do scripts and plugins really cause?
JavaScript is the biggest factor for INP. Every unused tracking script, every chat widget loader, every A/B test snippet blocks the main thread. Result: clicks feel sluggish, INP slips above 200 milliseconds.
Concrete levers: cut third-party scripts to the minimum, build your consent layer so non-essential scripts only load after approval, and lazy-load heavy components via code splitting. We almost always see the impact in the Search Console report on the same day. If you want a deeper technical look, the comparison Headless CMS vs. Classic CMS explains why modern architectures simplify INP control.
What role does hosting play?
A slow server response directly affects LCP, because the browser cannot render anything before the HTML arrives. A TTFB above 800 milliseconds is a warning sign. Common causes: cheap shared hosting, no CDN, no HTTP/2 or HTTP/3, no server-side cache. The easy win is often a switch to edge hosting like Vercel, Netlify or a dedicated cloud server with Cloudflare in front.
Why does Google separate mobile and desktop?
Google evaluates both device classes separately in the Search Console report. That is not a detail. According to the HTTP Archive Web Almanac 2024, the share of mobile origins that pass all three vitals is significantly lower than on desktop. Mobile hardware is slower, mobile networks fluctuate, and touch interactions need to be assessed differently from mouse clicks.
In practice, this means a page can be glowing green on desktop and fail on mobile. In my audit work, that is the rule, not the exception. Anyone who takes CWV seriously optimizes mobile-first and uses desktop values only as a sanity check.
Which devices does the CrUX dataset cover?
The Chrome User Experience Report aggregates anonymized field data from Chrome users who opted into telemetry. It is split by form factor (phone, tablet, desktop) and connection speed. If your offering is primarily B2B, you should still not ignore the mobile values. Research and first contact increasingly happen on the smartphone, even if the final conversion lands on desktop.
How do I optimize Core Web Vitals step by step?
There is a proven sequence I recommend to every SMB owner: measure, prioritize, biggest lever first, then verify. Without a baseline measurement, you are optimizing blind. Without prioritization, you scatter your effort. Without verification, you do not know whether the change actually worked. As a diagnostic tool, I use PageSpeed Insights as the default first stop, because it combines field and lab data in one view.
Step 1: Capture an honest baseline
Note the current LCP, INP and CLS values at the 75th percentile for each page type (home page, product page, category, blog). Source: Search Console or the CrUX Dashboard, not Lighthouse. This baseline is your reference point for every change.
Step 2: Fix images and the LCP element
The LCP lever is usually the biggest and the fastest to implement. Compress the hero image, convert it to AVIF or WebP, serve correct dimensions, set the fetchpriority attribute to "high," and serve web fonts with the font-display strategy "swap." One week of work, often one second saved on LCP.
Step 3: Reduce JavaScript load
Inventory all third-party scripts. Cut everything not actively used. Move tracking behind the consent layer. Lazy-load heavy components like chat widgets, maps or tabs. Expected effect: INP often drops by 100 to 300 milliseconds.
Step 4: Seal CLS sources
Reserve space for images via width and height attributes, for ads via CSS aspect ratio, and for embedded content via a fixed container. Most CLS problems disappear with three to five targeted CSS changes.
Step 5: Establish monitoring
Optimization without monitoring reliably leads to regression. Plugins get added, tracking gets retrofitted, a new image slips into the hero. After just three months, the old values are back. My suggestion: a weekly look at the Core Web Vitals report in Search Console and a monthly comparison of CrUX values per page type.
For larger sites, automated real user monitoring (RUM) is worth setting up, capturing field data directly from your own tag. That gives you an early warning system that does not lag by 28 days. If you want to combine this with solid SEO fundamentals, the article SEO Basics: How to Make Your Website Visible provides the strategic context.
Which measures bring little or nothing?
Because performance consulting is its own market, recommendations circulate that create more effort than impact for SMBs. Three examples from audits that come up regularly.
First: generic "speed plugins" for WordPress. They often bundle many features that make sense individually but, taken together, add complexity and conflict potential. Without a clear diagnosis of which lever actually matters, busy-work becomes the trap.
Second: HTTP/3 as a standalone solution. Modern protocol tuning saves a few milliseconds of TTFB on average, so it is no substitute for structural changes to images or scripts. It is the cherry on top, not the foundation.
Third: premature server upgrades. If you are stuck on a weak plan, yes, switch. But trying to solve an LCP problem with a "bigger machine" while leaving hero image and JavaScript untouched usually buys you only a few percent of improvement for a lot of money. The order stays the same: review content, optimize code, then scale infrastructure.
From Evelan's Practice
A holiday resort in northern Germany on the Baltic coast came to us with classic symptoms: heavy gallery images straight from a DSLR camera, a WordPress builder with eight active plugins, a booking widget loading via iframe right in the header. The LCP value in Search Console sat stably above 4 seconds on mobile, CLS at 0.28. The result: heavily fluctuating conversion rate despite growing organic reach.
We migrated the stack to a headless setup, converted images to AVIF and served them with correct srcset attributes, placed the booking widget behind a click-trigger and removed non-essential plugins. After three weeks, LCP at the 75th percentile was 1.9 seconds, CLS at 0.04. No new relaunch needed, only a focused performance sprint on the existing content.
Frequently Asked Questions
Google evaluates a page at the 75th percentile. "Good" means LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. The values are documented in the official web.dev articles and have not changed since the INP launch in March 2024. A page must hit all three thresholds to count as "good" overall.
Related Evelan Articles
- Lightning-Fast Website Turns Visitors Into Buyers
- SEO Basics: How to Make Your Website Visible
- Spot SEO Mistakes and Effectively Optimize Your Website
- Headless CMS vs. Classic CMS
Sources
- Google web.dev: Largest Contentful Paint (LCP) (2024)
- Google web.dev: Interaction to Next Paint (INP) (2024)
- Google web.dev: Cumulative Layout Shift (CLS) (2024)
- Google web.dev: INP is now a Core Web Vital (2024, Blog)
- Google Search Central: Page Experience (2024)
- HTTP Archive: Web Almanac 2024, Performance Chapter (2024)
- Chrome for Developers: CrUX Methodology (2024, Documentation)
- Google: PageSpeed Insights (2024, Tool)
