速度不是功能，是漏斗本身
一毫秒并非中性。Akamai 的《在线零售性能报告》基于约 100 亿 次零售访问发现：100 毫秒 的加载延迟会让转化下降 7%，而两秒延迟会让跳出率上升 103%。Google 的移动研究说得直接：加载超过三秒，53% 的移动访客会离开页面。Portent 对 1 亿多次页面浏览的分析显示，1 秒加载的网站转化率比慢站高 2.5 到 5 倍；德勤与 Google 测得 0.1 秒 的移动速度提升能让零售转化提高 8.4%、平均客单价提高 9.2%。在开放网络上，慢，就是一笔每次访问都要付的泄漏。
H5 在每次冷启动都交延迟税
WebView 里的 H5 页面，每次冷启动都要从零重建：拉取文档、解析并编译 JavaScript、框架启动，之后才能进行第一次有意义的交互。Web Almanac 2025 显示移动端中位页面约 2,164 KB、646–697 KB 的 JavaScript 分散在约 22 个 script 请求中——这些工作全部压在关键路径上，用户才能操作。没有预热环境，也没有预下载包，所以第一秒花在「和网络谈判」，而非服务用户。在金融场景，这一秒就是成交订单与放弃结账之间的距离。
小程序把这一秒花在点击之前
受管 runtime 会预热容器：逻辑引擎与渲染层被初始化并保持就绪，包也被预下载（主包 ≤ 2 MB，经平台强制的 preloadRule 流式拉取分包，整包 ≤ 20 MB）。用户点击时，runtime 早已存活、代码已在本地，因此可交互时间近乎瞬间——温启动与热启动实际上免费。H5 每次访问都要交的这笔成本，被摊薄到近乎为零，因为它在「用户到来之前」就已经花掉了。这正是小程序感觉「秒开」、而 H5 不断重交延迟税的结构性原因。
逐项对比
| 维度 | H5 / WebView（冷启动） | 小程序（runtime） |
|---|---|---|
| 冷启动成本 | 每次访问都拉取 + 解析 + 编译 JS | 容器预热，包预下载 |
| 首次交互 | 关键路径上耗时数秒 | 近乎瞬间（温/热启动） |
| 100ms 延迟影响 | 转化 −7%（Akamai） | 已预热，冷成本近零 |
| 3 秒加载 | 53% 移动端放弃（Google） | 包已缓存，TTI 亚秒级 |
| 速度→收入 | 快 0.1s = 转化 +8.4%（德勤/Google） | 热启动增量可忽略 |
| 输入响应 | 长任务阻塞 INP | 渲染线程，INP 低 |
对你的转化意味着什么
对交易型界面——注册、KYC、结账、下单——速度就是产品本身。Portent 的数据指向一个 1–2 秒 的收款页目标，因为每增加一秒，转化平均下降 0.3%。一个消除了冷启动税的 runtime，不是锦上添花，而是直接守护漏斗——尤其是在占全球装机主体量的低端 Android 上。H5 仍是开放网络与内容的正确工具，但宿主内「钱在流动」的界面，不该因一次慢首屏而漏掉转化。
Cross Mini App 的位置
Cross Mini App 是这一模型的 runtime 与开放 catalog。你按标准 API 面构建小程序，它便在每一个嵌入的宿主里继承一条预热、预下载的启动路径——而非一个每次访问都重交延迟税的 H5 页面。秒开是被设计进去的，漏斗不会在第一次点击前就漏。H5 讲故事，小程序留住用户。
