H5秒开方案大全( 二 ) _H5

如果使用了 PWA 的 HTML 页面，能否直接缓存呢？由于 PWA 可精细化控制缓存，答案是可以的。
对于直出 HTML，我们可以配合 PWA，将从后台直出的文件，缓存到 cacheStorage，在下一次请求时，优先从本地缓存中获取，同时发起网络请求更新本地 html 文件。
但是在 hybrid 的 h5 应用，第一次启动的加载资源仍然费时，我们可以通过 App 端上支持预加载一个 JAVAscript 脚本，拉取需要 PWA 缓存的页面，可以提前完成缓存。
对于非直出的页面，我们仍然无法避免浏览器渲染 html 时间的问题，应该如何 kill 调这里的时间呢？
这里明确两个点，第一次永远只能靠提前加载，所以上面的借助端上预加载脚本任然生效；第二点非直出页面，每个页面需要有独一无二的标记，比如 hash 。浏览器获取到数据，并且渲染好的 html，能够通过 outerHTML 方法，将 html 页面缓存到 cacheStorage 中，第二次访问任然优先从本地获取，同时发起 html 请求，通过对比其中唯一标识的差异，决定是否需要更新。

文章插图

PWA 一系列方案替代离线包策略，带来的好处是，属于 web 标准，适用于普通能够支持 service-worker 的 H5 页面。在允许兼容问题允许的情况下，建议主加。
NSR 渲染
GMTC2019 全球大前端技术上 UC 团队提到了 0.3 秒的 “闪开” 方案。NSR 就是前端版本的 SSR，非常具有启发性。
其核心思路是，借助浏览器启用一个 JS-Runtime，提前将下载好的 html 模板及预取的 feed 流数据进行渲染，然后将 HTML 设置到内存级别的 MemoryCache 中，从而达到点开即看的效果。
NSR 将 SSR 渲染的过程分发到了各个用户的端中，在减少了后台请求压力的同时，也加进一步快了页面打开速度，堪称做到极致。
问题是数据预取和预渲染带来额外的流量和性能开销，特别是流量，如何更准确的预测用户行为，提高命中率是非常重要的事。类似 NSR 的方案我们也在逐步探索中。
客户端 PWA
在实际测试、及和浏览器团队的同学了解和沟通中，service-worker 在 webview 实现性能并没有想象中好。在某项目下掉 sw 后，整体大盘访问速度整体反而提升上升了大概 300ms 。
这对 hybrid 应用而言，就提出了一项新的思路和挑战，能否在客户上实现一套基本的 service-worker api？从而达到和 web 标准相兼容。这里也只是一种思路和想法，有大量待探索的问题点，比如 webview sw 具体的性能现状，未来的支持情况呢，自行实现的成本，及最终带来的效果和价值等。
小程序化
小程序生态已经非常成熟了，各大厂也都已经推出了自己平台的小程序，国内厂商也不断在尝试推进 MiniApp w3c 标准。不管从加载速度还是页面流畅度小程序都要高于 H5 页面，其原因是通过在架构上对开发进行规范化和约束化，小程序内部将 webview 渲染和 js 执行分离开来，然后通过离线包，页面拆分，预加载页面等一系列优化手段，让小程序天然具备了大量的 H5 优化后的效果，其代价是牺牲了 web 的灵活性。但对于 hybrid 开发，通过原生客户端底层支持这种小程序环境，然后大量业务逻辑采用小程序方案开发，来达到迭代速度与性能兼并的效果，是一种非常不错的方向。
结
本文主要总结了这几天大量阅读梳理十几篇关于秒开的文章和及最近的一些思考与实践，从中提取出了部分具有代表性的方案。
不管哪种类型的方案，发现其总的思路和方向都是：