最快的網(wǎng)絡(luò)請求就是不發(fā)請求。”

無論何時有人說到這句話，我都會心一笑。這的確是真理，HTTP Cache對網(wǎng)頁速度至關(guān)重要。

現(xiàn)在緩存的使用看似正漸入佳境，但還不夠。下面HTTP Archive的數(shù)據(jù)顯示在過去一年里(2011),  緩存的資源增加了10%，而同時頁面資源卻增加了12%，頁面數(shù)據(jù)量增加了24%(css" rel="external nofollow" style="color: rgb(202, 0, 0); text-decoration: none;" target="_blank">http://static.ak.fbcdn.net/rsrc.php/v1/yx/r/lP_Rtwh3P-S.css (8710 hours)

其中有些有趣的發(fā)現(xiàn).

• 簡單的URLs有著較短的緩存時間 – 一些資源時間特別短，它們常常是在粘貼到頁面中的一個片段。短的緩存時間有利于解決一些緊急的問題。
• 較長的URLs有著同樣較長的緩存時間 – 許多第三方bootstrap腳本會動態(tài)地加載其它資源，他們所生成的URLs一般都比較長，里面含有一些唯一標識符。如果出現(xiàn)了緊急問題，負責加載的腳本會被修改支加載不同URL的資源，這樣就不需要對應更新那些資源了。
• Facebook中點贊按鈕去哪了? – Facebook的like.php和likebox.php是經(jīng)常被使用的，但沒有出現(xiàn)在上面的列表里。原因是不同的頁面下會有一個唯一標識，從而降低了總體的占比。相比于那些負責加載的腳本，它們有著更為激進的過期策略，如no-cache, no-store, must-revalidate。
• 擁有較短緩存時間的資源通常是異步的 – 為那些bootstrap腳本指定較短的緩存時間有利于應對緊急狀況，但會因為發(fā)送條件更新(Conditional GET)請求而影響性能。幸運地是一些第三方資源開發(fā)者已經(jīng)意識到這個問題，并提供了異步的方式來加載這些腳本，以減少較短的緩存時間帶來的影響。

常用的第三方資源通常有不錯的表現(xiàn)，但當我們考察更多的資源時，就可以發(fā)現(xiàn)這里相當?shù)奶嵘臻g。

緩存容量不足 

根據(jù)2007年的一項實驗(experiment) 40%-60%的用戶沒有所瀏覽頁面的緩存，其中20%的瀏覽頁面沒有本地緩存。

缺少足夠緩存的原因很多，我認為其中最重要的原因是過小的緩存容量。下面是我在我自己的設(shè)備測試的數(shù)據(jù)(一些瀏覽器的緩存大小會基于可用磁盤空間計算，而我的磁盤是250GB,其中54GB可用。):

• Chrome:320MB
• Internet Explorer 9:250 MB
• Firefox 11: 830 MB (about:cache)
• Opera 11: 20 MB (Preferences | Advanced | History)
• iPhone 4, iOS 5.1: 30-35 MB (基于測試)
• Galaxy Nexus: 18 MB (基于測試)

除了Firefox 11比較接近我期望的大小，其它的都太小了。一部鋼鐵俠2也有1.82GB了，根本不夠用。(讓瀏覽器中緩存多媒體文件!!!!!)。

現(xiàn)實的緩存狀況 

為了提供讓瀏覽增加緩存容量的依據(jù)，必須要獲取真實用戶的統(tǒng)計數(shù)據(jù)。為此參與Velocity Summit的各家瀏覽器團隊一起完成了一項課題 。特別推薦Will Chan的提交的這篇Chromium cache metrics，里面列出了一些非常有價值的緩存數(shù)據(jù)。

主要數(shù)據(jù)有:

• 近30%用戶的緩存全滿(320 MB)
• 對于緩存滿的用戶，他們平均要花4小的瀏覽時間(約20小時)才會填滿緩存
• 7%的用戶至少一周清一次緩存
• 19%用戶會一周經(jīng)歷一次"緩存損壞"的錯誤，然后清掉他們的緩存

最后一項關(guān)于緩存損壞的統(tǒng)計非常有趣，我非常欣賞這樣的坦率。IE9團隊有著相似的數(shù)據(jù)(something similar). IE 7&8 將緩存容量限制在50MB, 因為基于測試當時發(fā)現(xiàn)超過50MB并沒有提升緩存命中率。而IE9中，他們終于知道更大的緩存容量的確可以改善緩存命中率:

In IE9, we took a much closer look at our cache behaviors to better understand our surprising finding that larger caches were rarely improving our hit rate. We found a number of functional problems related to what IE treats as cacheable and how the cache cleanup algorithm works. After fixing these issues, we found larger cache sizes were again resulting in better hit rates, and as a result, we’ve changed our default cache size algorithm to provide a larger default cache.

Will也認識到Chrome的320MB緩存限制需要更新。對于擁有全滿緩存的用戶而言，30%的比例有些偏低。不過用戶也許只對少量的頁面比較活躍，比如是只看看Gmail和Facebook。建議加一下針對活躍度的統(tǒng)計。很可能一個用戶常常瀏覽大量的網(wǎng)頁，雖然擁有滿滿的緩存，卻體驗著低效的頁面加載時間。

下一步 

瀏覽器開發(fā)者對于改進緩存責無旁貸。1)提升緩存容量就是改進之一，特別是對于移動設(shè)備。2)需要提供和緩存容量及用戶行為相關(guān)的數(shù)據(jù)。3)更加有效的淘汰算法(比如IE 9′s prioritization based on mime type )。 4)更加關(guān)注個性化，當用戶訪問常用頁面可以得到更快的體驗。

轉(zhuǎn)載請注明出處: http://blog.csdn.net/horkychen  

原文地址: Cache them if you can