首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

更多腾讯海量技术文章,请关注云加社区: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包,可任意切换上面四种环境进行调试、测试、体验。

总结

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180212A0N3M600?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券