导语

随着移动设备性能不断增强，web 页面的性能体验逐渐变得可以接受，又因为 web 开发模式的诸多好处(跨平台，动态更新，减体积，无限扩展)，APP 客户端里出现越来越多内嵌 web 页面（为了配上当前流行的说法，以下把所有网页都称为 H5 页面，虽然可能跟 H5 没关系），很多 APP 把一些功能模块改成用 H5 实现。

虽然说 H5 页面性能变好了，但如果没针对性地做一些优化，体验还是很糟糕的，主要两部分体验：

页面启动白屏时间：打开一个 H5 页面需要做一系列处理，会有一段白屏时间，体验糟糕。
响应流畅度：由于 webkit 的渲染机制，单线程，历史包袱等原因，页面刷新/交互的性能体验不如原生。

本文先不讨论第二点，只讨论第一点，怎样减少白屏时间。对 APP 里的一些使用 H5 实现的功能模块，怎样加快它们的启动速度，让它们启动的体验接近原生。

过程

为什么打开一个 H5 页面会有一长段白屏时间？因为它做了很多事情，大概是：

初始化 webview -> 请求页面 -> 下载数据 -> 解析HTML -> 请求 js/css 资源 -> dom 渲染 -> 解析 JS 执行 -> JS 请求数据 -> 解析渲染 -> 下载渲染图片

一些简单的页面可能没有 JS 请求数据这一步，但大部分功能模块应该是有的，根据当前用户信息，JS 向后台请求相关数据再渲染，是常规开发方式。

一般页面在 dom 渲染后能显示雏形，在这之前用户看到的都是白屏，等到下载渲染图片后整个页面才完整显示，首屏秒开优化就是要减少这个过程的耗时。

前端优化

上述打开一个页面的过程有很多优化点，包括前端和客户端，常规的前端和后端的性能优化在桌面时代已经有最佳实践，主要的是：

降低请求量：合并资源，减少 HTTP 请求数，minify / gzip 压缩，webP，lazyLoad。
加快请求速度：预解析DNS，减少域名数，并行加载，CDN 分发。
缓存：HTTP 协议缓存请求，离线缓存 manifest，离线数据缓存localStorage。
渲染：JS/CSS优化，加载顺序，服务端渲染，pipeline。

其中对首屏启动速度影响最大的就是网络请求，所以优化的重点就是缓存，这里着重说一下前端对请求的缓存策略。我们再细分一下，分成 HTML 的缓存，JS/CSS/image 资源的缓存，以及 json 数据的缓存。

HTML 和 JS/CSS/image 资源都属于静态文件，HTTP 本身提供了缓存协议，浏览器实现了这些协议，可以做到静态文件的缓存，具体可以参考这里（https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching ），总的来说，就是两种缓存：

询问是否有更新：根据 If-Modified-Since / ETag 等协议向后端请求询问是否有更新，没有更新返回304，浏览器使用本地缓存。
直接使用本地缓存：根据协议里的 Cache-Control / Expires 字段去确定多长时间内可以不去发请求询问更新，直接使用本地缓存。

前端能做的最大限度的缓存策略是：HTML 文件每次都向服务器询问是否有更新，JS/CSS/Image资源文件则不请求更新，直接使用本地缓存。那 JS/CSS 资源文件如何更新？常见做法是在在构建过程中给每个资源文件一个版本号或hash值，若资源文件有更新，版本号和 hash 值变化，这个资源请求的 URL 就变化了，同时对应的 HTML 页面更新，变成请求新的资源URL，资源也就更新了。

json 数据的缓存可以用 localStorage 缓存请求下来的数据，可以在首次显示时先用本地数据，再请求更新，这都由前端 JS 控制。

这些缓存策略可以实现 JS/CSS 等资源文件以及用户数据的缓存的全缓存，可以做到每次都直接使用本地缓存数据，不用等待网络请求。但 HTML 文件的缓存做不到，对于 HTML 文件，如果把 Expires / max-age 时间设长了，长时间只使用本地缓存，那更新就不及时，如果设短了，每次打开页面都要发网络请求询问是否有更新，再确定是否使用本地资源，一般前端在这里的策略是每次都请求，这在弱网情况下用户感受到的白屏时间仍然会很长。所以 HTML 文件的“缓存”和跟“更新”间存在矛盾。

客户端优化

接着轮到客户端出场了，桌面时代受限于浏览器，H5 页面无法做更多的优化，现在 H5 页面是内嵌在客户端 APP 上，客户端有更多的权限，于是客户端上可以超出浏览器的范围，做更多的优化。

HTML 缓存

先接着缓存说，在客户端有更自由的缓存策略，客户端可以拦截 H5 页面的所有请求，由自己管理缓存，针对上述 HTML 文件的“缓存”和“更新”之间的矛盾，我们可以用这样的策略解决：

在客户端拦截请求，首次请求 HTML 文件后缓存数据，第二次不发请求，直接使用缓存数据。
什么时候去请求更新？这个更新请求可以客户端自由控制策略，可以在使用本地缓存打开本地页面后再在后台发起请求询问更新缓存，下次打开时生效；也可以在 APP 启动时或某个时机在后台去发起请求预更新，提升用户访问最新代码的几率。

这样看起来已经比较完美了，HTML 文件在用客户端的策略缓存，其余资源和数据沿用上述前端的缓存方式，这样一个 H5 页面第二次访问从 HTML 到 JS/CSS/Image 资源，再到数据，都可以直接从本地读取，无需等待网络请求，同时又能保持尽可能的实时更新，解决了缓存问题，大大提升 H5 页面首屏启动速度。

问题

上述方案似乎已完整解决缓存问题，但实际上还有很多问题：

没有预加载：第一次打开的体验很差，所有数据都要从网络请求。
缓存不可控：缓存的存取由系统 webview 控制，无法控制它的缓存逻辑，带来的问题包括： i. 清理逻辑不可控，缓存空间有限，可能缓存几张大图片后，重要的 HTML/JS/CSS 缓存就被清除了。 ii.磁盘 IO 无法控制，无法从磁盘预加载数据到内存。
更新体验差：后台 HTML/JS/CSS 更新时全量下载，数据量大，弱网下载耗时长。
无法防劫持：若 HTML 页面被运营商或其他第三方劫持，将长时间缓存劫持的页面。

这些问题在客户端上都是可以被解决的，只不过有点麻烦，简单描述下：

可以配置一个预加载列表，在APP启动或某些时机时提前去请求，这个预加载列表需要包含所需 H5 模块的页面和资源，还需要考虑到一个H5模块有多个页面的情况，这个列表可能会很大，也需要工具生成和管理这个预加载列表。
客户端可以接管所有请求的缓存，不走 webview 默认缓存逻辑，自行实现缓存机制，可以分缓存优先级以及缓存预加载。
可以针对每个 HTML 和资源文件做增量更新，只是实现和管理起来比较麻烦。
在客户端使用 httpdns + https 防劫持。

上面的解决方案实现起来十分繁琐，原因就是各个 HTML 和资源文件很多很分散，管理困难，有个较好的方案可以解决这些问题，就是离线包。

离线包

既然很多问题都是文件分散管理困难引起，而我们这里的使用场景是使用 H5 开发功能模块，那很容易想到把一个个功能模块的所有相关页面和资源打包下发，这个压缩包可以称为功能模块的离线包。使用离线包的方案，可以相对较简单地解决上述几个问题：

可以预先下载整个离线包，只需要按业务模块配置，不需要按文件配置，离线包包含业务模块相关的所有页面，可以一次性预加载。
离线包核心文件和页面动态的图片资源文件缓存分离，可以更方便地管理缓存，离线包也可以整体提前加载进内存，减少磁盘 IO 耗时。
离线包可以很方便地根据版本做增量更新。
离线包以压缩包的方式下发，同时会经过加密和校验，运营商和第三方无法对其劫持篡改。

到这里，对于使用 H5 开发功能模块，离线包是一个挺不错的方案了，简单复述一下离线包的方案：

后端使用构建工具把同一个业务模块相关的页面和资源打包成一个文件，同时对文件加密/签名。
客户端根据配置表，在自定义时机去把离线包拉下来，做解压/解密/校验等工作。
根据配置表，打开某个业务时转接到打开离线包的入口页面。
拦截网络请求，对于离线包已经有的文件，直接读取离线包数据返回，否则走 HTTP 协议缓存逻辑。
离线包更新时，根据版本号后台下发两个版本间的 diff 数据，客户端合并，增量更新。

最后

从前端优化，到客户端缓存，到离线包，到更多的细节优化，做到上述这些点，H5 页面在启动上差不多可以媲美原生的体验了。

总结起来，大体优化思路就是：缓存/预加载/并行，缓存一切网络请求，尽量在用户打开之前就加载好所有内容，能并行做的事不串行做。这里有些优化手段需要做好一整套工具和流程支持，需要跟开发效率权衡，视实际需求优化。

另外上述讨论的是针对功能模块类的 H5 页面秒开的优化方案，客户端 APP 上除了功能模块，其他一些像营销活动/外部接入的 H5 页面可能有些优化点就不适用，还需要视实际情况和需求而定。另外微信小程序就是属于功能模块的类别，差不多是这个套路。

这里讨论了 H5 页面首屏启动时间的优化，上述优化过后，基本上耗时只剩 webview 本身的启动/渲染机制问题了，这个问题跟后续的响应流畅度的问题一起属于另一个优化范围，就是类 RN / Weex 这样的方案，有机会再探讨。

如果您觉得我们的内容还不错，就请转发到朋友圈，和小伙伴一起分享吧~

导语

过程

前端优化

客户端优化

HTML 缓存

问题

离线包

更多优化

公共资源包

预加载 webview

预加载数据

Fallback

使用客户端接口

服务端渲染

最后