折腾不止：前端工程与性能优化

更多腾讯海量技术文章，请关注云加社区：https://cloud.tencent.com/developer/column

作者：addy（许斌），前端开发工程师，文艺青年一枚，写得了文章，编得了代码。

作为开发，不仅仅是前端，优化总是你绕不开的事，我们的目标就是要产品变得更快。优化的对象不仅仅指产品本身，还有我们日常的开发流程。从加入团队到现在，大概有一半左右的时间花在了优化上，期间遇到了很多问题，回过头看，优化这件事情并不是那么简单，也是些很琐碎的事情，要打造一个无痛的开发流程，并且能够相对轻松的对产品持续优化真的不轻松。没有银弹，任何项目都要花很多时间和精力。但任何值得改善的地方能够有所提升都让我们觉得努力没白费。有时候只想懒一点，从枯燥的重复中解放出来。

刚进来时，加上我团队中一共3个人专职前端开发。项目比较简单，前人已经做好了模块化，只是觉得还不够彻底。后来项目慢慢变得庞大，加上重构同学，人员最多的时候达到了13人。这个过程中遇到了很多问题，前端框架演变了三次，都是因为遇到了一些棘手的问题，而不得已做出调整，没有绝对的好坏，只有合不合适。

1

1.0时代

前期模块化已经做的不错了，至少不必花大量时间去重构代码。模块划分如下图，逻辑层次上还是比较清晰。

前端模块化依赖的主流库也就数国内的Seajs和国外的requirejs，这里就不陈述。采用了Seajs作为模块管理器，zepto作为基础库文件，lib主要包含了项目中用到的主流第三方库文件。

我们知道模块化带来的最大弊端便是HTTP请求数增加，所以上线的时候必须合并文件。下图中的package模块是文件大集合，打包了很多个JS模块，除去上图中的基础库文件和业务模块层，在上线的时候大部分文件都被打包在package.js里。

大部分页面的JS请求是这样的：

细心点的同学可能注意到两个问题：文件的大小和加载时间。刚才的截图还是在PC端截取的，手机和不同网络环境的表现会更加糟糕。

现在来看下目录

存在的问题：

目录看起来算规范，但实际上是公共的和业务的混在一块。

大部分文件合并在一个文件，合并策略不合理。

由第二点引发的第三个问题，发布上线时，只要两人发布涉及到package文件，冲突必然发生。

发布时需要down下上一次的文件，对照合并的新文件，以免发错。

注意，第四点是人工。一不小心发错，或者把他人刚发布的文件覆盖了，这种事情发生10+次。

只有一台测试机器，测试环境经常覆盖是常事。

版本控制问题，不以SVN为版本，而是预发布机器上代码，管理混乱

不敢想象如果10+人的团队一起在这种模式下开发，会是怎样的场面。

2

2.0时代

由第一个版本引起的问题，着实让人很蛋疼，每次开发版本就是一次阵痛，尤其是测试、发布环节。所以就开始慢慢着手解决。随着业务扩展，人员增多，就诞生了下面这个图。

优化措施：

调整模块，让共用的模块更加共用，业务模块跟随业务自身。

更改模块合并策略，既然大了，我就分成小，一定程度缓解了冲突。

替换原有的同步文件工具，包括测试与正式环境，接入ARS，提测发布流程顺畅多了。

ARS带有冲突检测功能，告别人工对照合并，覆盖不再容易发生。

公共JS文件缓存在localstorage中，模拟manifest，带版本号控制。

以SVN为板块控制工具，不再对照外网代码。

一些统计

localstorage本地缓存

localstorage缓存命中率

首屏时间

window.onload时间

一切看起来很美好，但是好景不长，因为新的问题又来了。

之前拆分package.js文件为多个文件，实际请求的时候则是合并了请求，包括JS文件和CSS文件。combo文件实际上会有延迟问题，在发布的时间节点上存在不同步的问题，直接导致页面挂了。

抛开combo文件不说，由于浏览器缓存的问题，每次更新版本的时候要手动加上一个时间戳，来规避缓存造成的错误。也是个很蛋疼的点。

随着业务增长，越来越多页面是放在APP里面访问。触屏页面已经不再是重点，如何更好的利用APP加速页面才是关注点。很多人想到了手Q的离线包，但听说实践起来也不是特别方便，我们就采用了客户端缓存hash文件的策略，告别304。所以这里又涉及到自动化。

雪碧图基本是手工；

代码混淆没有压缩；

CSS合并文件要手写地址，类似下面：

http://at.qq.com/min/f=cssv4/common/reset.css,cssv4/common/base.css,cssv4/module/btns.css,cssv4/module/tab.css,cssv4/module/app-list.css,cssv4/module/talk-bar.css,cssv4/module/popup.css,cssv4/page/game-detail.css,cssv4/page/talk.css,cssv4/module/comments-bar.css

3

3.0时代

为了解决上述问题，流程需要进一步优化，简单点就是让自动化程度更提高。

3.1 探索期

前期在方案选择上也做过一些讨论，自己完全从底层写时间上不允许。之前折腾过Grunt发现并不是那么好用，后来发现百度的前端解决方案FIS能够满足我们的需求。

生成以hash值（后缀）命名的文件，代码更改，生成新文件，且都会自动更新HTML中的引用（核心诉求），就像下图：

合并雪碧图

压缩混淆文件

文件合并（包括JS文件和CSS文件）

能做到这几点基本就满足了我们的需求。前期的一切都是未知的，不太明白会遇到什么大问题。乍看起来非常好用，如果简单的页面，确实会很简单，只要简单几行配置就可以搞定，但到现在FIS的配置文件200+行。一些特性很难满足，需要二次开发。上手简单，要深入难，必须要看源码改源码，写插件，这大概就是用FIS的心得。

前期想了要怎样把开发——测试——预发布——发布这个流程依赖工具流畅的跑起来，大概构思如下：

注：

调试、发布代码与源代码分离

本地调试用代理如fiddler，或者上开发机

deploy是构建工具同步文件的一个功能

保证源码的版本最新，发布代码走ARS。

工程化进展却不是想象中的顺利，实践中遇到了一些问题，也只能硬着头皮咬着牙去解决。

3.2 煎熬期

冲突问题 冲突问题一直存在，在2.0时代不那么明显罢了。原因是测试环境的JS已经被合并过一次。

时间问题 由于刚开始文件比较少，构建速度基本没啥问题。后来业务越来越多，参与的开发也越来约多。文件暴增到4000+，构建时间一步步增加。 开发调试耗时 3987ms

发布构建的时候因为要进行md5计算，文件压缩等，要181745ms！已经无法忍了。

ARS流程 用过ARS的同学肯定明白，流程还是比较蛋疼，要完成提交SVN，点击同步等等一系列操作，繁琐。

构建命令 命令比较长，参数多，难以记忆

产出文件多，发布麻烦 每改动一个字母，发布的时候就会生成一个新的文件，发布的时候真是在文件堆里找！！

这一系列的问题如山倒，组内的开发同学已经没法愉快的开发了。

3.3 深度优化

减少冲突问题 进一步解决的方案还是细分模块，测试环境不进行文件合并，这样冲突的概率几乎很小，因为公共库经过2.0的调整已经基本稳定。

缩短时间 构建时间这么长，这样发展下去是不行的。花了一些时间研究FIS源码，发现FIS监听的是整个项目文件，每一次构建都要扫描全部文件，这样时间必然会随着文件增加而变长。然后进行深度改造，变得不那么像FIS了。 进行一次又一次优化，改变构建策略。依赖构建：当某个文件依赖另一个文件时，另一个文件才会被构建。假如a.html依赖了b.js ，在构建产出的文件就只有这两个文件，其他文件不会被构建，文件数也减少，时间大大缩短。

开发构建 （单位ms ）

发布构建 （单位ms）

构建命令优化 输入命令麻烦，就用GUI界面，点点按钮就行。这里要感谢@koppthe@kolawang同学短时间内用node写的GUI。

产出文件多 依赖构建之后，只会产出相关文件，产出文件大大减少，发布难度减少很多。

ARS流程 修复bug的时候不用ARS同步，监听文件变化直接同步到测试环境。

只需要8ms！！！。如果打开了同步按钮，修改的文件会立马上传到测试环境上，会不会有相互覆盖的问题。组内每个人负责的模块都不同，而且公共模块已经基本稳定，很难出现这样的问题，在实践中很少发生这样的事情，相反小伙伴觉得简直获得解脱，相比找文件传文件这样繁琐的流程，这轻松了许多。

发布优化 构建工具会产出文件列表，点击就能打开文件夹，找到对应文件；列表对应SVN路径，直接贴到ARS就能提单。

雪碧图的优化 发布的时候所有引用的CSS文件会合并成一个，然后将引用的图标合并为雪碧图，有点粗暴。因为公共的CSS文件的图片单独合并为雪碧图会更加合理，公共的图片变动频率不会那么高。开发一插件，在CSS合并前雪碧图一次，合并后再雪碧图一次。

统计与优化

用户网络类型（粗略）

unknown是无法统计到的，理论上wifi还是占大部分。从其他四种类型看，wifi占据绝大部分，2g用户非常少。

PC VS Mobile

在JS下载和执行效率上，移动端明显要低于PC端。

JS优化

之前APP内部的JS文件都是通过seajs来下载文件，后来发觉何不直接干脆点直接写

下载就好了，优化后下载执行时间下降显著：

注：这里统计的时间，包括了下载JS和执行JS的时间。

JS内嵌与外联对比

在考虑优化的时候，我们一种方案便是将外联的JS代码（仅业务代码）通过工具内嵌到页面。现在来对比下性能： http://gqq.gtimg.com/static/mobile/js/v3/page/gift/list/inappand.a9a524eb.lc.js 文件大小8.7kb，gzip压缩后3.3kb。 内联加载时间几乎为0 0.0015793，外联的下载时间：

下载时间不到200ms，但相对来说已经是很长了，才8.7kb。

我们知道，DOMContentLoaded事件的触发基本意味着页面已经渲染完成，JS已经执行（异步的除外），已经达到可交互的状态了，具体可参考这篇文章。下面看下内联与外联对DOMContentLoaded的影响：

蓝色线条是外联的JS，时间明显要比内联的高出一些，大概200ms。由此可见，将小量的JS文件内联到页面，能够提高速度。但大的JS文件适不适合内联，目前还没有实验。这里需要在减少HTTP请求和利用缓存之间把握一个平衡，很多时候优化准则是并不是那么容易实施，因为可能自相矛盾，也可能和工程本身相矛盾。优化不是按照准则照本宣科的做，需要灵活变通。

优化措施 按照雅虎优化的14条准则，把还没做到的都处理了。

脚本域名切换，去cookie。

文件合并

利用浏览器缓存，无限增大缓存期

max-age=15552000

雪碧图

减少HTTP请求，构建工具内嵌JS到HTML

感觉速度还是不够快，再充分利用本地缓存和APP提供的缓存能力

浏览器使用localstorage缓存脚本

APP缓存hash文件名脚本

缓存HTML片段

调试、测试、体验流程

反向代理+白名单控制策略，域名对外访问是403，公司内网可访问。不用代理，手机直接连接wifi访问。环境分为开发——测试——预发布——正式（每个环境对应一个独立域名），任何角色（开发、测试、设计、产品）都可随时访问。

APP的debug包，可任意切换上面四种环境进行调试、测试、体验。

总结

这是过去一年工作的总结，一直都没静下来梳理。回过头想，自己是不是把这个流程变得更加复杂了。可能都有一个从简单到复杂再到简单的过程，坚持优化一直没有停下来，只要能够变得更好一点点，都会去尝试，所谓生命不息，折腾不止。