1.少用全局变量
原因：因为作用域链是一个堆栈的结构，所以遵循先进先出的原则，而javascript引擎在解析代码的时候，将全局对象放在栈底，然后向上依次出现的是不同作用域的活动对象（这些活动对象除了闭包没有相互依赖的关系），所以在查找变量的时候会从该活动对象开始，然后是闭包它的活动对象，最后是全局对象，如果全局变量过多就会影响获得变量时的速度，所以不要过多使用全局变量。
2.尽量使用局部变量封装全局变量
原因：正如前面所说，活动对象在栈的顶端，所以最先查找它的内容，当我们将document封装成局部变量后就会减少深层次查找的次数，使性能提高。
3.操作数组长度、对象属性时，尽量使用局部变量封装。
原因：IE、opera存取数组比对象属性快，而FF chrome safari正好相反，所以兼顾这些，我们最好封装一下。
4.尽量减少对象属性的深度
原因：深度太大，会增加javascript引擎对取得值的地址查找的开销，相当于增加了多层嵌套的指针，导致性能损失。
5.在for循环中尽量使用局部变量封装条件项
原因：例如for(var i=0;i<divs.length;i++) 的时候，如果divs为document.getElementsByTagName('div')，这样在每次循环判断条件的时候都会对DOM文档进行一次遍历求得长度，所以讲length封装起来，会提升性能。
6.谨慎的处理HTMLcollection对象（比如childNodes getElementsByTagName等取得DOM元素集合的对象），最好将其封装到数组里操作。
原因：还是因为操作DOM元素需要遍历DOM文档，而非DOM元素则不用遍历，所以请尽量减少对DOM的操作，而将DOM集合放到数组中去。
7.在针对safari浏览器的开发过程中，请尽量使用“.”获取对象属性而不是用“[]”。
8.建议在少于两次判断的环境下使用if-else，而大于三次的就用switch吧。而超过10次的时候，还是使用数组或json对象来通过索引来查找吧（这种模式相对简单）
9.如果循环数组的顺序从低到高或从高到低没有差别，那么还是从高到低比较好，比如我们循环输出一个数组中的内容：
var arr=[1,2,3,4,5]; var i=0; while(i<arr.length){ alert(arr[i]); }//这样开销会比较大，因为每次都要遍历求出数组元素的长度 //---------------------------------- var i=arr.length; while(i--){ alert(arr[i]); }//使用局部变量保存数组长度，然后该变量自减，连while中的判断都省了，因为0转换为布尔值就是false。
10.尽量少使用for-in循环，将其尽量改造成while 或for循环。
11.处理大数组时，请遵循duff策略。
duff策略：将大数组的个数拆分成8个一组，对这8个为一个单位的数组的操作不用循环处理，而是不怕繁琐的写出8行处理数组元素的代码，这样会提升大数组操作的性能。
12.用函数处理大数组的每个元素时，尽量使用定时器将每次操作挂起，时间设定在50-100ms比较合理
原因：如果简单的用循环来处理数组中的每个元素，如果是大数组，会造成页面的冻结和假死，给用户不好的体验，而用setTimeout，就会把每次操作都暂时挂起，让javascript引擎有其他的时间去处理队列中的其他函数，有效的防止了冻结和假死，而在设定的延迟时间之后，有可能javascript引擎是空闲的状态，可以更好的处理这些数组操作。相当于虚拟了一个后台操作。下面是zakas提出的解决方案：
function chunk(array,func,context){ setTimeout(function(){ var arr=array.shift(); func.call(context,item); if(array.length>0){ setTimeout(arguments.callee,100);//递归循环这个过程 arguments.callee为chunk这个函数对象 } },100); }
13.在使用iframe的时候注意window onload的阻塞
原因：iframe的加载会对window onload进行阻塞，导致有些window unload事件中加载的代码在用户关掉页面的时候可能不被执行，所以需要我们最好在window onload时间发生时动态为iframe设定src属性。
PS:能不用iframe就不用。
14.CSS选择符的优化
原因：CSS选择符的读取方式为从右至左，所以在写的时候尽可能右边规则详细，而且尽量少用子选择符合后代选择符标签选择符。