整页重量，都显在首开
营销页、结账流、数据看板——在手机上打开，浏览器便开始拉取。移动端网页首屏平均要传输约 2.2 MB（2164 KB） 资源（HTTP Archive Web Almanac 2025，2025 年 7 月爬取），其中 JavaScript 中位数就有 646–697 KB（压缩后），一个典型页面还有 22 个 独立脚本请求。其中约 251 KB（解压后，中位数）是根本没执行的 JavaScript。模型是「先拉文档，再拉它需要的」——而首次打开，用户为这一切买单。
H5 把重量一次前置
浏览器当然能代码分割、懒加载、路由切分。但主流模式仍是「一个入口包带着框架、路由、共用 UI 一起跑」。即便很自律，页面重量仍是用户「能用之前」必须下载的那一个数。JavaScript 是字节成本最高的资源（web.dev / Google）：下载后还要在主线程解析、编译、执行，所以大包会直接拖慢可交互时间。在中端设备上，1 MB+ 的包足以把可交互时间推过用户流失的临界点。
更深的症结是结构性的：浏览器没有「只要外壳、其余稍后」的概念。一切都是 URL 拉取，而第一次拉取就是整段体验。
小程序只下载主包
小程序以「包」交付，而非「页」。微信官方规定：主包不超过 2 MB，整包不超过 20 MB（腾讯云 / 官方文档）。启动时只下载主包——默认启动页、TabBar，以及所有分包共用的资源。分包（每个 ≤2 MB）只在用户进入时才拉取。独立分包 甚至可以脱离主包加载，活动页、营销页正是借此快速启动而不拖垮整包。
关键在于：拆分由平台强制，而非靠开发者自律。第一次下载天生有界且小巧。
预下载规则把等待藏起来
即便按需下载，在好的实现里也毫无感知。通过 app.json 的 preloadRule，宿主能在用户跳转之前就预取某页面可能需要的分包——进入首页时便在后台静默拉回「important」分包。等用户点击时，下一块屏幕通常已在设备上。平台还会在流量与存储间做平衡，单页预下载上限 2 MB，绝不会悄悄耗尽用户流量。
于是体验变成：首下极小，其余流式下发且往往已就位。H5 的对应手段——按路由懒加载——仍在每次首次进入新 chunk 时付一次拉取。
逐项对比
| 维度 | H5 / 移动网页 | 小程序 |
|---|---|---|
| 首下体积 | 约 2.2 MB 中位数整页重量 | 仅主包（≤2 MB）于启动时 |
| 包拆分 | 手动代码分割 / 懒 import | 平台强制分包（每包≤2 MB，整包≤20 MB） |
| 进入子页 | 首次访问拉取新 chunk | 分包已预取或按需拉取 |
| 冗余代码 | 约 251 KB 未用 JS 中位数 | 仅包所引用内容 |
| 预载控制 | Service Worker / 应用壳启发式 | 声明式 preloadRule，单页上限 2 MB |
| 大屏隔离 | 无 | 独立分包可脱离主包启动 |
对你的构建意味着什么
如果你的流程是「轻入口后藏几个重屏」，小程序让门保持轻、房间流式下发。这在新客获取页和低端 Android 上最为关键——2 MB 主包胜过 2 MB+ 单包，因为只有外壳在关键路径上。H5 仍赢在开放网络：分享链接、落地页、SEO 入口——但宿主内的体验，不该在不必全量下发时把整副重量压在首开。
Cross Mini App 的位置
Cross Mini App 给你的小程序一个 runtime 与开放 catalog，天然继承这套「拆分下发」模型。按标准 API 面构建一次，每个嵌入的宿主只下载入口所需、其余按平台规则流式下发，而非重新拉取一个庞然大物般的整包。首下体积是被刻意收束的。H5 带来访客，小程序留住他们，且不收重量税。
