只说web前端性能优化

－－－
2015-05-15更新，内容越来越多，后续会把相关主题拆开来讲
－－－
前段时间在公司内部做过一个关于前端性能优化的分享，在这码起键盘来记录下。

前提：

只说前端性能优化，涉及到一些具体可用的手段，都是日常工作中比较容易就可以做到的。不涉及复杂的比如CDN技术，或者服务器端优化技术（服务器端优化也可以改进前端性能）。
分享积累的经验和了解的技巧，因为有时候很多小的改变可以让用户体验有质的提升。比如保持一个良好的编码习惯和一些简单但不太注意到的策略。
先讲一讲一些常见的策略和方案，然后基于一个实际的项目案例来综合分析并给出解决方案。
（以下文章的截图图片都是来自我制作的ppt中）

问题：

为什么进行前端性能优化？

响应速度对用户的影响－用等待时间来衡量.png

可以看出来，前端性能，反应给用户最直观的方面就是页面的响应速度。
3-5秒还能接受，大于8秒甚至上双的响应时间，作为用户肯定是接受不了的。
相信我们自己平常上网逛论坛也有类似的体验。
一句话，页面的响应速度对用户体验至关重要。

如何提高响应速度？

下面就逐一来讲，有的可能没列举实例，对细节感兴趣的朋友可以网上查查相关主题的资料，或者直接问我。

1 避免坏请求：

什么是坏请求？最明显的就是404请求，也可以把无意义的重复请求叫做坏请求。

无意义的请求，浪费了服务器的资源也影响前端性能.jpg

404会导致服务器无谓的响应，所以，没用的请求，比如链接图片，请求无用的资源等都需要及时删除。

2 合并js和css文件：

这样也可以减少http请求次数

合并的策略.png

3 利用缓存：

可以缓存js css等文件资源，也可以缓存请求回来的数据。
开启了缓存之后，有些资源文件，客户端就不用每次都从服务器端重新请求加载，从本地缓存里取，速度会快得多。至于该缓存哪些文件数据，那就看你的需求了。我们的目的还是想办法减少请求次数。

4 使用css精灵整合图片：

通过整合图片和css定位的方法，我们可以把多张图片整合到一起，这样就减少了请求次数。

5 启用压缩：

减少请求资源的数据量，达到更快的速度。

6 避免css @import语句：

此语句顺序加载，会阻塞浏览器的并行加载。

7 优化脚本js和样式表css的顺序：

（经测试IE8及以上没有这个问题，如果还需要兼容IE8以下版本浏览器，请注意这点）

8 处理小文件：

将小文件比如小的js css文件写入到html中，或者第二点提到的合并，减少请求次数。

9 减少dom数量：

想方设法减少dom数量，即减少浏览器处理的时间，因为很多时候客户端javascript处理的就是dom，dom的多少直接影响前端到性能，而且是全方位，多角度的影响。
可以想象下，如果web应用程序中含有成千上万的dom节点，我的意思是比原本多的多多节点。然后我们需要使用选择器操作dom，无论如何优化，这些dom节点都是存在的，这无疑是一项耗时的工作。
我见过一个项目，在一个列表下，有2万多个li节点（没错，是这么多，后面我将会把它当作一个实例放最后来讲），这些节点数据都是ajax请求回来的，更要命的是，在这些节点下，还需要完成搜索的功能。
浏览器解析dom，渲染样式都会花费不少时间，何况还需要操作搜索，和各种重绘。

10 慎用document.write：

会阻塞浏览器的渲染。

11 使用浏览器文档碎片createDocumentFragment：

这个可以减少操作dom的次数，从而减少渲染次数，提高页面性能。
来看个实例，看具体如何运用文档碎片来改善页面的性能。
现在假设页面中有个列表ul元素，我们需要调用ajax获取json数据来填充这个列表。
第一个版本代码：
var list = document.querySelector('ul');
ajaxData.items.forEach(function(item) {
// 创建li元素
var li = document.createElement('li');
li.innerHTML = item.text;
// li元素常规操作，例如添加class，更改属性attribute，添加事件监听等
// 迅速将li元素注入父级ul中
list.apppendChild(li);
});
这样的写法实际上是非常慢的，因为每一个元素附加到ul元素之上，顺带着浏览器处理渲染的过程。我们再来看看使用文档碎片的写法如何。
第二个版本代码 ：
var frag = document.createDocumentFragment();
ajaxData.items.forEach(function(item) {
// 创建li元素
var li = document.createElement('li');
li.innerHTML = item.text;
// li元素常规操作
// 例如添加class，更改属性attribute，添加事件监听，添加子节点等
// 将li元素添加到碎片中
frag.appendChild(li);
});
// 最后将所有的列表对象通过DocumentFragment集中注入DOM
document.querySelector('ul').appendChild(frag);
使用文档碎片处理之后，我们可以分析下附加节点到ul之上，只需一次就可以，大大减少了浏览器处理渲染的过程，节省了宝贵的时间。
如果没有事件方面的考虑，或者可以使用事件委托的情况下，甚至可以把节点都当成html来处理，那么我们操作的就都是字符串了，请看第三个版本代码。
第三个版本代码：
var htmlStr = '';
ajaxData.items.forEach(function(item) {
// 构建包含HTML页面内容的字符串
htmlStr += '<'+'li>' + item.text + '<'+'/li>';
});
// 通过innerHTML设定ul内容
document.querySelector('ul').innerHTML = htmlStr;
当然，如果觉得这样字符串太长，我们可以运用数组。
第四个版本代码：
var htmlStr = '';
var htmlArr = [];
ajaxData.items.forEach(function(item) {
// 构建包含HTML页面内容的字符串
htmlArr.push('<'+li>' + item.text + '<'+/li>');
});
// 通过innerHTML设定ul内容
htmlStr = htmlArr.join('');
document.querySelector('ul').innerHTML = htmlStr;

总结

那么按这么说，我们就两招王牌：
减少请求，加快渲染！
提高页面性能，我们从这两个点出发，就可以解决很多问题。
以上大都是总结出来的一些可用的细节点。实际上，我们可以通过工具来检查页面上可供优化的地方，我感觉比较好用的工具是google page speed，大家可以在google应用商店搜索安装，使用方法也很简单。
除了我在文章中列举的优化外，大家可以参考page speed的说明，查找更多可供优化的信息。不过，话说回来，它列举的不一定都是对的，毕竟我们还是有自己的需求在内的。
实际项目中的问题，会表现的更加明显。

项目背景：

企业内部的选择人员的界面，分集团部门等节点展示用户，但是用户人数较多就会出现页面的性能问题，具体表现在：
1 接近3万人，加载速度50s，前台的搜索近20s（很多逻辑，支持拼音搜索，模糊搜索等）
2 前台需要展现的数据量太大，造成无响应崩溃
结合以上我们提到的点，我们的解决办法是：
1 增加单次请求的数据量（3万人，每个人在数据库中都是一条记录，不可能一次就全部请求加载到web客户端）。之前每次请求加载500人，来回60次请求，改成每次请求加载3000人，把请求次数减少到10次左右。这样一来，对于数据的请求加载时间就节约了6倍多。
2 请求数据使用Json，之前是使用xml，然后在前端转换为Json，既浪费转换时间，又需要转换的代码。这个问题属于历史遗留问题，前辈们使用了xml，后来的维护者就一直这样了
3 等数据请求完成后再调用angular组件画地址树。之前是请求一次就渲染一次地址树，即请求回来500人地址树立刻变化（使用的angular，显示和数据是绑定的，数据变了显示就会变）。改成数据请求完成之后再统一调用组件渲染，减少了渲染时间。
4 搜索不使用angular的filter，这个应该是angular的bug，每次都是搜索两次。后来自己写了实现搜索的方法。
5 最最重要的一点是，3万人每个人都需要画一行数据，造成dom渲染慢。所以每次只画20人，用户拖动鼠标的时候，再动态的改变选择区的人。这也是利用了angular数据和显示绑定的特点。
想查看原理，请看：
http://twofuckingdevelopers.com/2014/11/angularjs-virtual-list-directive-tutorial

最后

虽然现在网络速度越来越快，但web前端优化还是非常重要，毕竟没有最快只有更快！我们不能假设用户都使用chrome并且网络速度都和我们一样快不是吗。使用良好的策略，可以让用户在有限的带宽和客户端硬件资源条件下，获取最佳体验！
高效的web应用没有止境。
文章可以随意转发，但请告知作者，并表明来源。