摘要:最近在項目中遇到了瀏覽器因緩存問題未能成功向后端發送類型請求的,然后順藤摸瓜順便看了看緩存的知識,覺得有必要總結一下。是服務器響應消息頭字段,在響應請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據,而無需再次請求。
最近在項目中遇到了IE瀏覽器因緩存問題未能成功向后端發送GET類型請求的bug,然后順藤摸瓜順便看了看緩存的知識,覺得有必要總結一下。
在前端開發中,性能一直都是被大家所重視的一點,然而判斷一個網站的性能最直觀的就是看網頁打開的速度。其中提高網頁反應速度的一個方式就是使用緩存。一個優秀的緩存策略可以縮短網頁請求資源的距離,減少延遲,并且由于緩存文件可以重復利用,還可以減少帶寬,降低網絡負荷。
1. 介紹web緩存是指一個web資源(如html頁面,圖片,js,數據等)存在于web服務器和客戶端(瀏覽器)之間的副本。
緩存會根據進來的請求保存輸出內容的副本;當下一個請求來到的時候,如果是相同的URL,緩存會根據緩存機制決定是直接使用副本響應訪問請求,還是向源服務器再次發送請求。比較常見的就是瀏覽器會緩存訪問過網站的網頁,當再次訪問這個URL地址的時候,如果網頁沒有更新,就不會再次下載網頁,而是直接使用本地緩存的網頁。只有當網站明確標識資源已經更新,瀏覽器才會再次下載網頁。至于瀏覽器和網站服務器是如何標識網站頁面是否更新的機制,將在后面介紹。
1.1 web緩存的作用web緩存的作用顯而易見:
減少網絡帶寬消耗
無論對于網站運營者或者用戶,帶寬都代表著金錢,過多的帶寬消耗,只會便宜了網絡運營商。當Web緩存副本被使用時,只會產生極小的網絡流量,可以有效的降低運營成本。
降低服務器壓力
給網絡資源設定有效期之后,用戶可以重復使用本地的緩存,減少對源服務器的請求,間接降低服務器的壓力。同時,搜索引擎的爬蟲機器人也能根據過期機制降低爬取的頻率,也能有效降低服務器的壓力。
減少網絡延遲,加快頁面打開速度
帶寬對于個人網站運營者來說是十分重要,而對于大型的互聯網公司來說,可能有時因為錢多而真的不在乎。那Web緩存還有作用嗎?答案是肯定的,對于最終用戶,緩存的使用能夠明顯加快頁面打開速度,達到更好的體驗。
web緩存大致可以分為以下幾種類型:
數據庫數據緩存
服務器端緩存
瀏覽器端緩存
web應用層緩存
瀏覽器通過代理服務器向源服務器發起請求的原理如下圖:
瀏覽器先向代理服務器發起web請求,再將請求轉發到源服務器。它屬于共享緩存,所以很多地方都可以使用其緩存資源,因此對于節省流量有很大作用。
瀏覽器緩存是將文件保存在客戶端,在同一個會話過程中會檢查緩存的副本是否足夠新,在后退網頁時,訪問過的資源可以從瀏覽器緩存中拿出使用。通過減少服務器處理請求的數量,用戶將獲得更快的體驗
下面著重關注一下瀏覽器緩存。
2. web緩存的工作原理所有的緩存都是基于一套規則來幫助他們決定什么時候使用緩存中的副本提供服務(假設有副本可用的情況下,未被銷毀回收或者未被刪除修改)。這些規則有的在協議中有定義(如HTTP協議1.0和1.1),有的則是由緩存的管理員設置(如DBA、瀏覽器的用戶、代理服務器管理員或者應用開發者)。
2.1 瀏覽器端的緩存規則對于瀏覽器端的緩存來講,這些規則是在HTTP協議頭和HTML頁面的Meta標簽中定義的。他們分別從新鮮度和校驗值兩個維度來規定瀏覽器是直接使用緩存中的副本,還是需要去源服務器獲取更新的版本。
新鮮度(過期機制):也就是緩存副本有效期。一個緩存副本必須滿足以下任一條件,瀏覽器會認為它是有效的,足夠新的,而直接從緩存中獲取副本并渲染:
含有完整的過期時間控制頭信息(HTTP協議報頭),并且仍在有效期內
瀏覽器已經使用過這個緩存副本,并且在一個會話中已經檢查過新鮮度
校驗值(驗證機制):服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標簽Etag(Entity Tag),它可以用來作為瀏覽器再次請求過程的校驗標識。如過發現校驗標識不匹配,說明資源已經被修改或過期,瀏覽器需求重新獲取資源內容。
2.2 瀏覽器緩存的控制 2.2.1 使用HTML的 Meta 標簽上述代碼的作用是告訴瀏覽器當前頁面不被緩存,每次訪問都需要去服務器拉取。使用上很簡單,但只有部分瀏覽器可以支持,而且所有緩存代理服務器都不支持,因為代理不解析HTML內容本身。
可以通過這個頁面測試你的瀏覽器是否支持:Pragma No-Cache Test。
一個URI的完整HTTP協議交互過程是由HTTP請求和HTTP響應組成的。有關HTTP詳細內容可參考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP協議詳解》等。
在HTTP請求和響應的消息報頭中,常見的與緩存有關的消息報頭有:
Cache-Control
cache-control的種類這么多,然而怎么使用它們呢:
max-age(單位為s)指定設置緩存最大的有效時間,定義的是時間長短。當瀏覽器向服務器發送請求后,在max-age這段時間里瀏覽器就不會再向服務器發送請求了。
我們來找個資源看下。比如QQ推廣上的css資源,max-age=3600,也就是說緩存有效期為3600秒(也就是1h)。于是在1小時內都會使用這個版本的資源,即使服務器上的資源發生了變化,瀏覽器也不會得到通知。max-age會覆蓋掉Expires,后面會有討論。
s-maxage(單位為s)同max-age,只用于共享緩存(比如CDN緩存)。
比如,當s-maxage=60時,在這60秒中,即使更新了CDN的內容,瀏覽器也不會進行請求。也就是說max-age用于普通緩存,而s-maxage用于代理緩存。如果存在s-maxage,則會覆蓋掉max-age和Expires header。
public 指定響應會被緩存,并且在多用戶間共享。也就是下圖的意思。如果沒有指定public還是private,則默認為public。
private 響應只作為私有的緩存(見下圖),不能在用戶間共享。如果要求HTTP認證,響應會自動設置為private。
no-cache 指定不緩存響應,表明資源不進行緩存,但是設置了no-cache之后并不代表瀏覽器不緩存,而是在獲取緩存前要向服務器確認資源是否被更改。因此有的時候只設置no-cache防止緩存還是不夠保險,還可以加上private指令,將過期時間設為過去的時間。
no-store 絕對禁止緩存,一看就知道如果用了這個命令當然就是不會進行緩存啦~每次請求資源都要從服務器重新獲取。
must-revalidate 指定如果頁面是過期的,則去服務器進行獲取。這個指令并不常用,就不做過多的討論了。
Expires
緩存過期時間,用來指定資源到期的時間,是服務器端的具體的時間點。也就是說, Expires=max-age + 請求時間 ,需要和Last-modified結合使用。但在上面我們提到過,cache-control的優先級更高。 Expires是Web服務器響應消息頭字段,在響應http請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據,而無需再次請求。
Last-modified & If-modified-since
服務器端文件的最后修改時間,需要和cache-control共同使用,是檢查服務器端資源是否更新的一種方式。當瀏覽器再次進行請求時,會向服務器傳送If-Modified-Since報頭,詢問Last-Modified時間點之后資源是否被修改過。如果沒有修改,則返回碼為304,使用緩存;如果修改過,則再次去服務器請求資源,返回碼和首次請求相同為200,資源為服務器最新資源。
Etag & & If-None-Match
根據實體內容生成一段hash字符串,標識資源的狀態,由服務端產生。瀏覽器會將這串字符串傳回服務器,驗證資源是否已經修改,如果沒有修改,過程如下:
Cache-Control與Expires
Cache-Control與Expires的作用一致,都是指明當前資源的有效期,控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。只不過Cache-Control的選擇更多,設置更細致,如果同時設置的話,其優先級高于Expires。
Last-Modified與ETag
Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的唯一標識符,能夠更加準確的控制緩存。Last-Modified與ETag是可以一起使用的,服務器會優先驗證ETag,一致的情況下,才會繼續比對Last-Modified,最后才決定是否返回304。
你可能會覺得使用Last-Modified已經足以讓瀏覽器知道本地的緩存副本是否足夠新,為什么還需要Etag(實體標識)呢?HTTP1.1中Etag的出現主要是為了解決幾個Last-Modified比較難解決的問題:
Last-Modified標注的最后修改只能精確到秒級,如果某些文件在1秒鐘以內,被修改多次的話,它將不能準確標注文件的新鮮度
如果某些文件會被定期生成,當有時內容并沒有任何變化,但Last-Modified卻改變了,導致文件沒法使用緩存
有可能存在服務器沒有準確獲取文件修改時間,或者與代理服務器時間不一致等情形
Last-Modified/ETag 與 Cache-Control/Expires
配置Last-Modified/ETag的情況下,瀏覽器再次訪問統一URI的資源,還是會發送請求到服務器詢問文件是否已經修改,如果沒有,服務器會只發送一個304回給瀏覽器,告訴瀏覽器直接從自己本地的緩存取數據;如果修改過那就整個數據重新發給瀏覽器;
Cache-Control/Expires則不同,如果檢測到本地的緩存還是有效的時間范圍內,瀏覽器直接使用本地副本,不會發送任何請求。兩者一起使用時,Cache-Control/Expires的優先級要高,即當本地副本根據Cache-Control/Expires發現還在有效期內時,則不會再次發送請求去服務器詢問修改時間Last-Modified或實體標識Etag了。
一般情況下,兩者會配合一起使用,因為即使服務器設置緩存時間, 當用戶點擊“刷新”按鈕時,瀏覽器會忽略緩存繼續向服務器發送請求,這時Last-Modified/ETag將能夠很好利用304,從而減少響應開銷。
無法被瀏覽器緩存的請求:
HTTP信息頭中包含Cache-Control:no-cache,pragma:no-cache,或Cache-Control:max-age=0等告訴瀏覽器不用緩存的請求
需要根據Cookie,認證信息等決定輸入內容的動態請求是不能被緩存的
經過HTTPS安全加密的請求(有人也經過測試發現,ie其實在頭部加入Cache-Control:max-age信息,firefox在頭部加入Cache-Control:Public之后,能夠對HTTPS的資源進行緩存,參考《HTTPS的七個誤解》)
POST請求無法被緩存
HTTP響應頭中不包含Last-Modified/Etag,也不包含Cache-Control/Expires的請求無法被緩存
3. 使用緩存流程一個用戶發起一個靜態資源請求的時候,瀏覽器會通過以下幾步來獲取并展示資源:
緩存行為主要由緩存策略決定,而緩存策略由內容擁有者設置。這些策略主要通過特定的HTTP頭部來清晰地表達。
以上過程也可以被概括為三個階段:
本地緩存階段:先在本地查找該資源,如果有發現該資源,而且該資源還沒有過期,就使用這一個資源,完全不會發送http請求到服務器;
協商緩存階段:如果在本地緩存找到對應的資源,但是不知道該資源是否過期或者已經過期,則發一個http請求到服務器,然后服務器判斷這個請求,如果請求的資源在服務器上沒有改動過,則返回304,讓瀏覽器使用本地找到的那個資源;
緩存失敗階段:當服務器發現請求的資源已經修改過,或者這是一個新的請求(在本來沒有找到資源),服務器則返回該資源的數據,并且返回200, 當然這個是指找到資源的情況下,如果服務器上沒有這個資源,則返回404。
4. 用戶操作行為與緩存的關系用戶在使用瀏覽器的時候,會有各種操作,比如輸入地址后回車,按F5刷新等,這些行為會對緩存有什么影響呢?
通過上表我們可以看到,當用戶在按F5進行刷新的時候,會忽略Expires/Cache-Control的設置,會再次發送請求去服務器請求,而Last-Modified/Etag還是有效的,服務器會根據情況判斷返回304還是200;
而當用戶使用Ctrl+F5進行強制刷新的時候,只是所有的緩存機制都將失效,重新從服務器拉去資源。
普通刷新 – 當按下F5或者點擊刷新按鈕來刷新頁面的時候,瀏覽器將繞過本地緩存來發送請求到服務器, 此時, 協商緩存是有效的
強制刷新 – 當按下ctrl+F5來刷新頁面的時候, 瀏覽器將繞過各種緩存(本地緩存和協商緩存), 直接讓服務器返回最新的資源
回車或轉向 – 當在地址欄上輸入回車或者按下跳轉按鈕的時候, 所有緩存都生效
5. 如何從緩存角度改善站點詳細信息
同一個資源保證URL的穩定性
給css、js、圖片等資源增加HTTP緩存頭,并強制入口html不被緩存
減少對Cookie的依賴
減少對HTTPS加密協議的使用
多用Get方式請求動態Cgi
動態CGI也是可以被緩存
網上的帖子大多深淺不一,甚至有些前后矛盾,在下的文章都是學習過程中的總結,如果發現錯誤,歡迎留言指出~
參考:
Web緩存機制系列
淺談web緩存
Web前后端緩存技術
瀏覽器緩存機制:不同瀏覽器對用戶操作行為處理比較
PS:歡迎大家關注我的公眾號【前端下午茶】,一起加油吧~
另外可以加入「前端下午茶交流群」微信群,長按識別下面二維碼即可加我好友,備注加群,我拉你入群~
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/90407.html
摘要:淺談網站性能之前端性能優化性能優化的目的無非是減少用戶流量消耗,提升用戶首屏體驗,提升用戶訪問速度,讓用戶專注內容本身。前端性能優化減少請求數量基本原理在瀏覽器與服務器進行通信時,主要是通過進行通信。 最近項目慢慢走上正軌,需求趨于平穩,這才想起需要對整站進行性能優化。經過一段時間的學習,結合現在項目的實際性能情況,發現確實有許多地方可以進行優化。于是就開始了我的前端性能優化之旅。以下...
摘要:淺談網站性能之前端性能優化性能優化的目的無非是減少用戶流量消耗,提升用戶首屏體驗,提升用戶訪問速度,讓用戶專注內容本身。前端性能優化減少請求數量基本原理在瀏覽器與服務器進行通信時,主要是通過進行通信。 最近項目慢慢走上正軌,需求趨于平穩,這才想起需要對整站進行性能優化。經過一段時間的學習,結合現在項目的實際性能情況,發現確實有許多地方可以進行優化。于是就開始了我的前端性能優化之旅。以下...
摘要:協商緩存用戶發送的請求,發送到服務器后,由服務器判定是否從緩存中獲取資源。如果想主動清除緩存,也可以在請求頭信息中加入來禁止緩存。主要取值如下緩存的時效由決定。是的字段,而是的字段,當與同時存在時,的優先級要高于。 在講這幾個屬性之前,先復習下瀏覽器的緩存機制,再結合了解一下Last-Modified / If-Modified-Since、Etag / If-Match、cache-...
閱讀 1459·2021-09-30 09:57
閱讀 1466·2021-09-09 09:33
閱讀 2220·2021-09-04 16:40
閱讀 1792·2021-09-01 10:50
閱讀 3237·2021-09-01 10:31
閱讀 2539·2019-08-30 15:56
閱讀 2970·2019-08-30 15:44
閱讀 3475·2019-08-29 17:29