BT

前端工程精粹(一):静态资源版本更新与缓存

作者 张云龙 发布于 2013年9月12日 |

每个参与过开发企业级web应用的前端工程师或许都曾思考过前端性能优化方面的问题。我们有雅虎14条性能优化原则,还有两本很经典的性能优化指导书:《高性能网站建设指南》、《高性能网站建设进阶指南》。经验丰富的工程师对于前端性能优化方法耳濡目染,基本都能一一列举出来。这些性能优化原则大概是在7年前提出的,对于web性能优化至今都有非常重要的指导意义。

然而,对于构建大型web应用的团队来说,要坚持贯彻这些优化原则并不是一件十分容易的事。因为优化原则中很多要求是与工程管理相违背的,比如“把css放在头部”和“把js放在尾部”这两条原则,我们不能让团队的工程师在写样式和脚本引用的时候都去修改一个相同的页面文件。这样做会严重影响团队成员间并行开发的效率,尤其是在团队有版本管理的情况下,每天要花大量的时间进行代码修改合并,这项成本是难以接受的。因此在前端工程界,总会看到周期性的性能优化工作,辛勤的前端工程师们每到月圆之夜就会倾巢出动根据优化原则做一次性能优化。

 

本文从一个全新的视角来思考web性能优化与前端工程之间的关系,通过解读百度前端集成解决方案小组(F.I.S)在打造高性能前端架构并统一百度40多条前端产品线的过程中所经历的技术尝试,揭示前端性能优化在前端架构及开发工具设计层面的实现思路。

性能优化原则及分类

笔者先假设本文的读者是有前端开发经验的工程师,并对企业级web应用开发及性能优化有一定的思考,因此我不会重复介绍雅虎14条性能优化原则。如果您没有这些前续知识,请移步这里来学习。

首先,我们把雅虎14条优化原则,《高性能网站建设指南》以及《高性能网站建设进阶指南》中提到的优化点做一次梳理,按照优化方向分类,可以得到这样一张表格:

优化方向

优化手段

请求数量

合并脚本和样式表,CSS Sprites,拆分初始化负载,划分主域

请求带宽

开启GZip,精简JavaScript,移除重复脚本,图像优化

缓存利用

使用CDN,使用外部JavaScript和CSS,添加Expires头,减少DNS查找,配置ETag,使AjaX可缓存

页面结构

将样式表放在顶部,将脚本放在底部,尽早刷新文档的输出

代码校验

避免CSS表达式,避免重定向

表格1 性能优化原则分类

目前大多数前端团队可以利用yui compressor或者google closure compiler等压缩工具很容易做到“精简Javascript”这条原则;同样的,也可以使用图片压缩工具对图像进行压缩,实现“图像优化”原则。这两条原则是对单个资源的处理,因此不会引起任何工程方面的问题。很多团队也通过引入代码校验流程来确保实现“避免css表达式”和“避免重定向”原则。目前绝大多数互联网公司也已经开启了服务端的Gzip压缩,并使用CDN实现静态资源的缓存和快速访问;一些技术实力雄厚的前端团队甚至研发出了自动CSS Sprites工具,解决了CSS Sprites在工程维护方面的难题。使用“查找-替换”思路,我们似乎也可以很好的实现“划分主域”原则。

我们把以上这些已经成熟应用到实际生产中的优化手段去除掉,留下那些还没有很好实现的优化原则。再来回顾一下之前的性能优化分类:

优化方向

优化手段

请求数量

合并脚本和样式表,拆分初始化负载

请求带宽

移除重复脚本

缓存利用

添加Expires头,配置ETag,使Ajax可缓存

页面结构

将样式表放在顶部,将脚本放在底部,尽早刷新文档的输出

表格2 较难实现的优化原则

现在有很多顶尖的前端团队可以将上述还剩下的优化原则也都一一解决,但业界大多数团队都还没能很好的解决这些问题。因此,本文将就这些原则的解决方案做进一步的分析与讲解,从而为那些还没有进入前端工业化开发的团队提供一些基础技术建设意见,也借此机会与业界顶尖的前端团队在工业化工程化方向上交流一下彼此的心得。

静态资源版本更新与缓存

如表格2所示,“缓存利用”分类中保留了“添加Expires头”和“配置ETag”两项。或许有些人会质疑,明明这两项只要配置了服务器的相关选项就可以实现,为什么说它们难以解决呢?确实,开启这两项很容易,但开启了缓存后,我们的项目就开始面临另一个挑战:如何更新这些缓存。

相信大多数团队也找到了类似的答案,它和《高性能网站建设指南》关于“添加Expires头”所说的原则一样——修订文件名。即:

最有效的解决方案是修改其所有链接,这样,全新的请求将从原始服务器下载最新的内容。

思路没错,但要怎么改变链接呢?变成什么样的链接才能有效更新缓存,又能最大限度避免那些没有修改过的文件缓存不失效呢?

先来看看现在一般前端团队的做法:

或者

大家会采用添加query的形式修改链接。这样做是比较直观的解决方案,但在访问量较大的网站,这么做可能将面临一些新的问题。

通常一个大型的web应用几乎每天都会有迭代和更新,发布新版本也就是发布新的静态资源和页面的过程。以上述代码为例,假设现在线上运行着index.html文件,并且使用了线上的a.js资源。index.html的内容为:

这次我们更新了页面中的一些内容,得到一个index.html文件,并开发了新的与之匹配的a.js资源来完成页面交互,新的index.html文件的内容因此而变成了:

好了,现在要开始将两份新的文件发布到线上去。可以看到,index.html和a.js的资源实际上是要覆盖线上的同名文件的。不管怎样,在发布的过程中,index.html和a.js总有一个先后的顺序,从而中间出现一段或大或小的时间间隔。对于一个大型互联网应用来说即使在一个很小的时间间隔内,都有可能出现新用户访问。在这个时间间隔中,访问了网站的用户会发生什么情况呢?

  1. 如果先覆盖index.html,后覆盖a.js,用户在这个时间间隙访问,会得到新的index.html配合旧的a.js的情况,从而出现错误的页面。
  2. 如果先覆盖a.js,后覆盖index.html,用户在这个间隙访问,会得到旧的index.html配合新的a.js的情况,从而也出现了错误的页面。

这就是为什么大型web应用在版本上线的过程中经常会较集中的出现前端报错日志的原因,也是一些互联网公司选择加班到半夜等待访问低峰期再上线的原因之一。此外,由于静态资源文件版本更新是“覆盖式”的,而页面需要通过修改query来更新,对于使用CDN缓存的web产品来说,还可能面临CDN缓存攻击的问题。我们再来观察一下前面说的版本更新手段:

我们不难预测,a.js的下一个版本是“1.0.1”,那么就可以刻意构造一串这样的请求“a.js?v=1.0.1”、“a.js?v=1.0.2”、……让CDN将当前的资源缓存为“未来的版本”。这样当这个页面所用的资源有更新时,即使更改了链接地址,也会因为CDN的原因返回给用户旧版本的静态资源,从而造成页面错误。即便不是刻意制造的攻击,在上线间隙出现访问也可能导致区域性的CDN缓存错误。

此外,当版本有更新时,修改所有引用链接也是一件与工程管理相悖的事,至少我们需要一个可以“查找-替换”的工具来自动化的解决版本号修改的问题。

对付这个问题,目前来说最优方案就是基于文件内容的hash版本冗余机制了。也就是说,我们希望工程师源码是这么写的:

但是线上代码是这样的:

其中”_82244e91”这串字符是根据a.js的文件内容进行hash运算得到的,只有文件内容发生变化了才会有更改。由于版本序列是与文件名写在一起的,而不是同名文件覆盖,因此不会出现上述说的那些问题。同时,这么做还有其他的好处:

  1. 线上的a.js不是同名文件覆盖,而是文件名+hash的冗余,所以可以先上线静态资源,再上线html页面,不存在间隙问题;
  2. 遇到问题回滚版本的时候,无需回滚a.js,只须回滚页面即可;
  3. 由于静态资源版本号是文件内容的hash,因此所有静态资源可以开启永久强缓存,只有更新了内容的文件才会缓存失效,缓存利用率大增;
  4. 修改静态资源后会在线上产生新的文件,一个文件对应一个版本,因此不会受到构造CDN缓存形式的攻击

虽然这种方案是相比之下最完美的解决方案,但它无法通过手工的形式来维护,因为要依靠手工的形式来计算和替换hash值,并生成相应的文件。这将是一项非常繁琐且容易出错的工作,因此我们需要借助工具。我们下面来了解一下fis是如何完成这项工作的。

首先,之所以有这种工具需求,完全是由web应用运行的根本机制决定的:web应用所需的资源是以字面的形式通知浏览器下载而聚合在一起运行的。这种资源加载策略使得web应用从本质上区别于传统桌面应用的版本更新方式。为了实现资源定位的字面量替换操作,前端构建工具理论上需要识别所有资源定位的标记,其中包括:

  • css中的@import url(path)、background:url(path)、backgournd-image:url(path)、filter中的src
  • js中的自定义资源定位函数,在fis中我们将其规定为__uri(path)。
  • html中的<script src=”path”>、<link href=”path”>、<imgsrc=”path”>、已经embed、audio、video、object等具有资源加载功能的标签。

为了工程上的维护方便,我们希望工程师在源码中写的是相对路径,而工具可以将其替换为线上的绝对路径,从而避免相对路径定位错误的问题(比如js中需要定位图片路径时不能使用相对路径的情况)。

fis的资源定位设计思想

fis有一个非常棒的资源定位系统,它是根据用户自己的配置来指定资源发布后的地址,然后由fis的资源定位系统识别文件中的定位标记,计算内容hash,并根据配置替换为上线后的绝对url路径。

要想实现具备hash版本生成功能的构建工具不是“查找-替换”这么简单的。我们考虑这样一种情况:

资源引用关系

由于我们的资源版本号是通过对文件内容进行hash运算得到,如上图所示,index.html中引用的a.css文件的内容其实也包含了a.png的hash运算结果,因此我们在修改index.html中a.css的引用时,不能直接计算a.css的内容hash,而是要先计算出a.png的内容hash,替换a.css中的引用,得到了a.css的最终内容,再做hash运算,最后替换index.html中的引用。

这意味着构建工具需要具备“递归编译”的能力,这也是为什么fis团队不得不放弃gruntjs等task-based系统的根本原因。针对前端项目的构建工具必须是具备递归处理能力的。此外,由于文件之间的交叉引用等原因,fis构建工具还实现了构建缓存等机制,以提升构建速度。

在解决了基于内容hash的版本更新问题之后,我们可以将所有前端静态资源开启永久强缓存,每次版本发布都可以首先让静态资源全量上线,再进一步上线模板或者页面文件,再也不用担心各种缓存和时间间隙的问题了!

在本系列的下一部分,我们将介绍静态资源管理与模板框架的思路和用法。

作者简介:张云龙,百度公司Web前端研发部前端集成解决方案小组技术负责人,目前负责F.I.S项目,读者可以关注他的微博:http://weibo.com/fouber/


感谢崔康对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

那日后维护的时候,怎么知道哪个资源文件还在用,哪个没在用? by li bo

基于上面的问题,不清楚文件是是否还在被使用的时候,发布到线上,最后同步到CDN的时候,资源文件的磁盘占用量随着文件修改的次数增多而爆增

Re: 那日后维护的时候,怎么知道哪个资源文件还在用,哪个没在用? by 张 云龙

首先,感谢这位读者的提问。其实线上的资源冗余会有,但增长速度是没有想象中的那么大的。

1. 网站程序的静态资源部分的冗余增长情况相比网站用户的图片上传、内容发布等资源增长十分微不足道。
2. 每次上线,只有内容有变化的文件才会出现新的带md5戳的文件,没有修改过的文件md5没变化,因此这些没改过的文件没有产生新的冗余
3. 我们跟踪统计过实际的开发情况,一个重点业务模块,持续使用 fis 1年之后,当前静态资源源码总计5.36M,线上冗余的总量是41.4M,有了这样的实际数据,或许就不会那么担心了吧
4. 退一步说,如果真的因为“看着舒服”需要清理线上冗余,可以写一个脚本,对相同文件的不同版本做最后访问时间排序,把历史版本删除即可
5. 我在第二篇文章里讲了一种基于表的静态资源管理系统设计思路,其实也可以根据静态资源表来确定当前正在使用的文件情况,这是fis的设计精髓。

总而言之,言而总之,静态资源md5冗余没有想象中的那么严重,但它对服务的稳定性提供了坚实的基础,实际测量的数据也显示没有这类问题

a_8244a91.js vs a_1.0.1.js by Wei Zhong

直接写<script type="text/javascript" src="a_1.0.1.js"></script>不是更省事吗?

Re: a_8244a91.js vs a_1.0.1.js by Hu Yaowen

需要做自动重命名的话,使用这种“看着舒服”的1.0.1却是提供不了任何参考性的,结果就是必须另外维护一张表来记录不同文件的不同版本号对应的哈希值。

Re: a_8244a91.js vs a_1.0.1.js by 张 云龙

是的,这样写更加直观,跟md5戳有着类似的实现思路——文件是非覆盖式发布的。采用版本号策略意味着要引入一定的人工维护成本,尤其是网站拆分细粒度化的时候,这种成本会大量增加。我们也曾在工程维护和版本控制上做过仔细的衡量,最后还是觉得基于内容的hash文件生成更划算一些。

8位hash? by c l

示例是8位hash,是有什么特殊的算法?会碰撞否?

Re: 8位hash? by liu ryan

其实碰撞也不怕,一般的资源缓存只有30天左右。30天内不同名就可以,几率很少。

我的做法是用svn的版本号加在文件名上。
如style_10023.css 做build的时候自己加上,如是没有修改过的版本号不会变。

我们的实践是用GIT commit hash by Fu Cheng

在build的时候把git commit对应的hash作为版本号,配合Expires和Cache-Control header来使用,设置一个很长的过期时间。

Re: 我们的实践是用GIT commit hash by 张 云龙

在build的时候把git commit对应的hash作为版本号,配合Expires和Cache-Control header来使用,设置一个很长的过期时间。


这样恐怕会导致这个git下的所有文件都更新了一个版本,这多少会有一些资源带宽上的浪费

Re: 8位hash? by 张 云龙

示例是8位hash,是有什么特殊的算法?会碰撞否?


其实不会碰撞,因为文件的部署路径还是跟原来保持一致的,也就是说,碰撞的可能仅发生在同一个文件的历史版本中,这样的几率更加少之又少了

资源多处引用问题 by lai zhiqiang

比如有样式global.css, 它被多个文件引用,是否修改global.css后,所有引用过它的页面需重新发布,才能让页面获得最新的hash路径。
这没考虑到这种场景呢,毕竟有些静态资源不是只对应一个页面的。

Re: 资源多处引用问题 by 张 云龙

有考虑这种情况。首先,本文基于“web应用需要构建工具支持”的假设。推理过程是:

web应用程序分发原理与传统应用有本质区别 -> 传统应用将程序资源打包成一个安装文件来分发,web应用通过浏览器下载分散的程序资源来运行 -> 传统应用更新是以安装文件为单位,web应用以零散的资源为单位 -> web应用必须找到支持独立资源文件更新的机制。

基于这样的推理过程,“web应用需要构建工具支持”的假设就比较确定了。现在我们考虑怎么解决 “批量修改所有资源引用” 的问题。解决方案有两种:

1 构建工具替换。如果web应用的所有项目文件都在一起,那么可以利用构建工具来识别资源定位语法,将其替换为上线地址,包括加域名、md5戳等。
2 模板框架支持。这个我在第二篇文章《前端工程与性能优化(下):静态资源管理与模板框架》里有解释。具体的做法就是我们并不在页面直接写资源引用,而是通过模板接口去获取。构建工具将资源及其发布路径写入一张表,模板接口运行时去读取表,从而获得资源真实路径。

比如有样式global.css, 它被多个文件引用,是否修改global.css后,所有引用过它的页面需重新发布,才能让页面获得最新的hash路径。
这没考虑到这种场景呢,毕竟有些静态资源不是只对应一个页面的。

对于脚本中动态加入的静态资源有做处理么? by duan jun

rt

Re: 对于脚本中动态加入的静态资源有做处理么? by 张 云龙


对于脚本中动态加入的静态资源有做处理么?
rt


有的,在fis中任何js文件里可以使用编译函数:__uri('path'),来定位资源。

例如;


var img = __uri('a.png');


经过构建工具处理之后,得到:


var img = '/path/to/a_a0cb23ef.png';

fis可以使用在所有Web站点吗? by Sun Xiaoliang

我们team是用.net开发的站点,现在在处理静态资源缓存问题。leader希望做成永久缓存,IIS里可以简单配置实现,但是leader希望能做成一个具体的实现,就像您的这篇文章中提到的给静态资源添加MD5或者hash或者版本号。冗余静态资源,网上查找了一下,有一个gruntjs插件,正在研究。如果fis可以用的话我就开始研究下fis的文档了。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

15 讨论
提供反馈
错误报告
商务合作
内容合作
Marketing
InfoQ.com及所有内容,版权所有 © 2006-2016 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司 京ICP备09022563号-7 隐私政策
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.