6月11号

第一个cache-read耗时0.2秒多，第二个（并行发起）0.3秒多，第三个0.4秒多，接下去每个图片的耗时差不多都比上一个慢0.1秒以上。结论很明显了，并发的cache-read会相互堵塞，非常严重的相互堵塞。
以上抓包是在IE6下完成的。在IE7和IE8下面情况要好一些，但是问题性质是相同的。
很多我们曾经以为cache的非常好速度应该非常快的web应用，也许其实存在着严重的cache-read速度瓶颈而不为我们所知。
网上没有搜到太多关于cache-read时间的文章，看来真是个盲点。

解决方案和网络延迟是类似的，减少cache-read请求，把多个小文件和小图片合并成大文件和大图片（而不要一厢情愿的以为小文件被浏览器缓存后会有很好的速度表现），区分优先级引用资源。还有一个可能有用的：交错的发起不可避免的异步动态网络请求和cache-read请求，让网络延迟和cache-read延迟时间叠加在一起，来节省用户实际要等待的时间。

文章作者说“跑到微软那一查,给的答复让我吐血:Do not enable HTTP compression for the script files 请不要对脚本文件开启http压缩 只好在服务器端增加对浏览器的识别代码,如果是ie6,就不压缩脚本文件了 虽然脚本能运行了,可是用户体验就...  哎,我恨ie 6”

唉，说啥好呢？

真相是，微软的答复(http://support.microsoft.com/kb/327286/en-us?sid=64&spid=2073) 里面提供了两个解决方案，其中第一个描述的稍微啰嗦了一点，被这个作者直接忽略掉了。第二个解决方案只有一句话，显然更容易被读懂：

Emu虽然英文比较烂，四级老考不过，为了方便大家还是翻译一下吧，不然又该有人读不下去了。

作者： KeeKim Heng, Google Web Developer

在我们开发互联网富应用（RIA）时，我们经常写一些javascript脚本来修改或者增加页面元素，这些工作最终是DOM——或者说文档对象模型——来完成的，而我们的实现方式会影响到应用的响应速度。

DOM操作会导致浏览器重解析(reflow)，这是浏览器的一个决定页面元素如何展现的计算过程。直接修改DOM，修改元素的CSS样式，修改浏览器的窗口大小，都会触发重解析。读取元素的布局属性比如offsetHeithe或者offsetWidth也会触发重解析。重解析需要花费计算时间，因此重解析触发的越少，应用就会越快。

DOM操作通常要不就是修改已经存在的页面上的元素，要不就是创建新的页面元素。下面的4种优化方案覆盖了修改和创建DOM节点两种方式，帮助你减少触发浏览器重解析的次数。

方案一：通过CSS类名切换来修改DOM 

这个方案让我们可以一次性修改一个元素和它的子元素的多个样式属性而只触发一次重解析。

需求：

（emu注：原文作者写到这里的时候脑子显然短路了一下，把后面的Out-of-the-flow DOM Manipulation模式要解决的问题给摆到这里来了，不过从示范代码中很容易明白作者真正想描述的问题，因此emu就不照翻原文了）

我们现在需要写一个函数来修改一个超链接的几个样式规则。要实现很简单，把这几个规则对应的属性逐一改了就好了。但是带来的问题是，每修改一个样式属性，都会导致一次页面的重解析。

解决方案

要解决这个问题，我们可以先创建一个样式名，并且把要修改的样式规则都放到这个类名上，然后我们给超链接添加上这个新类名，就可以实现添加几个样式规则而只触发一次重解析了。这个模式还有个好处是也实现了表现和逻辑相分离。

（emu注：作者在这里再次脑子短路，把DocumentFragment DOM Generation模式的介绍提前到这里来了，emu只好再次发挥一下）
上一个方案解决的是修改一个超链接的问题，当一次需要对很多个超链接进行相同修改的时候，这个方案就可以大显身手了。

需求

需求是这样的，我们要写一个函数来修改一个指定元素的子元素中所有的超链接的样式名（className）属性。要实现很简单，我们可以通过遍历每个超链接并且修改它们的样式名来完成任务。但是带来的问题就是，每修改一个超链接都会导致一次重解析。

解决方案

要解决这个问题，我们可以把被修改的指定元素从DOM里面移除，再修改所有的超链接，然后在把这个元素插入回到它原来的位置上。为了完成这个复杂的操作，我们可以先写一个可重用的函数，它不但移除了这个DOM节点，还返回了一个把元素插回到原来的位置的函数。

方案三：一次性的DOM元素生成

这个方案让我们创建一个元素的过程只触发一次重解析。在创建完元素以后，先进行所有需要的修改，最后才把它插入到DOM里面去就可以了

需求

需求是这样的，实现一个函数，往一个指定的父元素上插入一个超链接元素。这个函数要同时可以设置这个超链接的显示文字和样式类。我们可以这样做：创建元素，插入到DOM里面，然后设置相应的属性。这就要触发3次重解析。

解决方案

很简单，我们只要把插入元素这个操作放到最后做，就可以只进行一次重解析了。

不过，要是我们想要插入很多个超链接到一个元素里面的话，那么这个做法还是有问题：每插入一个超链接还是要触发一次重解析。下一个方案可以解决这个问题。

方案四：通过文档片段对象（DocumentFragment）创建一组元素

这个方案允许我们创建并插入很多个元素而只触发一次重解析。要实现这点需要用到所谓的文档片段对象（DocumentFragment）。我们先在DOM之外创建一个文档片段对象（这样它也就不需要解析和渲染），然后我们在文档片段对象中创建很多个元素，最后我们把这个文档片段对象中所有的元素一次性放到DOM里面去，只触发一次重解析。

需求

我们要写一个函数，往一个指定的元素上面增加10个超链接。如果我们简单的直接插入10个超链接到元素上面，就会触发10次重解析。

解决方案

要解决这个问题，我们要先创建一个文档片段对象，然后把每个新创建的超链接都插入到它里面去。当我们把文档片段对象用appendChild命令插入到指定的节点时，这个文档片段对象的所有子节点就一起被插入到指定的元素里面，而且只需要触发一次重解析。

Functions invoked by setTimeout are passed an extra "lateness" argument in Mozilla, i.e., the lateness of the timeout in milliseconds.

使用谷歌浏览器(chrome)的时候，有的时候脚本程序会捕获到“Uncaught TypeError: Object #<an HTMLObjectElement> has no method 'create' ”这个错误，在chrome的用户论坛上也有人在问这个问题。

这个错误应该是由于最新版的谷歌浏览器没有自带完整的google gears组件导致的。看起来最新版的chrome浏览器会在用户第一次使用gears组件的时候自动下载和安装该组件，而在安装成功以前我们虽然可以成功创建 application/x-googlegears 对象，却无法调用它的create方法创建任何有用的东西。

这个时候其实没有太多的事情可以做，基本上我们我们只能检测这个对象的create接口是否存在，发现不存在的时候提示用户耐心等待，过一段时间后再刷新，或者下回再来看看，希望它已经自己安装好了。