摘要:當我們第一次或者打開百度,我們會發現加載的請求響應字段如下由于是第一次或者強制刷新打開的,所以瀏覽器會忽略緩存,直接向服務器發送請求加載資源,圖中畫框的那幾個字段是與緩存相關的。
合理利用緩存
概述:本章主要討論了兩方面的內容。1. 瀏覽器緩存機制。 2. web實踐中如何有效利用這些緩存
瀏覽器緩存機制
作為web開發人員經常遇到的問題之一就是我明明修復并且部署了這個BUG為什么線上有的用戶還會出現這個問題呢?還有每次更新完我們都會說你清除緩存試試?為什么一定要清除緩存呢,可以肯定說絕大部分用戶是不知道要清除緩存的!那我們能否不清除緩存,最新部署的文件能夠馬上就生效呢。答案是肯定的,這就需要我們花費一點時間了解一下緩存是怎么工作的。 我們可以簡單的理解為緩存是為了減少網絡帶寬和優化用戶體驗而存在的。核心就是把緩存的內容保存在了本地,而不用每次都向服務端發送相同的請求,設想下每次都打開相同的頁面,而在第一次打開的同時,將下載的js、css、圖片等“保存”在了本地,而之后的請求每次都在本地讀取,效率是不是高了很多。當我用瀏覽器打開一個網頁可以發現瀏覽器加載頁面資源的http請求返回的Status Code有以下常見的值304 Not Modified/200 OK (from disk cache)/ 200 OK。這些值代表著什么意思呢?其實瀏覽器就是依靠請求和響應中的的頭信息來控制緩存的。下面我們來具體分析一下。 當我們第一次(或者ctrl+F5)打開百度,我們會發現加載jquery.js的http請求響應字段如下
由于是第一次或者強制刷新打開的,所以瀏覽器會忽略緩存,直接向服務器發送請求加載資源,圖中畫框的那幾個字段是與緩存相關的。它們的意義如下:
1. cache-control:max-age=315360000:它告訴瀏覽器這個資源的緩存時間為315360000秒(10年),那么瀏覽器就將這個文件保存到本地磁盤緩存起來,下次你再次打開百度時,只要是再10年內瀏覽器就不向服務器發送請求加載資源了,而是直接從緩存中加載。 2. expires:Fri, 06 Nov 2026 04:20:09 GMT:它告訴瀏覽器這個資源的有效期:現在-->2026年11月6號04:20:09,在這個時間內你打開百度瀏覽器就不向服務器發送請求加載資源了,而是直接從緩存中加載。
這個是不是與cache-control功能有點重合呢,是的!Expires是HTTP1.0的東西,而Cache-Control是HTTP1.1的,規定如果max-age和Expires同時存在,前者優先級高于后者。Cache-Control的參數可以設置很多值,譬如(參考瀏覽器緩存機制)。
3. Last-Modified: Mon, 07 Nov 2016 07:51:11 GMT:標示這個響應資源的最后修改時間。 4. ETag: 告訴瀏覽器當前資源在服務器的唯一標識(生成規則由服務器覺得) 當我按下F5重新加載頁面時會得到下面的http請求響應信息
我們會發現瀏覽器是發送了一個http請求而不是我們之前說的在10年之內不發送請求,并且這個請求的響應是304,就是說當我按下F5時,瀏覽器忽略了上次請求返回的cache-control和expires字段的值,它是再次發送了一個獲取資源的請求,但是這次http請求頭部包含了兩個新字段If-Modified-Since和If-None-Match(這兩個字段的值就是上次請求資源響應中包含的Last-Modified和ETag的值),這就是問題所在,服務器檢測到這兩個字段做對應的響應如下: If-Modified-Since:服務器收到請求后發現有頭If-Modified-Since則與被請求資源的最后修改時間進行比對。若最后修改時間較新,說明資源又被改動過,則響應整片資源內容(寫在響應消息包體內),HTTP 200;若最后修改時間較舊,說明資源無新修改,則響應HTTP 304 (無需包體,節省加載時間與帶寬),告知瀏覽器繼續使用所保存的cache。 If-None-Match: 服務器收到請求后發現有If-None-Match則與被請求資源的相應校驗串進行比對,決定返回200或304。
我們會發現這兩個字段功能也有點重合,原因如下:
1) 次Last-Modified標注的最后修改只能精確到秒級,如果某些文件在1秒鐘以內,被修改多次的話,它將不能準確標注文件的修改時間。
2) 如果某些文件會被定期生成,當有時內容并沒有任何變化,但Last-Modified卻改變了,導致文件沒法使用緩存。
3) 有可能存在服務器沒有準確獲取文件修改時間,或者與代理服務器時間不一致等情形。
Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的唯一標識符,能夠更加準確的控制緩存。Last-Modified與ETag是可以一起使用的,服務器會優先驗證ETag,一致的情況下,才會繼續比對Last-Modified,最后才決定是否返回304。
那現在就還剩下一個問題,就是當我按下F5時,瀏覽器為什么不是直接從本地緩存中加載文件而是發送了一個http請求呢?這個是就用戶行為與瀏覽器對緩存的控制有關
緩存總結如下
瀏覽器第一次請求:
瀏覽器再次請求時:
有效利用緩存
下面我們就來說說WEB資源文件的緩存時間設置為多少是全適的呢。
現在大部分網站都是每次更新部署時,只要有修改的文件都會重新生成一個名字(如:gulp打包[http://www.xxx.tv/dist/hr20170117/js/main-f3d7137ecb.js],HTML文件除外),相當于有更改的文件都有新的URL.針對這種情況,我們可以進行如下設置
HTML文件可以設置為max-age為0,那么用戶每次打開網頁都會向服務器詢問這個網頁有沒有更改,如果有更改用戶就能夠加載最新的文件。
CSS/JS文件可以設置為30天或者1年。
下面為對應的nginx配置
location ~ .*.(js|css)?${
expires 1M;
}
~* .(?:manifest|appcache|html?|xml|json)$ {
expires -1;
}
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/39438.html
摘要:性能優化頁面渲染減少頁面修改元素多個樣式可以通過修改完成這樣可以把多次減少為一次修改元素多個樣式可以分為三步先隱藏再修改最后顯示。 代碼優化 這個部分僅僅將代碼優化本身,不考慮性能,關于代碼部分的性能優化在 頁面渲染 部分 代碼優化 中 HTML+CSS 符合 XHTML 規范: 小寫,正確嵌套,必須關閉; 雙引號,合理縮進,utf-8編碼; 標簽語義化,便于維護; 合理注釋,比如 ...
摘要:性能優化頁面渲染減少頁面修改元素多個樣式可以通過修改完成這樣可以把多次減少為一次修改元素多個樣式可以分為三步先隱藏再修改最后顯示。 代碼優化 這個部分僅僅將代碼優化本身,不考慮性能,關于代碼部分的性能優化在 頁面渲染 部分 代碼優化 中 HTML+CSS 符合 XHTML 規范: 小寫,正確嵌套,必須關閉; 雙引號,合理縮進,utf-8編碼; 標簽語義化,便于維護; 合理注釋,比如 ...
摘要:性能優化頁面渲染減少頁面修改元素多個樣式可以通過修改完成這樣可以把多次減少為一次修改元素多個樣式可以分為三步先隱藏再修改最后顯示。 代碼優化 這個部分僅僅將代碼優化本身,不考慮性能,關于代碼部分的性能優化在 頁面渲染 部分 代碼優化 中 HTML+CSS 符合 XHTML 規范: 小寫,正確嵌套,必須關閉; 雙引號,合理縮進,utf-8編碼; 標簽語義化,便于維護; 合理注釋,比如 ...
閱讀 2695·2023-04-25 17:58
閱讀 2978·2021-11-15 11:38
閱讀 2378·2021-11-02 14:48
閱讀 1185·2021-08-25 09:40
閱讀 1823·2019-08-30 15:53
閱讀 1093·2019-08-30 15:52
閱讀 1031·2019-08-30 13:55
閱讀 2437·2019-08-29 15:21