Core Web Vitals Data Study 2026: Lab Tests of 219 Websites

Key findings: On a throttled mobile profile, only 25.4% of 201 randomly sampled homepages had a good Largest Contentful Paint (≤ 2.5 s), while 80.6% had a good Cumulative Layout Shift (≤ 0.1). The median page blocked the main thread for 1.62 s (Total Blocking Time), and just 23.4% passed both LCP and CLS. Loading speed and main-thread work, not layout stability, are where most sites fail.

These are lab measurements: one controlled load per site under Lighthouse-style mobile throttling. They show how pages behave on a slow device and network, which is what most diagnostic tools (including PageSpeed Insights' lab section) report. For comparison, real-user field data from the Chrome UX Report is included below.

Method

Third-party sites in the sample aren't named.

Results: Lab Core Web Vitals on Mobile

The median homepage transferred 768 KB in 63 requests.

How lab compares with field data

Real-user data is kinder because most visitors have faster devices and networks than a 4×-throttled lab run. The HTTP Archive's 2024 Web Almanac performance chapter, based on Chrome UX Report field data, found:

CLS lines up closely between our lab sample (80.6%) and the field (79% mobile). LCP doesn't: 25.4% in our throttled lab run versus 59% of mobile origins in the field. That gap is the cost of a slow device and network, and the reason lab tests are good at finding problems that a share of your real users do hit.

Results by Front-End Framework

We matched each site with the framework detected in our raw-vs-rendered study of the same sample (groups with at least five sites):

Framework labels overlap (a Next.js site is also a React site), and some groups are small, so treat this as direction, not ranking. The pattern is still clear: pages that ship little JavaScript (Astro's default) loaded fastest, and JavaScript-heavy stacks carried the most main-thread blocking. See our Astro SEO guide and unused JavaScript statistics, where the median site shipped 55.9% unused JavaScript.

What the Data Says to Fix First

1. LCP is the most common failure. 57.2% were poor in the lab. Start with server response (half of sites had a TTFB over 800 ms on this profile) and the size and priority of the LCP resource. Our guide to improving LCP under 2.5 s walks through it.
2. Main-thread work is the second. Three quarters of pages had poor TBT, which predicts slow responses to the first taps. See INP explained.
3. CLS is mostly solved, but one in ten pages still shifted badly; reserve space for images, embeds and banners.

Measure Your Own Pages the Same Way

This script runs the study's lab profile against one URL:

"""Lab Core Web Vitals for one URL on a throttled mobile profile.

Same profile as the BugViso 219-site study: 412x823 mobile viewport, 4x CPU,
150 ms RTT, 1.6 Mbps down. Reports LCP, CLS, TBT, FCP and TTFB.
Usage:
  pip install playwright && python -m playwright install chromium
  python cwv_lab.py https://example.com/
"""
import sys
from playwright.sync_api import sync_playwright

INIT = """window.__v = {cls: 0, lt: []};
new PerformanceObserver(l => { for (const e of l.getEntries()) if (e.name === 'first-contentful-paint') __v.fcp = e.startTime; }).observe({type: 'paint', buffered: true});
new PerformanceObserver(l => { for (const e of l.getEntries()) __v.lcp = e.startTime; }).observe({type: 'largest-contentful-paint', buffered: true});
new PerformanceObserver(l => { for (const e of l.getEntries()) if (!e.hadRecentInput) __v.cls += e.value; }).observe({type: 'layout-shift', buffered: true});
new PerformanceObserver(l => { for (const e of l.getEntries()) __v.lt.push([e.startTime, e.duration]); }).observe({type: 'longtask', buffered: true});"""

COLLECT = """() => {
  let tbt = 0;
  for (const [s, d] of __v.lt) if (s + d > (__v.fcp || 0) && d > 50) tbt += d - 50;
  const nav = performance.getEntriesByType('navigation')[0];
  return {LCP: __v.lcp, CLS: __v.cls, TBT: tbt, FCP: __v.fcp, TTFB: nav ? nav.responseStart : null};
}"""
GOOD = {"LCP": 2500, "CLS": 0.1, "TBT": 200, "FCP": 1800, "TTFB": 800}


def main(url):
    with sync_playwright() as p:
        browser = p.chromium.launch()
        ctx = browser.new_context(viewport={"width": 412, "height": 823}, is_mobile=True, has_touch=True)
        ctx.add_init_script(INIT)
        page = ctx.new_page()
        cdp = ctx.new_cdp_session(page)
        cdp.send("Network.enable")
        cdp.send("Network.emulateNetworkConditions", {"offline": False, "latency": 150,
                 "downloadThroughput": 1.6 * 1024 * 1024 / 8, "uploadThroughput": 750 * 1024 / 8})
        cdp.send("Emulation.setCPUThrottlingRate", {"rate": 4})
        page.goto(url, wait_until="load", timeout=60000)
        page.wait_for_timeout(5000)
        m = page.evaluate(COLLECT)
        browser.close()
    for k, v in m.items():
        if v is None:
            print(f"{k:5} n/a")
            continue
        unit = "" if k == "CLS" else " ms"
        shown = f"{v:.3f}" if k == "CLS" else f"{v:.0f}"
        print(f"{k:5} {shown + unit:>10}  {'good' if v <= GOOD[k] else 'needs work'} (good <= {GOOD[k]}{unit})")


if __name__ == "__main__":
    main(sys.argv[1])

LCP      2550 ms  needs work (good <= 2500 ms)
CLS        0.000  good (good <= 0.1)
TBT       304 ms  needs work (good <= 200 ms)
FCP      2550 ms  needs work (good <= 1800 ms)
TTFB      842 ms  needs work (good <= 800 ms)

Run it three to five times and take the median; single lab runs vary.

How BugViso Measures Core Web Vitals

A BugViso audit captures LCP, CLS, INP (when an interaction occurs), FCP and TTFB with the same self-hosted web-vitals library, reloads the page under emulated Slow 3G and Fast 3G with CPU throttling, measures unused JavaScript and CSS through Chrome DevTools coverage, and attributes the worst long task to its script. When real-user CrUX data or a PageSpeed lab run is available, the score uses it and labels the source, so a lab number is never presented as field data.

You can see every rule BugViso applies in its Core Web Vitals checker.

Limitations

• Lab, not field. One throttled load per site; real users' devices and networks vary.
• Homepages only. Inner pages often perform differently.
• One location and machine. Network distance and the test machine's CPU affect absolute numbers; compare relative results.
• No INP. INP needs real interactions; TBT is reported as a stand-in for main-thread risk.

FAQ

What percentage of websites pass Core Web Vitals?

In real-user data from the 2024 Web Almanac, 43% of websites passed all three on mobile and 54% on desktop. In our throttled lab test, 23.4% of homepages had both a good LCP and a good CLS.

Which Core Web Vital fails most often?

LCP. In our lab sample, 57.2% of homepages had a poor LCP, compared with 10.9% for CLS.

Why do lab and field Core Web Vitals differ?

Lab tests use one fixed, deliberately slow profile. Field data aggregates real visitors, most of whom have faster devices and connections, at the 75th percentile.

Is lab data useful if Google uses field data?

Yes. Lab data reproduces problems on demand, so you can find and fix them; field data tells you how many real users are affected.

The Takeaway

Most sites pass on layout stability and fail on loading speed and main-thread work, which a BugViso performance audit breaks down page by page.