客户端脚本能让你的应用更加地动态和活跃， 但是浏览器对代码的解析可能造成效率问题， 而这种性能差异在客户端之间也不尽相同。 这里我们讨论和给出一些优化你的 JavaScript 代码的提示和最佳实践。

使用字符串

字符串连接操作会对 Internet Explorer 6 和 7 的垃圾收集带来很大的影响。 尽管这个问题在 Internet Explorer 8 里面得到解决 -- 字符串连接在 IE8 和其它非 IE 浏览器（如 Chrome）中稍微更有效率一点 -- 如果你的用户中有很大一部分在使用 Internet Explorer 6 或 7， 你就需要非常注意你构建字符串的方式了。

有如下示例代码：

以下为引用的内容：

var veryLongMessage =
'This is a long string that due to our strict line length limit of' +
maxCharsPerLine +
' characters per line must be wrapped. ' +
percentWhoDislike +
'% of engineers dislike this rule. The line length limit is for ' +
' style purposes, but we don't want it to have a performance impact.' +
' So the question is how should we do the wrapping?';
 

比起用连接的方式， 尝试使用 join（）：

以下为引用的内容：

var veryLongMessage =
['This is a long string that due to our strict line length limit of',
maxCharsPerLine,
' characters per line must be wrapped. ',
percentWhoDislike,
'% of engineers dislike this rule. The line length limit is for ',
' style purposes, but we don't want it to have a performance impact.',
' So the question is how should we do the wrapping?'
].join();
 

相似的， 用连接的方式在条件语句和循环中构建字符串是很低效的。 错误的方式：

以下为引用的内容：

var fibonacciStr = '前 20 个斐波那契数 ';
for (var i = 0; i < 20; i++) {
fibonacciStr += i + ' = ' + fibonacci(i) + '
';
}
 

正确的方法：

以下为引用的内容：
var strBuilder = ['前 20 个斐波那契数:'];
for (var i = 0; i < 20; i++) {
  strBuilder.push(i, ' = ', fibonacci(i));
}
var fibonacciStr = strBuilder.join('');

构建通过辅助函数生成的字符串

通过传递字符串构建器（可以是数组或者辅助类）到函数中构建长字符串， 以避免出现存放临时结果的字符串。

例如， 假定 buildMenuItemHtml_ 需要用文字串和变量构建一个字符串， 并且会在内部使用一个字符串构建器， 与其使用：

以下为引用的内容：

var strBuilder = [];
for (var i = 0; i < menuItems.length; i++) {
  strBuilder.push(this.buildMenuItemHtml_(menuItems[i]));
}
var menuHtml = strBuilder.join();

不如用:

var strBuilder = [];
for (var i = 0; i < menuItems.length; i++) {
  this.buildMenuItem_(menuItems[i], strBuilder);
}
var menuHtml = strBuilder.join();
 

定义类的方法

下面的代码效率不高， 因为每次构造 baz.Bar 的实例时， 都会为 foo 创建一个新函数和闭包（closure）：

以下为引用的内容：

baz.Bar = function() {
  // 构造函数代码
  this.foo = function() {
  // 方法代码
  };
}

推荐的方式为:

baz.Bar = function() {
  // 构造函数代码
};

baz.Bar.prototype.foo = function() {
  // 方法代码
};
 

用这种方式， 无论构造了多少个 baz.Bar 实例， 只会创建一个函数给 foo， 同时不会创建任何闭包。

初始化实例变量

将带有值类型（非引用的）的初始化值（例如类型为数字， 布尔值， null， undefined 或字符串的值）的变量声明/初始化代码直接放在 prototype 原型中。 这可以避免每次调用构造函数时不必要地运行初始化代码。 （这个方法无法应用到初始化值由构造器参数决定或构造时状态不确定的实例变量上。）

例如， 比起写：

以下为引用的内容：

foo.Bar = function() {
  this.prop1_ = 4;
  this.prop2_ = true;
  this.prop3_ = [];
  this.prop4_ = 'blah';
};

不如写:

foo.Bar = function() {
  this.prop3_ = [];
};

foo.Bar.prototype.prop1_ = 4;

foo.Bar.prototype.prop2_ = true;

foo.Bar.prototype.prop4_ = 'blah';
 

谨慎地使用闭包（closure）

闭包是 JavaScript 中一个强大而有用的特性; 但是， 它们也有不好的地方， 包括：

它们是最常见的内存泄漏源头。

创建一个闭包比创建一个没有闭包的内联函数明显要慢， 比起重用一个静态函数则更慢。 例如：

以下为引用的内容：
function setupAlertTimeout() {
  var msg = '要显示的消息';
  window.setTimeout(function() { alert(msg); }, 100);
}
比下面的代码慢:

function setupAlertTimeout() {
  window.setTimeout(function() {
    var msg = '要显示的消息';
    alert(msg);
  }, 100);
}
更比下面的代码慢:

function alertMsg() {
  var msg = '要显示的消息';
  alert(msg);
}

function setupAlertTimeout() {
  window.setTimeout(alertMsg, 100);
} 

他们增加了作用域链（scope chain）的层级。 当浏览器解析属性时， 作用域链的每一个层级都必须被检查一次。 在下面的例子中：

以下为引用的内容：
var a = 'a';

function createFunctionWithClosure() {
  var b = 'b';
  return function () {
    var c = 'c';
    a;
    b;
    c;
  };
}

var f = createFunctionWithClosure();
f(); 

当 f 被调用时， 引用 a 比引用 b 慢， 它们都比引用 c 要慢。

查看 IE+JScript Performance Recommendations Part 3: JavaScript Code inefficiencies 获得更多有关在 IE 中使用闭包的信息。

避免使用 with

在你的代码中避免使用 with. 它对性能有非常坏的影响， 因为它修改了作用域链， 让查找在其它作用域的变量变得代价高昂。

避免浏览器内存泄漏

内存泄漏对 Web 应用而言是个很普遍的问题， 它会带来严重的性能问题。 当浏览器的内存使用上升时， 你的 Web 应用， 连同用户系统的其他部分， 都会变慢。 Web 应用最常见的内存泄漏原因是： 在 JavaScript 脚本引擎和浏览器 DOM 的 C++ 对象实现间的循环引用（例如， 在 JavaScript 脚本引擎和 Internet Explorer 的 COM 基础架构间， 或者 JavaScript 引擎和 Firefox 的 XPCOM 基础架构间）。

下面是避免内存泄漏的一些经验法则：

使用一个事件系统来附加事件处理函数

最常见的循环引用模式 ［ DOM 元素 --》 事件处理函数 --》 闭包作用域 --》 DOM ］ 在 这篇 MSDN 的 Blog 文章中讨论过了。 为避免这个问题， 可以使用一个经过严格测试的事件系统来附件事件处理函数， 例如 Google doctype, Dojo, or JQuery.

另外， 在 IE 中使用内联（inline）的事件处理函数会导致另外一类泄漏。 这不是通常的循环引用泄漏， 而是内存中临时匿名脚本对象的泄漏。 详情请查看 理解和解决 IE 泄漏模式(Understanding and Solving Internet Explorer Leak Patterns)  的 “DOM 插入顺序泄漏模型（DOM Insertion Order Leak Model）” 一节， 另外在 JavaScript Kit 教程 中还有一个例子。

避免使用扩展（expando）属性

扩展属性是附加到 DOM 元素上的任意 JavaScript 属性， 也是循环引用的常见原因。 你能够在使用扩展属性时不导致内存泄漏， 但是很容易不小心就引入一个泄漏。 这个泄漏的模式是 ［ DOM 元素 --》 扩展属性 --》 中间对象 --》 DOM 元素 ］。 最好的方法就是避免使用它们。 如果你要使用它们， 就只使用简单的值类型。 如果你要非简单的类型， 那么在不再需要扩展属性时将它设为空（null）。 参见 理解和解决 IE 泄漏模式(Understanding and Solving Internet Explorer Leak Patterns) 中的 “循环引用（Circular References）” 一节.