Web性能优化宝典
绪论
性能优化一直是系统开发和项目维护中经久不衰的话题，性能问题也往往是程序员们谈虎色变的诟病。随着互联网的高速发展，越来越多的应用系统已经以web的形式摆上了台面。而在Web系统中，性能问题绝大部分体现为页面的快速响应和系统的持续稳定。根据yahoo的调查，后台只占5%，而前端高达95%之多，其中有88%的东西是可以优化的。
虚话不多说，就以业界的2-5-8原则来拉开本次Web性能优化话题的篇章吧。
当用户能够在2秒以内得到响应时，会感觉系统的响应很快，用户体验非常好；
当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；
当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，勉强可以使用；
当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点。
1 兵法篇
凡用兵之道，以法为首。有法可依者，制胜之方也。
内容(Content)方面
1）尽量减少HTTP请求次数
终端用户响应的时间中，大部分是在下载各项内容。这部分时间包括下载页面中的图像、样式表、脚本、Flash等。通过减少页面中的元素可以减少HTTP请求的次数。
减少HTTP请求的方式通常有：
1.合并文件。通过把所有的脚本放到一个文件中来减少HTTP请求的方法，如可以简单地把所有的CSS文件都放入一个样式表中。
2.CSS Sprites。减少图像请求的有效方法。把所有的背景图像都放到一个图片文件中，然后通过CSS的background-image和background-position属性来显示图片的不同部分；
2）减少DOM元素数量
关注以下原则：
1. 一个复杂的页面意味着需要下载更多数据，同时也意味着JavaScript遍历DOM的效率越慢。
2. 只有在语意上有意义时才使用<div>，而不是因为它具有换行效果才使用它。
3. 一个页面的Dom应尽量控制在500个之内，计算Dom元素个数的方法可以通过document.getElementsByTagName('*').length获得。
3）使iframe的数量最小
Iframe让页面无缝集成的特性使之在Web系统中大受青睐，但同时我们也要看到iframe的缺点，不能滥用iframe：
1. 即时内容为空，加载也需要时间。
2. 会阻止页面加载。
3. 没有语意的iframe请使用div代替，完全可以实现同样的效果。
4. 对客户端的负荷相对较重。
4）减少DNS查询
一次DNS的解析过程会消耗20-120毫秒的时间,在dns查询结束之前，浏览器不会下载该域名下的任何东西。所以减少dns查询的时间可以加快页面的加载速度。建议一个页面所包含的域名数尽量控制在2-4个。
5）不要出现404错误
HTTP请求时间消耗是很大的，因此使用HTTP请求来获得一个没有用处的响应（例如404没有找到页面）是完全没有必要的，它只会降低用户体验而不会有一点好处。
服务端(server)方面
1）采用缓存机制
缓存机制指的是促使客户端在访问系统时，尽量采用本地缓存文件，避免与服务端进行重复的交互。这种方式能够最大程度的减轻服务端和网络的负荷，有效提高页面性能。
httpResponse.addHeader("Cache-Control","private,max-age=86400");//缓存一天
需要注意的是，通常缓存仅针对静态资源而言，如图片，XML，JS，CSS等。对于动态数据是不能采取缓存的。因此在服务端做缓存时，需要根据后缀名做区分。
<filter-mapping>
<filter-name>staticResouceCacheFilter</filter-name>
<url-pattern>*.gif</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>staticResouceCacheFilter</filter-name>
<url-pattern>*.png</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>staticResouceCacheFilter</filter-name>
<url-pattern>*.js</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>staticResouceCacheFilter</filter-name>
<url-pattern>*.css</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>staticResouceCacheFilter</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>
2）采用GZip压缩
Gzip是指把文件先在服务器端进行压缩，然后再传输。这样可以显著减少文件传输的大小。传输完毕后浏览器会重新对压缩过的内容进行解压缩，并执行。gzip的压缩比例非常大，一般压缩率为85%，服务器端100K的页面可以压缩到25K左右再发送到客户端。特别强调， 所有的文本内容都应该被gzip压缩: html (php), js, css, xml, txt…
方法为，在容器的配置文件中，对http端口的配置加入如下：
<Connector port="5050"address="${jboss.bind.address}"
maxThreads="300"strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="false" enableLookups="false"redirectPort="5000"
acceptCount="100"connectionTimeout="15000" maxSpareThreads="75"
minSpareThreads="10"disableUploadTimeout="true" URIEncoding="UTF-8"
compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla,traviata"
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain,application/json"/>
静态资源（JavaScript ,CSS,Image）方面
1）压缩 JavaScript，CSS和Image
原因不必多赘述，另外一个角度的避免因网络情况差而出现的性能瓶颈。
2）正确使用和放置js和css
请关注以下原则：
1. 将CSS样式放在页面的head区域，避免页面在加载过程中出现空白或无样式。
2. 将外联JS放在页面的head区域，避免加载不到JS的情况出现。
3. 将执行的JS放到页面的最下方，避免浏览器在解释JS时，发生阻塞而导致页面加载停滞。
4. 避免使用 CSS 中的 Expressions。
3）将 JavaScript 和 CSS 独立成外部文件
觉得这一点和内容部分的“尽量减少HTTP请求数量”貌似有点冲突？其实不然。
先关注一下IE作为的HttpClient的并发能力：
IE6：1个并发
IE7：2个并发
IE8：默认6个并发且可以自行设置。
可以看到，在高版本IE的支持并发，且在网络情况良好的情况下，采用多个外联文件的方式加载js和css，可以最大程度的利用客户端和网络的资源，快速访问页面。
4）移除重复的脚本
这点不说也知道，不仅是从性能上考虑，代码规范上看也是这样。不得不承认，很多时候我们会因为图一时之快而加上一些或许是重复的代码。采用一个统一的css框架和js框架可以比较好的解决这个问题。如，JQuery。
2 兵练篇
学而不用，纸上谈兵，是以为殆也。
以下借鉴在MDSP中做性能优化或性能攻关中各个案例，为大家讲述各式各样的性能问题的定位思路和解决之道。
网络不畅导致网络传输超慢，前后台交互耗时长，用户体验极其低下。（江苏移动）
问题现象：MDMC所有页面访问速度极其慢。
定位思路：
1.所有页面访问速度都慢，说明不是单页面问题而是统一性问题。如：后台CPU居高不下或内存占用异常，导致MDMC无法处理页面请求；或者是网络带宽问题；或者是MDMC的过滤器问题。
2.通过top命令发现后台资源无异常。（排除后台资源问题）
3.搭建简单tomcat环境+静态页面，访问速度仍然慢。（排除MDMC系统过滤器问题）
4.通过客户端ping命令发现网络丢包严重。（初步找到原因）
5.通过httpWatch(参考兵器篇的详细介绍)监控，发现每个http请求的时间都耗在wait阶段（进一步证实网络故障）：
6.关闭服务端和客户端的防火墙，访问速度仍然慢。（排除防火墙带来的网络传输问题，最终确认问题根因为：网络本身的连通性问题）
解决方案：
1.由于局方坚持保持网络现状，只能从系统方面优化。
2.根据兵法篇做服务端优化，首先采用静态资源缓存，效果相当明显。页面在使用本地缓存文件之后，访问页面的速度得到极大提升。
3.进一步采用Gzip压缩，则即使是第一次访问系统，速度也较优化前提升50%。
DOM元素过多导致页面浏览的响应时间极长，用户体验极其低下。（游戏基地/越南VMS）
问题现象：MDMC的呈现详情页面访问速度极长。
定位思路：
1.其他页面访问均正常，说明是单页面问题。
2.通过IE Developer（详细介绍参见兵器篇）逐个查看页面元素，发现有2000多个<input type=”checkbox”>的dom元素。
3.查看相关页面代码，搜索checkbox，发现如下js:
for (var i=0;i<checkboxes.length;i++){….}
得知该for循环将执行2000次，每次都会操作DOM元素进行页面的重绘和渲染。
4.确认问题根因为：DOM元素过多导致页面解析和渲染时间超长。
解决方案：
1.分析：checkbox的数量为何如此之多？（现网终端数目多，2000多款）
2.讨论：由于是浏览页面（只读），只需要展示选中终端即可，无需展示所有终端。
3.实施：将浏览页面改为仅展示选中终端。
问题解决。
文件控件元素过多，且没有清空，导致表单提交数据超大，表单提交失败，阻塞内容发布及后续流程。（动漫基地）
问题现象：MDMC的新增实体文件页面上，当实体文件到达一定数目时，提交失败表单失败，阻塞内容发布流程。
定位思路：
1.查看后台日志，发现报File size exceed。
2.查看配置文件，发现文件上传上限为2M。
3.使用httpWatch（详细介绍参见兵器篇）查看页面表单提交数据（send），总大小有3M之多。（异常现像）
4.使用IE Developer（详细介绍参见兵器篇）查看页面中有10个左右的input type=file，并且value不为空。（找到问题）
5.确认问题根因为：表单中文件控件过多，表单提交时数据超大。
解决方案：
1.文件提交动作和表单提交动作不需要同时执行，否则可能会数据超大。
2.将文件提交改为动态生成input type=file的方式，并在提交成功后，remove掉input，避免页面产生冗余的DOM。
问题解决。
列表页面迭代设计不合理导致页面响应时间极长，用户体验低下。（动漫基地）
问题现象：MDMC的内容列表页面响应时间极长。
定位思路：
1. 使用httpWatch（详细介绍参见兵器篇）查看列表页面，发现每次访问列表页面，http请求action有11次之多。（异常现像）
2. 将列表改成每页50条，再次访问列表页面，发现http请求action有51次之多.。（次数跟分页数目有关）
3. 查看列表页面代码，发现列表在每次迭代时，会发起一个http请求。（确定问题）
4.确认问题根因为：列表页面迭代涉及不合理，导致http请求次数过多。
解决方案：
1.分析：为什么要在页面迭代中再次请求？（额外的列表项需求）
2.实施：即使是额外的列表项需要展示，也应该在后台一次性获取到，并封装到列表数据对象中。
问题解决。
3 兵器篇
工欲善其事，必先利其器。
前台分析工具
1）HttpWatch Professional
HttpWatch Professional绝对是Web性能定位分析工具的首选。该工具简单易用，并能轻量集成到IE中，实时监控http请求中从始到终的各种数据和状态。其中的URL瀑布图，TimeChart，发送数据（头），响应数据（头），是我们定位Web问题（不仅仅是性能问题）的最常用手段。另外，其Cookie，Cache等数据，更是一些Web疑难杂症的线索藏身之处。可谓是“Watch在手，数据全有”。该工具也是作者使用最频繁的武器（没有之一）。强烈推荐Web开发人员必备，人手一份。详细使用方法，请见附件中的说明。
2）IE Developer ToolBar
IE Developer ToolBar其实是一款页面Dom分析工具，它能够以树状菜单的形式描述一个完整的页面Dom结构，相应的勾勒出页面控件的形状，并能够显示每个Dom的js或css属性，便于开发人员直观的分析和定位。
3）FireBug
FireBug其实是FireFox的自带插件，其功能跟HttpWatch相差无几，只是所依附的浏览器不同。（HttpWatch也有FireFox版的插件）
4）Page Speed
Page speed 是基于Firebug的1个工具，主要可以对页面进行评分，总分100分，而且会显示对各项的改进意见，Page Speed也能检测到JS的解析时间。
对于开发人员而言，这款工具的神奇之处就是在于它能通过自动评分的方式，评价页面各项指标的好坏，让开发人员能够聚焦于正确的优化方向，大大减少自行分析和定位的时间，可以称得上是Web系统性能优化的进阶利器。
5）DynaTrace's Ajax Edition
Web系统性能分析终极工具，Web页面的各种缺陷可以通过该工具一览无余。不但可以检测资源加载瀑布图，而且还能监控页面呈现时间，页面渲染过程，网络传输性能，客户端CPU开销，JS分析和执行时间，CSS解析时间等等。同时，它也能像PageSpeed一样给出页面各项指标的评分。熟练掌握该工具，可以精确定位Web系统的各类性能问题。附件是该工具的使用指南。
后台分析工具
1）线程和堆栈分析工具（IBM Thread and Monitor）
分析jave core文件，常用于查看阻塞线程以及分析堆栈。
2）heapdump分析工具（IBM HeapAnalyzer）
分析java heap文件。用于查看heapdump中的java对象的占用情况，判断java大对象的GC状态。
这个工具的意义非常重大，大家都知道在java自带gz的机制，并且没有sizeOf及类似的方法用于计算对象大小，因此在定位java一些大对象带来的性能问题时，往往比较吃力。该工具能够以树形菜单和对象列表的形式将dump文件中的java对象详细展示出来，包括size, total, type等等，非常直观。
以下是该工具的使用指南。
后记
性能问题永远都不会有一个最终的完美方案。其要点在于，设计，编程，配置，测试时要有性能的概念。思考自己的每一个动作会对性能造成什么样的影响。性能的改进依赖于测试，任何改进都必须有性能测试报告来证明其是行之有效的，而不是拍脑袋拍出来的。性能的改进同时依赖于团队对于性能持久的关注，而不是有了问题才想到去解决。
希望该文档对能够让大家对性能优化问题有初步的接触和了解，认识到性能问题并不可怕，只要能够找对方向，抓住要点，实施行之有效的改进，任何性能问题都是纸老虎。