The signal is never guaranteed
Most mobile time is spent on networks that are fine until they are not — a subway car between stations, a stadium at kickoff, a rural road, a roaming border. For a broker refreshing a position, a rider accepting an order, or a clerk scanning a ticket, the moment the signal dips is exactly when the screen must keep working. Two models on the same phone handle that moment very differently, and the difference is measured in white screens.
H5 can hope the connection holds. A mini-program is built so the connection is the optional part.
H5 re-fetches the world on every open
An H5 page is a document fetched from a URL, and every open is a fresh negotiation with the network. The browser pays DNS, TCP, and TLS handshakes for each origin, then pulls HTML, CSS, JavaScript, and images in a chain where each step waits on the previous. The cost is not theoretical: the HTTP Archive 2025 Web Almanac measured the median mobile page at 2,164 KB of total weight with 22 separate JavaScript requests averaging 646 KB of script. On a flaky link, every one of those requests is a chance to stall, and a single render-blocking stylesheet or script holds the first paint hostage.
The result is visible in the field. The same report found mobile Time to First Byte met the "good" bar on only 44% of pages, and median mobile Total Blocking Time reached 1,916 ms — rising to 7,555 ms at the 90th percentile. A page can look loaded while the main thread is too busy to answer a tap. On patchy mobile networks, the tail is long and jumpy, and a white screen is the default failure mode when the wire does not cooperate.
A mini-program only asks for data
A mini-program does not re-fetch its own body on every open. The package — framework, shell, and first screen — was delivered and cached on a previous launch, often by prediction or a preload rule while the signal was good. When the user taps, the UI paints from local assets, and only small JSON data requests cross the wire. The heavy, failure-prone assets are simply not on the critical path.
The runtime also gives the program explicit tools the browser page lacks. WeChat documents a default 60-second timeout for network requests (configurable per call or globally), and the onNetworkStatusChange API lets the app detect a drop and switch behavior — show cached data, queue the action, retry when the link returns — instead of leaving the user on a blank page. Subpackage preload rules (preloadRule) fetch the next screen while the connection is healthy, so navigation never waits on a weak link.
Where the resilience actually comes from
- Pre-cached package. The shell and first screen are local; the visible UI opens without a network round trip.
- Small data surface. Only live requests are exposed to the flaky link — not stylesheets, not frameworks, not images.
- Network awareness. The runtime reports signal changes so the app can degrade gracefully rather than blindly retry.
- Predictable weak-network behavior. Because the assets are already on the device, the experience degrades by seconds of data latency, not by a full white screen.
Side by side
| Dimension | H5 / Mobile Web | Mini-Program |
|---|---|---|
| What crosses the wire on open | HTML + CSS + JS + images | Only live data (JSON) |
| Median mobile weight | ~2,164 KB total, ~646 KB JS | Package cached; ~KB-scale requests |
| Signal drop on open | White screen until assets load | UI paints from cache; data retries |
| TBT exposure (mobile median) | 1,916 ms; 7,555 ms at p90 | Logic/network isolated from paint |
| Network awareness | Hand-built, if at all | Built-in status API + timeout control |
| Degradation shape | Binary: loads or blank | Graceful: cached view + queued calls |
What this means for your flow
For any flow that happens in the real world — a transit check-in, a field sale, a market refresh in a basement — network resilience is the difference between a completed action and a dead screen. H5 can reach the same place, but only by hand-building and maintaining a service worker, a caching strategy, and a retry layer that most pages never ship. A mini-program gets the resilient shape by default, because the part that breaks on mobile (the asset download) is the part it already finished earlier.
Where Cross Mini App fits
Cross Mini App is the runtime and the open catalog for the resilience-by-default model. A mini-program built once against a standard API surface runs inside any host with its package pre-cached and its data layer intact, so the screen opens and the cached view is there even when the link is weak. The network becomes the optional layer, not the foundation. H5 stays the door; the mini-program is the room that stays lit when the signal flickers.
Sources
- WeChat Mini Program — Network request (wx.request, 60s default timeout)
- Tencent Cloud — Mini Program network configuration & timeouts
- HTTP Archive Web Almanac 2025 — Performance (TBT, page weight, requests)
- web.dev by Google — Total Blocking Time (TBT)
- WeChat Mini Program — Subpackages & preloadRule
