小小和rizen嘗試過定位一個cache-read耗費時間隨機的變得很長的詭異問題，排除過了文件內容、文件類型、文件頭等各種影響，但是很遺憾沒有最終結論。emu那天看知道這個事情后猜測，會不會就是很簡單的多個cache-read操作相互競爭堵塞導致的呢？這個其實很容易驗證了。寫了一個簡單的小頁面應用了一組圖片，然后抓包重新打開頁面，就看到下面這個圖了：
第一個cache-read耗時0.2秒多，第二個（并行發(fā)起）0.3秒多，第三個0.4秒多，接下去每個圖片的耗時差不多都比上一個慢0.1秒以上。結論很明顯了，并發(fā)的cache-read會相互堵塞，非常嚴重的相互堵塞。
以上抓包是在IE6下完成的。在IE7和IE8下面情況要好一些，但是問題性質是相同的。
很多我們曾經以為cache的非常好速度應該非常快的web應用，也許其實存在著嚴重的cache-read速度瓶頸而不為我們所知。
網上沒有搜到太多關于cache-read時間的文章，看來真是個盲點。
解決方案和網絡延遲是類似的，減少cache-read請求，把多個小文件和小圖片合并成大文件和大圖片（而不要一廂情愿的以為小文件被瀏覽器緩存后會有很好的速度表現），區(qū)分優(yōu)先級引用資源。還有一個可能有用的：交錯的發(fā)起不可避免的異步動態(tài)網絡請求和cache-read請求，讓網絡延遲和cache-read延遲時間疊加在一起，來節(jié)省用戶實際要等待的時間。