Speed is not a feature, it is the funnel
A millisecond is not neutral. Akamai's State of Online Retail Performance report — built on roughly 10 billion retail visits — found that a 100-millisecond delay in load time cuts conversion by 7%, and a two-second delay raises bounce rate by 103%. Google's mobile research puts it bluntly: 53% of mobile visitors leave a page that takes longer than three seconds. Portent's analysis of 100M+ page views shows a site that loads in 1 second converts 2.5x to 5x better than a slower one, and Deloitte and Google measured that a 0.1-second mobile speed improvement lifts retail conversions by 8.4% and average order value by 9.2%. On the open web, slow is a leak you pay for on every visit.
H5 pays the latency tax on every cold start
An H5 page inside a WebView rebuilds itself from scratch on each cold start: the document is fetched, the JavaScript is parsed and compiled, the framework boots, and only then can the first meaningful interaction happen. The Web Almanac 2025 reports a median mobile page of about 2,164 KB and 646–697 KB of JavaScript across ~22 script requests — all of that work sits on the critical path before the user can act. There is no pre-warmed environment and no pre-downloaded package, so the first second is spent negotiating with the network, not serving the user. In finance, that first second is the difference between a filled order and an abandoned checkout.
A mini-program spends that second before the tap
A governed runtime pre-warms the container: the logic engine and render layer are initialized and kept ready, and the package is pre-downloaded (main package ≤ 2 MB, streamed subpackages ≤ 20 MB total via platform-enforced preloadRule). When the user taps, the runtime is already alive and the code is already local, so time-to-interactive is near-instant — the warm and hot starts are effectively free. The cost that H5 pays on every visit is amortized to near zero because it was spent before the user ever arrived. That is the structural reason mini-programs feel "instant" while H5 keeps re-paying the latency tax.
Side by side
| Dimension | H5 / WebView (cold) | Mini-Program (runtime) |
|---|---|---|
| Cold start cost | Fetch + parse + compile JS every visit | Container pre-warmed, package pre-downloaded |
| First interaction | Seconds on the critical path | Near-instant (warm/hot start) |
| 100ms delay impact | −7% conversion (Akamai) | Pre-warmed; near-zero cold cost |
| 3s load | 53% mobile abandon (Google) | Package cached; sub-second TTI |
| Speed→revenue | 0.1s faster = +8.4% conv (Deloitte/Google) | Hot-start delta is negligible |
| Input responsiveness | Long tasks block INP | Render thread keeps INP low |
What this means for conversion
For transactional surfaces — sign-up, KYC, checkout, trade entry — speed is the product. Portent's data points to a 1–2 second target for pages that take payment, because conversion drops an average of 0.3% for every additional second. A runtime that removes the cold-start tax is not a cosmetic win; it directly protects the funnel on the low-end Android devices that make up most of the global installed base. H5 remains the right tool for the open web and content, but the in-host surface where money moves should not bleed conversions to a slow first paint.
Where Cross Mini App fits
Cross Mini App is the runtime and open catalog for this model. You build a mini-program against a standard API surface and it inherits a pre-warmed, pre-downloaded launch path in every host that embeds it — not an H5 page that re-pays the latency tax on every visit. Instant is designed in, so the funnel does not leak before the first tap. H5 tells the story; the mini-program keeps the user.
Sources
- Akamai — State of Online Retail Performance (milliseconds matter)
- Think with Google — The need for mobile speed
- Portent — Site speed still impacts conversion rate
- Deloitte & Google — Milliseconds Make Millions
- HTTP Archive — Web Almanac 2025, performance & JavaScript
- web.dev — Interaction to Next Paint (INP)
