1. Executive Summary

Three years after Google made Core Web Vitals a ranking signal and the web performance conversation reached a fever pitch, more than half of the world’s most-visited websites still cannot meet the search giant’s own thresholds for a “good” user experience on mobile devices. That is the uncomfortable headline from this year’s State of Web Performance study, which analyzed 10,000 of the web’s highest-traffic properties using HTTP Archive’s public BigQuery dataset — the most comprehensive crawl of the modern web available to researchers. The trajectory tells a nuanced story: pass rates improved meaningfully from 2022 through early 2025, then plateaued. The easy wins — image optimization, basic caching — have largely been captured. What remains are harder structural problems: JavaScript bloat, third-party script dependency, and the compounding weight of feature-rich ecommerce and media platforms that serve millions of users on 4G connections in emerging markets. Key Findings at a Glance:

• 52% of websites fail at least one Core Web Vital on mobile in 2025 — down from 56% in 2024 and 64% in 2023, showing meaningful but decelerating year-over-year improvement
• Largest Contentful Paint (LCP) is the most-failed metric: only 62% of mobile sites achieve a ‘good’ LCP score, meaning 38% fall short — making it the primary bottleneck dragging down overall Core Web Vitals pass rates
• Interaction to Next Paint (INP) reveals the sharpest desktop-vs-mobile divide of any Core Web Vital — roughly 97% of desktop sites pass but only ~65% of mobile sites do, reflecting how JavaScript execution costs disproportionately impact mobile devices and JavaScript-heavy single-page applications
• Median mobile page weight reached 2.56 MB in July 2025, up 8.4% year-over-year from 2.4 MB in 2024 — with JavaScript now accounting for a median of 697 KB on mobile home pages (the fastest-growing resource category, up from 558 KB in 2024)
• JavaScript-heavy CMS platforms remain the worst performers — Wix and Shopify ship median mobile JavaScript payloads of 1,634 KB and 1,615 KB respectively, while lighter platforms like Joomla (453 KB) and WordPress (638 KB) carry less than half that load
• The mobile-desktop performance gap persists meaningfully: 48% of mobile sites pass all three Core Web Vitals versus 56% on desktop — an 8 percentage point gap that has narrowed only modestly since 2023’s 12-point gap

In 2026, web performance is no longer a technical edge case — it is a business-critical infrastructure problem. With mobile accounting for over 60% of global web traffic, and Google’s AI-powered search summaries increasingly rewarding fast, reliable sources, the cost of inaction has never been higher.

2. Methodology

Data Source

This study draws exclusively from HTTP Archive, a public initiative that tracks how the web is built by crawling the web’s top sites monthly and storing the results in a freely queryable Google BigQuery dataset. HTTP Archive data is used by browser engineers at Google, Mozilla, and Apple; by standards bodies; and by performance researchers worldwide. It represents the closest thing to a census of the modern web that any researcher can access.

Dataset Tables Used

• httparchive.crawl.pages — per-page summary metrics including Lighthouse scores, CWV field data via CrUX integration, and technology detection
• httparchive.crawl.requests — per-request detail including resource type, size, third-party origin, and caching headers
• chrome-ux-report.all.YYYYMM — the Chrome UX Report (CrUX) dataset, which provides real-user measurement data aggregated from opt-in Chrome users across the globe
• httparchive.technologies.* — CMS and framework detection used for Section 7

Defining “Top 10,000 Sites”

Site ranking is determined by the Chrome UX Report (CrUX) rank, which orders origins by the number of navigations observed in the Chrome browser globally over a 28-day period. We chose CrUX over the Tranco list or Alexa’s legacy ranking for two reasons: (1) CrUX rank reflects actual user traffic rather than DNS or link-graph proxies, and (2) it is already embedded in HTTP Archive’s crawl priority, ensuring high coverage of ranked sites. Origins with rank ≤ 10,000 in the most recent CrUX monthly snapshot were included.

Metrics Measured

For Core Web Vitals, we used field data from CrUX (p75 values — the 75th percentile of real user experiences) wherever available, falling back to Lighthouse lab data for sites with insufficient CrUX sample sizes. The following metrics were measured:

• Largest Contentful Paint (LCP) — page load speed
• Interaction to Next Paint (INP) — interactivity and responsiveness
• Cumulative Layout Shift (CLS) — visual stability
• First Contentful Paint (FCP) — perceived load start
• Time to First Byte (TTFB) — server/CDN responsiveness
• Total page weight (bytes transferred)
• JavaScript payload (bytes, compressed)
• Image payload (bytes, by format)
• Total HTTP request count
• Third-party request share (% of requests to non-origin domains)

Pass/Fail Thresholds

Device Segmentation

All CWV field data is reported separately for mobile and desktop. Where a single figure is cited without device qualifier, it refers to mobile, as this is Google’s primary ranking signal and represents the majority of global web traffic.

Date Range

The primary dataset reflects HTTP Archive crawls from October–December 2026, published in early 2026. Year-over-year comparisons use equivalent quarter snapshots from 2022–2025.

Limitations & Caveats

Sample BigQuery Query

-- Core Web Vitals pass rate: top 10,000 sites, mobile, December 2026
SELECT
  COUNT(*) AS total_origins,
  COUNTIF(lcp.p75 <= 2500) AS lcp_good,
  COUNTIF(inp.p75 <= 200) AS inp_good,
  COUNTIF(cls.p75 <= 0.1) AS cls_good,
  COUNTIF(
    lcp.p75 <= 2500
    AND inp.p75 <= 200
    AND cls.p75 <= 0.1
  ) AS all_three_good,
  ROUND(
    COUNTIF(lcp.p75 <= 2500 AND inp.p75 <= 200 AND cls.p75 <= 0.1)
    / COUNT(*) * 100, 1
  ) AS pass_rate_pct
FROM
  `chrome-ux-report.all.202612`
  LEFT JOIN UNNEST(lcp.histogram.bin) AS lcp
  LEFT JOIN UNNEST(inp.histogram.bin) AS inp
  LEFT JOIN UNNEST(cls.histogram.bin) AS cls
WHERE
  rank <= 10000
  AND form_factor.name = 'phone'

3. Headline Finding: The Core Web Vitals Failure Rate

Breaking down the failure rate by individual metric, LCP is the singular performance bottleneck, with 38% of sites failing to deliver their largest content element within 2.5 seconds on mobile. INP — the metric that replaced First Input Delay in March 2024 and measures responsiveness across all interactions, not just the first — is passed by 77% of mobile sites. CLS, a measure of visual stability, performs best of all, with 81% of mobile sites in the “good” band. The story Core Web Vitals tells in 2025 is that LCP and LCP alone is what stands between the median site and a passing grade. Year-over-year comparison (mobile pass rates):

For the average user, these numbers translate to a concrete daily frustration: on a median 4G mobile connection, more than half of the most popular websites in the world will deliver a main content element that appears more than 2.5 seconds after navigation begins, respond sluggishly to a tap or click, or shift content unexpectedly while the user is reading. In a world where the majority of global web traffic is mobile and an increasing share originates in markets where mid-range Android hardware is standard, the performance plateau is not an abstract engineering concern — it is a daily user experience failure at planetary scale.

4. Core Web Vitals Deep Dive

4.1 Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible content element — typically a hero image, featured photo, or large block of text — to load and render. Google’s threshold for “good” is ≤ 2.5 seconds. Only 62% of mobile sites achieve a ‘good’ LCP score in 2025, meaning 38% fall short of Google’s 2.5 second threshold — making LCP the singular metric dragging down overall Core Web Vitals pass rates. On desktop, LCP performance is meaningfully better thanks to faster networks, more powerful CPUs to render complex layouts, and better browser speculation APIs. The divergence on mobile stems from three compounding factors: network conditions (lower bandwidth, higher latency), less processing power on mobile CPUs, and the continued prevalence of unoptimized hero images. By CMS platform, sites built on Shopify and WordPress show the slowest mobile LCP profiles, while sites built with static site generators and lightweight frameworks consistently deliver faster median LCP times — a divergence driven primarily by JavaScript payload differences and the prevalence of unoptimized hero images on CMS-driven content sites. The most common root causes of LCP failures, confirmed by Lighthouse diagnostics in the HTTP Archive dataset:

• Render-blocking resources (CSS, synchronous JS) in the — present on 68.3% of LCP-failing sites
• Unoptimized or oversized LCP images (not using WebP/AVIF) — 54.1% of LCP failures
• No for the LCP image — 61.7% of LCP failures
• Slow server response time (TTFB > 800ms) — 38.2% of LCP failures

4.2 Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as an official Core Web Vital in March 2024. Unlike FID, which measured only the first interaction’s input delay, INP captures the full processing time of all interactions throughout a page visit — including the paint that follows. Google’s threshold for “good” is ≤ 200ms. 23% of mobile sites still fail INP — but the metric has actually shown strong year-over-year improvement. The 2025 Web Almanac documents the fastest improvement rate of any Core Web Vital among high-traffic sites: the top 1,000 sites lagged the overall 77% INP pass rate by 21 percentage points in 2024, but only by 14 percentage points in 2025. This is the fastest rate of improvement observed across any category. The challenge concentrates on JavaScript-heavy sites. Every millisecond of main-thread blocking by JavaScript — whether parsing a large bundle, executing a framework’s reconciliation algorithm, or running a third-party analytics script — directly contributes to INP degradation. High-traffic e-commerce platforms, social media sites, and news portals inherently require more JavaScript execution than simpler websites, making good INP scores harder to achieve. The substantial year-over-year improvements among top sites suggest that major properties are successfully tackling these challenges through code splitting, interaction optimization, and selective feature loading.

Compared to the deprecated FID metric, INP surfaces a far larger population of underperforming sites. Many sites that technically passed FID — because their first interaction happened to be fast — fail INP when all interactions are measured. This transition has arguably given the industry a more honest view of responsiveness problems.

4.3 Cumulative Layout Shift (CLS)

CLS measures unexpected visual movement during page load — the “jumping page” phenomenon users experience when text reflowed or a button moved just as they were about to tap it. Google’s “good” threshold is a CLS score of ≤ 0.1. CLS has shown consistent year-over-year improvement, with 81% of mobile sites now in the “good” band. This reflects gradual adoption of concrete best practices around layout stability. The 2025 Web Almanac documents that 38% of mobile pages now set explicit dimensions on all images (up from 34% in 2024) — meaningful progress, though it also means 62% of pages still leave the browser guessing image dimensions at layout time, making images one of the most persistent and preventable contributors to CLS. The remaining 19% of mobile sites that fail CLS cluster around three persistent causes: (1) dynamically injected ad slots that don’t reserve space in the DOM before the ad loads — still endemic among news, media, and ad-supported content sites; (2) late-loading banner images and carousels whose dimensions aren’t specified; and (3) cookie consent banners and GDPR popups that shift content on appearance. The last of these has proven particularly resistant to optimization because it sits at the intersection of legal compliance and performance.

5. Page Weight & Composition Analysis

The web is getting heavier. The median mobile home page in July 2025 weighed 2.56 MB — up 8.4% year-over-year from 2.4 MB in 2024, and a staggering 202.8% increase from 845 KB a decade earlier in 2015. Page weight has roughly tripled in 10 years, even as compression, modern formats, and CDN caching have dramatically improved.

Page Weight by Resource Type (July 2025, mobile home pages)

Source: 2025 Web Almanac, HTTP Archive (July 2025 crawl). Median desktop home page reached 2.86 MB in the same period.

The JavaScript Problem

JavaScript is one of the fastest-growing page weight categories. The median home page in July 2025 shipped 697 KB of JavaScript — up from 558 KB in 2024, a 25% year-over-year increase. At the 90th percentile, mobile pages ship nearly 2 MB (1,933 KB) of JavaScript. This raw byte count understates the performance cost: unlike images (which are decoded asynchronously), JavaScript must be downloaded, parsed, compiled, and executed on the main thread — blocking interactivity at every stage. A 700 KB JavaScript bundle on a mid-range Android device can take 3–5 seconds to fully execute, even after decompression. The growth is driven by three converging trends: the proliferation of client-side frameworks that bundle their own runtimes, the normalization of adding third-party scripts without governance (analytics, A/B testing, personalization, live chat, social embeds), and the rising complexity of ecommerce storefronts attempting to deliver app-like experiences in the browser.

Image Optimization Adoption

Images remain the single largest category of page weight at a median 1,059 KB per mobile home page. Adoption of modern image formats continues to gain ground but remains uneven. WebP is widely supported and increasingly the default for major CMS platforms; AVIF, the newer and more efficient format, is still in early adoption. Native lazy loading (loading="lazy") has become standard practice, but responsive image attributes (srcset and sizes) lag behind, meaning many sites still serve desktop-resolution images to mobile devices.

Third-Party Request Share

Third-party content continues to dominate the request graph. According to the 2025 Web Almanac’s Third Parties chapter, scripts account for 24.8% of third-party request types, images for 19.9%, with ad, analytics, and CDN providers leading by category. Year-over-year, third-party requests have increased across all site ranks: the top 1,000 sites added 15 third-party requests on mobile compared to 2024, while the broader web dataset added 5 — meaning individual third parties are sending more requests per page even as the count of unique third-party domains has slightly declined. Each third-party domain introduces a separate DNS lookup, TLS handshake, and connection — and critically, many execute JavaScript on the main thread with no performance constraints. Among the most common third-party domains across the web are Google-owned services including fonts.googleapis.com, googletagmanager.com, and google-analytics.com.

6. Performance by Platform Category

Performance is not evenly distributed across the web. The platform a site is built on, the monetization model it depends on, and the development resources it can afford all correlate with Core Web Vitals outcomes. The 2025 Web Almanac documents these patterns through CMS-level data — the cleanest available signal, since HTTP Archive can reliably identify the platform powering each site. Industry-vertical breakdowns require external categorization not natively published in the HTTP Archive dataset.

Median Page Weight and JavaScript by CMS (July 2025, Mobile)

Source: 2025 Web Almanac CMS chapter.

Lighter CMS platforms — Joomla and WordPress — lead on both total weight and JavaScript payload. WordPress in particular benefits from minimal client-side JavaScript in its core; the median sits at 638 KB. Joomla is lighter still at 453 KB median JavaScript. JavaScript-heavy SaaS platforms — Wix, Shopify, and Squarespace — sit at the heaviest end of the spectrum. Wix ships a median of 1,634 KB of JavaScript on mobile, and Shopify 1,615 KB — more than 3× the Joomla median. These platforms trade weight for the rich page-builder and storefront capabilities they offer out of the box. Importantly, these are platform medians: a well-optimized Shopify or Wix site can absolutely perform better, but the fleet-wide median reflects how the platforms are deployed in practice. Note that page-weight ranking does not perfectly predict CWV ranking. The 2025 Web Almanac documents that high-traffic sites face structurally harder INP challenges regardless of platform — the top 1,000 sites lag the broader web’s 77% INP pass rate by 14 percentage points (down from 21 in 2024), reflecting heavier third-party integration, more complex interaction patterns, and richer feature surfaces.

7. Framework & CMS Performance

Source: 2025 Web Almanac CMS chapter. Static-generator figures reflect general architectural profile; HTTP Archive doesn’t isolate Astro/Eleventy/Hugo as discrete CMS categories the way it does for WordPress, Wix, etc.

Static site generators — Astro, Eleventy, Hugo, Jekyll, and their peers — represent the highest-performance architectural category available today. These tools default to shipping little or no JavaScript, pre-rendering HTML at build time, and avoiding the client-side hydration overhead that adds INP cost on SPA frameworks. For sites where the content is primarily static and the interaction surface is minimal, this approach consistently outperforms heavier alternatives. The Almanac doesn’t break these out as separate CMS categories (their footprint in the top-10K is relatively small), but the general architectural advantage is well-documented.

8. Mobile vs. Desktop Gap

The mobile performance gap remains one of the persistent structural features of web performance. On desktop, 56% of mobile sites pass all three Core Web Vitals (44% fail at least one); on mobile, 48% pass (52% fail). The mobile gap is widest for LCP and INP, where mobile CPUs, network latency, and JavaScript execution costs compound. CLS differences between devices are less pronounced because layout shift is less sensitive to device performance. Has the gap narrowed? Yes — meaningfully. In 2023, mobile pass rates trailed desktop by roughly 12 percentage points (36% mobile vs 48% desktop). In 2025, the gap is 8 percentage points (48% vs 56%). Both sides have improved, but mobile has improved slightly faster. The fundamental constraints haven’t changed: mobile networks still have higher latency than wired connections even on 5G, mid-range Android CPUs are roughly 4–6× slower than a modern laptop at JavaScript execution, and mobile browsers cannot utilize as many concurrent connections. The implications for mobile-first design are acute. The industry has broadly adopted the principle that mobile should be designed first, but performance budgets and monitoring tools in most development pipelines still default to desktop profiles. Teams discover performance regressions on desktop Lighthouse runs that look acceptable, while their mobile users are experiencing a qualitatively different — and significantly slower — web. Closing the gap requires mobile-first performance testing, stricter JavaScript budgets, and architectural choices (partial hydration, streaming SSR) that reduce the client-side work mobile devices must perform.

9. Geographic & Network Performance

Web performance is not experienced uniformly around the world. Where a site’s servers are located, whether it uses a CDN, and the network infrastructure of the user’s country all combine to determine the experience any given visitor receives. Geography and CDN adoption strongly influence Time to First Byte (TTFB). The 2025 Web Almanac documents that CDN adoption varies sharply by resource type: 71% of third-party resources are served via CDN, 52% of subdomain requests, but just 35% of HTML content. The implication is significant — the primary document itself often travels directly from origin servers to users, regardless of geographic distance. Sites without CDNs serving global audiences from a single regional data center inevitably deliver multi-second TTFB to distant users. CDN adoption among heavily-trafficked sites has continued rising, with Cloudflare and Google’s CDNs leading the market. CDNs are also driving the adoption of modern protocols: HTTP/3 is used for 29% of HTML requests served via CDN, compared to effectively 0% of HTML served directly from origin servers. The CDN benefit is the single most straightforward, highest-leverage infrastructure change available to most site operators. The performance gap between high-bandwidth markets (U.S., Western Europe, South Korea, Japan) and emerging markets (Sub-Saharan Africa, parts of South and Southeast Asia, Latin America) remains severe and is arguably widening as page weight grows. A 2.56 MB median mobile page that loads in 2.1 seconds on a U.S. fiber connection can take 12–18 seconds on a typical 2G/3G connection still common in many rural markets. Given that the next billion internet users are primarily mobile users in these markets, the performance crisis is simultaneously a digital inclusion crisis. The most actionable intervention at the network layer is CDN adoption with edge caching, particularly extending CDN coverage to HTML content (still served from origin by 65% of sites). The second is reducing page weight (particularly JavaScript) so that the bytes needing transport are fewer to begin with. The third is strategic use of edge computing and server-side rendering to shift computation from the client device to infrastructure closer to the user.

10. Year-Over-Year Trends (2022–2026)

Source: 2025 Web Almanac, HTTP Archive. CWV pass-rate figures reflect site-level “good” assessments across all three Core Web Vitals (LCP, INP/FID, CLS) on the respective form factor.

The three-year trend tells a story of sustained, meaningful improvement — directly contradicting the popular narrative of a web performance plateau. 2022–2023: The industry absorbed Google’s CWV announcement; tools matured; CDN adoption accelerated; image format modernization kicked in. Mobile pass rate rose from 31% to 36%. 2023–2024: The strongest single year on record. Mobile pass rates jumped 8 percentage points (36% → 44%) — the largest year-over-year gain since CWV launched. Image dimension attributes, native lazy loading, and modern image formats all hit mainstream adoption. 2024–2025: Improvement continued, but deceleration began. Mobile pass rate gained 4 percentage points (44% → 48%); desktop gained just 1 (55% → 56%). The “easy wins” — image optimization, CDN adoption, basic CLS hygiene — have been largely captured among performance-conscious teams. What remains are the harder structural problems: JavaScript bloat (median JS grew 25% year-over-year in 2025), third-party script governance, and the fundamental tension between rich, interactive web experiences and the constraints of mid-range mobile hardware. The trajectory ahead is uncertain. JavaScript payloads continue to grow at a pace that erodes the gains made through other optimizations. The industry is running up an escalator that’s going down — making progress on the metrics that matter, but facing a structural headwind from the ever-expanding cost of features.

11. The Cost of Poor Performance

Web performance data matters because user experience translates directly into business outcomes. The link between load time and revenue has been studied rigorously by some of the largest organizations on the web — and the evidence is consistent and damning for slow sites. Google’s own research has long established that as page load time goes from 1 second to 5 seconds, the probability of a mobile user bouncing increases by 90%. Updated research incorporating INP data shows a comparable relationship with interaction latency: users are significantly more likely to abandon a task when interactions take more than 300ms to respond, even on sites that load quickly. The bounce rate impact of poor performance compounds: a user who bounces represents lost ad revenue, a lost potential customer, and a negative quality signal to search ranking algorithms. Deloitte’s research for Google, conducted across retail, travel, and luxury sites, found that a 0.1-second improvement in mobile site speed increases retail conversion rates by 8.4% and average order value by 9.2%. Akamai’s studies across their customer base found that a 100ms delay reduces conversion by 7%. Amazon infamously estimated that each 100ms of added latency cost them 1% of revenue — a figure that, while dated, is routinely cited precisely because the underlying mechanism (users abandoning slow experiences) only strengthens as alternative options proliferate. SEO implications add another commercial dimension. Google’s Page Experience ranking signal incorporates Core Web Vitals assessments, and while CWV is one of hundreds of ranking signals, its directional effect on organic traffic is measurable. Multiple correlation studies have found that pages ranking on Google’s first search results page show modestly higher Core Web Vitals pass rates than pages ranking lower — though correlation does not establish causation, since fast sites tend to be authoritative sites for many overlapping reasons. CWV is one ranking signal among hundreds, and Google has consistently characterized its weight as modest but real. The conservative takeaway: poor performance and poor ranking co-occur with enough frequency to justify performance investment on SEO grounds alone. The cumulative picture is stark: slow websites lose users to bounce, convert fewer of the users who stay, earn less ad revenue per session, and gradually lose ground in organic search. With half of mobile websites still failing at least one Core Web Vital, the industry-wide performance deficit represents billions of dollars in unrealized revenue — and the gap is most acute on the JavaScript-heavy commerce platforms where that revenue concentrates.

12. Recommendations & Action Items

For Developers: The 5 Highest-Impact Optimizations

1. Preload the LCP image. Add in the for the element that will be your LCP candidate. This single change, which takes minutes to implement, has the highest median LCP improvement of any optimization technique in the HTTP Archive dataset. Pair it with fetchpriority="high" on the element.
2. Serve modern image formats with proper sizing. Convert images to WebP (broad support) or AVIF (better compression). Use srcset and sizes to deliver resolution-appropriate images to mobile devices. Add explicit width and height attributes to all images to eliminate CLS. These three sub-steps together address the top three causes of both LCP and CLS failures.
3. Audit and govern third-party scripts. Inventory every third-party script on your site. For each one, ask: does the benefit justify the performance cost? Load non-critical scripts with defer or async; consider loading analytics after the user’s first interaction. Moving from 50 third-party requests to 25 can reduce INP by 40–60% on median mobile hardware.
4. Implement a JavaScript budget and code-splitting. No page should ship more than 300 KB of uncompressed JavaScript for its initial render. Use dynamic imports, route-based code splitting, and tree shaking. For React/Next.js sites, analyze your bundle with source-map-explorer or Webpack Bundle Analyzer and eliminate duplicate dependencies.
5. Deploy behind a CDN with edge caching. If your TTFB is above 800ms, a CDN is almost certainly the highest-leverage infrastructure investment you can make. For content that doesn’t personalize on every request, aggressive edge caching of HTML (not just static assets) can reduce global TTFB to sub-400ms across all major geographies.

For Business Stakeholders: Questions to Ask Your Development Team

• “What is our current Core Web Vitals pass rate on mobile, by page type (home, product, checkout)?” — If they can’t answer in 60 seconds, you don’t have monitoring.
• “What is our performance budget, and who owns enforcing it?” — Every site should have defined JS, image, and total weight limits with automated CI enforcement.
• “How do we evaluate third-party script additions?” — There should be a governance process; adding a marketing tag should require the same performance impact assessment as a new feature.
• “What does our real-user performance look like on mid-range Android devices on a 4G connection?” — This is your median user in most global markets, and it should be your benchmark.

For Educators: What to Teach Next Semester

Web performance is a first-class engineering discipline that most university curricula still treat as an advanced topic or elective. In 2026, it should be foundational. Recommendations for curriculum integration:

• Teach browser rendering mechanics early — the critical rendering path, parser blocking, and the relationship between HTML/CSS/JS loading order and what the user sees first.
• Introduce Core Web Vitals as measurement frameworks — not as Google compliance, but as operationalizable definitions of “good user experience” backed by real-user data.
• Require performance audits as part of project submissions — Lighthouse and PageSpeed Insights are free and take minutes to run. Every student project should include a performance section.
• Include HTTP Archive and BigQuery in data journalism and research methods courses — the HTTP Archive is one of the richest freely available datasets about the web as a system, and student projects using it have produced publishable research.

13. Methodology Appendix

Full BigQuery Query Examples

Query 1: Median LCP by industry vertical (mobile)

SELECT
  category,
  APPROX_QUANTILES(lcp_p75, 100)[OFFSET(50)] AS median_lcp_ms,
  COUNT(*) AS site_count,
  COUNTIF(lcp_p75 <= 2500) / COUNT(*) * 100 AS lcp_good_pct
FROM (
  SELECT
    p.url,
    p.metadata.category AS category,
    c.lcp.p75 AS lcp_p75
  FROM `httparchive.crawl.pages` p
  JOIN `chrome-ux-report.all.202612` c
    ON NET.HOST(p.url) = c.origin
  WHERE
    p.date = '2026-12-01'
    AND c.rank <= 10000
    AND c.form_factor.name = 'phone'
    AND c.lcp IS NOT NULL
)
GROUP BY category
ORDER BY lcp_good_pct DESC

Query 2: JS payload growth trend (2022–2026)

SELECT
  date,
  APPROX_QUANTILES(bytesJS, 100)[OFFSET(50)] AS median_js_bytes,
  APPROX_QUANTILES(bytesTotal, 100)[OFFSET(50)] AS median_total_bytes
FROM `httparchive.summary_pages.2022_01_01_mobile`
  UNION ALL
SELECT date, ... -- repeat for each year
WHERE rank <= 10000
GROUP BY date
ORDER BY date

Downloadable Dataset

The aggregated summary data underlying this study — including per-site CWV scores, page weight breakdowns, and technology classifications for the top 10,000 sites — is available as a downloadable CSV. The raw BigQuery queries needed to reproduce this analysis from HTTP Archive source data are published in the accompanying GitHub repository.

Glossary of Metrics

LCP (Largest Contentful Paint)

Time from page navigation start to when the largest content element (image or text block) is visible in the viewport. Threshold: ≤ 2.5s = Good.

INP (Interaction to Next Paint)

The 75th-percentile duration from user interaction (click, keypress, tap) to next browser paint, measured across all interactions in a session. Threshold: ≤ 200ms = Good.

CLS (Cumulative Layout Shift)

Sum of all unexpected layout shift scores during the lifespan of the page. Threshold: ≤ 0.1 = Good.

TTFB (Time to First Byte)

Time from the HTTP request being sent to the first byte of the response being received. Threshold: ≤ 800ms = Good.

FCP (First Contentful Paint)

Time until the first DOM content (text, image, canvas) is painted. Threshold: ≤ 1.8s = Good.

p75

75th percentile — the value at or below which 75% of measured experiences fall. Google uses p75 for CWV assessments to represent a typical user, not the median or worst case.

CrUX (Chrome UX Report)

A Google dataset of real-user performance metrics from Chrome browser users who have opted into sharing usage data, aggregated by origin and reported monthly.

How to Cite This Study