移动 WEB 通用优化策略介绍(一)

共 2709 字 约 7 分钟 8 年前 39 评论

❗ 本文最后更新于 3131 天前,文中所描述的信息可能已发生改变,请谨慎使用。

在我去年的《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_1js_1js_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 通用优化策略第一要点需要完善下:

重要的 CSS、JS、JSON 数据直接内联在 HTML 中,头部禁止出现任何外链资源。同时,尽可能减少页面传输体积。

好了,这个系列的开篇先就写这么多。还是老规矩,如果有任何问题和疑问欢迎留言,我会及时回复。

本文链接:https://imququ.com/post/wpo-of-mobile-web-1.html参与评论 »

--EOF--

Comments

Waline 评论加载中...