还有一个小时才到2012，那还能有点时间写点吐槽的东西，嘿嘿...2011年12月绝对是本人工作以来压力最大的一个月，已经忙到睡觉时间少了，业余看书时间少了，身体开始报警了，肩膀上的责任压的我实在喘不过气...作为一个普通的北漂，在北京类似我这样的人海的去了，尤其是在咱们这个行业。
我非常热爱生活，每分钟都无比珍贵；我热爱我现在所做的一切，哪怕确实让我精疲力尽(所以写博客暂时被我当成减压的方法)。
在我看来生活就是应该这样，既然我们在投胎的时候选择的生存模式or困难模式，那么不管发生什么困难都是意料之中。所以我在这不是想要表达自己的抱怨，而是想提醒自己和大家 “ 再忙再累也不要忘记自己的梦想和目标 ”。
突然想起个例子不吐不快，关于我们80后应该都玩过的超级玛丽(mario)。不管你有多少生命多少金币，说到底都是浮云，游戏中你会碰到无数的敌人(乌龟、飞鱼、食人花...)，遇到无数的艰险(一个接一个的坑、下水道、火海...)，可是想要通关只有一个方法，那就是救到公主，这就是目标。
If you want to live a happy life, tie it to a goal. Not to people or things.
如果你想过得快乐，那就把生活和目标结合在一起，而不是来自他人或物质。
许久才出来冒一次泡，所以难免吐槽一下，不喜欢以上那段的就当看个热闹，下面咱们开始正题。
-------------------------------------------------我是分割线-------------------------------------------------
作为本人2011年的收尾文章，就来个总结性质的吧，^_^...最近一直有给新同学做前端方面的培训，也有去参与公司前端的招聘，所以把自己资料库里面很多高效且有用的知识做了些规整分类，然后再分享一篇关于前端优化方面的总结。而且春节一过就又是招聘的高峰期了，在校的、跳槽的、浮躁的都开始进入面试的大军，前端优化也是前端面试一般会问到的东西，所以希望能对朋友们有用。
前端性能优化
1. 请减少HTTP请求
基本原理：
在浏览器(客户端)和服务器发生通信时，就已经消耗了大量的时间，尤其是在网络情况比较糟糕的时候，这个问题尤其的突出。
一个正常HTTP请求的流程简述：如在浏览器中输入"www.xxxxxx.com"并按下回车，浏览器再与这个URL指向的服务器建立连接，然后浏览器才能向服务器发送请求信息，服务器在接受到请求的信息后再返回相应的信息，浏览器接收到来自服务器的应答信息后，对这些数据解释执行。
而当我们请求的网页文件中有很多图片、CSS、JS甚至音乐等信息时，将会频繁的与服务器建立连接，与释放连接，这必定会造成资源的浪费，且每个HTTP请求都会对服务器和浏览器产生性能负担。
网速相同的条件下，下载一个100KB的图片比下载两个50KB的图片要快。所以，请减少HTTP请求。
解决办法：
合并图片（css sprites），合并CSS和JS文件；图片较多的页面也可以使用 lazyLoad 等技术进行优化。
2. 请正确理解 Repaint 和 Reflow
注：Repaint 和 Reflow 也就是重绘和重排，请允许我在这卖弄下我有限认识的那么几个英语单词...囧
基本原理：
Repaint(重绘)就是在一个元素的外观被改变，但没有改变布局(宽高)的情况下发生，如改变visibility、outline、背景色等等。
Reflow(重排)就是DOM的变化影响到了元素的几何属性（宽和高），浏览器会重新计算元素的几何属性，会使渲染树中受到影响的部分失效，浏览器会验证DOM树上的所有其它结点的visibility属性，这也是Reflow低效的原因。如：改变窗囗大小、改变文字大小、内容的改变、浏览器窗口变化，style属性的改变等等。如果Reflow的过于频繁，CPU使用率就会噌噌的往上涨，所以前端也就有必要知道 Repaint 和 Reflow的知识。
减少性能影响的办法：
上面提到通过设置style属性改变结点样式的话，每设置一次都会导致一次reflow，所以最好通过设置class的方式； 有动画效果的元素，它的position属性应当设为fixed或absolute，这样不会影响其它元素的布局；如果功能需求上不能设置position为fixed或absolute，那么就权衡速度的平滑性。
总之，因为 Reflow 有时确实不可避免，所以只能尽可能限制Reflow的影响范围。
3. 请减少对DOM的操作
基本原理：
对DOM操作的代价是高昂的，这在网页应用中的通常是一个性能瓶颈。
天生就慢。在《高性能JavaScript》中这么比喻：“把DOM看成一个岛屿，把JavaScript(ECMAScript)看成另一个岛屿，两者之间以一座收费桥连接”。所以每次访问DOM都会教一个过桥费，而访问的次数越多，交的费用也就越多。所以一般建议尽量减少过桥次数。
解决办法：
修改和访问DOM元素会造成页面的Repaint和Reflow，循环对DOM操作更是罪恶的行为。所以请合理的使用JavaScript变量储存内容，考虑大量DOM元素中循环的性能开销，在循环结束时一次性写入。
减少对DOM元素的查询和修改，查询时可将其赋值给局部变量。
注：在IE中:hover会降低响应速度。
4. 使用JSON格式来进行数据交换
基本原理：
JSON是一种轻量级的数据交换格式，采用完全独立于语言的文本格式，是理想的数据交换格式。同时，JSON是 JavaScript原生格式，这意味着在 JavaScript 中处理 JSON数据不需要任何特殊的 API 或工具包。
与XML序列化相比，JSON序列化后产生的数据一般要比XML序列化后数据体积小，所以在Facebook等知名网站中都采用了JSON作为数据交换方式。
JS操作JSON：
在JSON中，有两种结构：对象和数组。
1. 一个对象以 “ { ” 开始，“ } ” 结束。每个“名称”后跟一个 “ : ” ；“名称/值 对”之间使用 “ , ”（逗号）分隔。 名称用引号括起来；值如果是字符串则必须用引号括起来，数值型则不需要。如：
var obj={"name":"darren","age":24,"location":"beijing"}2. 数组是值（value）的有序集合。一个数组以 “ [ ” 开始， “ ] ” 结束。值之间使用 “ , ” （逗号）分隔。如：
var jsonlist=[{"name":"darren","age":24,"location":"beijing"},{"name":"weidong.nie","age":24,"location":"hunan"}];对这种数组和对象字面量的操作是非常方便且高效的。如果预先知道JSON结构的情况下，使用JSON进行数据传递简直是太美妙了，可以写出很实用美观可读性强的代码。如果你是纯粹的前台开发人员，一定会非常喜欢JSON。
5. 高效使用HTML标签和CSS样式
基本原理：
HTML是一门用来描述网页的一种语言，它使用标记标签来描述网页，作为一名合格的前端开发，你有必要去知道其常用标签代表的含义(SEO)和属性(表现形式)。
CSS指层叠样式表 (Cascading Style Sheets)，如果说把页面想象成一个人，HTML就是人的骨架，CSS就是人的衣装，一个人的品味从他的衣装就能一目了然。
一名专业的前端开发也是一名优秀的重构，因为在页面中经常会有各种不合理的嵌套和重复定义的CSS样式，我不是要你重构页面，只是希望你在碰到这种情况的时候解决这些问题。如这样的HTML：
<table><tr><td>
<table><tr><td>
...
</td></tr></table>
</td></tr></table>或者这样的CSS:
body .box .border ul li p strong span{color:#000}以上都是对HTML和CSS非常糟糕的使用方法。
正确理解：
HTML是一门标记语言，使用合理的HTML标签前你必须了解其属性，比如Flow Elements，Metadata Elements ，Phrasing Elements。比较基础的就是得知道块级元素和内联元素、盒模型、SEO方面的知识。
CSS是用来渲染页面的，也是存在渲染效率的问题。CSS选择符是从右向左进行匹配的，这里对css选择符按照开销从小到大的顺序梳理一下：
ID选择符 #box
类选择符 .box
标签 div
伪类和伪元素 a:hover当页面被触发引起回流（reflow）的时候，低效的选择符依然会引发更高的开销，所以请避免低效。
6. 使用CDN加速（内容分发网络）
基本原理：
CDN的全称是Content Delivery Network，即内容分发网络。
"其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。" - 百度百科。
上面几句话有多少能安安心心看完的，所以我还是通过说故事再来介绍一遍吧，顺便补一句，故事出处不明，^_^：
古代打仗大家一定都知道，由于古代的交通很不发达，所以当外族进攻的时候往往不能及时的反击，等朝廷征完兵再把兵派往边境的时候那些侵略者却是早已不见了踪影，这个让古代的帝王很是郁闷。后来帝王们学聪明了，都将大量的兵员提前派往边境驻扎，让他们平时屯田，战时当兵，这样的策略起到了很显著的作用。
不足之处：
实时性不太好是CDN的致命缺陷。随着对CDN需求的逐渐升温，这一缺陷将得到改进，使来自于远程服务器的网络内容网页与复本服务器或缓存器中的网页保持同步。解决方法是在网络内容发生变化时将新的网络内容从服务器端直接传送到缓存器，或者当对网络内容的访问增加时将数据源服务器的网络内容尽可能实时地复制到缓存服务器。
7. 将CSS和JS放到外部文件中引用，CSS放头，JS放尾
基本原理：
注：这个是很基础且必须遵循的知识点，可是为了文章的完整性勉为其难加进来吧，嘿嘿。
引入外部文件好处是显而易见的，而且是项目稍稍复杂一点的时候就有必要了这样做了。
易维护、易扩展，方便管理和重复利用。
正确的方式：
JavaScript是浏览器中的霸主，为什么这么说，因为在浏览器在执行JavaScript代码时，不能同时做其它事情，即<script>每次出现都会让页面等待脚本的解析和执行（不论JavaScript是内嵌的还是外链的），JavaScript代码执行完成后，才继续渲染页面。这个也就是JavaScript的阻塞特性。
因为这个阻塞的特点，建议把JavaScript代码放到</body>标签以前，这样既能有效的防止JavaScript的阻塞，又能使得页面的HTML结构能更快的释放。
HTML规范清楚指出CSS要放包含在页面的<head>区域内，这里就不多解释了。
8. 精简CSS和JS文件
基本原理：
有一条非常重要的准则一直没有提到，就是CSS和JavaScript的压缩，直接减少下载的文件体积。我个人经常使用的方式是使用 YUI Compressor，它的特点是：移除注释；移除额外的空格；细微优化；标识符替换。
YUI Compressor是java程序，如果你对java很熟悉的话可快速的上手使用yuicompressor.jar；如果你对java很陌生也没关系，一样可以使用YUI Compressor，下面介绍其使用方式。
YUI Compressor的配置和使用：
先配置使用环境：
1.先确保电脑中是否安装了JDK
2.再配置必要的环境变量(细节不能三两句说清，所以不知道如何设置还是搜索吧)
3.在cmd界面，输入javac可测试是否安装成功
使用方法可从cmd到进入yuicompressor.jar所在磁盘，我以自己的yuicompressor-2.4.2.jar为例：
1.压缩JS
java -jar yuicompressor-2.4.2.jar api.js > api.min.js2.压缩CSS
java -jar yuicompressor-2.4.2.jar style.css > style.min.css
当然，还有另一种更傻瓜式的使用方式，赶兴趣的朋友自己可去多尝试下。
9. 压缩图片和使用图片Spirit技术
基本原理:
注：其实压缩图片和图片精灵是两个方面的技术，可是既然都是关于图片的优化还是放到一块吧。
现在由于工作的细分，专业的前端工程师已经少有机会去切图了，可是关于图片压缩还是得略微了解，一般图片压缩的方式有：
1.缩小图片分辨率；
2.改变图片格式；
3.降低图片保存质量。
关于图片精灵(Spirit)技术就和我们工作直接相关，不管是在CSS中的图片还是在HTML结构中的图片都会产生HTTP请求，前端优化的第一条就是减少请求数，最直接有效的方法是使用图片精灵（CSS Spirit）。图片精灵就是把许多图片放到一张大图片里面，通过CSS来显示图片的一部分。
至于图片精灵的操作细节就不多做介绍了，网上相关内容很多。
10. 注意控制Cookie大小和污染
基本原理和使用方法：
有关Cookie的基础和高级知识可以去看本人写过的一篇文章《JavaScript 操作 Cookie》。
因为Cookie是本地的磁盘文件，每次浏览器都会去读取相应的Cookie，所以建议去除不必要的Coockie，使Coockie体积尽量小以减少对用户响应的影响；
使用Cookie跨域操作时注意在适应级别的域名上设置coockie以便使子域名不受其影响
Cookie是有生命周期的，所以请注意设置合理的过期时间，合理地Expire时间和不要过早去清除coockie，都会改善用户的响应时间。
时间有限，今年就先到这里吧，哈哈。愿大家新年快乐，工作顺利。我会在以后的工作中慢慢完善这篇文章，也请大家多提宝贵建议。
如果大家也有什么好的优化方式也请留言，到时会补充到这篇文章当中，先在此谢谢了。
参考资料
百度百科
http://dev.w3.org/html5/markup/common-models.html
前端攻城师攻略系列
作为一名前端攻城师，越来越感受到在公司受到的重视，身边也有越来越多的朋友加入到前端开发这个岗位上，有种说不出的骄傲感。
由于闲暇时间喜欢看书，所以曾萌生过希望写本书的想法，虽然现在自己还有很多的坑需要踩过，真要写书也是将来很久以后的事了，可是有打算先尝试写点与前端紧密相关的攻略，于是就有了“前端攻略系列”。
由于现在本人表达能力和技术能力上的欠缺，难免有理解不对的地方，也请大家多多谅解。
如果觉得此文还算用心，请劳驾点击右下角的推荐^.^ 。