Mobile Web Performance Reality Check 2026: Public Benchmarks and a 39-Site Homepage Audit

Mobile web performance in 2026 is better, but not under control. That is the clearest conclusion from both public benchmark data and a focused audit of 39 real mobile homepages. Core Web Vitals have improved, especially INP and CLS, yet the same structural problems continue to dominate: delayed LCP, oversized JavaScript, unstable layouts, heavy media surfaces, and long chains of third-party or external-domain requests.

The important point is not that teams lack guidance. The web has had years of documentation, tooling, and metric thresholds. The harder truth is that many homepages are now expected to do too many things at once: market, personalize, track, experiment, collect consent, recommend content, and render rich interfaces before the primary content has even settled. In that environment, performance failure is rarely one bad image or one careless script. It is usually the cumulative result of too many legitimate business demands competing for the same startup budget.

Public data supports that reading. In the Web Almanac 2025 Performance chapter, 48% of mobile websites achieved good Core Web Vitals, up from 44% in 2024 and 36% in 2023. In the Chrome UX Report April 2026 release, 56.4% of origins had good Core Web Vitals overall, with 68.9% good LCP, 81.3% good CLS, and 87.1% good INP. That is real progress. It is also a reminder that roughly half of origins still fail the full assessment.

The weakest link remains familiar. Web Almanac 2025 reports that only 62% of phone experiences had good LCP, versus 77% good INP and 81% good CLS. Images remain the dominant LCP content type: 76% of mobile pages have an image as the LCP element. At the same time, page weight continues to rise. The Web Almanac 2025 Page Weight chapter reports a median mobile homepage of 2.6 MB, including 632 KB JavaScript, 911 KB images, 122 KB fonts, and 77 KB CSS. The Third Parties chapter adds another structural constraint: more than nine in ten pages use at least one third party, and the median mobile page made 79 third-party requests across all sites, rising to 106 among the top 1,000 sites.

To test whether those broad signals still show up in concrete mobile homepages, this article also looks at a focused audit of 39 public homepages across ecommerce, news/media, SaaS, travel, finance, government, and blogs/publishing. This audit is illustrative, not representative. It should not be read as a benchmark for the web. Its value is narrower: it shows how recurring public-data patterns behave when you inspect recognizable, high-complexity pages one by one.

Public benchmark vs focused audit: the gap at a glance

Public web metrics show broad improvement, but the focused 39-site audit paints a harsher picture for complex homepages. The difference does not prove contradiction. It shows how much weaker performance can look when the sample is limited to visible, high-complexity entry pages.

Key findings from the focused audit

• 11/39 pages passed all three field Core Web Vitals thresholds.
• 23/39 had field LCP above 2.5 seconds.
• 19/39 had field INP above 200 ms.
• 16/39 had field CLS above 0.1.
• 25/39 transferred more than 1 MB of JavaScript in the lab run.
• 20/39 transferred more than 3 MB total.
• 27/39 made more than 50 external-domain requests.
• 23/39 had an image-classified LCP element.
• Government pages were the lightest vertical in the sample; SaaS and travel were the weakest on field Core Web Vitals.

The headline is not that the modern web is careless. It is that startup complexity has become normal. Too many mobile homepages now behave like operating environments rather than documents or task-first entry points, and that shift has a predictable cost.

Methodology

This article combines two evidence layers.

The first is public benchmark data from primary sources:

The second is a focused 39-site audit. The candidate list covered seven verticals: ecommerce, news/media, SaaS, travel, finance, government, and blogs/publishing. Only pages with both usable CrUX field data and a completed mobile Lighthouse run were included. Pages whose lab runs did not complete reliably were excluded rather than padded with placeholders.

• Field metrics are from CrUX: LCP, INP, CLS, and TTFB where available.
• Lab diagnostics come from a single mobile Lighthouse run per page: Performance score, TBT, transfer size, request counts, resource breakdown, and external-domain request counts.
• INP is treated as a field metric only. TBT is used as a lab signal for main-thread blocking, not as a substitute for INP.
• External-domain requests are classified by registrable-domain mismatch. That includes independent third parties, but it can also include owned CDNs and adjacent first-party infrastructure.
• The audit is homepage-only, small, and non-representative.

Core Web Vitals thresholds follow current Google guidance: good LCP is 2.5 seconds or less, good INP is 200 ms or less, and good CLS is 0.1 or less, evaluated at the 75th percentile and segmented by device class.

Public benchmark reality check

Core Web Vitals improved, but mobile still lags where it matters most

The broad trend is positive. Web Almanac 2025 shows mobile good-CWV rates rising from 36% in 2023 to 44% in 2024 and 48% in 2025. Desktop reached 56% in 2025. The same chapter also shows that homepages remain harder than secondary pages: 45% of mobile homepages had good CWV, compared with 56% of mobile secondary pages.

CrUX’s April 2026 release looks somewhat stronger at the origin level, with 56.4% of origins passing good Core Web Vitals overall. These figures are not directly equivalent to homepage-level cuts in Web Almanac, but the direction is the same: the web is improving, yet homepages remain the place where product ambition most often overruns performance discipline.

LCP is still the metric that exposes architectural shortcuts

LCP remains the most stubborn mobile weakness. Web Almanac 2025 reports 62% good LCP on phones, compared with 77% good INP and 81% good CLS. It is tempting to translate that into “optimize your images,” but that is too shallow. LCP is usually a critical-path story: server response, HTML delivery, resource discovery, fetch priority, render-blocking CSS, script competition, font behavior, and whether the likely LCP element is visible to the browser early enough to matter.

Google’s own LCP guidance points directly at delayed discovery: dynamically inserted images, CSS background images, hidden lazy-loading patterns, and resources invisible to the preload scanner. The public-data gap is not abstract. In Web Almanac 2025, only 17.3% of mobile pages with LCP images used fetchpriority="high", only about 2.1% used preload for LCP prioritization, and roughly 17% still lazy-loaded the LCP image.

That is why LCP remains such a useful reality check. It punishes not only large assets, but also organizational indecision about what deserves priority.

INP looks healthier, but JavaScript is still where mobile debt accumulates

Public data makes INP look comparatively strong. CrUX April 2026 reports 87.1% of origins with good INP, and Web Almanac 2025 reports 77% good INP on phones. But those numbers should not be read as proof that mobile responsiveness is solved.

Web Almanac notes that while mobile INP improved, TBT increased 58%. That is an uncomfortable but useful signal: pages may be performing better on measured user interactions while still carrying increasingly expensive JavaScript startup behavior. Google’s INP guidance explains the risk clearly. A page can look ready before it is ready to respond. Long tasks from parsing, compiling, and executing script during startup still create latent interaction cost.

For product teams, that distinction matters. INP measures real user outcomes. TBT is a lab diagnostic. They are not interchangeable. But large JS payloads, hydration-heavy shells, early tag managers, and broad script ownership almost always mean the same thing operationally: the margin for interaction quality is thinner than it appears.

CLS improved, but regressions still come from boring mistakes

CLS is the success story of recent years, with 81% good CLS on mobile in Web Almanac 2025. But the remaining failures are not mysterious. The same chapter reports that 62% of mobile pages still fail to set dimensions on at least one image. Google continues to emphasize basic layout reservation: explicit media dimensions, aspect-ratio, and reserved space for ads, embeds, banners, and other late-loading surfaces.

Consent interfaces remain especially revealing because they cut across product, legal, and analytics priorities. Google’s cookie-notice guidance notes that these notices often load early, affect LCP, frequently trigger CLS, and can worsen INP when acceptance fires a burst of third-party activity. In other words, one small UI block often exposes the full governance problem in miniature.

Page weight and third parties are not edge cases. They are the default.

The median mobile homepage in Web Almanac 2025 is 2.6 MB, up 8.4% year over year. Images remain the largest resource class, but JavaScript is not far behind: 911 KB images and 632 KB JavaScript at the median.

Third parties are even more structurally embedded. More than nine in ten pages include them, and the median mobile page makes 79 third-party requests across all sites. Among the top 1,000 sites, that rises to 106. Google’s third-party JavaScript guidance is blunt for good reason: third-party code consumes bandwidth, extends request chains, and adds parse, compile, and execution work that the core team does not fully control. At that point, the request chain is no longer incidental plumbing. It is part of the product.

Focused 39-site mobile audit

What this small audit is useful for

This audit is intentionally narrow. It is not a ranking of the web, and it should not be used to generalize from one homepage to an entire vertical. Its value is simpler: it tests whether the broad warnings from public benchmark data still appear when you inspect real mobile homepages that many teams would recognize as mature, high-traffic surfaces.

In most cases, they do.

Audit summary by vertical

Median mobile LCP by vertical in the 39-site audit

This small-sample comparison is not representative of the web, but it makes one pattern obvious: task-first and simpler homepage models still retain a measurable performance advantage.

What the vertical split actually says

Ecommerce performed poorly not simply because commerce uses more images, but because the homepage is usually overburdened before the session has even begun. Promotional modules, merchandising, personalization, testing, analytics, and large JS bundles all compete for early attention. That is why ecommerce tends to generate simultaneous risk for LCP, INP, and CLS rather than failing only one metric.

News and media showed a more complicated pattern. Request volume and total transfer were extreme, yet some field metrics remained respectable. In a small audit like this, that does not make the waterfall harmless. It suggests that mature publishers can offset some cost through caching, edge delivery, prioritization, or traffic patterns that a single lab run does not reproduce well. Even so, high request chains remain operationally fragile.

SaaS was the weakest vertical on field Core Web Vitals in this sample, with 0/6 pages passing all three thresholds. That is notable because SaaS homepages often look cleaner than ecommerce surfaces. The issue is that “clean” design can still hide substantial runtime cost: long marketing pages, animation, product screenshots, chat, multi-product navigation, form logic, experimentation, and personalization all accumulate silently in startup work.

Travel also failed all-three-CWV in every measured case. The likely explanation is interaction complexity. Travel homepages frequently prepare forms, calendars, destinations, maps, recommendations, pricing modules, and review surfaces early. They may look restrained above the fold, yet still carry heavy state and interaction cost underneath.

Finance was mixed, but its recurring weakness was JavaScript rather than imagery. These pages often combine account-entry flows, security logic, compliance surfaces, personalization, product marketing, and analytics. The result is a page that may look visually conservative while remaining computationally expensive.

Government was the clearest contrast. It was lighter, simpler, and more task-first almost across the board, and the metrics reflected that. The lesson is not that government sites are universally better designed. It is that narrowing the homepage’s job still buys real performance headroom.

Blogs and publishing split cleanly into two models: simple text-first surfaces that perform well, and platform-like publishing homepages that behave more like product shells than reading environments. That split is a reminder not to treat “publishing” as a single technical category.

Recurring failure modes

1. LCP failures are usually about startup sequencing, not just image compression

Public data says images dominate LCP, and the audit echoed that: 23/39 measured pages had an image-classified LCP element. But the real issue is not “images are bad.” It is that teams often optimize the asset while leaving the discovery path, priority rules, script competition, and render delay untouched. In the audit, several pages with moderate image bytes still had slow field LCP, which suggests that startup sequencing often matters more than raw media weight.

2. JavaScript remains the hidden tax on mobile responsiveness

In the focused audit, 19/39 pages had field INP above 200 ms, 19/39 had lab TBT above 600 ms, and 25/39 transferred more than 1 MB of JavaScript. Those are not isolated outliers. They point to a common operating model in which every stakeholder gets a startup budget, but no one owns the total.

Where the audit shows the heaviest concentration of failure

The strongest pattern in the audit is not a single bad metric. It is accumulation: slow LCP, large JavaScript payloads, heavy total transfer, and long external dependency chains often appear together rather than in isolation.

3. CLS failures still come from predictable component behavior

16/39 pages had CLS above 0.1, and 8/39 were above 0.25. The causes were not exotic. They were the usual suspects: media without reserved dimensions, banners, dynamic modules, consent UI, and late-loading components. CLS remains one of the clearest signs that layout rules are not enforced early enough in the component system.

4. Total page weight is still a practical risk proxy

The median lab transfer in the audit was about 3.06 MB, with 20/39 pages above 3 MB and a heavy tail that extended far beyond that. Weight alone does not explain every bad experience, but large transfers tend to travel with other problems: more requests, more external domains, more scripts, and more ways to delay meaningful rendering or block the main thread.

5. External-domain dependency chains are part of the performance budget

27/39 pages made more than 50 external-domain requests. Even allowing for the fact that this proxy includes some owned infrastructure, the pattern is hard to ignore. More domains mean more connection setup, more scheduling complexity, more cache variability, and more systems that can degrade the page without the core team shipping a line of new product code.

What the public data and the focused audit agree on

• LCP remains the main mobile weakness.
• Images are central to LCP, but rarely the whole story.
• JavaScript is still the main execution-cost problem.
• Third-party and adjacent dependency chains are normal, not exceptional.
• Simpler task-first pages retain a measurable advantage.
• Homepages remain harder than secondary pages because more priorities collide there.

The focused audit produced worse pass rates than public CrUX origin-level data: only 11/39 measured pages passed all three field thresholds, versus 56.4% of origins in CrUX April 2026. That is not a contradiction. The audit was small, homepage-only, and intentionally skewed toward recognizable, complex public entry pages. If anything, the gap helps explain why many teams feel performance is “supposed to be improving” while their most visible surfaces still feel fragile.

Practical recommendations

1. Treat LCP as an architecture decision, not an image task

For every important mobile template, identify the likely LCP element and verify that it is discoverable early, not lazy-loaded, assigned appropriate priority, and not delayed by CSS, hydration, or script-heavy startup work. If the main content is not clearly winning the first few seconds, the page is already negotiating against itself.

2. Define a JavaScript budget that includes third-party code

A budget that covers only first-party bundles is not a real mobile budget. Track first-party JS, third-party JS, long tasks, TBT, field INP, and vendor-level ownership. If no one can say who owns the startup cost of experimentation, chat, consent, analytics, or personalization, then no one really owns mobile responsiveness.

3. Keep field outcomes and lab diagnostics separate

Use CrUX or RUM to understand user outcomes. Use Lighthouse, DevTools, traces, and similar tools to debug causes. The distinction matters because overreacting to one lab run can be as misleading as ignoring it. Good performance work depends on keeping outcome metrics and causal diagnostics in dialogue, not treating them as the same evidence.

4. Make layout stability a component-system rule

CLS prevention should live in the design system and CMS, not in occasional clean-up passes. Media components should require dimensions or aspect ratio. Ad slots should reserve space. Consent and promo surfaces should avoid pushing content unexpectedly. Recommendation modules should have placeholders. If layout stability depends on late vigilance, it will eventually fail.

5. Audit external dependencies like product features

Every external dependency should have an owner, a business purpose, a loading strategy, and a removal path. Teams should regularly ask whether a script belongs before LCP, after interaction, after consent, or off the homepage entirely. If an external system is allowed to consume startup budget indefinitely without review, it is effectively shipping product policy by default.

6. Set budgets by surface type, not only site-wide averages

Limitations

This article has several important limits. Public datasets do not all measure the same thing. Web Almanac combines HTTP Archive crawl data and CrUX field data. CrUX reflects real Chrome users for eligible pages and origins. PageSpeed Insights may show URL-level or origin-level field data depending on availability, and Lighthouse remains a simulated lab diagnostic rather than a field outcome.

The focused audit is also narrow by design. It covers 39 public homepages, not product pages, article pages, search flows, checkout, logged-in experiences, or repeat visits. It uses one lab run per page, so lab metrics should be read as directional rather than stable. It also mixes field and lab evidence deliberately: LCP, INP, and CLS are field values from CrUX, while TBT, transfer size, request counts, and Lighthouse scores come from a single controlled run.

External-domain request counts are a proxy, not a perfect vendor census. They include independent third parties, but may also include owned CDNs, image hosts, static asset domains, and adjacent infrastructure. The useful interpretation is dependency pressure, not a literal count of external vendors.

Finally, homepages are volatile. Promotions, campaigns, breaking news, experimentation, consent state, CDN behavior, device class, and network quality can all change the observed result.

Conclusion

The mobile web in 2026 is not stagnant. Core Web Vitals pass rates have improved, INP looks stronger, and CLS is materially better than it was a few years ago. But the deeper performance story is less flattering. LCP still lags. Page weight keeps rising. JavaScript remains expensive. Third-party and external-domain dependency chains are built into the modern homepage by default.

The focused 39-site audit reinforces that point without pretending to be universal. Complex commercial homepages continue to repeat the same failure modes: image-led LCP candidates, crowded startup paths, large JS payloads, long request chains, dependency sprawl, and layout shifts from dynamic UI.

The practical lesson is that mobile performance is no longer mainly a documentation problem. Teams generally know what good practice looks like. The harder question is governance: who gets to spend the first few seconds of the mobile experience, and who says no when the budget is already gone? Until that question is answered more rigorously, aggregate web metrics may keep improving while many real homepages continue to feel slower and more fragile than they need to be.

Sources

• HTTP Archive Web Almanac 2025: Performance
• HTTP Archive Web Almanac 2025: Page Weight
• HTTP Archive Web Almanac 2025: Third Parties
• HTTP Archive Web Almanac 2025: Ecommerce
• Chrome UX Report documentation
• Chrome UX Report release notes
• web.dev: Core Web Vitals
• web.dev: Optimize Largest Contentful Paint
• web.dev: Optimize Interaction to Next Paint
• web.dev: Optimize Cumulative Layout Shift
• web.dev: Cookie notice best practices
• web.dev: Optimizing third-party JavaScript
• Google PageSpeed Insights documentation