移动 WEB 通用优化策略介绍（一）

发表于 5年以前 | 总阅读数：2065 次

在我去年的《AMP，来自 Google 的移动页面优化方案》这篇文章里，我给自己挖了个坑：

借助客户端所做的优化，如现在广为流行的移动端 Webview 容器加速方案，优化效果局限在指定 APP 内，甚至还会导致使用通用浏览器访问速度更慢（这个话题很有意思，有机会以后再讨论）。

现在过去快半年，我终于想起来把这个坑填上，今天先来写这个系列第一篇。

我在标题里用了「通用」二字，说明我要介绍的优化策略不是为特定的 Webview 容器定制，它面向的是所有主流的移动端浏览器，包括各种 APP 嵌入的通用 Webview。

借助定制化的 Webview 容器，我们完全可以通过主动提前本地化资源包，使得移动 WEB 应用跟 Native 应用一样，只需走网络获取必要的数据。这种情况下的性能优化，更多需要关注代码执行效率，本地化资源包的推送流程和成功率。

而对于通用的移动 WEB 性能优化，首先要考虑的是网络传输性能。

我们知道，浏览器获取一个资源，花在网络上的时间开销至少有这几块：DNS 解析、建立 TCP 连接、发送请求、等待响应、传输响应正文。相比 PC 的网络环境，移动端更为糟糕，集中在这几点：高时延、高丢包、低速率、多劫持。

所以，在移动 WEB 上，引入外链资源的网络成本非常高。在我们最近的一次测试中，移动端同域名空图片（使用 Nginx 的 empty_gif 指令构造）加载失败率（我们对失败的定义是触发图片的 error 事件，或者超过 9s 仍未触发 load 事件）高达 2%，外域图片失败率还要高上几个百分点。

我们还知道，头部的外链 CSS、JS 会阻塞页面渲染，通俗来讲就是头部的这些外链资源加载完之前，页面会一直白屏。之前我们统计过，一个 GZip 后十几 KB 的头部 JS，会增加大概半秒的白屏时间。

基于上述原因，我的移动 WEB 通用优化策略第一要点：

重要的 CSS、JS 直接内联在 HTML 中，头部禁止出现任何外链资源。

需要注意的是，很多性能评估工具 / 文档都说 HTML 头部不要有任何 JS。实际上这一点在实际项目中很难做到，至少大部分页面性能监控就需要在头部计时（Web Performance API 并不能解决所有性能监控问题）。对于头部内联 JS，我只有两点要求：1）没有耗时操作；2）只保留必要代码。

现在很多 WEB 应用，尤其是 SPA，服务端往往都只提供 RESTful 数据接口。这样页面 JS 代码执行过程中，还要异步获取数据，在数据加载完成之前，页面一片空白或者只有 Loading。这么做也违背了我提出的第一要点，要解决这个问题最简单的做法是服务端直接将首屏数据以 JSON 变量的形式输出到页面上；高级点的方案是利用 JavaScript 同构框架，首屏直接输出 HTML。

将重要 CSS、JS 甚至数据接口都内联在页面上，可以减少由于移动网络环境造成的页面呈现慢或者不可用等情况，但是也带来另外的问题：多次请求之间无法利用缓存，浪费流量，也让移动网络低速率的问题雪上加霜。

为了聚焦，本文不讨论代码压缩、传输压缩以及清理无用代码等减少文件体积等基础优化项目，也不讨论异步或按需加载的资源。我们假设要加载的所有内容都是首屏必须且压缩过的。那么，对于用户首次访问，内联无疑是最优选择，因为无论如何这些资源都要加载，能减少连接数就是最大的改进。那么，如何解决用户后续访问，内联导致的无法利用 HTTP 缓存机制的问题呢？

我们引入了 localStorage 方案：用户首次访问时，服务端输出包含内联 CSS、JS 和 JSON 数据的页面，并通过 JS 将这些数据存入 localStorage；用户后续访问时，服务端只需要输出从 localStorage 读取并执行代码的 JS 片段即可。这样，后续访问的页面体积就小很多了。

可以看到，这个方案的难点在于：1）服务端如何得知用户本地存有 localStorage；2）服务端如何得知用户本地存的 localStorage 中的某个具体文件的版本是否最新。有同学会说，把存入 localStorage 的文件及对应版本都记在 Cookie 里不就可以了？但别忘了往 Cookie 里存太多信息，本身就是一种错误的做法。况且，如果 Cookie 信息完好，但 localStorage 却被清除要怎么处理？

为此，我们设计了一整套流程。首先，我们引入了由以下字符组成的 70 进制：


0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~!()*_-.

它们会被用来在 Cookie 中存放文件路径及版本号，70 进制意味着可以用单字符区分 70 种不同的文件或版本。另外，这 70 个字符都无需编码即可存入 Cookie。

然后，在编译流程中，对全站代码里所有需要存入 localStorage 的资源（我们通过外链标签是否存在某个自定义属性来判断）进行分析，生成文件名及对应版本号的 Map 文件。示意如下：


{

        'file/path/to/js/1.js' : { filename : '0', version : '0', md5 : '‍xxx'},
        'file/path/to/js/2.js' : { filename : '1', version : '0', md5 : 'yyy'},
        'file/path/to/css/1.css' : { filename : '2', version : '0', md5 : 'zzz'},
    }

这份配置每次编译都需要重新构建，但有两点需要保证：1）相同文件路径对应的 70 进制字符标记必须固定；2）文件内容 md5 发生变化时，对应的版本号需要 +1。每个使用到本方案的页面头部都需要包含这份配置。

那么对于下面这样的原始 HTML 代码片段：


<link rel="stylesheet" href="file/path/to/css/1.css" lsname="css_1" />

    <script src="file/path/to/js/1.js" lsname="js_1"></script>
    <script src="file/path/to/js/2.js" lsname="js_2"></script>

用户首次访问时，将以这样的形式输出：


<style id="css_1">‍‍/* the content of 1.css... */</style>

    <script>LS.html2ls("css_1");LS.updateVersion('cookie_name','0','0')</script>
    <script id="js_1">‍‍/* the content of 1.js... */</script>
    <script>LS.html2ls("js_1");LS.updateVersion('cookie_name','1','0')</script>
    <script id="js_2">‍‍/* the content of 2.js... */</script>
    <script>LS.html2ls("js_2");LS.updateVersion('cookie_name','2','0')</script>

这时，用户本地将会新增 css_1、js_1、js_2 三份 localStorage 数据，以及取值为 001020 的一个 Cookie。

用户再次访问时，服务端会分析 Cookie，找出对应文件在 Map 配置中的版本号，与 Cookie 中的版本进行比较，如果都没有变化，则只会输出这样少量的代码：


<script>LS.ls2html("css_1","style","cookie_name")</script>

    <script>LS.ls2html("js_1","script","cookie_name")</script>
    <script>LS.ls2html("js_2","script","cookie_name")</script>

这样，浏览器就会从 localStorage 中取出之前存储的内容，创建相应的标签并执行。

如果之前的资源有改动，编译后 Map 配置文件就会更新。假设 js_1 已经迭代到版本 3，那么服务端会输出这样的代码：


<script>LS.ls2html("css_1","style","cookie_name")</script>

    <script id="js_1">‍‍/* the new content of 1.js ... */</script>
    <script>LS.html2ls("js_1");LS.updateVersion('cookie_name','1','3')</script>
    <script>LS.ls2html("js_2","script","cookie_name")</script>

可以看到，只有本次更新的资源才会输出全部内容。这份代码执行完之后，本地 js_1 这份 localStorage 会随之更新，Cookie 也会更新为 001320。

看到这里，大家应该明白这个方案的基本原理了，这个方案需要在服务端处理一系列复杂的分支判断，具体实现代码我就不贴了。下面说几个需要特别关注的点：

首先，移动端部分浏览器在隐私模式下，访问 localStorage 对象会直接抛出异常，必须把 localStorage 的几个方法包装一下，加上 try。

其次，如果 Cookie 中的标记存在，但是 localStorage 内容丢失如何处理？我们来看这行代码：


LS.ls2html("css_1","style","cookie_name")

它执行的具体操作是：查找 localStorage 中名为 css_1 的内容，找到之后创建 style 标签并插入页面。第三个参数值 cookie_name 是为了在读取 localStorage 失败时，能够清掉这个 Cookie 标记，然后刷新页面。这时，服务端发现 Cookie 标记不存在，就会全量输出内联内容，等同于用户首次访问。

另外，我们用单字符标记文件名和版本，容量只有 70。每个项目中，允许同时有 70 个不同的文件存入 localStorage，完全够用。假设一个文件每周修改两次版本，那么 70 个版本号会在大半年后循环到起点。假设用户浏览器存在某个文件的版本 0，大半年期间一直没来访问，直到这个文件的版本号轮回到 0 他再访问一次，这时候服务端会认为他本地的文件已经是最新的。这种极端情况我们评估后认为完全可以接受。如果实在不放心，可以将文件或版本扩充为两位来表示，就能应对 4900 种不同情况。

有些 Webview 没有开启 localStorage 功能，如果我们检测到这种情况，就额外记一个 Cookie 标记，服务端看到这个标记，每次直接全量输出内联。同样，如果 Webview 连 Cookie 也不支持，那么最终效果也是每次都全量内联，至少不比优化前差。

实际上，还可以采用类似于购物车的做法实施这套方案：在用户浏览器存一个 Cookie 标识，然后服务端通过 Redis 这样的 KV 服务来找出曾经给他发送过哪些资源及各自版本。这样做的好处是代码逻辑简单，但需要引入外部服务。

资源内联可以缓解移动端网络的高时延、高丢包等问题；而资源 localStorage 化可以应对低速率；二者结合使用，才能有最好的效果。也就是说，我前面提出的移动 WEB 通用优化策略第一要点需要完善下：