第一秒，就是转化率
打开行情、点下买入、扫码进店——在交易型流程里，第一秒不只是观感，而是用户判断「这是个真产品」还是「一个可能打不开的网页」的时刻。同一台手机上两种技术给出两种第一秒：从网络拉取的 H5 页面，与早已候在设备上的小程序。
差别不在「网页慢、原生快」，而在等待发生在哪里：H5 把第一秒花在和网络谈判上，受管 runtime 则把第一秒花在用户点击之前。
H5 每次都要交网络税
H5 页面是从 URL 拉取的文档。冷启动无缓存时，浏览器要先初始化 WebView、请求 HTML、解析 DOM、再拉取并解析 CSS 与 JS、执行脚本，最后才绘制。在中端 Android 设备上，无缓存时首屏往往要 1.5–3 秒，首次内容绘制约 1.2 秒，可交互时间接近 2.2 秒。每一步都等连接，弱网下的长尾又长又抖。
Service Worker 能优化回访，但模型仍是「先拉页面，再尽量记住它」。而最关乎获取的首次打开——永远被网络拴着。
小程序，是预载而来的
小程序不会在用户点击时才去拉取自己。宿主早已初始化好 runtime，框架、应用外壳、往往连首屏内容都已打包缓存在设备里。微信官方明确规定包体积上限——主包不超过 2MB、整包不超过 20MB（含虚拟支付的游戏为 30MB）——正是为了让冷启动下载保持小而可控。分包按需下载，而预下载规则让宿主在用户跳转前就把下一个分包取回。
端到端实测，小程序冷启动约 800–1200 毫秒，约为 H5 的一半；温启动与热启动近乎瞬开，因为运行环境已在后台预热（runtime 常驻后，仅容器初始化就只需 10–20 毫秒）。这些等待都不在「点击→绘制」的关键路径上。
runtime 如何把等待前置
受管 runtime 的三项结构性选择，是裸浏览器页面做不到的：
- 环境预热：宿主在 App 启动时预初始化 JS 引擎与基础库，小程序继承一个已在运行的 runtime，而不是临时去启动一个。
- 包预下载：外壳、框架、首屏在意图产生前就下发到设备——靠预测、靠预下载规则、靠显式预载调用，而非等用户开口。
- 有界、可拆分的下发：分包与体积上限让下载保持小巧，而双线程模型（逻辑与渲染分离）避免重脚本阻塞首屏。
心智模型：H5 是「先拉再跑」，小程序是「早已在此，直接跑」。
逐项对比
| 维度 | H5 / 移动网页 | 小程序 |
|---|---|---|
| 冷启动（无缓存） | 首屏约 1.5–3.0 秒 | 含包下载约 0.8–1.2 秒 |
| 温/热启动 | 仍重拉资源 | 近乎瞬开（runtime 常驻） |
| 首屏驱动 | 网络 + 解析 + 执行 | 本地包 + 已预热 runtime |
| 交付单元 | 按需拉取的 URL 文档 | 预缓存包（主包≤2MB，整包≤20MB） |
| 拆分加载 | 手动代码分割 | 内置分包 + 预下载规则 |
| runtime 初始化成本 | 首次打开时支付 | 宿主启动时一次性支付 |
对你的流程意味着什么
登录、结账、行情、扫码进场这类交易型核心，冷启动的差距就是「能用」与「是个网页」之间的差距。把交易核心搬进小程序，团队常能直接看到完成率与留存的变化——因为意图产生的瞬间，迎面而来的是一块已经就绪的屏幕。H5 仍握着开放网络的入口——分享链接、活动页、SEO 页面——但宿主内的交易核心，不该在不必等待时还被网络拴着。
Cross Mini App 的位置
Cross Mini App 是预载模型下的 runtime 与开放 catalog。你只需按标准 API 面构建一次小程序，它便在每一个嵌入的宿主（即时通讯、钱包、超级 App）里继承一个已预热、预缓存的 runtime，而非每次进入都重新拉取。第一秒是设计进去的，不是和网络谈判来的。H5 仍是门，小程序则是那间早已亮灯的房间。
