国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

網(wǎng)頁性能： 緩存效率實踐

Ashin / 2231人閱讀

摘要：上圖顯示了桌面瀏覽器一周內(nèi)的緩存命中率。和早期版本用當(dāng)前方法測試的緩存命中率為，過版本及以上卻大大的下降。實際應(yīng)用總的來看緩存命中率相比年有所提高。如果忽略及以上版本無法測試，這樣緩存命中率由年的左右提高到現(xiàn)在的。

[]()

Ryan Albrecht
caisijie 翻譯于2015/12/21

任何網(wǎng)站都會考慮性能，不管是當(dāng)?shù)氐睦戆l(fā)店或者有巨大知識庫的維基百科。這是一個無法被忽略的需求。因此緩存變得尤其重要 —— 一種讓網(wǎng)站變快的極佳途徑，通過保存部分?jǐn)?shù)據(jù)，使得下次訪問時不用再次計算或者下載。

我們團(tuán)隊最近在討論Facebook.com沒有被緩存的的部分網(wǎng)頁，問題就來了：Facebook每兩天發(fā)布一次代碼，緩存的效率有多高？我們是否發(fā)布代碼太頻繁導(dǎo)致瀏覽器的緩存沒有充分利用？為了找到答案，我們在Yahoo"s Performance Research blog?發(fā)現(xiàn)一篇研究關(guān)于瀏覽器緩存對網(wǎng)頁性能的影響的文章。

我們從中驚訝的發(fā)現(xiàn)一個悲觀的結(jié)論：有20%的頁面訪問沒有經(jīng)過緩存。但是這份研究至今已超過8年，那時候瀏覽器還無法顯示如頂部截圖那樣的瀑布式流量圖，那時候IE7和jQuery才發(fā)布了幾個月。我想忘記這份研究吧，jQuery 1.0 —— 老掉牙了。為了得到更精確的結(jié)果，我們決定重新測試看看事情是否有所改觀。

重開課題

在原來的研究中，Yahoo構(gòu)造的一種帶特殊頭的圖片。這些頭會告訴瀏覽器如果同樣的圖片被請求兩次，不會進(jìn)行正常的請求，而是根據(jù)圖片是否變動這個條件發(fā)送GET請求。這種GET請求會把最后修改時間的頭傳給服務(wù)器，如果請求時間和圖片最后修改時間間隔太小，則返回304沒有修改而是不是200成功。Yahoo最后查看服務(wù)器日志進(jìn)行分析。

與之類似，我們構(gòu)建了一個PHP終端來提供圖片以及向數(shù)據(jù)庫記錄請求。圖片附帶特殊的頭來控制瀏覽器的緩存和中間件的緩存，而且我們會在請求同時記錄所有頭的信息。而響應(yīng)頭如下：

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

當(dāng)瀏覽器請求圖片時，會沒有附帶或者附帶一到兩個額外頭部：

沒有額外頭部，因為瀏覽器并不認(rèn)識這個圖片。我們返回Status: 200 Success 以及?image data ，然后瀏覽器會緩存這些內(nèi)容。并生成Last-Modified?時間和?ETag值會已備下次使用。

if-none-match?和?if-modified-since?頭的一個或兩個，它說明瀏覽器之前獲取過圖片。服務(wù)器會返回Status: 304 Not Modified并且不包含圖片數(shù)據(jù)。我們還把Last-Modified頭設(shè)置為$header["if-modified-since"]而不是$now，這樣瀏覽器每次就能獲得相同的響應(yīng)內(nèi)容。

最后的問題就是什么時候和在哪里發(fā)送圖片請求。我們決定在Facebook搜索條旁邊包含一個img標(biāo)簽，這樣Facebook每次重載的時候就會渲染。在一個整個頁面的重載中，內(nèi)存資源會被卸載，然后瀏覽器根據(jù)緩存頭重新請求CSS，JavaScript和我們的圖片。所以這是測量緩存是否工作的最佳位置。

在準(zhǔn)備好終端去記錄請求日志和讓img標(biāo)簽去發(fā)送請求之后，我們馬上開始...

研究結(jié)果

經(jīng)過幾周的數(shù)據(jù)收集和填滿緩存，對比最后超過7天的數(shù)據(jù)。初次結(jié)果同樣出乎意料：25.5%的請求沒有命中緩存。我們把數(shù)據(jù)按接口分類，桌面和移動設(shè)備，但是結(jié)果相似：桌面版24.8%以及移動版的26.9%請求沒有命中緩存。這不是期望的結(jié)果，所以我們繼續(xù)深入調(diào)試。

把桌面數(shù)據(jù)按瀏覽器劃分后變得一目了然。

上圖顯示了桌面瀏覽器一周內(nèi)的緩存命中率。使用Chrome和Opera顯然從瀏覽器緩存受益更多。你可能注意到Fireforx并沒有出現(xiàn)在表中，這是有原因的。Firefox v31和早期版本用當(dāng)前方法測試的緩存命中率為80%，過v32版本及以上卻大大的下降。v32 版本說明解釋了緩存后臺會?記錄并重用最近的響應(yīng)頭。如果重用響應(yīng)，我們的終端就沒法收到請求并記錄日志。這樣測試會錯誤的認(rèn)為Firefox表現(xiàn)糟糕。但實際上仍在命中本地緩存;只是無法統(tǒng)計信息。考慮到這點，我們把Firefox排除在測試結(jié)果之外。

讓我們看看移動端的情況

不同產(chǎn)品的緩存命中在68%和84%之間浮動，和之前的線差不多。移動端的變動性更多，因為許多不同 ?year class 的設(shè)備在訪問移動網(wǎng)頁，而且每一個瀏覽器版本都有一個可能的范圍。這些數(shù)字普遍比桌面版的低但是排序基本一致。

我們還可以看看不同用戶命中空緩存的比例

平均44.6%的用戶獲取了空緩存。這佐證了Yahoo在2007年關(guān)于每個用戶命中率的結(jié)果。

更進(jìn)一步

還沒有完呢。在Facebook，我們希望小步快走的每天兩次地發(fā)布包含當(dāng)天完成的所有優(yōu)秀功能。這就引出一個問題：瀏覽器緩存生命周期是多少？我們可以通過把請求頭if-modified-since的值減去當(dāng)前時間值，這樣就可以得到這個用戶命中緩存的存活時間。

所以我們發(fā)掘數(shù)據(jù)。仍然是最近一周的數(shù)據(jù)，我們生成描述緩存持續(xù)命中（請求返回304）時間分布的柱狀圖。換一種說法，每次重新獲取圖片的間隔有多長。

橫軸 duration 單位是小時，豎線 p50_（百分之50）, _mean_（平均）和 _p75（百分之75）分別表示對應(yīng)請求比例的緩存時間。比如，_p50 表示50%的請求在命中最多47小時之前生成的緩存，類似的 p75 表明25%的請求的緩存存在的時間至少有260個小時。在移動端做同樣的分析顯示有50%的請求的緩存不會超過12個小時。

實際應(yīng)用

總的來看緩存命中率相比2007年有所提高。如果忽略Firefox v32及以上版本（無法測試），這樣緩存命中率由2007年的80%左右提高到現(xiàn)在的84.1%。另一方面，緩存保持活躍的時間并不是很長。根據(jù)我們的研究，在桌面版，有42%概率任何請求的緩存的存在時間不超過47小時。這是一個新的維度，而且在某些網(wǎng)站影響突出。

很容易解釋為什么緩存存在時間通常很短。看看因特網(wǎng)如何傳輸和網(wǎng)頁大小size從2007年至今的變化。在2007年，家庭有線帶寬是2.5Mbps，Yahoo主頁168.1KB。如今，我有8Mbps的LTE移動下載帶寬，Yahoo主頁是768KB。現(xiàn)在網(wǎng)頁平均大小是1MB，對瀏覽器優(yōu)化造成了更大的壓力。

因此利用好瀏覽器緩存仍然重要，如果用好帶來的收益也會比8年前更大。我們的最佳實踐是使用外部樣式和腳本，包含Cache-Control和Etag頭，傳輸層數(shù)據(jù)壓縮，使用URL使緩存資源失效，把平凡更新的資源和穩(wěn)定資源分開。所有這些技術(shù)都能在任何網(wǎng)站協(xié)同工作，而不單單是Facebook。我們一開始擔(dān)心自己的發(fā)布流程會給緩存性能帶來負(fù)面影響，但結(jié)果并不是這樣。實際上，我們使用這份數(shù)據(jù)專注于改進(jìn)讓所有人訪問www.facebook.com都能通過緩存。真是有意思的一次緩存挖掘之旅。

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/61762.html

相關(guān)文章

  • 網(wǎng)頁性能： 緩存效率實踐

    摘要：上圖顯示了桌面瀏覽器一周內(nèi)的緩存命中率。和早期版本用當(dāng)前方法測試的緩存命中率為，過版本及以上卻大大的下降。實際應(yīng)用總的來看緩存命中率相比年有所提高。如果忽略及以上版本無法測試，這樣緩存命中率由年的左右提高到現(xiàn)在的。 [showImg(https://segmentfault.com/img/remote/1460000006788057);]() showImg(https://seg...

    anRui 評論0 收藏0

  • 前端性能優(yōu)化

    摘要：端優(yōu)談?wù)勱P(guān)于前端的緩存的問題我們都知道對頁面進(jìn)行緩存能夠有利于減少請求發(fā)送，從而達(dá)到對頁面的優(yōu)化。而作為一名有追求的前端，勢必要力所能及地優(yōu)化我們前端頁面的性能。這種方式主要解決了淺談前端中的過早優(yōu)化問題過早優(yōu)化是萬惡之源。 優(yōu)化向：單頁應(yīng)用多路由預(yù)渲染指南 Ajax 技術(shù)的出現(xiàn)，讓我們的 Web 應(yīng)用能夠在不刷新的狀態(tài)下顯示不同頁面的內(nèi)容，這就是單頁應(yīng)用。在一個單頁應(yīng)用中，往往只有一...

    Dean 評論0 收藏0

  • 前端優(yōu)化 - 收藏集 - 掘金

    摘要：雖然有著各種各樣的不同，但是相同的是，他們前端優(yōu)化不完全指南前端掘金篇幅可能有點長，我想先聊一聊閱讀的方式，我希望你閱讀的時候，能夠把我當(dāng)作你的競爭對手，你的夢想是超越我。 如何提升頁面渲染效率 - 前端 - 掘金Web頁面的性能 我們每天都會瀏覽很多的Web頁面，使用很多基于Web的應(yīng)用。這些站點看起來既不一樣，用途也都各有不同，有在線視頻，Social Media，新聞，郵件客戶端...

    VincentFF 評論0 收藏0

  • JHipster技術(shù)簡介

    摘要：本文簡單介紹是什么，為什么用，怎么用。技術(shù)棧是什么是一個開發(fā)平臺，用于生成，開發(fā)，部署和。實現(xiàn)需定制化源碼。 本文簡單介紹Jhipster是什么，為什么用Jhipster，怎么用Jhipster。 WHAT - 技術(shù)棧 JHipster是什么 JHipster是一個開發(fā)平臺，用于生成，開發(fā)，部署Spring Boot + Angular/React Web Application和Sp...

    hightopo 評論0 收藏0

  • 精讀《高性能 javascript》

    摘要：嵌套對象成員會造成重大性能影響盡量少用。一般來說你可以通過這種方法提高代碼的性能將經(jīng)常使用的對象成員數(shù)組項和域外變量存入局部變量中。在反復(fù)訪問的地方使用局部變量存放引用小心地處理集合因為他們表現(xiàn)出存在性總是對底層文檔重新查詢。 前言 本期我來給大家推薦的書是《高性能JavaScript》,在這本書中我們能夠了解 javascript 開發(fā)過程中的性能瓶頸,如何提升各方面的性能，包括代碼...

    caohaoyu 評論0 收藏0

發(fā)表評論

0條評論

Ashin

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<