前面讲了前端优化和客户端的优化。我们最后来讲讲细节上的优化。
细节多重优化
离线包方案在缓存上已经做得差不多了，还可以再配上一些细节优化：
公共资源包
每个包都会使用相同的 JS 框架和 CSS 全局样式，这些资源重复在每一个离线包出现太浪费，可以做一个公共资源包提供这些全局文件。
预加载 webview
为什么打开一个 H5 页面会有一长段白屏时间？因为它做了很多事情，大概是：
一、.首次预加载：在一个进程内首次初始化 webview 与第二次初始化不同，首次会比第二次慢很多。原因预计是 webview 首次初始化后，即使 webview 已经释放，但一些多 webview 共用的全局服务或资源对象仍没有释放，第二次初始化时不需要再生成这些对象从而变快。我们可以在 APP 启动时预先初始化一个 webview 然后释放，这样等用户真正走到 H5 模块去加载 webview时就变快了。
二、.webview 池：可以用两个或多个 webview 重复使用，而不是每次打开 H5 都新建 webview。不过这种方式要解决页面跳转时清空上一个页面，另外若一个 H5 页面上 JS 出现内存泄漏，就影响到其他页面，在 APP 运行期间都无法释放了。
预加载数据
理想情况下离线包的方案第一次打开时所有 HTML/JS/CSS 都使用本地缓存，无需等待网络请求，但页面上的用户数据还是需要实时拉，这里可以做个优化，在 webview 初始化的同时并行去请求数据，webview 初始化是需要一些时间的，这段时间没有任何网络请求，在这个时机并行请求可以节省不少时间。
具体实现上，首先可以在配置表注明某个离线包需要预加载的 URL，客户端在 webview 初始化同时发起请求，请求由一个管理器管理，请求完成时缓存结果，然后 webview 在初始化完毕后开始请求刚才预加载的 URL，客户端拦截到请求，转接到刚才提到的请求管理器，若预加载已完成就直接返回内容，若未完成则等待。
三、Fallback
如果用户访问某个离线包模块时，这个离线包还没有下载，或配置表检测到已有新版本但本地是旧版本的情况如何处理？几种方案：
1.简单的方案是如果本地离线包没有或不是最新，就同步阻塞等待下载最新离线包。这种用户打开的体验更差了，因为离线包体积相对较大。
2.也可以是如果本地有旧包，用户本次就直接使用旧包，如果没有再同步阻塞等待，这种会导致更新不及时，无法确保用户使用最新版本。
3.还可以对离线包做一个线上版本，离线包里的文件在服务端有一一对应的访问地址，在本地没有离线包时，直接访问对应的线上地址，跟传统打开一个在线页面一样，这种体验相对等待下载整个离线包较好，也能保证用户访问到最新。
第三种 Fallback 的方式还带来兜底的好处，在一些意外情况离线包出错的时候可以直接访问线上版本，功能不受影响，此外像公共资源包更新不及时导致版本没有对应上时也可以直接访问线上版本，是个不错的兜底方案。
上述几种方案策略也可以混着使用，看业务需求。
使用客户端接口
网路和存储接口如果使用 webkit 的 ajax 和 localStorage 会有不少限制，难以优化，可以在客户端提供这些接口给 JS，客户端可以在网络请求上做像 DNS 预解析/IP直连/长连接/并行请求等更细致的优化，存储也使用客户端接口也能做读写并发/用户隔离等针对性优化。
服务端渲染
早期 web 页面里，JS 只是负责交互，所有内容都是直接在 HTML 里，到现代H5页面，很多内容已经依赖 JS 逻辑去决定渲染什么，例如等待 JS 请求 JSON 数据，再拼接成 HTML 生成 DOM 渲染到页面上，于是页面的渲染展现就要等待这一整个过程，这里有一个耗时，减少这里的耗时也是白屏优化的范围之内。
优化方法可以是人为减少 JS 渲染逻辑，也可以是更彻底地，回归到原始，所有内容都由服务端返回的 HTML 决定，无需等待 JS 逻辑，称之为服务端渲染。是否做这种优化视业务情况而定，毕竟这种会带来开发模式变化/流量增大/服务端开销增大这些负面影响。手Q的部分页面就是使用服务端渲染的方式，称为动态直出。
最后
从前端优化，到客户端缓存，到离线包，到更多的细节优化，做到上述这些点，H5 页面在启动上差不多可以媲美原生的体验了。
总结起来，大体优化思路就是：缓存/预加载/并行，缓存一切网络请求，尽量在用户打开之前就加载好所有内容，能并行做的事不串行做。这里有些优化手段需要做好一整套工具和流程支持，需要跟开发效率权衡，视实际需求优化。
另外上述讨论的是针对功能模块类的 H5 页面秒开的优化方案，客户端 APP 上除了功能模块，其他一些像营销活动/外部接入的 H5 页面可能有些优化点就不适用，还需要视实际情况和需求而定。另外微信小程序就是属于功能模块的类别，差不多是这个套路。
这里讨论了 H5 页面首屏启动时间的优化，上述优化过后，基本上耗时只剩 webview 本身的启动/渲染机制问题了，这个问题跟后续的响应流畅度的问题一起属于另一个优化范围，就是类 RN / Weex 这样的方案，有机会再探讨。
一个H5首屏时间的优化方案大致就是前端优化、客户端优化和细节优化了，以后还会给大家继续分享H5技术方面的知识。