H5性能优化调研

首屏打开速度

首屏渲染可以分为三个阶段。

• Native 的耗时 ≈ WebWindow 创建 + WebView 初始化

理论上可以优化，但这是一个 Native 要解决的问题

• 网络的耗时 ≈ DNS + TCP(SSL) + 服务端渲染耗时(如果采用 SSR 的话) + Document 下载

H5资源离线加载，或是webview容器创建之前加载，需要客户端支持。

• 渲染的耗时 ≈ Ajax(CSR) + JS scripting(CSR 耗时) + 浏览器 Painting(内核)

前端可以优化，纯前端手段有限（ssr）

通常意义上，前端开发者所说的“渲染”，其实指的是将页面分拆为数据和模板，然后根据一定的规则拼接形成完整 HTML 结构的过程。

SSR

如果这个过程在浏览器中完成，我们则称之 CSR！如果在服务端完成，那么就是 SSR！

• SSR:首次加载会更快，但是在不同页面之间导航都需要下载新的HTML内容。它的跨浏览器兼容性良好，但代价是页间加载时间延长，也就是总体感知上的性能降低：每加载一个页面，都需要一个服务器请求往返的时间。

• CSR:允许在导航到不同页面时几乎立即在浏览器中更新网站，但在开始时需要更多的初始下载和客户端上的额外渲染。 首次访问时网站速度较慢，但后续访问速度要快得多。

• 将 SSR 与 CSR 混用可以获得最佳效果，在服务器上渲染网站，缓存其内容，然后在客户端需要时更新渲染。因为使用了 SSR，第一页加载很快；因为客户端可以仅使用已更改的部分重新渲染页面，所以页面之间的导航也是平滑的。

NSR

NSR(Native side rendering)就是在客户端（Native 侧）实现页面数据与结构的拼装，进而实现页面渲染的处理技术。在用户访问的那一刻，页面所需的“资源”不再依赖网络而从内核的内存级缓存中获取，然后直接交给渲染引擎执行最后的处理，达到理论上的完成页面渲染的最短路径。
参考：https://www.infoq.cn/article/9UKos4Xh_6wL4Fh1FOGL

小程序

小程序生态已经非常成熟了，各大厂也都已经推出了自己平台的小程序，国内厂商也不断在尝试推进 MiniApp w3c 标准。不管从加载速度还是页面流畅度小程序都要高于 H5 页面，其原因是通过在架构上对开发进行规范化和约束化，小程序内部将 webview 渲染和 js 执行分离开来，然后通过离线包，页面拆分，预加载页面等一系列优化手段，让小程序天然具备了大量的 H5 优化后的效果，其代价是牺牲了 web 的灵活性。但对于 hybrid 开发，通过原生客户端底层支持这种小程序环境，然后大量业务逻辑采用小程序方案开发，来达到迭代速度与性能兼并的效果，是一种非常不错的方向。

PWA+直出+预加载

渐进式 Web 应用（PWA），作为 web 标准，能够通过纯 web 的方案去加速和优化加载性能。

首先，pwa 通过 Service Worker 创建一个独立的线程，用来进行一些资源请求与缓存的工作。另一方面，在传统的 http cache 中，我们一般不会缓存 html，这是因为页面一旦设置了过长的 max-age，在浏览器缓存过期时间内，用户看到的永远将是旧的。由于 pwa 可精细化控制缓存，对于 html，我们可以配合 pwa，将从后台直出的文件，缓存到 cacheStorage，在下一次请求时，优先从本地缓存中获取，同时发起网络请求更新本地 html 文件。

但是在 hybrid 开发中的 h5 应用，第一次启动的加载资源仍然费时，我们可以通过 app 端上支持预加载一个 javascript 脚本，拉取需要 PWA 缓存的页面，可以提前完成缓存。

对于非直出的页面，我们仍然无法避免浏览器渲染 html 时间的问题，应该如何减少这里的时间呢？

这里明确两个点，第一次永远只能靠提前加载，所以上面的借助端上预加载脚本仍然生效；第二点非直出页面，每个页面需要有独一无二的标记，比如 hash。浏览器获取到数据，并且渲染好的 html，能够通过 outerHTML 方法，将 html 页面缓存到 cacheStorage 中，第二次访问优先从本地获取，同时发起 html 请求，通过对比其中唯一标识的差异，决定是否需要更新。

pwa 一系列方案替代离线包策略，带来的好处是，属于 web 标准，适用于普通能够支持 service-worker 的 H5 页面。