网站性能优化

inssuc

最近一直在做性能优化和模块化改造的工作，并完成了一次前端重构。在这里总结出一些经验和得失来帮助大家思考。共两篇文章，第一篇讨论性能优化，第 二篇讨论模块化框架。而之所以把这两个话题放到一起，是因为这两项工作都涉及到对前端代码进行不同程度的重构，而且模块化改造其实是我们在对性能优化做到 一定程度之后发现必须要做的一件事情。本篇是性能优化的部分，下面我把我们的产品简称为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加载完成后才去执行回调方法。
按需加载还需要有一套触发条件。在我们的页面中，对鼠标移动和鼠标点击都进行了**，以保障在用户想使用某个功能之前或进