小小和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延遲時間疊加在一起，來節省使用者實際要等待的時間。