Facebook團(tuán)隊(duì)關(guān)于網(wǎng)頁緩存的再實(shí)踐

譯者前言：

在8年之前，Yahoo團(tuán)隊(duì)曾經(jīng)對(duì)網(wǎng)頁中的緩存做了比較詳盡的研究，但是隨著互聯(lián)網(wǎng)的高速發(fā)展，研究數(shù)據(jù)發(fā)生了一些變化。這篇文章主要是Facebook的web團(tuán)隊(duì)對(duì)現(xiàn)在緩存情況一些數(shù)據(jù)收集和研究。包括PC和移動(dòng)端資源被緩存的時(shí)間以及資源在存在的時(shí)間。網(wǎng)頁緩存是性能優(yōu)化很重要的因素，值得一讀。

能力有限，如有翻譯錯(cuò)誤的地方，歡迎隨時(shí)找我交流，我會(huì)及時(shí)更正:)

正文：

網(wǎng)頁加載速度是每個(gè)網(wǎng)站都應(yīng)該重視的因素。但是往往被大家忽略。緩存是一個(gè)提升網(wǎng)站訪問速度非常重要的因素(因?yàn)橛脩粼谙麓卧L問的時(shí)候不需要重新計(jì)算或者下載已經(jīng)緩存的資源)

我們團(tuán)隊(duì)(facebook web團(tuán)隊(duì))最近針對(duì)目前facebook.com沒有緩存的現(xiàn)狀進(jìn)行了一番討論，主要問題是：在facebook,.我們每天都會(huì)發(fā)布兩個(gè)版本，怎么樣才能令緩存更有效率?怎么樣的緩存策略才適合我們?

在找解決方案的時(shí)候， 我們發(fā)現(xiàn)雅虎性能優(yōu)化研究博客上已經(jīng)有了一篇關(guān)于性能研究的文章。

但是令我們非常吃驚的是：20%的頁面訪問是在空緩存的情況下進(jìn)行的。但是這個(gè)研究結(jié)果距離現(xiàn)在有8年了，那個(gè)時(shí)代剛發(fā)布IE7，jquery也剛發(fā)布第一個(gè)版本，所以我們決定重新研究一下，看現(xiàn)在是不是有所改善。

重新研究：

在之前的研究當(dāng)中，Yahoo在服務(wù)器創(chuàng)建了HTTP頭設(shè)置了圖片的過期時(shí)間和上次修改時(shí)間，如果圖片沒有發(fā)生改變，就用GET請(qǐng)求發(fā)送給服務(wù)器一個(gè)最后修改時(shí)間的信息，如果圖片沒有修改，就返回304(沒有修改)來替換200(請(qǐng)求成功)。因?yàn)榉?wù)器可以記錄瀏覽器請(qǐng)求的請(qǐng)求狀態(tài)，所以Yahoo用服務(wù)器日志來統(tǒng)計(jì)緩存的用戶數(shù)。

像那樣的研究方法一樣，我們創(chuàng)建了一個(gè)既能發(fā)送圖片請(qǐng)求也能在數(shù)據(jù)庫當(dāng)中記錄日志的PHP終點(diǎn)。這張圖片用http頭信息來控制瀏覽器的緩存和其他通過代理產(chǎn)生的緩存。之后在用戶請(qǐng)求圖片的時(shí)候記錄這些信息。

這個(gè)圖片HTTP頭信息的設(shè)置是這樣的：

但是因?yàn)橐恍┮阎腂UG，我們在IE7和IE8中把兩個(gè)屬性替換成了下面這樣：

當(dāng)瀏覽器發(fā)送請(qǐng)求給圖片時(shí)候，將會(huì)發(fā)生兩件事情：

1.因?yàn)闉g覽器從來沒有打開過這張圖片，所以沒有額外的頭信息，服務(wù)器將返回一個(gè)狀態(tài)碼：200 Success 接著返回圖片數(shù)據(jù)給瀏覽器，之后瀏覽器會(huì)緩存文件的HTTP頭信息當(dāng)中的Last-Modified(文件最后修改時(shí)間)和ETag(被請(qǐng)求變量的實(shí)體值)

2.瀏覽器檢查if-none-match或者if-modified-since頭信息，如果之前有打開過。將會(huì)不加載圖片數(shù)據(jù)直接返回Status:304 Not Modified(沒有更新)。同時(shí)我們把Last-Moidified頭信息用$header['if-modified-since']替換掉$now()，所以每次返回的內(nèi)容都將是一樣的。

現(xiàn)在剩下問題是我們在哪里應(yīng)用這張圖片，最后我們決定在Facebook的搜索條下面包含一個(gè)img標(biāo)簽，這樣每次facebook加載的時(shí)候都會(huì)渲染這張圖片。在整個(gè)頁面重新加載的時(shí)候，資源將會(huì)根據(jù)緩存的頭信息進(jìn)行加載。這將是最好的方式來測試我們的想法。

在確保endpoint可以正常記錄請(qǐng)求、圖片標(biāo)簽可以正常訪問了之后，我們正式開始了這次研究!

研究結(jié)果：

在數(shù)周的數(shù)據(jù)收集之后，我們決定來研究一下7天最后比較有價(jià)值的數(shù)據(jù)。數(shù)據(jù)的統(tǒng)計(jì)結(jié)果依舊讓我們感到吃驚：依舊有25.5%的請(qǐng)求是空緩存的。為了讓數(shù)據(jù)看起來更清晰，我們分隔了PC和手機(jī)的統(tǒng)計(jì)數(shù)據(jù)，但是數(shù)據(jù)依舊差不多:PC有24.8%而手機(jī)端有26.9%是空緩存的。這個(gè)結(jié)果不太符合我們預(yù)期，所以我們更加深入的研究了這個(gè)數(shù)據(jù)。

把PC端的瀏覽器分開來統(tǒng)計(jì)可能更加清楚：

根據(jù)上面一周的數(shù)據(jù)來看：用戶用chrome和opera緩存的幾率更大。你可能注意到你這個(gè)圖表中并沒有firefox瀏覽器的數(shù)據(jù)，那是因?yàn)閒irefox 31版本以及更早期的版本在我們的統(tǒng)計(jì)中有80%的緩存概率，但是在32版本和更高的版本當(dāng)中有很明顯的下降。那是因?yàn)閒irefox的緩存策略和我們的統(tǒng)計(jì)方法有點(diǎn)沖突(http://www.janbambas.cz/new-firefox-http-cache-enabled/)，

所以我們就干脆去掉了firefox瀏覽器的數(shù)據(jù)統(tǒng)計(jì)。

好了，現(xiàn)在讓我們來看看移動(dòng)端的數(shù)據(jù)：

可以看到，大部分瀏覽器的緩存比例是在68%和84%之間。移動(dòng)平臺(tái)的數(shù)據(jù)差別還是挺大的，我們想可能都是比較低端的移動(dòng)設(shè)備(https://code.facebook.com/posts/307478339448736/year-class-a-classification-system-for-android/)。除此以外數(shù)據(jù)跟桌面端還是比較相似的。

下面這個(gè)圖分別是移動(dòng)端和手機(jī)端空緩存用戶所占的比例：

平均來看，有44.6%的用戶是空緩存的，這個(gè)也很符合Yahoo團(tuán)隊(duì)在2007年做的研究。

更進(jìn)一步：

到這里，文章還沒有完結(jié)。在Facebook，我們迭代速度非?？欤刻鞄缀醵紩?huì)發(fā)布兩個(gè)版本。這個(gè)驅(qū)動(dòng)我們?nèi)ニ伎?，多長時(shí)間的緩存設(shè)置適合我們呢?我們將if-modified-since這個(gè)文件頭返回的時(shí)間減去當(dāng)前時(shí)間來尋找答案。

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

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

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

實(shí)際應(yīng)用：

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

另一方面，緩存的存在時(shí)間并不是太長?；谖覀兊难芯浚m然在一個(gè)新版本發(fā)布的47小時(shí)之后有42%的請(qǐng)求將會(huì)帶有緩存，但是這個(gè)緩存資源在電腦上存在時(shí)間也大概是這個(gè)時(shí)間。這個(gè)新的發(fā)現(xiàn)，對(duì)其他網(wǎng)站很有參考意義。

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

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

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

原文：https://code.facebook.com/posts/964122680272229/web-performance-cache-efficiency-exercise/

翻譯：TGideas - Allan