The first second is the conversion
Open a stock quote, tap a buy button, scan a QR to enter a store. In a transactional flow the first second is not cosmetic — it is where users decide whether this feels like a real product or a webpage that might not work. Two technologies sitting on the same phone produce two very different first seconds: an H5 page fetched over the network, and a mini-program that was already waiting on the device.
The difference is not "web is slow and native is fast." It is where the wait happens. H5 spends its first second negotiating with the network; a governed runtime spends it before the user ever taps.
H5 pays the network tax every time
An H5 page is a document fetched from a URL. On a cold start with no cache, the browser must initialize the WebView, request the HTML, parse the DOM, fetch and parse CSS and JavaScript, execute the scripts, then paint. On a mid-range Android device that pipeline runs 1.5–3 seconds before first paint when nothing is cached, with first contentful paint around 1.2s and time-to-interactive near 2.2s. Every step waits on the connection, and on patchy mobile networks the tail is long and jumpy.
Service workers can shave repeat visits, but the model is still "fetch a page, then try to remember it." The first open — the one that matters most for acquisition — is always network-bound.
Mini-programs arrive pre-loaded
A mini-program does not fetch itself when the user taps. The host has already initialized the runtime, and the framework, the app shell, and often the first screen of content are packaged and cached on the device. WeChat documents hard package limits — a main package no larger than 2MB and a total program no larger than 20MB (30MB for mini-games) — precisely so the cold-start download stays small and predictable. Subpackages download on demand, and preload rules let the host fetch the next subpackage before the user navigates to it.
Measured end to end, a mini-program cold start lands around 800–1200ms, roughly half the H5 figure, and warm or hot starts are near-instant because the environment was warmed up in the background (container initialization alone is often 10–20ms once the runtime is resident). None of that wait is paid on the critical tap-to-paint path.
How the runtime front-loads the wait
The gains come from three structural choices a governed runtime makes that a bare browser page cannot:
- Environment warm-up. The host pre-initializes the JavaScript engine and base library at app launch, so the mini-program inherits a running runtime instead of booting one.
- Package pre-download. The shell, framework, and first screen ship to the device ahead of intent — by prediction, by preload rules, or by an explicit preload call — not after the user asks.
- Bounded, split delivery. Subpackages and size limits keep the download small, while the dual-thread model (logic and render separated) stops heavy scripts from blocking the first paint.
The mental model: H5 is fetch then run; a mini-program is already here, then run.
Side by side
| Dimension | H5 / Mobile Web | Mini-Program |
|---|---|---|
| Cold start (no cache) | ~1.5–3.0s to first paint | ~0.8–1.2s including package download |
| Warm / hot start | Still re-fetches assets | Near-instant (runtime resident) |
| First paint driver | Network + parse + execute | Local package + warm runtime |
| Delivery unit | URL document, fetched on demand | Pre-cached package (main ≤2MB, total ≤20MB) |
| Split loading | Manual code-splitting | Built-in subpackages + preload rules |
| Runtime init cost | Paid on first open | Paid once at host launch |
What this means for your flow
For a login, a checkout, a market quote, or a scan-to-enter flow, the cold-start gap is the gap between "this works" and "this is a webpage." Teams that move the transactional core into a mini-program routinely report the difference showing up directly in completion and retention, because the moment of intent is met with a screen that is already there. H5 still owns the open-web surface — the shared link, the campaign, the SEO page — but the in-host transactional core should not wait on the wire when it does not have to.
Where Cross Mini App fits
Cross Mini App is the runtime and the open catalog for the pre-loaded model. You build a mini-program once against a standard API surface, and it inherits a warmed, pre-cached runtime in every host that embeds it — messenger, wallet, or super-app — instead of being re-fetched on every entry. The first second is designed in, not negotiated with the network. H5 stays the door; the mini-program is the room that is already lit.
