前端重构实践(一)：性能优化.docVIP

最近一直在做性能优化和模块化改造的工作，并完成了一次前端重构。在这里总结出一些经验和得失来帮助大家思考。共两篇文章，第一篇讨论性能优化，第 二篇讨论模块化框架。而之所以把这两个话题放到一起，是因为这两项工作都涉及到对前端代码进行不同程度的重构，而且模块化改造其实是我们在对性能优化做到 一定程度之后发现必须要做的一件事情。本篇是性能优化的部分，下面我把我们的产品简称为N页面。 应用场景分析： N页面作为一个入口页面，对页面加载速度有着极高的要求。同时，N页面内部却又有着非常复杂的功能与交互。N页面的第一版上线时，页面引用的js文件有3个，一共40-50k（压缩Gzip之后）。页面onload时间在1.3秒。 1.3秒的load时间，相比较绝大多数网站来说都是一个不错的数值。但老板一句话“怎么这个页面打开这么慢”，立刻像是给我们的后背安了一枚定时炸弹。性能优化成了N页面下一步工作的重中之重。 老板重视页面速度，对于Web前端开发人员来说其实是件幸事，这表明你将有更丰富的时间和资源去实践Web性能优化这一课题，不用被翻来覆去的产品升级需求所打扰。那么对于N页面，我们做了哪些实践： 常规优化手段包括： CSS置顶，JS置底。 静态资源外联、合并、压缩。 图片优化。（Png使用pngcrush；Gif使用gifsicle；Jpeg使用jpegtran） 图片延迟加载。（主要针对首屏外的图片。） 使用CSS Sprite，首屏图片全部合到一张图上。 静态文件上CDN。（静态文件的下载能提速20%左右。） 静态文件设置强缓存。（命中强缓存82.4%；命中若缓存3.4%；未命中缓存14.2%。） HTML压缩。（Gzip后减少%5。） 增强型手段： 基础库定制。（用代码分析代码，自动打包被使用到的方法作为基础库，使基础库从原来的压缩后25K减小为9.8K，减小了61%） 页面数据存储优化。（从原来的直接写json形式的script，变为将json隐藏在textarea中，初始化或用到的时候才去提取并进行解析。） 首屏CSS检测。（对首屏用到的CSS进行检测，将不属于首屏的CSS代码单独打包并移到首屏之外进行延迟加载） js按需加载。（在后面做重点介绍） 监控 测量 性能优化最重要的工作不是优化而是监控。这个道理很简单：没有监控体系就没办法衡量性能优化的效果，那么你所做的任何工作都是盲目的。 我们对性能的监控是从多个维度展开的，包括平均时间、时段分布、浏览器分布、省份、运营商等。便于发现和定位任何一个细节的问题。 而在平均时间这一维度，我们又分为四个级别： 1.Head时间– head标签加载完成的时间 2.TTi时间– 页面可交互时间（即首屏第一次渲染出来的时间） 3.Dom时间– Dom Ready的时间 4.Load 时间– 页面完全加载完成的时间 这样划分的好处是，页面加载每个环节的耗时一目了然： Head ：CSS加载时间 TTI ：整体HTML加载和渲染时间 DOM 减TTI ： js文件网络传输时间和在浏览器进行解析的时间 Load 减Dom ： js初始化+ 图片加载的时间 而且，我们通过移动tti时间点的位置，发现了一个有趣的现象，如下图 可以看出，页面加载的性能瓶颈就在script的下载和解析时间。 为了进一步定位性能瓶颈，我们在页面内对用户网速进行了测试，结果很震惊：有2%的用户网速小于2k/s，5%的用户网速小于10k/s。（国内的网络状况真是惨不忍睹啊） 那么，优化方案就很明显了：最大限度地减小js文件大小，以减小网络传输时间，提升页面性能。 通过后来的优化工作我们发现：js代码压缩、Gzip后每减小1k，页面加载时间就能减小10ms左右。 按需加载： 这是除了js压缩外，你能想到的最有效减小js文件大小的办法了。 按需加载，顾名思义，就是在页面首次加载的时候只提供最需要的js给用户，而剩余的js等用户使用到了相关的功能再去加载。 按需加载适合哪种类型的网站：如果80%的用户来到你的页面只使用20%的功能，那么就有必要把这20%的js作为首屏加载，而剩余的js做按需加载。 从这个角度来讲，几乎所有网站都可以做按需加载，因为总有一些功能是用户很少会用到的。 那么，如何做按需加载： 按需加载需要有一套js模块加载的框架。这个框架的作用是：保障在所需的js加载完成后才去执行回调方法。 按需加载还需要有一套触发条件。在我们的页面中，对鼠标移动和鼠标点击都进行了监听，以保障在用户想使用某个功能之前或进行了相应操作时，触发js加载。 除此之外，我们还对js基础库进行了进一步拆分，分为首屏用到的基础方法，和延迟加载的js所需的基础方法。以最大限度地保证首屏js量的最小化。 通过按需加载的拆分，我们将首屏的js代码从原来的gzip之后