摘要:上圖顯示了桌面瀏覽器一周內的緩存命中率。和早期版本用當前方法測試的緩存命中率為,過版本及以上卻大大的下降。實際應用總的來看緩存命中率相比年有所提高。如果忽略及以上版本無法測試,這樣緩存命中率由年的左右提高到現在的。
[]()
Ryan Albrecht
caisijie 翻譯于2015/12/21
任何網站都會考慮性能,不管是當地的理發店或者有巨大知識庫的維基百科。這是一個無法被忽略的需求。因此緩存變得尤其重要 —— 一種讓網站變快的極佳途徑,通過保存部分數據,使得下次訪問時不用再次計算或者下載。
我們團隊最近在討論Facebook.com沒有被緩存的的部分網頁,問題就來了:Facebook每兩天發布一次代碼,緩存的效率有多高?我們是否發布代碼太頻繁導致瀏覽器的緩存沒有充分利用?為了找到答案,我們在Yahoo"s Performance Research blog?發現一篇研究關于瀏覽器緩存對網頁性能的影響的文章。
我們從中驚訝的發現一個悲觀的結論:有20%的頁面訪問沒有經過緩存。但是這份研究至今已超過8年,那時候瀏覽器還無法顯示如頂部截圖那樣的瀑布式流量圖,那時候IE7和jQuery才發布了幾個月。我想忘記這份研究吧,jQuery 1.0 —— 老掉牙了。為了得到更精確的結果,我們決定重新測試看看事情是否有所改觀。
重開課題在原來的研究中,Yahoo構造的一種帶特殊頭的圖片。這些頭會告訴瀏覽器如果同樣的圖片被請求兩次,不會進行正常的請求,而是根據圖片是否變動這個條件發送GET請求。這種GET請求會把最后修改時間的頭傳給服務器,如果請求時間和圖片最后修改時間間隔太小,則返回304沒有修改而是不是200成功。Yahoo最后查看服務器日志進行分析。
與之類似,我們構建了一個PHP終端來提供圖片以及向數據庫記錄請求。圖片附帶特殊的頭來控制瀏覽器的緩存和中間件的緩存,而且我們會在請求同時記錄所有頭的信息。而響應頭如下:
Cache-Control: no-cache, private, max-age=0 ETag: abcde Expires: Thu, 15 Apr 2014 20:00:00 GMT Pragma: private Last-Modified: $now // RFC1123 format
在IE7和IE8下,為了繞過一些已知問題,需要特殊修改:
Cache-Control: private, max-age=0 Pragma: no-cache
當瀏覽器請求圖片時,會沒有附帶或者附帶一到兩個額外頭部:
沒有額外頭部,因為瀏覽器并不認識這個圖片。我們返回Status: 200 Success 以及?image data ,然后瀏覽器會緩存這些內容。并生成Last-Modified?時間和?ETag值會已備下次使用。
if-none-match?和?if-modified-since?頭的一個或兩個,它說明瀏覽器之前獲取過圖片。服務器會返回Status: 304 Not Modified并且不包含圖片數據。我們還把Last-Modified頭設置為$header["if-modified-since"]而不是$now,這樣瀏覽器每次就能獲得相同的響應內容。
最后的問題就是什么時候和在哪里發送圖片請求。我們決定在Facebook搜索條旁邊包含一個img標簽,這樣Facebook每次重載的時候就會渲染。在一個整個頁面的重載中,內存資源會被卸載,然后瀏覽器根據緩存頭重新請求CSS,JavaScript和我們的圖片。所以這是測量緩存是否工作的最佳位置。
在準備好終端去記錄請求日志和讓img標簽去發送請求之后,我們馬上開始...
研究結果經過幾周的數據收集和填滿緩存,對比最后超過7天的數據。初次結果同樣出乎意料:25.5%的請求沒有命中緩存。我們把數據按接口分類,桌面和移動設備,但是結果相似:桌面版24.8%以及移動版的26.9%請求沒有命中緩存。這不是期望的結果,所以我們繼續深入調試。
把桌面數據按瀏覽器劃分后變得一目了然。
上圖顯示了桌面瀏覽器一周內的緩存命中率。使用Chrome和Opera顯然從瀏覽器緩存受益更多。你可能注意到Fireforx并沒有出現在表中,這是有原因的。Firefox v31和早期版本用當前方法測試的緩存命中率為80%,過v32版本及以上卻大大的下降。v32 版本說明解釋了緩存后臺會?記錄并重用最近的響應頭。如果重用響應,我們的終端就沒法收到請求并記錄日志。這樣測試會錯誤的認為Firefox表現糟糕。但實際上仍在命中本地緩存;只是無法統計信息。考慮到這點,我們把Firefox排除在測試結果之外。
讓我們看看移動端的情況
不同產品的緩存命中在68%和84%之間浮動,和之前的線差不多。移動端的變動性更多,因為許多不同 ?year class 的設備在訪問移動網頁,而且每一個瀏覽器版本都有一個可能的范圍。這些數字普遍比桌面版的低但是排序基本一致。
我們還可以看看不同用戶命中空緩存的比例
平均44.6%的用戶獲取了空緩存。這佐證了Yahoo在2007年關于每個用戶命中率的結果。
更進一步還沒有完呢。在Facebook,我們希望小步快走的每天兩次地發布包含當天完成的所有優秀功能。這就引出一個問題:瀏覽器緩存生命周期是多少?我們可以通過把請求頭if-modified-since的值減去當前時間值,這樣就可以得到這個用戶命中緩存的存活時間。
所以我們發掘數據。仍然是最近一周的數據,我們生成描述緩存持續命中(請求返回304)時間分布的柱狀圖。換一種說法,每次重新獲取圖片的間隔有多長。
橫軸 duration 單位是小時,豎線 p50_(百分之50), _mean_(平均)和 _p75(百分之75)分別表示對應請求比例的緩存時間。比如,_p50 表示50%的請求在命中最多47小時之前生成的緩存,類似的 p75 表明25%的請求的緩存存在的時間至少有260個小時。在移動端做同樣的分析顯示有50%的請求的緩存不會超過12個小時。
實際應用總的來看緩存命中率相比2007年有所提高。如果忽略Firefox v32及以上版本(無法測試),這樣緩存命中率由2007年的80%左右提高到現在的84.1%。另一方面,緩存保持活躍的時間并不是很長。根據我們的研究,在桌面版,有42%概率任何請求的緩存的存在時間不超過47小時。這是一個新的維度,而且在某些網站影響突出。
很容易解釋為什么緩存存在時間通常很短。看看因特網如何傳輸和網頁大小size從2007年至今的變化。在2007年,家庭有線帶寬是2.5Mbps,Yahoo主頁168.1KB。如今,我有8Mbps的LTE移動下載帶寬,Yahoo主頁是768KB。現在網頁平均大小是1MB,對瀏覽器優化造成了更大的壓力。
因此利用好瀏覽器緩存仍然重要,如果用好帶來的收益也會比8年前更大。我們的最佳實踐是使用外部樣式和腳本,包含Cache-Control和Etag頭,傳輸層數據壓縮,使用URL使緩存資源失效,把平凡更新的資源和穩定資源分開。所有這些技術都能在任何網站協同工作,而不單單是Facebook。我們一開始擔心自己的發布流程會給緩存性能帶來負面影響,但結果并不是這樣。實際上,我們使用這份數據專注于改進讓所有人訪問www.facebook.com都能通過緩存。真是有意思的一次緩存挖掘之旅。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/61762.html
摘要:上圖顯示了桌面瀏覽器一周內的緩存命中率。和早期版本用當前方法測試的緩存命中率為,過版本及以上卻大大的下降。實際應用總的來看緩存命中率相比年有所提高。如果忽略及以上版本無法測試,這樣緩存命中率由年的左右提高到現在的。 [showImg(https://segmentfault.com/img/remote/1460000006788057);]() showImg(https://seg...
摘要:雖然有著各種各樣的不同,但是相同的是,他們前端優化不完全指南前端掘金篇幅可能有點長,我想先聊一聊閱讀的方式,我希望你閱讀的時候,能夠把我當作你的競爭對手,你的夢想是超越我。 如何提升頁面渲染效率 - 前端 - 掘金Web頁面的性能 我們每天都會瀏覽很多的Web頁面,使用很多基于Web的應用。這些站點看起來既不一樣,用途也都各有不同,有在線視頻,Social Media,新聞,郵件客戶端...
摘要:本文簡單介紹是什么,為什么用,怎么用。技術棧是什么是一個開發平臺,用于生成,開發,部署和。實現需定制化源碼。 本文簡單介紹Jhipster是什么,為什么用Jhipster,怎么用Jhipster。 WHAT - 技術棧 JHipster是什么 JHipster是一個開發平臺,用于生成,開發,部署Spring Boot + Angular/React Web Application和Sp...
摘要:嵌套對象成員會造成重大性能影響盡量少用。一般來說你可以通過這種方法提高代碼的性能將經常使用的對象成員數組項和域外變量存入局部變量中。在反復訪問的地方使用局部變量存放引用小心地處理集合因為他們表現出存在性總是對底層文檔重新查詢。 前言 本期我來給大家推薦的書是《高性能JavaScript》,在這本書中我們能夠了解 javascript 開發過程中的性能瓶頸,如何提升各方面的性能,包括代碼...
閱讀 3176·2021-11-23 09:51
閱讀 688·2021-10-14 09:43
閱讀 3212·2021-09-06 15:00
閱讀 2411·2019-08-30 15:54
閱讀 2565·2019-08-30 13:58
閱讀 1853·2019-08-29 13:18
閱讀 1384·2019-08-27 10:58
閱讀 518·2019-08-27 10:53