Mobiletech https://www.mobiletech.mobi Sat, 29 Aug 2026 18:11:17 +0000 en-US hourly 1 https://wordpress.org/?v=7.1 The Web Page No Longer Has a Reliable End https://www.mobiletech.mobi/web-page-lifecycle-unload-bfcache-visibility/ Sat, 29 Aug 2026 10:00:00 +0000 http://localhost:18082/web-page-lifecycle-unload-bfcache-visibility/

A web page used to look like a small program with a reassuringly linear life. It loaded, it ran, and eventually it unloaded. That last step appeared to give developers a place to save a draft, send analytics, close a connection or mark a session as finished.

Mobile operating systems made that story difficult to defend. A browser can move into the background, have its processes suspended, and later lose them under memory pressure without ever returning control to the page. Back/forward caches complicate the model in another direction: navigating away may not destroy the document at all. The browser may freeze the whole page and bring it back with its DOM and JavaScript state intact.

Chrome’s current deprecation of unload matters, but mostly because it formalizes what mobile developers have had to learn for years: an application cannot assume that it will observe its own termination.

That constraint now belongs to the modern mobile web platform. For the earlier strategic context, the archive’s native-versus-web application-platform debate shows how MobileTech framed reach and distribution before lifecycle resilience became a first-class concern.

Why unload once made sense

The original document model was easy to understand. A new document replaced the old one. load was a setup point; unload was a teardown point. On desktop browsers, where a visible page often remained attached to a long-lived browser process until a deliberate navigation or window close, that model worked often enough to become habit.

Developers used the event for several very different jobs:

  • sending end-of-visit analytics;
  • saving form values, draft text or application state;
  • closing sockets and other resources;
  • telling a server that a session had ended;
  • performing library or component cleanup.

The problem was not that all of these needs were imaginary. The problem was that they were bundled behind one ambiguous idea: “the user is leaving.”

Leaving can mean a same-tab navigation, a reload, closing one tab, closing the browser, switching to another app, losing the browser process, or having the operating system kill that process later. Early web code routinely treated these as variations of the same transition. They are not.

Comparison between the old linear page lifecycle and a modern branching lifecycle with hidden, frozen, restored and discarded states.
The old mental model had one terminal edge. The modern model has several possible transitions, including paths that produce no final script callback.

unload therefore offered a practical behavior and an architectural illusion at the same time. It encouraged application logic to wait until the last possible moment, even though that moment was never under the page’s control.

Mobile broke the terminal-callback model

A phone cannot keep every background application fully alive. Memory is limited, battery is limited, and the operating system has stronger priorities than preserving a callback for a hidden browser tab. Android documents that cached and background processes may be killed to reclaim memory; Apple’s lifecycle guidance likewise treats background execution and later suspension or termination as normal resource-management behavior.[16][17]

Consider a common sequence:

  1. A user opens a page and starts writing.
  2. The user switches to a messaging or camera app.
  3. The browser moves into the background.
  4. Memory pressure increases later.
  5. The operating system removes the browser process.

There is no useful instant between steps four and five when the hidden page can be woken up and politely told to finish its JavaScript. Once the process is gone, it is gone. unload, beforeunload and even pagehide may never run in this scenario.[12][13]

This was sometimes described as mobile browsers being unreliable. A more useful reading is that mobile browsers exposed a systems principle that desktop web development had managed to ignore: no application controls its own termination.

The same pressure is no longer confined to phones. Desktop browsers suspend background work, freeze eligible tabs and discard documents to reduce CPU, memory and energy use. Mobile did not create every lifecycle mechanism now used on the web, but constrained devices made the old assumption fail earlier and more visibly.[9]

Back/forward cache made “leaving” non-terminal

Back/forward cache, usually shortened to bfcache, is not the HTTP cache. The HTTP cache stores responses and resources that can be reused during a new load. Bfcache keeps an entire document alive in memory: the DOM, JavaScript heap and much of the page’s runtime state are preserved while execution is paused. A history navigation can then restore that page instead of rebuilding it from HTML, CSS and JavaScript.[15]

This is an old idea. WebKit says its Page Cache was built in 2002, before the first Safari beta. Mozilla documented whole-page in-memory caching, including preserved JavaScript state, in Firefox 1.5. WebKit added pageshow and pagehide in 2009, explicitly crediting Mozilla’s earlier solution.[4][5][6]

The mechanism creates an unavoidable conflict with unload.

If the browser fires unload before placing a page in bfcache, the handler may perform destructive teardown: close connections, remove state, detach components or tell a server that the session is over. The page is then restored in a state its own code declared terminal.

If the browser does not fire unload, the page can be cached safely, but the callback is no longer dependable. Firing it later, when an invisible cached page is finally evicted, would mean unexpectedly waking old script that the user left minutes ago. WebKit’s engineers described this exact dilemma in 2009. The core conflict has not changed.[5]

A back-forward cache cycle showing Page A being hidden and frozen while Page B is visible, then restored with pageshow.
With bfcache, navigation can mean “pause this document” rather than “destroy this document.” Code that runs on the way out may need a matching restoration path.

Browsers historically resolved the conflict in different ways. Some excluded pages with unload listeners from bfcache. Others prioritized bfcache and skipped the handler on relevant navigations. Either choice weakens the idea that unload is both reliable and compatible with fast history restoration.

A Chromium Permissions Policy explainer reported internal telemetry in which an unload handler somewhere in the frame tree was the only bfcache blocker for 16% of history navigations. That is vendor telemetry from a particular implementation, not a measurement of the whole web, but it shows why removing an apparently harmless listener can affect a meaningful share of return navigations.[20]

The performance benefit is direct. A restored page does not have to repeat its normal network, parse, style, layout and JavaScript startup work. That can make back and forward navigation feel nearly immediate, which matters particularly on mobile hardware and variable networks.

The modern signals: visibility, pagehide and pageshow

The platform did not replace unload with one equally final event. It split the problem into signals that answer narrower questions.

Page Visibility: can the user currently see this document?

document.visibilityState distinguishes at least visible and hidden, and visibilitychange fires when that state changes. A page can become hidden because the user changed tabs, minimized the browser, navigated, locked the screen or switched away from the browser app.

On mobile, the transition to hidden is often the last state change a page can reliably observe. That makes it a good checkpoint for saving important user state and flushing non-blocking analytics.[7][9]

But hidden does not mean “about to die.” The user may return a second later. The page may remain hidden for hours. It may be frozen, cached, discarded or left alone. Visibility is a signal about presentation, not a termination guarantee.

function checkpoint() {
  persistDraft();
  flushAnalytics();
}

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    checkpoint();
  }
});

window.addEventListener('pagehide', checkpoint);

Both events may fire during the same navigation, so the work should be idempotent. The goal is not to predict the exact end of a session. It is to move important work earlier, while execution is still available.

pagehide: is this document being left through navigation?

pagehide is navigation-aware. It can fire when a document is replaced, reloaded or closed, and it is compatible with bfcache. Its persisted property tells the page whether the user agent may preserve the document for reuse. In the current HTML definition, true means the page might be reused if it remains salvageable; it is not a promise that the user will return.[3]

It is useful when the application needs to distinguish a navigation away from a mere tab switch. It is still not a universal “last chance” event: a page that goes into the background and is killed later may never receive it.[13]

pageshow: was this document restored?

pageshow runs on the initial presentation and after a bfcache restoration. When event.persisted is true, the page is returning with preserved runtime state rather than starting from a normal reload.

window.addEventListener('pagehide', () => {
  pauseLiveUpdates();
});

window.addEventListener('pageshow', event => {
  if (event.persisted) {
    refreshTimeSensitiveData();
  }

  resumeLiveUpdates();
});

This restoration path is easy to overlook. A page can return with old timestamps, stale authentication assumptions, an expired API result or a connection that no longer exists. The correct response is usually selective revalidation, not a forced reload that throws away the benefit of bfcache. At product level, this is a mobile UX problem of interruption and recovery as much as a browser API problem.

There is no single interoperable Page Lifecycle API

“Page lifecycle” is useful terminology, but it can imply more standardization than the platform currently provides.

Some pieces are established web-platform APIs: Page Visibility, pagehide, pageshow, beforeunload, unload, Beacon and Fetch. The HTML Living Standard defines the page-transition events and their persisted state.[3]

The familiar state diagram containing active, passive, hidden, frozen, terminated and discarded is largely associated with Chrome guidance and the WICG Page Lifecycle proposal. It is a valuable model of browser behavior, but not one fully interoperable API that applications can use identically in every engine.[9][10]

That distinction matters. Chrome exposes lifecycle-related mechanisms such as freeze, resume and document.wasDiscarded. Developers can progressively enhance around them, but should not build a cross-browser correctness requirement on Chromium-only hooks.

Analytics after unload

Analytics helped make exit handlers sticky. An end-of-session batch seemed efficient, and blocking the next navigation with synchronous XHR improved delivery rates. It also delayed the user, consumed scarce mobile resources and still could not solve process termination.

The Beacon API was designed for small, asynchronous, non-blocking reports. The user agent queues a request with Fetch’s keepalive flag, and the specification tells it to schedule pending beacons when the document becomes hidden. navigator.sendBeacon() returns true when the data was accepted into the queue, not when the server received it.[11]

function flushAnalytics() {
  const events = readPendingEvents();

  if (events.length === 0) {
    return;
  }

  const body = JSON.stringify(events);
  navigator.sendBeacon('/analytics', body);
}

That last distinction is important. Beacon improves the chance that a small report can continue without blocking navigation, but it is not a guaranteed delivery system. A device can lose connectivity. A process can be killed before a request is queued. The browser can reject an oversized batch. The server can fail after the client has moved on.

fetch() with keepalive: true is the more flexible option when code needs custom headers, methods or other Fetch behavior. It is still subject to normal Fetch and CORS rules, and keepalive request bodies are deliberately limited; current Fetch semantics cap the aggregate queued body size at 64 KiB.[18]

For ordinary analytics, a sensible pattern is to send data periodically or after meaningful events, then make one last best-effort flush on visibilitychange when the page becomes hidden. For information that the product cannot afford to lose—a payment, a saved document, a security action—the application should obtain an explicit server acknowledgement while it is active. Analytics transport is not a transaction protocol.

State persistence and the narrow role of beforeunload

User state should not accumulate in memory until a theoretical exit. Drafts and client-side edits are safer when persisted on meaningful changes, with debouncing to control write frequency, plus a visibility-loss checkpoint. The exact storage layer depends on the application: a small preference may fit in localStorage; structured offline data generally belongs in IndexedDB; authoritative records should be confirmed by the server.

This is less dramatic than a final save callback, and that is the point. Durability works better as an ongoing property than as an emergency action.

Session termination needs the same rethink. A server should not rely on a browser page to announce that a person has “left.” Tabs crash, networks vanish and devices sleep. Expiry, revocable credentials, server-side session state and, where appropriate, heartbeats are better foundations than an exit beacon.

When beforeunload is still appropriate

beforeunload is not a drop-in replacement for unload. Its legitimate use is much narrower: asking the browser to warn a user who is about to abandon unsaved work.

Modern browsers require prior user interaction before showing the dialog, display browser-controlled generic text, and may not fire the event on mobile when the browser is killed from the background. Firefox also excludes pages with beforeunload listeners from bfcache. The listener should therefore exist only while the page is genuinely dirty, and be removed as soon as the work is safe.[12]

function warnAboutUnsavedChanges(event) {
  event.preventDefault();
  event.returnValue = '';
}

function setDirty(isDirty) {
  const method = isDirty ? 'addEventListener' : 'removeEventListener';
  window[method]('beforeunload', warnAboutUnsavedChanges);
}

The dialog is a user-facing safety net, not a persistence mechanism. The application should already be saving what it can.

Resource cleanup without a final callback

“Close everything in unload” sounds disciplined, but it combines resources with very different lifetimes. The better question is what must happen while the page is still observable, what must be reversible after restoration, and what the browser can reclaim by destroying the process.

Durable application data
Commit it as part of the user action or shortly afterward. An IndexedDB transaction should not depend on a final page event to become meaningful.

User-sensitive capture
Camera, microphone and screen-capture tracks should follow explicit product and visibility rules. Stop them when the user should reasonably expect capture to end, not merely because a document might be destroyed.

Long-lived connections
WebSockets and WebRTC sessions may need to pause, close or reconnect depending on the product. Any action taken on pagehide must account for the possibility of a later pageshow.

Cross-context coordination
Web Locks, BroadcastChannel messages and worker coordination should tolerate a participant disappearing without a farewell message. Reacquire or resynchronize when the page becomes active again.

Timers, observers and background work
Assume they can be throttled, frozen or terminated. Pause work that has no value while hidden, but do not treat a timer callback as evidence that the page will remain alive.

Bfcache eligibility rules for particular APIs also evolve as engines learn to suspend them safely. A static list copied into application architecture will age badly. Test the actual page, inspect current browser diagnostics, and keep correctness independent from whether the browser chooses to cache, freeze or destroy it.

Browser differences still matter

The direction of travel is shared, but the details remain engine-specific.

WebKit and Safari

WebKit has unusually long historical memory here. Its engineers were documenting the conflict between unload handlers and the Page Cache in 2009, and the cache itself predates Safari’s first public beta. WebKit’s solution was to make navigation suspendable and to use pagehide/pageshow for state that can be left and restored.[4][5]

Current compatibility guidance describes Safari as prioritizing its page cache over firing unload in relevant cases. That is good for history-navigation performance and another reason not to treat observed desktop behavior in one engine as a cross-browser guarantee.[19]

Gecko and Firefox

Firefox’s bfcache lineage is also early. Mozilla’s Firefox 1.5 documentation explains that entire pages, including JavaScript state, could be kept in memory, and introduced pageshow/pagehide as the way to cooperate with that model.[6]

On current Firefox, unload listeners can still prevent bfcache use, and MDN documents the same issue for beforeunload. That makes conditional listener registration particularly important.[12][19]

Chromium and Chrome

Chromium came later to broad bfcache deployment and spent years on compatibility work and outreach. Chrome’s unload deprecation now flips the old desktop tradeoff: instead of sacrificing bfcache to preserve a callback that was already unreliable on mobile, Chrome is progressively making the callback disabled by default.[1]

Chrome also has the richest current diagnostics, including a DevTools bfcache test and PerformanceNavigationTiming.notRestoredReasons. That API shipped in Chrome 123 and can expose blocking reasons such as an unload listener, including reasons found in same-origin frames. It should be treated as a Chromium diagnostic, not assumed to exist everywhere.[14]

The common baseline is still useful: Page Visibility and the page-transition events are broadly implemented. The edges—what blocks bfcache, which resources can be frozen, whether an exit event fires, and which diagnostics are exposed—must be tested per engine and device class.

What Chrome is changing in 2026

Chrome is not simply deleting the unload property in one release. It is changing the default behavior in stages so that registered handlers stop firing unless the page has opted back in.

Chrome unload deprecation schedule from one percent of page loads in March 2026 to a planned one hundred percent in September 2026.
Chrome’s published all-origin schedule as of August 29, 2026. Percentages are shares of Chrome page loads; dates and milestones may change.[1]

The rollout follows earlier work on the top 50 sites during 2025. For all other origins, Chrome’s published 2026 stages are:

  • : 1%
  • : 5%
  • : 10%
  • : 20%
  • : 40%
  • : 60%
  • : 80%
  • : planned 100%

Sites can currently control the transition with the unload Permissions Policy. A site that has removed its dependency can disable the event deliberately with:

Permissions-Policy: unload=()

A top-level document that needs temporary compatibility can opt back in with:

Permissions-Policy: unload=self

Cross-origin frames need compatible policy declarations through the ancestor chain and appropriate iframe permissions. Chrome also provides enterprise policy and local testing flags. These are migration controls, not a new reliability guarantee: opting in does not make the event dependable on mobile.[20]

Chrome says its long-term aim is to remove unload, but the published schedule covers staged changes to whether handlers fire by default. It does not schedule physical removal of the API.[2]

How to audit an unload dependency

Start by finding the dependency, including code you did not write. Search first-party source, compiled bundles, tag-manager output and third-party frames for unload, onunload and unconditional beforeunload registration.

Then test behavior rather than stopping at source search:

  1. Use Chrome DevTools’ Application → Back/forward cache test.
  2. Navigate away and back, then inspect pageshow and event.persisted.
  3. Collect field diagnostics with notRestoredReasons where Chromium support is acceptable.
  4. Use a report-only unload Permissions Policy to discover attempted registrations before enforcing the policy.
  5. Repeat the test in Safari and Firefox, on desktop and mobile hardware.
Decision map matching former unload use cases to analytics delivery, state persistence, pagehide, conditional beforeunload and reversible resource handling.
There is no universal replacement event. Migrate according to the job the old handler was trying to perform.

Analytics

Batch during the session and make a best-effort Beacon or Fetch keepalive flush when visibility becomes hidden. Do not promise delivery that the transport cannot guarantee.

State saving

Persist on meaningful changes, debounce routine writes, and checkpoint on visibility loss. Treat server acknowledgement as the authority for critical records.

Navigation detection

Use pagehide. If the page changes resources or pauses work, add a corresponding pageshow restoration path.

Unsaved-change warning

Register beforeunload only while unsaved user work actually exists, and remove it immediately after saving.

Resource cleanup

Decide whether the resource needs early release, reversible suspension or no script cleanup at all. Test current bfcache behavior instead of relying on old blocker lists.

Session termination

Move authority to the server: expiry, revocation, acknowledgement and resilient presence logic. A disappearing tab cannot be a trusted logout signal.

MobileTech’s 2026 homepage audit examined startup weight, JavaScript and third-party pressure. Bfcache affects a different phase—return navigation—but reinforces the same architectural point: application-like pages need explicit lifecycle design as well as a fast initial load.[21]

From document teardown to application resilience

The deprecation of unload is easy to frame as browser housekeeping. That misses the larger change.

The early web inherited a document lifecycle: load the page, use it, tear it down. The modern web increasingly behaves like an application platform running inside another application, under an operating system that may pause, cache, discard or kill it. Navigation itself may preserve the document rather than destroy it.

So the platform’s advice has moved earlier. Save state while the page is still visible or when it first becomes hidden. Send analytics without blocking the next action. Treat navigation as potentially reversible. Restore time-sensitive state when a cached page returns. Use beforeunload only when the user genuinely needs a warning.

The page may receive another event. It may come back exactly where it was. Or it may disappear without one last line of JavaScript.

That is not a lifecycle edge case anymore. It is the lifecycle.

]]> Mobile Web Performance Reality Check 2026: Public Benchmarks and a 39-Site Homepage Audit https://www.mobiletech.mobi/mobile-web-performance-reality-check-2026-public-benchmarks-and-a-site-homepage-audit/ Tue, 09 Jun 2026 00:21:32 +0000 https://www.mobiletech.mobi/?p=426 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.

Bar chart comparing public benchmark figures with focused audit results for good Core Web Vitals pass rate, LCP weakness, and homepage complexity signals. Public benchmark Focused 39-site audit 0% 20% 40% 60% 80% Good CWV pass rate 56.4% origins in CrUX 28.2% pages in audit Pages with poor LCP 38% mobile experiences not good 59.0% pages above 2.5s Pages with image LCP 76% mobile pages 59.0% audit pages Sources: Web Almanac 2025, CrUX April 2026, and the focused 39-site audit.
Benchmark data compared with the focused 39-site homepage audit.

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:

Source What it contributes
HTTP Archive / Web Almanac 2025 Performance Core Web Vitals pass rates, LCP/INP/CLS patterns, LCP content types, prioritization practices
HTTP Archive / Web Almanac 2025 Page Weight Median mobile page weight and resource composition
HTTP Archive / Web Almanac 2025 Third Parties Third-party prevalence, request counts, request categories
HTTP Archive / Web Almanac 2025 Ecommerce Ecommerce platform-level Core Web Vitals differences
Chrome UX Report release notes and documentation Current origin-level field status for Core Web Vitals
Google / web.dev Core Web Vitals documentation Metric definitions, thresholds, and optimization guidance
PageSpeed Insights / Lighthouse documentation How to read lab vs field data and what diagnostics can and cannot prove

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

Vertical Sites Median LH score Median LCP ms Median INP ms Median CLS Median TBT ms Median total MB Median JS MB Median image MB Median requests Median ext-domain reqs
Ecommerce 5 33 2681 279 0.14 1318 3.47 2.27 0.37 229 189
News / media 5 40 1297 131 0.01 739 6.69 3.66 1.53 599 494
SaaS 6 38 3108 292 0.14 1033 5.90 2.22 1.18 250 148
Travel 5 41 2813 338 0.17 663 3.56 2.24 0.78 184 159
Finance 6 35 2778 210 0.11 1395 3.30 2.59 0.13 162 107
Government 6 62 1278 120 0.00 58 1.10 0.49 0.20 46 8
Blogs / publishing 6 74 2568 130 0.00 37 1.52 0.67 0.23 68 32

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.

Horizontal bar chart comparing median LCP in milliseconds across seven verticals in the 39-site audit. 2.5s good LCP threshold News / media 1297 ms Government 1278 ms Blogs / publishing 2568 ms Ecommerce 2681 ms Finance 2778 ms Travel 2813 ms SaaS 3108 ms Source: focused 39-site audit; median field LCP from CrUX.
Median mobile LCP by vertical in the focused 39-site audit.

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.

Horizontal bars showing how many pages in the 39-site audit crossed specific risk thresholds for LCP, INP, JavaScript transfer, total transfer, external-domain requests, and CLS. 0 10 20 30 39 pages LCP above 2.5s 23 pages INP above 200ms 19 pages More than 1 MB JS 25 pages More than 3 MB total 20 pages More than 50 ext-domain reqs 27 pages CLS above 0.1 16 pages Threshold counts from the focused 39-site audit described in this article.
Pages crossing key performance-risk thresholds in the focused audit.

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

Surface type Suggested mobile priority
Government / public service Keep text-first, minimize JS, avoid unnecessary external dependencies
Ecommerce homepage Prioritize hero/product LCP, limit early personalization, reserve promo and product image space
News/media homepage Control ad and analytics waterfalls, isolate embeds, monitor external request growth
SaaS marketing Cap animation and hydration cost, simplify above-the-fold sections
Travel search Delay non-critical widgets, isolate calendar and map cost, protect INP explicitly
Finance Audit JS boot cost, defer non-auth-critical scripts, measure responsiveness under real interaction
Publishing platforms Separate lightweight reading surfaces from heavy feed/onboarding surfaces

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

]]>