摘要:前端靜態(tài)資源緩存最優(yōu)解以及的陷阱合理的使用緩存可以極大地提高網(wǎng)站的性能優(yōu)勢,還可以節(jié)約帶寬從而降低服務器成本。此處注意和與第一天請求的版本號不同。既支持版本號類型的靜態(tài)資源緩存方式也支持服務器重新認證的方式。
前端靜態(tài)資源緩存最優(yōu)解以及max-age的陷阱
合理的使用緩存可以極大地提高網(wǎng)站的性能優(yōu)勢,還可以節(jié)約帶寬從而降低服務器成本。但是很多站點有只弄對了一半或者一半都沒有,如果是這樣,就完全沒有發(fā)揮出緩存的優(yōu)勢。很大程度上產(chǎn)生會由于靜態(tài)資源的競爭關(guān)系而導致依賴的靜態(tài)資源不同步。
以下為兩個最佳靜態(tài)資源緩存實踐的例子。
一、資源內(nèi)容不變 + 設(shè)置長時間max-age// 設(shè)置緩存時間為1年 Cache-Control: max-age=31536000
資源的內(nèi)容不會更改,所以。。。
瀏覽器/CDN可以緩存一年時間,在這期間資源不會出現(xiàn)問題。
可以在不請求服務器的請情況下,一年內(nèi)都使用緩存內(nèi)容。
第一天瀏覽器請求了/index-v1.js、/base-v1.css以及/dog-v1.png這三個資源。
第二天這次瀏覽器請求了/index-v2.js、/base-v2.css以及/dog-v1.png這三個資源。
此處注意:index.js和base.css與第一天請求的版本號不同。過了一年
在一年的時間里,瀏覽器再也沒有請求過/index-v1.js、/base-v1.css以及/dog-v1.png這三個資源,瀏覽器緩存就會把它們給刪掉。
所以在這個例子中,為了讓緩存發(fā)揮最大效率,你要做的并不是更改文件的內(nèi)容,而是應該更改資源的URL:
每一個靜態(tài)資源URL都應該跟隨其內(nèi)容的修改而改變。例如示例index-v1.js中的v1,你對它的命名不需要有任何限制。它可以是一個版本號,最后修改的日期,或者根據(jù)內(nèi)容計算出來的散列值。
絕大多數(shù)服務器端的框架都提供了工具來實現(xiàn)這一點,同樣的在nodejs中有很多優(yōu)秀的庫來實現(xiàn)這個功能,比如gulp-rev、webpack、fis3。
Cache-Control: no-cache
該URL下資源的內(nèi)容可能經(jīng)常修改,所以。。。
沒有服務器的確認,任何本地緩存的版本內(nèi)容都是不可信的。
第一天 第二天注意:
no-cache并不意味著不緩存。它的意思是在使用緩存資源之前,它必須經(jīng)過服務器的檢查(revalidate也可以實現(xiàn)這個功能)。
no-store才是告訴瀏覽器不要緩存它。此外,must-revalidate并不意味著必須重新認證,它的前提是資源還在max-age的緩存期內(nèi),否則必須重新認證。
在此模式下 ,你也可以將ETag(你選擇的版本ID)或者Last-modified日期添加到響應首部中。客戶端下次獲取資源時,他會分別通過If-None-Match(與ETage對應)和If-Modified-Since(與Last-Mofied對應)兩個請求首部將值發(fā)送給服務器。如果服務器發(fā)現(xiàn)兩次值都是對等的,就是返回一個HTTP 304。
如果沒有發(fā)送ETag和Last-Modified,那么服務器將始終返回完整的資源內(nèi)容。
但是這種方法有個缺點,就是它每次都會去服務器做一次驗證,涉及到了網(wǎng)絡(luò)提取,所以它不如第一個例子那樣可以完全繞過網(wǎng)絡(luò)。
這種情況并不少見,例如它就實實在在地發(fā)生在了github的頁面上。
想象一下 :
/article/
/styles.css
/script.js
它們?nèi)渴褂玫氖牵?/p>
// 十分鐘內(nèi)不需要重新認證,超過十分鐘就需要重新認證 Cache-Control: must-revalidate, max-age=600
隨著內(nèi)容的修改,URLs發(fā)生改變
在十分鐘內(nèi),瀏覽器將會一直使用緩存住的內(nèi)容,而不會去服務器請求最新的資源 。
超過十分鐘,在可用的前提下使用If-Modified-Since和If-None-Match重新進行服務器認證。
第一次請求:
六七分鐘過后:
最終:
這種情況在測試中經(jīng)常出現(xiàn)。但是想象一下,在線上環(huán)境你永遠不知道瀏覽器前面坐著的是什么樣的人,他很有可能無意中胡亂地用鼠標點點點,就打亂了瀏覽器的靜態(tài)資源緩存機制,導致頁面發(fā)生了錯亂,而且真的很難追蹤。
在上面的例子中,服務器實際上已經(jīng)更新了HTML、CSS和JS,但是頁面最后使用的是緩存中舊的HTML和JS,以及剛從服務器下載的最新的CSS。多個靜態(tài)資源版本之間不匹配的問題隨之出現(xiàn)。
通常,當我們對HTML進行重大修改時,我們可能會更改CSS文件來適配新的DOM結(jié)構(gòu),并且更新JS來配置樣式和DOM的修改。這些資源都是相互依賴的,但攜帶緩存信息的HTTP首部可不管你這些有的沒的。最終,用戶很有可能會得到一個/兩個靜態(tài)資源新版本,而其他資源都是舊版本。
max-age是相對于服務器響應時間的,所以如果所有上述資源都在同一時間請求,即便它們都被設(shè)置為了相同的max-age時長,它們?nèi)匀淮嬖诤苄〉母偁幙赡苄裕ó吘褂械馁Y源先返回有的資源后返回)。如果你的某些頁面不包含JS,或者包含不同的CSS,它們的緩存失效時間就有可能會不同步。更惡心的是,瀏覽器始終會從緩存中刪除和獲取資源,它并不知道這些資源中哪個是相互依賴的,只要過了緩存時間它就會毫不猶豫地刪掉一個,并不會刪掉這個過期文件所依賴的其他資源。把上面的種種可能性加在一起,就會大概率出現(xiàn)靜態(tài)資源版本不匹配的問題。
不過還好,我們還有法子來解決這個問題:
強制刷新瀏覽器或者清除緩存在強制刷新瀏覽器或者清除緩存后,請求的頁面以及頁面內(nèi)的所有資源會忽略之前的max-age,去服務器做重新認證。因此,如果用戶由于max-age出現(xiàn)問題之后,只需要強制刷新或者清緩存就可以修復問題。當然,強迫用戶這樣做只會讓它們降低對你網(wǎng)站的信任度,認為你的網(wǎng)站不靠譜。。。
使用serviceWorker減少這種錯誤的出現(xiàn)幾率service Worker的執(zhí)行時機:
注冊serviceWorker:
if (navigator.serviceWorker) { navigator.serviceWorker.register("/serviceworker.js", { scope: "/" }); }
執(zhí)行serviceworker.js:
const version = "2"; self.addEventListener("install", event => { // 由于系統(tǒng)會隨時睡眠SW,所以,為了防止執(zhí)行中斷,就需要使用 event.waitUntil 進行捕獲 event.waitUntil( caches.open(`static-${version}`) .then(cache => cache.addAll( // 不穩(wěn)定文件或者大文件加載 //... ), cache.addAll([ // 穩(wěn)定文件或小文件加載 "/styles.css", "/script.js" ])); ); }); self.addEventListener("activate", event => { // …delete old caches… }); self.addEventListener("fetch", event => { event.respondWith( caches.match(event.request) .then(response => response || fetch(event.request)) ); });
將script和styles緩存起來。
如果有匹配到的緩存就從緩存中獲取,如果沒有就從服務器獲取。
如果我們修改了JS/CSS,只需修改version就可以讓service worker觸發(fā)更新。
你也可以在service worker中跳過緩存:
self.addEventListener("install", event => { event.waitUntil( caches.open(`static-${version}`) .then(cache => cache.addAll([ new Request("/styles.css", { cache: "no-cache" }), new Request("/script.js", { cache: "no-cache" }) ])) ); });
不過很不巧的是,cache選項在和safari和opera中都不支持 ,只有firefox和chrome最近才開始支持。但是你可以這樣做:
self.addEventListener("install", event => { event.waitUntil( caches.open(`static-${version}`) .then(cache => Promise.all( [ "/styles.css", "/script.js" ].map(url => { // cache-bust using a random query string return fetch(`${url}?${Math.random()}`).then(response => { // fail on 404, 500 etc if (!response.ok) throw Error("Not ok"); return cache.put(url, response); }) }) )) ); });
你可以使用上面代碼中的隨機字符串,也可以使用散列值。這有點像在javascript中實現(xiàn)文章剛開始第一小節(jié)的方法,不過僅僅是在server worker中使用。
通過上個的例子,你可以看到service worker可以很好的處理一些糟糕的緩存情況。但是僅僅是做一些hack處理而已,最重要的是再根源上解決問題。正確的使用緩存不僅可以更好地使用service worker,還可以很好地在那些不支持service worker的瀏覽器(IE/Safari/Opera)上提高網(wǎng)站的性能。除此之外,對你的CDN也是大有益處。
正確的使用緩存,可以大量簡化service worker的代碼:
const version = "23"; self.addEventListener("install", event => { event.waitUntil( caches.open(`static-${version}`) .then(cache => cache.addAll([ "/", "/script-v3.js", "/styles-v3.css", "/dog-v3.jpg" ])) ); });
所以,我們可以使用第二小節(jié)的方法(服務器重新認證)來緩存根HTML頁面。并使用第一小節(jié)的方法(不同的內(nèi)容使用不同的URL)來緩存其他資源。每次service worker更新世都會去請求網(wǎng)站的根HTML頁面,其他資源只有在更改URL時才會去下載,從而提高網(wǎng)站的性能。
雖然service worker擅長提高網(wǎng)站的性能,但它并不是一個完整的解決方案。因此要和HTTP cache配合使用才可以顯著地提高性能。
在內(nèi)容經(jīng)常修改但是URL不變的靜態(tài)資源上使用max-age在通常意義上來說不是一個好點子,但事實卻不總是如此。
假如一個頁面的max-age為三分鐘,并且在這個頁面上不需要考慮靜態(tài)資源的競爭關(guān)系(靜態(tài)資源之間存在相互依賴,見第三小節(jié)),所以在這個頁面上不存在任何的靜態(tài)資源依賴。在這種情況下就可以盡情使用max-age。不過這也意味著網(wǎng)站的修改要再三分鐘之后才可以被看到。
不過要是頁面存在靜態(tài)資源競爭關(guān)系的話,這種法子不好用了,比如我現(xiàn)在有兩個文章A和B,我現(xiàn)在文章A中添加一個新的章節(jié),然后在文章B中增加了一個指向文章A新增章節(jié)的超鏈接。然后我從文章B中訪問這個鏈接,假如文章A的max-age沒有過期,那么我訪問到的文章A里將會發(fā)現(xiàn)文章并沒有那個新增的章節(jié)。此時只能等max-age過期或者強制刷新瀏覽器,再或者清除緩存了。所以,一定要謹慎使用這種方法。
正確使用緩存可以代理巨大的性能收益并且有效節(jié)省服務器帶寬。既支持版本號類型的靜態(tài)資源緩存方式也支持服務器重新認證(no-cache、304)的方式。如果你覺得自己很勇敢,那么大可混合使用max-age和『內(nèi)容經(jīng)常修改但是URL不變的靜態(tài)資源』,但是前提你得確定自己的HTML中沒有靜態(tài)資源競爭關(guān)系。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/61955.html
摘要:可能會延長這些的壽命假設(shè)你有以下的這個緩存了和如果命中了緩存,就從緩存中取,否則發(fā)起網(wǎng)絡(luò)請求如果我們更改了,我們會修改中的版本號,觸發(fā)的更新。 本文翻譯自:https://jakearchibald.com/201...這是一篇2016年的老文章。作者是Chrome瀏覽器的開發(fā)成員。 本文首發(fā)于公眾號:符合預期的CoyPan 使用正確的緩存可以帶來巨大的頁面性能上的收益,節(jié)省帶寬,減...
摘要:根據(jù)資源的分類的資源分類主要分為兩大類主資源和派生資源。此時的數(shù)據(jù)時緩存到內(nèi)存中的,當進程后,也就是瀏覽器關(guān)閉以后,數(shù)據(jù)將不存在。信息最大作用就是用于判斷服務器上該的內(nèi)容是否被修改。附上我的學習筆記。 根據(jù)webkit資源的分類 webkit的資源分類主要分為兩大類:主資源和派生資源。 主資源:比如HTML頁面,或者下載項,對應代碼中的類是MainResourceLoader。 派生...
摘要:增量更新是目前大部分團隊采用的緩存更新方案,能讓用戶在無感知的情況獲取最新內(nèi)容。那我們需要考慮的就是如何確保加載的是最新的了,其他的靜態(tài)資源就充分利用瀏覽器緩存以減少網(wǎng)絡(luò)請求提高性能。 增量更新是目前大部分團隊采用的緩存更新方案,能讓用戶在無感知的情況獲取最新內(nèi)容。具體實現(xiàn)方式通常是(一般我們通過構(gòu)建工具來實現(xiàn),比如webpack): 構(gòu)建產(chǎn)出文件hash(如:index.d94f8...
閱讀 1349·2021-09-28 09:43
閱讀 4116·2021-09-04 16:41
閱讀 1918·2019-08-30 15:44
閱讀 3729·2019-08-30 15:43
閱讀 776·2019-08-30 14:21
閱讀 2037·2019-08-30 11:00
閱讀 3320·2019-08-29 16:20
閱讀 1923·2019-08-29 14:21