可以看到,大部分瀏覽器的緩存比例是在68%和84%之間.移動平臺的數據差別還是挺大的,我們想可能都是比較低端的移動設備().除此以外數據跟桌面端還是比較相似的.
下面這個圖分別是移動端和手機端空緩存用戶所占的比例:
平均來看,有的用戶是空緩存的,這個也很符合Yahoo團隊在2007年做的研究.
更進一步:
到這里,文章還沒有完結.在Facebook,我們迭代速度非常快,每天幾乎都會發布兩個版本.這個驅動我們去思考,多長時間的緩存設置適合我們呢?我們將if-modified-since這個文件頭返回的時間減去當前時間來尋找答案.
所以我們根據上面的方法,我們統計了從第一次正常請求到發生304請求的時間(這說明了用戶從沒有緩存到有緩存經歷了多長時間),下面是數據生成的圖標:
橫軸是以小時為單位的時間值,垂直豎線P50和P75表示在某一時間內緩存請求所占的比例,例如P50告訴我們在47小時的時候有50%的請求是有緩存的,同樣,p75意味著75%的請求將是有緩存的.
移動端的測試數據告訴我們大概在12小時的時候有50%的請求是有緩存的.
實際應用:
總體來看我們的統計跟2007年是比較相似的,如果我們firefox瀏覽器(32和更高版本)不計入統計的話:這次有緩存的比例最高點是,高于2007年的80%.
另一方面,緩存的存在時間并不是太長.基于我們的研究,雖然在一個新版本發布的47小時之后有42%的請求將會帶有緩存,但是這個緩存資源在電腦上存在時間也大概是這個時間.這個新的發現,對其他網站很有參考意義.
為什么緩存存在的時間不是太長?其實非常容易理解,從互聯網的發展來說,網站的體積從2007到現在發生了不小的變化.拿2007年年來說,那時候我們家里的網速大概是,Yahoo的首頁有.現在我的手機都有了8G下行,Yahoo首頁已經變到768KB.現在市面上網頁的平均大小已經超過1MB了,這將給我們的瀏覽器的良好運作帶來很大的壓力(譯者注:因為需要緩存的資源太多,超過瀏覽器設置的默認資源緩存大小會自動刪掉早期的一些緩存文件,例如ie默認的是50MB,而chrome的是320MB).
因此合理利用瀏覽器緩存比8年之前更加有意義.
最佳實踐告訴我們:盡量用外鏈樣式表和JS、讓headers設置Cache-Control and ETag,并盡可能的壓縮我們的數據、用不同的網址管理緩存、分割需要頻繁更新的資源.這些優化方法不僅適用于像facebook這樣規模的項目,其他網站也可以應用它們.雖然我們的更新頻率會對緩存的優化帶來負面的影響,但是這個不是本次文章所研究的重點.事實上,我們已經開始運用這次的研究成果來讓所有訪問facebook的用戶收益.
評論(0人參與,0條評論)
發布評論
最新評論