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

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

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

1.因?yàn)闉g覽器從來(lái)沒(méi)有打開(kāi)過(guò)這張圖片,所以沒(méi)有額外的頭信息,服務(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頭信息,如果之前有打開(kāi)過(guò).將會(huì)不加載圖片數(shù)據(jù)直接返回Status:304 Not Modified(沒(méi)有更新).同時(shí)我們把Last-Moidified頭信息用$header["if-modified-since"]替換掉$now(),所以每次返回的內(nèi)容都將是一樣的.

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

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

研究結(jié)果:

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

把PC端的瀏覽器分開(kāi)來(lái)統(tǒng)計(jì)可能更加清楚:

根據(jù)上面一周的數(shù)據(jù)來(lái)看:用戶用chrome和opera緩存的幾率更大.你可能注意到你這個(gè)圖表中并沒(méi)有firefox瀏覽器的數(shù)據(jù),那是因?yàn)閒irefox 31版本以及更早期的版本在我們的統(tǒng)計(jì)中有80%的緩存概率,但是在32版本和更高的版本當(dāng)中有很明顯的下降.那是因?yàn)閒irefox的緩存策略和我們的統(tǒng)計(jì)方法有點(diǎn)沖突(),所以我們就干脆去掉了firefox瀏覽器的數(shù)據(jù)統(tǒng)計(jì).