The whole page shows up in the weight
A marketing site, a checkout flow, a dashboard — open it on a phone and the browser begins pulling. The median mobile web page now transfers about 2.2 MB (2,164 KB) of resources on first view (HTTP Archive Web Almanac 2025, July 2025 crawl), with JavaScript alone at a median of 646–697 KB compressed and 22 separate script requests on a typical page. A chunk of that — about 251 KB uncompressed, median — is JavaScript that never runs. The model is "fetch the document, then fetch what it needs," and on first open the user pays for all of it.
H5 ships the weight up front
Browsers can code-split, lazy-load, and route-split. But the dominant pattern is still one entry bundle that drags the framework, the route, and the shared UI along for the ride. Even with discipline, the page weight is a single number the user downloads before anything is useful. JavaScript is the most expensive resource byte-for-byte (web.dev / Google): after download it must be parsed, compiled, and executed on the main thread, so a heavy bundle delays interactivity directly. On a mid-range device a 1 MB+ bundle can push time-to-interactive well past the point where users bounce.
The deeper issue is structural: the browser has no notion of "only the shell, the rest later." Everything is a URL fetch, and the first fetch is the whole experience.
Mini-programs download only the main package
A mini-program is delivered as packages, not a page. WeChat's documented limits are a main package no larger than 2 MB and a total program no larger than 20 MB (Tencent Cloud / official docs). On launch only the main package downloads — the default launch page, the TabBar, and the common resources every subpackage shares. Subpackages (each ≤2 MB) are fetched only when the user navigates into them. An independent subpackage can even load without the main package, which is how activity and campaign pages launch fast without dragging the whole app down.
The key is that the split is enforced by the platform, not left to developer discipline. The first download is bounded and small by construction.
Preload rules hide the wait
Even the on-demand download is invisible in good implementations. With preloadRule in app.json, the host prefetches the subpackage a page is likely to need before the user navigates — when entering the home page it can quietly pull the "important" subpackage in the background. By the time the tap happens, the next screen is usually already on the device. The platform balances this against traffic and storage, capping preload size per page at 2 MB so it never silently drains the user's data.
So the experience is: tiny first download, rest streamed and often already present. H5's equivalent — route-based lazy loading — still pays a fetch on every first navigation into a new chunk.
Side by side
| Dimension | H5 / Mobile Web | Mini-Program |
|---|---|---|
| First-download size | ~2.2 MB median page (whole weight) | Main package only (≤2 MB) at launch |
| Bundle split | Manual code-split / lazy import | Platform-enforced subpackages (each ≤2 MB, total ≤20 MB) |
| On navigation | Fetch the new chunk on first visit | Subpackage already prefetched or fetched on demand |
| Unused code | ~251 KB unused JS median | Only what the package references |
| Preload control | Service worker / app shell heuristics | Declarative preloadRule, capped at 2 MB/page |
| Large-screen isolation | N/A | Independent subpackages launch without main package |
What this means for your build
If your flow is a few heavy screens behind a light entry, a mini-program keeps the door light and streams the rooms. That matters most on the acquisition screen and on low-end Android, where a 2 MB main package beats a 2 MB+ single bundle because only the shell is on the critical path. H5 still wins for the open web — the link, the landing page, the SEO surface — but the in-host experience should not ship its whole weight on first open when it does not have to.
Where Cross Mini App fits
Cross Mini App gives your mini-program a runtime and an open catalog that inherit this split-delivery model. Build once against a standard API surface; every host that embeds it downloads only what the entry needs and streams the rest by platform rules, instead of re-fetching a monolithic bundle. The first download is bounded on purpose. H5 brings the visitor; the mini-program keeps them without the weight tax.
