A page can score 100 on Lighthouse and still fail Core Web Vitals for real visitors. That gap — between what a synthetic lab test measures and what actual users experience — is the single most misunderstood part of web performance work, and it's the reason so many sites chase the wrong number. Here's what the field data actually shows in 2026, why it diverges from lab scores, and how to close the gap that matters.
The three metrics, quickly
Core Web Vitals is Google's standardized set of three user-experience metrics:
- LCP (Largest Contentful Paint) measures loading speed — specifically, how long it takes the largest visible element (usually a hero image, video, or block of text) to render. "Good" is under 2.5 seconds.
- INP (Interaction to Next Paint) measures responsiveness — how long the page takes to visually respond after a user clicks, taps, or types. "Good" is under 200 milliseconds. INP replaced the older First Input Delay (FID) metric as the responsiveness signal.
- CLS (Cumulative Layout Shift) measures visual stability — how much content unexpectedly shifts around as a page loads. "Good" is under 0.1.
All three are evaluated at the 75th percentile of real visits — meaning 75% of a page's visits need to fall in the "good" range for the page to pass overall. That threshold, and the underlying real-visit requirement, is where lab testing and field reality start to diverge.
Lab data vs. field data — and why they disagree
Lab data comes from synthetic, controlled tests — Lighthouse (built into Chrome DevTools and PageSpeed Insights) is the most common tool. It runs your page once, on a simulated device and network connection, under conditions you or the tool define. It's fast, repeatable, and excellent for debugging a specific change before you ship it.
Field data comes from the Chrome User Experience Report (CrUX) — real, anonymized performance data collected from actual Chrome users who've opted into sharing usage statistics, aggregated over a rolling 28-day window. This is the data Google Search Console reports, and critically, it's the data Google actually uses as a ranking signal — not your Lighthouse score.
The two disagree constantly, and for understandable reasons: your lab test runs on one device, one network condition, one geography, once. Your real users are on a mix of five-year-old Android phones on patchy 4G and brand-new iPhones on fiber, in dozens of countries, with browser extensions, ad blockers, and background tabs all competing for the same CPU. A page that loads in 1.2 seconds in a lab test on a fast connection can easily land at 4+ seconds for the slower half of your real traffic — and it's that real distribution, not your best-case lab number, that determines whether you pass.
The practical rule of thumb that's emerged from this: use lab tools like Lighthouse and PageSpeed Insights for diagnosis — pinpointing what's slow and verifying a fix worked — but validate against Search Console's Core Web Vitals report, which reflects real CrUX field data, before declaring victory. A green Lighthouse score with a red field-data report means you've fixed something that wasn't the actual bottleneck for real users.
What the current field data actually shows
Aggregate CrUX data paints a picture that should reset expectations for anyone assuming Core Web Vitals is a solved problem industry-wide. INP is the most commonly failed metric — current data puts roughly 43% of sites failing the 200ms threshold, making responsiveness the dominant weak spot for most sites, more so than loading speed. LCP remains stubbornly difficult too: roughly 62% of mobile sites currently have "good" LCP scores (around 68% across all device types combined), meaning a meaningful chunk of the web is still failing a metric that's been a ranking factor for years.
CLS, by contrast, tends to be the easiest of the three to fix once identified — most CLS problems trace back to a small number of well-understood causes (images or ads without reserved dimensions, web fonts causing text reflow, content injected above existing content) that have known, mechanical fixes.
The pattern across all this data is consistent: responsiveness (INP) and loading (LCP) are where most sites are still losing points, while visual stability (CLS) is comparatively solved once a team knows what to look for.
Fixing LCP in the real world
Since LCP is about the largest visible element rendering fast, the fix depends on what that element is:
- If it's an image: serve it in a modern format (WebP or AVIF), size it correctly for the viewport rather than shipping an oversized file the browser has to scale down, and — critically — don't lazy-load it. The LCP image is, by definition, visible immediately; lazy-loading it delays the exact render you're trying to speed up.
fetchpriority="high"on the LCP image is a small, high-leverage hint that tells the browser to prioritize it over other resources. - If it's a font-heavy hero text block: avoid render-blocking web font requests, or use
font-display: swapso text renders in a fallback font immediately rather than waiting invisibly for a custom font to download. - Across the board: a slow server response time (Time to First Byte) delays everything downstream, including LCP — this is where CDN placement, server-side caching, and reducing backend processing time on the critical path pay off disproportionately, because they move the starting line for every other optimization.
Fixing INP in the real world
INP being the most commonly failed metric in 2026 isn't an accident — it's a harder problem than LCP because it depends on what happens after load, often driven by JavaScript that keeps executing long after the page appears finished. Common culprits:
- Long tasks blocking the main thread. Any JavaScript execution over 50ms blocks the browser from responding to user input during that window. Breaking large scripts into smaller chunks (via
requestIdleCallback,setTimeoutscheduling, or the newerscheduler.yield()API) lets the browser interleave user interactions between chunks of work instead of freezing until a big task finishes. - Heavy event handlers. Click and input handlers that do expensive synchronous work — large DOM updates, layout recalculation, unoptimized state management re-renders in frameworks like React — directly inflate INP, since the metric measures the gap between interaction and the next visual update.
- Third-party scripts. Ad tech, analytics, chat widgets, and tag manager containers are frequent, underappreciated INP culprits, because they run on the same main thread as your own code and often aren't under your direct control. Auditing what third-party scripts are actually loaded — and deferring or removing ones that aren't earning their keep — is often the single highest-leverage INP fix available, precisely because it requires no engineering work on your own codebase.
Fixing CLS in the real world
- Always set explicit
widthandheightattributes (oraspect-ratioin CSS) on images and video embeds, so the browser reserves the correct space before the asset loads. - Reserve space for ad slots and dynamically injected content (cookie banners, promotional bars) rather than letting them push content down after the fact.
- Avoid inserting new content above existing content unless it's in direct response to a user interaction (a "load more" click is fine; an unprompted layout shift while someone is reading is not).
Why the 75th percentile trips people up
A subtlety that catches a lot of teams off guard: passing Core Web Vitals doesn't mean your average visit is good — it means the 75th-percentile visit is good, which is a meaningfully stricter bar. If your median visitor gets a snappy 1.8-second LCP but your slowest quarter of visitors — often on older devices, slower networks, or in geographies farther from your server — see 4+ seconds, the page fails, even though "most" visits by a simple average would look fine. This is precisely why the lab test on a fast office connection is such a misleading proxy: it approximates your fastest visitors, not the tail that determines pass/fail.
It also means fixing Core Web Vitals is disproportionately about fixing your worst experiences, not your best ones. A team that spends a sprint shaving another 200ms off an already-fast 1.5-second LCP while ignoring a segment of mobile users hitting 5+ seconds is optimizing the wrong end of the distribution. Segmenting CrUX or Real User Monitoring data by device type, connection speed, and geography — most RUM tools and even Search Console's own breakdown support this — is how you find where the real percentile-75 problem actually lives.
Mobile-first reality
Because Google's indexing and most Core Web Vitals evaluation is mobile-first, and because mobile devices are inherently more variable in processing power and network quality than desktop, mobile performance tends to be the harder and more consequential half of the problem. A site that performs excellently on desktop can still fail Core Web Vitals overall if its mobile experience — often running the same heavy JavaScript bundle on a mid-range Android phone with a fraction of a modern laptop's CPU — lags behind. Testing exclusively on a developer's own high-end phone or laptop is one of the most common reasons real-world mobile performance surprises teams after launch; CPU throttling settings in Lighthouse (which simulate a slower device) exist specifically to correct for this blind spot, and it's worth using them deliberately rather than trusting an untouched default lab run.
Measuring what matters
For any business tracking this seriously, the workflow that field data implies is: monitor Search Console's Core Web Vitals report (or a Real User Monitoring tool wired to your own analytics) as the source of truth, use PageSpeed Insights or Lighthouse locally to debug and validate specific fixes before shipping, and specifically watch the URL groups Search Console flags — Google groups similar pages together, so a template-level fix (a shared header component, a shared hero image pattern) often resolves dozens of URLs' worth of failing scores at once rather than requiring a page-by-page chase.
It's also worth remembering that Core Web Vitals feed into a broader page experience signal in ranking, not a hard gate — a page with excellent content and a mediocre CLS score will usually still outrank a fast page with thin content. But among pages that are otherwise comparable, the field-data performance gap is a real, measurable tiebreaker, and it directly affects conversion rates independent of SEO: slow, janky pages lose visitors regardless of where they rank.
If your site runs any kind of interactive widget — a chat assistant, a qualifying form, a document upload tool — it's worth specifically checking that widget's script against INP and LCP impact, since third-party and embedded scripts are a disproportionately common cause of real-world performance regressions that never show up in a quick lab test run before launch.
Sources:
Get new posts as they publish
No spam — just the next post, straight to your inbox.