可以看到,大部分瀏覽器的緩存比例是在68%和84%之間.移動平臺的數(shù)據(jù)差別還是挺大的,我們想可能都是比較低端的移動設(shè)備().除此以外數(shù)據(jù)跟桌面端還是比較相似的.

下面這個圖分別是移動端和手機端空緩存用戶所占的比例:

平均來看,有的用戶是空緩存的,這個也很符合Yahoo團(tuán)隊在2007年做的研究.

更進(jìn)一步:

到這里,文章還沒有完結(jié).在Facebook,我們迭代速度非常快,每天幾乎都會發(fā)布兩個版本.這個驅(qū)動我們?nèi)ニ伎?多長時間的緩存設(shè)置適合我們呢?我們將if-modified-since這個文件頭返回的時間減去當(dāng)前時間來尋找答案.

所以我們根據(jù)上面的方法,我們統(tǒng)計了從第一次正常請求到發(fā)生304請求的時間(這說明了用戶從沒有緩存到有緩存經(jīng)歷了多長時間),下面是數(shù)據(jù)生成的圖標(biāo):

橫軸是以小時為單位的時間值,垂直豎線P50和P75表示在某一時間內(nèi)緩存請求所占的比例,例如P50告訴我們在47小時的時候有50%的請求是有緩存的,同樣,p75意味著75%的請求將是有緩存的.

移動端的測試數(shù)據(jù)告訴我們大概在12小時的時候有50%的請求是有緩存的.

實際應(yīng)用:

總體來看我們的統(tǒng)計跟2007年是比較相似的,如果我們firefox瀏覽器(32和更高版本)不計入統(tǒng)計的話:這次有緩存的比例最高點是,高于2007年的80%.

另一方面,緩存的存在時間并不是太長.基于我們的研究,雖然在一個新版本發(fā)布的47小時之后有42%的請求將會帶有緩存,但是這個緩存資源在電腦上存在時間也大概是這個時間.這個新的發(fā)現(xiàn),對其他網(wǎng)站很有參考意義.

為什么緩存存在的時間不是太長?其實非常容易理解,從互聯(lián)網(wǎng)的發(fā)展來說,網(wǎng)站的體積從2007到現(xiàn)在發(fā)生了不小的變化.拿2007年年來說,那時候我們家里的網(wǎng)速大概是,Yahoo的首頁有.現(xiàn)在我的手機都有了8G下行,Yahoo首頁已經(jīng)變到768KB.現(xiàn)在市面上網(wǎng)頁的平均大小已經(jīng)超過1MB了,這將給我們的瀏覽器的良好運作帶來很大的壓力(譯者注:因為需要緩存的資源太多,超過瀏覽器設(shè)置的默認(rèn)資源緩存大小會自動刪掉早期的一些緩存文件,例如ie默認(rèn)的是50MB,而chrome的是320MB).

因此合理利用瀏覽器緩存比8年之前更加有意義.

最佳實踐告訴我們:盡量用外鏈樣式表和JS、讓headers設(shè)置Cache-Control and ETag,并盡可能的壓縮我們的數(shù)據(jù)、用不同的網(wǎng)址管理緩存、分割需要頻繁更新的資源.這些優(yōu)化方法不僅適用于像facebook這樣規(guī)模的項目,其他網(wǎng)站也可以應(yīng)用它們.雖然我們的更新頻率會對緩存的優(yōu)化帶來負(fù)面的影響,但是這個不是本次文章所研究的重點.事實上,我們已經(jīng)開始運用這次的研究成果來讓所有訪問facebook的用戶收益.