阅读目录
- Javascript第一条定律：将脚本放在底部。
- Javascript第二条定律：将脚本成组打包。
- 杂谈
- 尽量使用局部变量来保存全局变量
- 尽量少去改变作用域链
- 尽量少去使用闭包
- 访问速度与成员嵌套深度有关
- 缓存变量的值
- 1、在修改DOM元素的时候，我们应该尽量使用innerHTML而不是CreateElement再AppendChild(因为经过测试，在所有的浏览器当中使用innerHTML更加快一些)
- 2、修改DOM元素内容时另外一个方法是使用element.cloneNode来代替document.createElement()
- 3、在循环或者遍历元素时，尽量使用局部变量保存HTML Collections
- 4、childNodes是一个集合，这也是为什么很多提高JavaScript性能的建议当中有这样一条了“使用firstChild和nextSibling代替childNodes遍历dom元素” 用图来说话吧（不信你可以测试一下，明显testNextSibling的速度比testChildNodes的快特别是当数据量大的时候一眼就能看出来）
- 5、如果浏览器使用具有原生的QuerySelectorAll（）方法和querySelector()方法尽量使用它们（因为自己实现它们的功能需要编写特别多的代码，还有就是任何编程语言都有一个共通的特性就是原生方法永远是性能最佳的）
- 6、最小化重绘和重排
众所周知浏览器是使用单进程处理UI更新和JavaScript运行等多个任务的，而同一时间只能有一个任务被执行，如此说来，JavaScript运行了多长时间就意味着用户得等待浏览器响应需要花多久时间。
从认知上来说，解析器解析一个界面的时候都是从上至下依次解析的，这就是说界面上出现多少个<script>标签（不管是内联还是外部文件），页面下载和解析必须停止等待脚本下载完成并运行完成（注意这里包括运行），这个过程当中，页面解析和用户交互是被完全阻塞的。
Javascript第一条定律：将脚本放在底部。
大家都知道，浏览器在遇到<body>标签之前，不会渲染页面中的任何部分，如果我们把<script>标签全部放在<body>标签之前，大家想想界面是不是一片空白，直至浏览器将所有js都下载并执行后才会去渲染页面，这也就是为什么要将所有<script>标签放在尽可能接近<body>标签底部也就是</body>前的原因。
Javascript第二条定律：将脚本成组打包。
减少引用外部脚本文件的数量，大家相信都会看到一些大型网站需要多次请求JavaScript文件时会将这个文件整合成一个文件，因为这样只需要一个<script>标签而减少性能损失。
书中介绍了运行一个<script>标签来加载两个js文件（但是自己没有试验成功，如果有知道怎么用的，可以告知我，谢谢！）
在此特意说明一下
- 为什么很多人特别喜欢用外部文件来写js而不用内联js，这是因为1）外部文件易于管理2）浏览器有缓存外部文件的功能，同样一个js文件如果被多个界面共享使用，第二个使用的可以直接从缓存中拿而不用从远程服务器上去下载，省去了好多时间及流量呀
- 为什么许多人会用CDN（Content Delivery Network）来加载公用js比如说jquery.js，这是因为从别的网站比如说jQuery官网下载jQuery占有的是别人服务器的资源，减轻了本地服务器的负载，节省网站分布式架构的支出成本和运维成本。
- 上文中讲了将多个js文件打包成一个js文件，可以提高性能，可以试试用Yahoo! Combo handler ,这篇文章介绍了一下http://www.ooso.net/archives/458 不过百度一下js打包工具一大堆，大家可以任意发挥哦
总归一句话就是加载js的时候会阻塞页面渲染，那怎么样让脚本不阻塞页面渲染呢，唯一的方法就是在window.onload发生后开始下载js
Javascript第三条定律：使用非阻塞方式下载js。
第一种方法：为script增加了一个defer属性，defer属性指定的script指明脚本不打算修改DOM,所以代码可以稍后执行。但是defer并不是所有浏览器都支持的。当defer指定的脚本文件被下载时，它不会阻塞浏览器的其它处理过程，所以事实上defer指定的脚本文件是可以与页面中的其它资源并行下载的。任何被指定为defer的脚本文件一定会在DOM加载完成之后才会被执行，也就是在onload事件之前被执行。
第二种方法：动态创建脚本也就是通过js创建script标签指定它的src来加载脚本文件，这种方法使得脚本下载和运行不会阻塞其它页面处理程序，所以你甚至可以把这种动态创建脚本的文件放在head标签当中都没有关系。
动态创建脚本的js如下图所示：
上述动态创建的脚本只要一指定它的src并append到document中，它就会自动执行里面的代码，那怎么样让它加载完成之后执行回调函数或者说如果我要加载多个js文件合格保证它们的顺序呢
看代码吧！ 哈哈（因为动态加载的js，浏览器不保证加载的顺序）
另外一种以非阻塞方式获得脚本文件的方法就是使用XHR(XmlHttpRequest脚本注入)
这种方法的主要优点是你可以下载不立即执行的脚本文件，但是缺点就是你要动态加载的js文件必须与当前运行的页面在同一个域中。
下面介绍几个动态加载的脚本库
LazyLoad--可以下载多个脚本文件并保证在所有浏览器上保证顺序执行。（虽然可以动态加载多个文件，但还是建议尽可能的减少文件数量，因为每个下载仍然是一个单独的HTTP请求）
Labs.js 它的script方法用于加载js文件，wait方法用于等待文件下载并运行之后执行的回调函数，通过wait方法允许你哪些文件应该等待其它文件，具体用法可以参照labs使用方法
杂谈
对于任何一种编程语言来说，数据存储的位置关系到访问速度！
在JavaScript中的直接量包括字符串string、数字number、布尔值boolean、对象object、数组array、函数function、正则表达式regular expression、空值null、未定义数组undefined。而数组项则需要通过数组的数字索引来访问，对象通过字符串进行索引来访问其成员（这里顺便提一句因为数组项是通过数字进行索引、对象成员是通过字符串进行索引，所以这也就是为什么访问对象成员比访问数组项更慢的原因）。
总结一句话就是说直接量和局部变量的访问速度要远已于数组项和对象成员，所以我们应该尽量使用直接量和局部变量，尽量限制使用数组项和对象成员。
了解过JavaScript原型链和闭包的都知道在JavaScript中每个函数事实上就是对象，每个函数内部都会有一个Scope属性，这个属性包含被创建的作用域中对象的集合，所以事实上内部Scope属性就是函数的作用域。在函数运行时，会建立一个运行期上下文（运行期上下文事实上就是函数运行时的环境，对于函数的每次运行而言，运行期上下文都是独一的，函数执行完毕运行期上下文将被销毁，也就是说多次运行同一个函数就会创建多个运行期上下文）。
当函数运行期上下文确定后，它的作用域将被初始化（作用域初始化包括函数参数、函数内部变量、this），作用域初始化之后将被作为激活对象推入作用域链的前端。（事实上这就是原型链的原理，js就是通过原型链来实现继承，通过闭包来实现成员的公有和私有），这也是为什么访问全局变量是最慢的，因为全局变量它是处于运行期上下文作用域链的最后一个位置。
尽量使用局部变量来保存全局变量
如果需要多次访问全局变量，尽量使用局部变量来保存它（我觉得这条规则运用在哪种编程语言中都适用）
尽量少去改变作用域链
- 使用with
- try catch
我了解到的JavaScript中改变作用域链的方式只有两种1）使用with表达式 2）通过捕获异常try catch来实现
但是with是大家都深恶痛绝的影响性能的表达式，因为我们完全可以通过使用一个局部变量的方式来取代它（因为with的原理是它的改变作用域链的同时需要保存很多信息以保证完成当前操作后恢复之前的作用域链，这些就明显的影响到了性能）
try catch中的catch子句同样可以改变作用域链。当try块发生错误时，程序自动转入catch块并将异常对象推入作用域链前端的一个可变对象中，也就是说在catch块中，函数所有的局部变量已经被放在第二个作用域链对象中，但是catch子句执行完成之后，作用域链就会返回到原来的状态。应该最小化catch子句来保证代码性能，如果知道错误的概念很高，我们应该尽量修正错误而不是使用try catch
尽量少去使用闭包
众所周知，闭包最厉害的地方就是允许函数使用局部范围之外的数据。
大家知道当函数运行完成之后，其运行期上下文就将被销毁，当涉及闭包的时候，它就不能被销毁，因为可能它还需要被函数引用，这样无形中就需要更多的内存开销。
访问速度与成员嵌套深度有关
成员嵌套越深访问速度越慢
location.href快于window.location.href
window.location.href快于window.location.href.toString()
缓存变量的值
（事实上就是如果需要访问全局变量或者多次访问具有深度的对象成员，使用局部变量将其保存下来以方便后续使用）
在JavaScript高级程序设计第一章当中就把JavaScript分成三大部分
所以事实上DOM和BOM是两在独立的部分，它们之间的通信是通过相互之间的功能接口来实现的，这样说来两个独立的部分以功能接口必定会带来性能损耗。这也就是为什么大家一致都说尽量少去访问和修改DOM元素（注意我这里说的是访问和修改，为什么包括访问，请继续往下看 哈哈）。
下面用一张图来说明它们各自的作用。
1、在修改DOM元素的时候，我们应该尽量使用innerHTML而不是CreateElement再AppendChild(因为经过测试，在所有的浏览器当中使用innerHTML更加快一些)
2、修改DOM元素内容时另外一个方法是使用element.cloneNode来代替document.createElement()
3、在循环或者遍历元素时，尽量使用局部变量保存HTML Collections
那具体什么叫HTML Collections，它包括哪些元素呢？
总结一句话就是说HTML Collections事实上是虚拟存在的，意味着当底层文档更新时，它们将自动更新。当每次迭代访问HTML Collections的length属性时，它会导致集合器更新，所以将length属性缓存到一个变量中，然后在循环判断条件中使用这个变量。
4、childNodes是一个集合，这也是为什么很多提高JavaScript性能的建议当中有这样一条了“使用firstChild和nextSibling代替childNodes遍历dom元素” 用图来说话吧（不信你可以测试一下，明显testNextSibling的速度比testChildNodes的快特别是当数据量大的时候一眼就能看出来）
5、如果浏览器使用具有原生的QuerySelectorAll（）方法和querySelector()方法尽量使用它们（因为自己实现它们的功能需要编写特别多的代码，还有就是任何编程语言都有一个共通的特性就是原生方法永远是性能最佳的）
6、最小化重绘和重排
在说明这个的时候顺便理清一下什么叫重绘，什么叫重排
大家都知道当一个页面展示在我们面前的时候，事实上浏览器下载完成所有的html标记，js，css，图片之后，它解析文件并创建两个内部结构，一个是DOM树，一个是渲染树。浏览器根据DOM树来进行排列，根据渲染树来进行绘制。
什么情况下会发什么重排呢
- 添加或删除可见的DOM元素
- 元素位置改变
- 元素尺寸改变（因为边距、填充、边框宽高等属性）
- 内容改变
- 最初的页面渲染
- 浏览器窗口改变尺寸
理解了重排，重绘就更加简单了，从字面意思上来说就是重新绘制，那什么情况下会发生重绘，比如说改变样式背景等
类似的我们知道了这个也应该在脚本中注意尽量减少repaint和reflow，什么情况会导致这两种情况呢
reflow：当DOM元素出现隐藏／显示、尺寸变化、位置变化的时候都会让浏览器重新渲染页面，之前渲染工作白费了
repaint：当元素的背景颜色、边框颜色不引起reflow的变化是会让浏览器重新渲染该元素。貌似还可以接受，但如果我们在开始就定义好了，不让浏览器重复工作就更好了。
上图中列举的这些属性的访问将会导致重新刷新渲染树从而导致重排，最好减少对这些属性（布局信息）的查询次数，查询时将它赋给局部变量，并用局部变量参与计算。
再来看一个小例子
这明显是糟糕的代码，改变了三次风格属性，导致浏览器重排了三次。一个提高效率的方法就是只重排一次。看下面代码就明白了
或者使用类名的方法
当你需要对DOM树中的多个元素进行修改的话，最好依据下列步骤来减少重排和重绘
- 从文档流中摘下此元素
- 对其应用多重改变
- 将元素带回文档中
有三种方式可以将元素从文档流中摘除
- 隐藏元素，对其进行修改后再显示
- 使用文档片断在已存DOM之外创建一个子树，然后将它拷贝到文档中（推荐使用此方法，因为它是涉及最小数量的DOM操作和重排）
- 将原始元素拷贝到一个脱离文档的节点中，修改副本，然后副本，然后覆盖原始元素
将第二次方案的代码贴一下，希望大家能使用这种方法来提高性能。
for (var i = 0; i < 1000; i++) {
var el = document.createElement('p');
el.innerHTML = i;
document.body.appendChild(el);
}
//可以替换为：
var frag = document.createDocumentFragment();
for (var i = 0; i < 1000; i++) {
var el = document.createElement('p');
el.innerHTML = i;
frag.appendChild(el);
}
document.body.appendChild(frag);
如果是动画元素的话，最好使用绝对定位以让它不在文档流中，这样的话改变它的位置不会引起页面其它元素重排
(我要说的就这些啦，希望大家共同探讨！)
这是我看高性能JavaScript的一点总结，希望对前端感兴趣的可以与我共同研讨！
有兴趣的可以去了解一下lab.js和lazyload 这俩挺好用的。哈哈！也可以跟我共同研讨！