小小和rizen尝试过定位一个cache-read耗费时间随机的变得很长的诡异问题，排除过了文件内容、文件类型、文件头等各种影响，但是很遗憾没有最终结论。emu那天看知道这个事情后猜测，会不会就是很简单的多个cache-read操作相互竞争堵塞导致的呢？这个其实很容易验证了。写了一个简单的小页面应用了一组图片，然后抓包重新打开页面，就看到下面这个图了：
第一个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延迟时间叠加在一起，来节省用户实际要等待的时间。
