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

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

現(xiàn)在緩存的使用看似正漸入佳境，但還不夠。下面HTTP Archive的數(shù)據(jù)顯示在過去一年里(2011),  緩存的資源增加了10%，而同時(shí)頁(yè)面資源卻增加了12%，頁(yè)面數(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).

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

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

緩存容量不足 

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

缺少足夠緩存的原因很多，我認(rèn)為其中最重要的原因是過小的緩存容量。下面是我在我自己的設(shè)備測(cè)試的數(shù)據(jù)(一些瀏覽器的緩存大小會(huì)基于可用磁盤空間計(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 (基于測(cè)試)
• Galaxy Nexus: 18 MB (基于測(cè)試)

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

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

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

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

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

最后一項(xiàng)關(guān)于緩存損壞的統(tǒng)計(jì)非常有趣，我非常欣賞這樣的坦率。IE9團(tuán)隊(duì)有著相似的數(shù)據(jù)(something similar). IE 7&8 將緩存容量限制在50MB, 因?yàn)榛跍y(cè)試當(dāng)時(shí)發(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也認(rèn)識(shí)到Chrome的320MB緩存限制需要更新。對(duì)于擁有全滿緩存的用戶而言，30%的比例有些偏低。不過用戶也許只對(duì)少量的頁(yè)面比較活躍，比如是只看看Gmail和Facebook。建議加一下針對(duì)活躍度的統(tǒng)計(jì)。很可能一個(gè)用戶常常瀏覽大量的網(wǎng)頁(yè)，雖然擁有滿滿的緩存，卻體驗(yàn)著低效的頁(yè)面加載時(shí)間。

下一步 

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

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

原文地址: Cache them if you can