性能优化浅谈

这次总结主要关于性能优化探索心得。水平很浅，只是说说自己的学习收获。

************这里开始了*************

看过的前端开发书籍都在说这四个字，性能优化的字面解释是：不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。这句话可以看出性能优化的目的：更快的速度、更少的时间。

1）性能优化有什么意义？

谷歌的数据表明，一个有10条数据0.4秒可以加载完的页面，在变成30条数据加载时间为0.9秒后，流量和广告收入减少了20%。当谷歌地图的首页文件大小从100kb减少到70~80kb时，流量在第一周涨了10%，接下来的三周涨了25%。腾讯的前端工程师根据长期的数据监控也发现页面的一秒钟延迟会造成9.4%的PV的下降，8.3%跳出率的增加以及3.5%转化率的下降。这两家公司都是行业的翘楚，具有极其巨大的用户群，这些数据足够让我们重视性能优化。近八成的用户可以忍受的响应时间为5秒，500PC的主站打开资源加载完毕的时间为5.67s，QQ彩票为12.75s，网易彩票为16.79，看到这里还是很骄傲的*_*。

2）如何优化？

资料显示和浏览器调试分析发现，页面的打开速度关系密切的三个原因：宽带速率（俗称网速），web服务器，页面结构。可参加表1:

表1.主要影响打开速度的四个因素分析

主要影响因素	作用原理	影响
宽带速率	接收响应、连接速度减慢	连接变慢
服务器	宽带限制或者服务器请求响应最大限制、硬盘故障、网卡故障	等待时间延长
页面结构	导致重绘和白板屏	用户体验

-----服务器-----

就如对着大山呐喊等自己的回音，页面打开浏览器和服务器（单指web服务器）之间通过http协议进行通信的过程。服务器的影响也分为服务器性能和硬件配置。这里可以简单看下浏览器加载渲染网页的过程见图1：

图1.浏览器的工作原理

由图可知浏览器中有一个请求的链接www.500.com，DNS解析查到映射的IP地址（记为A）192.168.18.58，然后浏览器向这个IP地址连接，连接成功后将请求头信息通过http协议向A所在的服务器web servers发起请求，服务器接收并等待处理，处理后响应给浏览器。这个时候浏览器开始显示html代码，并获取css/image/js的地址，再次向DNS发起请求并获得后开始渲染页面（我们熟悉的样式和动效等实现）。这是逻辑上的，实际上的情况可以在浏览器的调试器俗称web检查器（目前只有Safari的Web Inspector，IE的开发人员工具、火狐的FireBug、Opera的Dragonfly）上看见。此处使用火狐的firebug,在搜索栏输入www.500.com后，截取其中一个请求的时长详情如图2所示：

图2.500彩票主站某次请求的时间详情

由图可见域名解析从16ms开始持续了0ms，连接到ip从16ms开始持续了31ms，发送给ip所在服务器用了0ms，等待服务器（想知道为什么要等待？可以参看结尾的附言）响应用了47ms，传回接收数据用了0ms。服务器的影响对于前端来说占据了很大的加载时间，但是这也客观取决于服务器和后台的DB设计，我们似乎有些手足无措。但是关于http请求数确是前端可以做的。

如何减少http请求？根据上面的分析我们会知道image、css、js链接都会发出http请求，我们会自然的想到合并资源。事实上我们也是这样做的，图片可以用图片精灵进行处理，css可以合并为<2个（style.css,public.css），js合并为一个。图2是500主站一张合并后的图片：

图3.500主站合并后的图片

刚开始做项目的时候为了更加清晰的看样式文件，我将css分为base.css,public.css,style.css,header.css...我得承认这样确实可以帮助我看样式结构，但是后来我才知道我牺牲了对用户有利的宝贵的加载时间。现在自己也严格控制保持在2个css链接以下了。为了避免额外的js链接，将对时间帧要求不严格的动画统一用css3写，也是做的改变。现在想想最初分散的css列表，滥用的js链接，数量庞大的图片简直是灾难。

-----宽带速率-----

宽带速率，简单的说就是速率越大，上传下载的速度越快。2014年统计的中国固网宽带用户平均上网速度为199.3kb/s，我们如果按照200kb/s计算，2M的宽带的理论速度是256kb/s，可以发现中国网民的平均宽带速率处于2M左右。

我们现在可以保持一个页面的所有资源总和在500kb左右，那么我们的用户使用时平均会花500/200=2.5s，如果网速更慢将会影响更大。

图4.世界互联网大会

今年12月16日在这江乌镇召开的“第二届世界互联网大会”上习总书记发声：中国正实施“宽带中国”战略，2020年全覆盖（附美图一张-_-）。对于宽带速率的未来相对是乐观的，但处于眼下的前端可以做的即是减少分母的数值，也即是我们的网页总大小。

如何减少资源总量？浮现在脑海中的就是一个字：压。写页面的时候压代码数量，做到尽量少的冗余。写完后使用压缩软件进行代码格式化图片压缩，减少总资源大小。

那么问题来了：不冗余的代码的标准是什么？通常来说，一段程序能够执行既定的任务，但是经过优化能够同样达到目的，而执行时间和代码数量减少了，说明删除的代码就是程序的冗余代码。在实际的项目中不在多个样式名中使用大部分相同的样式，重复样式归并到一个公共类、删除没用的标签避免占位。总体来说不多余，不重复的代码即是不冗余的。之前的项目中有时为了区分两个DOM节点，我赋予节点空的标签，也增加了资源总量。

-----页面结构-----

页面结构是指页面中的元素排列顺序。页面结构会对加载速度造成影响是由于浏览器对页面的读取顺序所致。由图1可知，浏览器会先解析html代码结构，然后再渲染页面。而浏览器加载显示html时是按照从上到下的顺序进行的，渲染的顺序也是从上到下，下载和渲染是同时进行的。遇到语义解释性的标签嵌入文件（JS脚本、css等）下载过程会启用单独连接进行下载。下载后进行解析，解析时停止所有元素的下载。解析完成后开始渲染。JS、CSS中如有重定义，后定义函数将覆盖前定义函数。详细的html页面加载和解析流程如下图所示：

图5. html页面加载和解析流程

由图可知，html按照从上到下的顺序解析和渲染页面，正常情况下解析1次+渲染1次。有些浏览器为了减少重绘，会在css文件加载完成后渲染页面，这时我们的用户就会对着一个白屏思考人生~_~。大内容+低网速会加大白板的时间，为了保证用户在页面加载的时候至少可以看到一些东西，将css放在html头部是一种照顾用户的做法。js因为其对dom节点的操作性，则会出现不能与html并行下载解析的情形。即是如果脚本在头部则会阻止页面的渲染，用户又要开始对着白板发呆了。虽然目前可以用DEFER属性通知浏览器并行下载，部分浏览器可能不认识这个属性加之DEFER的使用就禁止了docment.white().将js放在html的尾部可以从本质上解决脚本阻塞加载时间问题。

-----总结-----

1）减少http请求

2）合并资源（css,js,image）

3）压缩图片，代码

4）减少重绘

5）CSS放在头部，JS放在页尾