理论上AJAX技术在很大的程度上可以减少用户操作的等待时间，同时节约网络上的数据流量。而然，实际情况却并不总是这样。用户时常会抱怨用了AJAX的系统响应速度反而降低了。
笔者从事AJAX方面的研发多年，参与开发了目前国内较为成熟的AJAX平台-dorado。根据笔者的经验，导致这种结果的根本原因并不在AJAX。很多时候系统响应速度的降低都是由不够合理的界面设计和不够高效的编程习惯造成的。下面我们就来分析几个AJAX开发过程中需要时刻注意的环节。
合理的使用客户端编程和远程过程调用
客户端的编程主要都是基于JavaScript的。而JavaScript是一种解释型的编程语言，它的运行效率相对于Java等都要稍逊一筹。同时JavaScript又是运行在浏览器这样一个严格受限的环境当中。因此开发人员对于哪些逻辑可以在客户端执行应该有一个清醒的认识。
在实际的应用中究竟应该怎样使用客户端编程，这依赖于开发人员的经验判断。这里很多问题是只可意会的。由于篇幅有限，在这里我们大致归纳出下面这几个注意事项：
尽可能避免频繁的使用远程过程调用，例如避免在循环体中使用远程过程调用。
如果可能的话尽可能使用AJAX方式的远程过程调用（异步方式的远程过程调用）。
避免将重量级的数据操作放置在客户端。例如：大批量的数据复制操作、需要通过大量的数据遍历完成的计算等。
改进对DOM对象的操作方式。
客户端的编程中，对DOM对象的操作往往是最容易占用CPU时间的。而对于DOM对象的操作，不同的编程方法之间的性能差异又往往是非常大的。
以下是三段运行结果完全相同的代码，它们的作用是在网页中创建一个10x1000的表格。然而它们的运行速度却有着天壤之别。
/* 测试代码1 - 耗时: 41秒*/
var table = document.createElement("TABLE");
document.body.appendChild(table);
for(var i = 0; i 这里的“测试代码1”和“测试代码2”之间的差别在于在创建表格单元时使用了不同的API方法。而“测试代码2”和“测试代码3” 之间的差别在于处理顺序的略微不同。
“测试代码1”和“测试代码2”之间如此大的性能差别我们无从分析，目前所知的是insertRow和insertCell是DHTML中表格特有的 API，createElement和appendChild是W3C DOM的原生API。而前者应该是对后者的封装。不过，我们并不能因此而得出结论认为DOM的原生API总是优于对象特有的API。建议大家在需要频繁调用某一API时，对其性能表现做一些基本的测试。
“测试代码2”和“测试代码3”之间的性能差异主要来自于他们的构建顺序不同。“测试代码2”的做法是首先创建最外层的<TABLE>对象，然后再在循环中依次创建<TR>和<TD>。而“测试代码3”的做法是首先在内存中由内到外的构建好整个表格，最后再将它添加到网页中。这样做的目的是尽可能的减少浏览器重新计算页面布局的次数。每当我们将一个对象添加到网页中时，浏览器都会尝试对页面中的控件的布局进行重新计算。所以，如果我们能够首先在内存中将整个要构造的对象全部创建好，然后再一次性的添加到网页中。那么，浏览器将只会做一次布局的重计算。总结为一句话那就是越晚执行appendChild越好。有时为了提高运行效率，我们甚至可以考虑先使用 removeChild将已存在的控件从页面中移除，然后构造完成后再重新将其放置回页面当中。
提高字符串累加的速度
在使用AJAX提交信息时，我可能常常需要拼装一些比较大的字符串通过XmlHttp来完成POST提交。尽管提交这样大的信息的做法看起来并不优雅，但有时我们可能不得不面对这样的需求。那么JavaScript中对字符串的累加速度如何呢？我们先来做下面的这个实验。累加一个长度为30000的字符串。
/* 测试代码1 - 耗时: 14.325秒 */ var str = ""; for (var i = 0; i
这段代码耗时14.325秒，结果并不理想。现在我们将代码改为如下的形式：
/* 测试代码2 - 耗时: 0.359秒 */ var str = ""; for (var i = 0; i
这段代码耗时0.359秒！同样的结果，我们做的只是首先拼装一些较小的字符串然后再组装成更大的字符串。这种做法可以有效的在字符串拼装的后期减小内存复制的数据量。知道了这一原理之后我们还可以把上面的代码进一步拆散以后进行测试。下面的代码仅耗时0.140秒。
/* 测试代码3 - 耗时: 0.140秒 */ var str = ""; for (var i1 = 0; i1
不过，上面这种做法也许并不是最好的！如果我们需要提交的信息是XML格式的（其实绝大多数情况下，我们都可以设法将要提交的信息组装成XML格式），我们还能找到更高效更优雅的方法—利用DOM对象为我们组装字符串。下面这段代买组装一个长度为950015的字符串仅须耗时0.890秒。
/* 利用DOM对象组装信息 - 耗时: 0.890秒 */
var xmlDoc;
if (browserType == BROWSER_IE) {
xmlDoc = new ActiveXObject("Msxml.DOMDocument");
}
else {
xmlDoc = document.createElement("DOM");
}
var root = xmlDoc.createElement("root");
for (var i = 0; i 避免DOM对象的内存泄漏
关于IE中DOM对象的内存泄露是一个常常被开发人员忽略的问题。然而它带来的后果却是非常严重的！它会导致IE的内存占用量持续上升，并且浏览器的整体运行速度明显下降。对于一些泄露比较严重的网页，甚至只要刷新几次，运行速度就会降低一倍。
比较常见的内存泄漏的模型有“循环引用模型”、“闭包函数模型”和“DOM插入顺序模型”,对于前两种泄漏模型，我们都可以通过在网页析构时解除引用的方式来避免。而对于“DOM插入顺序模型”则需要通过改变一些惯有的编程习惯的方式来避免。
有关内存泄漏的模型的更多介绍可以通过Google很快的查到，本文不做过多的阐述。不过，这里我向您推荐一个可用于查找和分析网页内存泄露的小工具——Drip，目前的较新版本是0.5，下载地址是http://outofhanwell.com/ieleak/index.php。
复杂页面的分段装载和初始化
对系统当中某些确实比较复杂而又不便使用IFrame的界面，我们可以对其实施分段装载。例如对于多页标签的界面，我们可以首先下载和初始化多页标签的默认页，然后利用AJAH（asynchronous JavaScript and HTML）技术来异步的装载其他标签页中的内容。这样就能保证界面可以在第一时间首先展现给用户。把整个复杂界面的装载过程分散到用户的操作过程当中。
利用GZIP压缩网络流量
除了上面提到的这些代码级的改良之外，我们还可以利用GZIP来有效的降低网络流量。目前常见的主流浏览器已经全部支持GZIP算法，我们往往只需要编写少量的代码就可以支持GZIP了。例如在J2EE中我们可以在Filter中通过下面的代码来判断客户端浏览器是否支持GZIP算法，然后根据需要利用 java.util.zip.GZIPOutputStream来实现GZIP的输出。
/* 判断浏览器对GZIP支持方式的代码 */
private static String getGZIPEncoding(HttpServletRequest request) {
String acceptEncoding = request.getHeader("Accept-Encoding");
if (acceptEncoding == null) return null;
acceptEncoding = acceptEncoding.toLowerCase();
if (acceptEncoding.indexOf("x-gzip") >= 0) return "x-gzip";
if (acceptEncoding.indexOf("gzip") >= 0) return "gzip";
return null;
} 一般而言，GZIP对于HTML、JSP的压缩比可以达到80%左右，而它造成的服务端和客户端的性能损耗几乎是可以忽略的。结合其他因素，支持GZIP 的网站有可能为我们节约50%的网络流量。因此GZIP的使用可以为那些网络环境不是特别好的应用带来显著的性能提升。使用Http的监视工具Fiddler可以方便的检测出网页在使用GZIP前后的通讯数据量。（Fiddler的下载地址是http://www.fiddlertool.com/fiddler/）
关于Web应用的性能优化其实是一个非常大的话题。本文由于篇幅有限，只能涉及其中的几个细节，并且也无法将这些细节的优化方式全面的展现给大家。期望本文能够引起大家对Web应用尤其是客户端性能优化的充分重视。毕竟服务端编程技巧已为大家熟知多年，在服务端挖掘性能的潜力已经不大了。而在客户端的方法改进往往能够得到令人惊奇的性能提升。