整合營銷服務商

          電腦端+手機端+微信端=數據同步管理

          免費咨詢熱線:

          前端項目如何防止瀏覽器緩存舊版js和css

          迎關注我的頭條號:Wooola,專注于Java、Golang、微服務架構,致力于每天分享原創文章、快樂編碼和開源技術。

          前言

          最近發版前端項目,用戶經常反饋新添加功能在線上環境不好用,常出現新老頁面并存的狀況。經前端同事排查法發現,實際上只需要重新刷新一下頁面就沒事了。但是每次去通知用戶肯定不現實,所以需要對前端的js和css等文件采取一定的緩存失效的措施,強制瀏覽器重新去服務器獲取新的js代碼以及css文件。

          樓主經過實際的項目情況反饋,總結以下兩點切實可行的辦法,分享給大家,希望對大家有幫助。

          1. 路徑后面加時間戳或者隨機數的方式
          2. 采用hash(md5)重命名文件

          路徑后面加時間戳或者隨機數的方式

          時間版本號

          如果每次發布,針對修改過的js或者css文件路徑加上時間的版本號,一般以年月日拼寫。

          <script type="text/javascript" src="lib/common.js?v=20190719"></script>
          <link rel="stylesheet" type="text/css" href="assets/css/ie/ie8.css?v=20190719" />
          

          如果發生緊急情況,需要在一天當中對某些css或者js文件多次發版,可以把時間精確到時分秒。

          目前樓主主推采用加版本號的方式,因為文件太多,只能做增量修改。好處是沒有做任何修改js或者css文件可以不用加版本號。

          采用隨機數

          document.write('<script src=\".lib/common.js?r=' + Math.random() + "\"" + '><\/script>');
          

          一般不建議用隨機數的方式,因為每次刷新頁面,隨機數都會變化,那么瀏覽器認為一個新的url需要重新請求服務端獲取js或css文件,不會在使用瀏覽器本地緩存。同時占用網絡帶寬,影響服務器響應速度。

          采用hash(md5)重命名文件

          可以利用 gulp-rev或者webpack

          entry: {
           main: './src/common.js',
           slove: './src/ie8.js'
          },
          output: {
           filename: '[name].[hash].js',
           path: path.resolve(__dirname, 'dist')
          }
          

          例如百度搜索首頁,就是利用hash給js和css文件重命名。

          覽器緩存究竟是什么?

          瀏覽器緩存(Browser Caching)是為了加速瀏覽,瀏覽器在用戶磁盤上對請求過的文檔進行存儲,當訪問者再次請求這個頁面時,瀏覽器就可以從本地磁盤顯示文檔,這樣就可以加速頁面的閱覽。它是網站訪問統計最難解決的問題之一。為了回收重復閱覽網站而產生的資源浪費,而產生的機制。緩存的方式節約了網絡的資源,提高了網絡的效率。

          為什么要清理緩存呢?緩存會帶來哪些問題?

          部署前端項目以后,你會發現一個問題(為什么必須刷新頁面,頁面才會更新到最新版本),其實就是因為服務器緩存的問題。緩存會導致你頁面樣式、圖片或腳本等未能及時更新展示。

          瀏覽器自身如何清理緩存呢?

          以谷歌瀏覽器為例:按照下圖指示:(也可使用快捷鍵直接喚起:Ctrl + Shift + Del)


          清除緩存步驟1


          清除緩存步驟2

          vue項目中如何清理緩存呢?

          1.在根目錄下index.html的header頭中添加一下代碼:

          vue不緩存-方式1

          2.配置 nginx 不緩存 html

          index.html在服務器端可能是有緩存的,需要在服務器nginx上配置不讓緩存index.html


          vue不緩存-方式2

          名詞解釋:

          no-cache:數據內容不能被緩存, 每次請求都重新訪問服務器, 若有max-age(最大緩存期), 則緩存期間不訪問服務器

          no-store:不僅不能緩存, 連暫存也不可以(即: 臨時文件夾中不能暫存該資源)


          以上就是我本次分享的方式,各位同仁們還有什么好的方式可以下方留言,共同學習!


          ---攜手共進,一同進階!

          者:kevinylzhao,騰訊音樂前端開發工程師

          瀏覽器緩存策略對于前端開發同學來說不陌生,大家都有一定的了解,但如果沒有系統的歸納總結,可能三言兩語很難說明白,甚至說錯,尤其在面試過程中感觸頗深,很多候選人對這類基礎知識竟然都是一知半解,說出幾個概念就沒了,所以重新歸納總結下,溫故而知新。


          Web 緩存介紹

          • Web 緩存是指一個 Web 資源(如 html 頁面,圖片,js,數據等)存在于 Web 服務器和客戶端(瀏覽器)之間的副本。
          • 緩存會根據進來的請求保存輸出內容的副本;當下一個請求來到的時候,如果是相同的 URL,緩存會根據緩存機制決定是直接使用副本響應訪問請求,還是向源服務器再次發送請求。

          Web 緩存的好處

          • 減少網絡延遲,加快頁面打開速度
          • 減少網絡帶寬消耗
          • 降低服務器壓力
          • ...

          HTTP 的緩存機制

          簡化的流程如下

          根據什么規則緩存

          1. 新鮮度(過期機制):也就是緩存副本有效期。一個緩存副本必須滿足以下條件,瀏覽器會認為它是有效的,足夠新的:
          • 含有完整的過期時間控制頭信息(HTTP 協議報頭),并且仍在有效期內;
          • 瀏覽器已經使用過這個緩存副本,并且在一個會話中已經檢查過新鮮度;
          1. 校驗值(驗證機制):服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標簽 Etag(Entity Tag),它可以用來作為瀏覽器再次請求過程的校驗標識。如果發現校驗標識不匹配,說明資源已經被修改或過期,瀏覽器需求重新獲取資源內容。

          HTTP 緩存的兩個階段

          瀏覽器緩存一般分為兩類:強緩存(也稱本地緩存)和協商緩存(也稱弱緩存)。

          本地緩存階段

          瀏覽器發送請求前,會先去緩存里查看是否命中強緩存,如果命中,則直接從緩存中讀取資源,不會發送請求到服務器。否則,進入下一步。

          協商緩存階段

          當強緩存沒有命中時,瀏覽器一定會向服務器發起請求。服務器會根據 Request Header 中的一些字段來判斷是否命中協商緩存。如果命中,服務器會返回 304 響應,但是不會攜帶任何響應實體,只是告訴瀏覽器可以直接從瀏覽器緩存中獲取這個資源。如果本地緩存和協商緩存都沒有命中,則從直接從服務器加載資源。

          啟用&關閉緩存

          按照本地緩存階段和協商緩存階段分類:

          1. 使用 HTML Meta 標簽    Web 開發者可以在 HTML 頁面的節點中加入標簽,如下:

          上述代碼的作用是告訴瀏覽器當前頁面不被緩存,事實上這種禁用緩存的形式用處很有限:

          a. 僅有 IE 才能識別這段 meta 標簽含義,其它主流瀏覽器僅識別“Cache-Control: no-store”的 meta 標簽。

          b. 在 IE 中識別到該 meta 標簽含義,并不一定會在請求字段加上 Pragma,但的確會讓當前頁面每次都發新請求(僅限頁面,頁面上的資源則不受影響)。

          1. 使用緩存有關的 HTTP 消息報頭 這里需要了解 HTTP 的基礎知識。一個 URI 的完整 HTTP 協議交互過程是由 HTTP 請求和 HTTP 響應組成的。有關 HTTP 詳細內容可參考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP 權威指南》等。

          在 HTTP 請求和響應的消息報頭中,常見的與緩存有關的消息報頭有:

          上圖中只是常用的消息報頭,下面來看下不同字段之間的關系和區別:

          1. Cache-Control 與 Expires
          2. Cache-Control:HTTP1.1 提出的特性,為了彌補 Expires 缺陷加入的,提供了更精確細致的緩存功能。詳細了解詳細看幾個常見的指令:_ max-age:功能和 Expires 類似,但是后面跟一個以“秒”為單位的相對時間,來供瀏覽器計算過期時間。_ no-cache:提供了過期驗證機制。(在 Chrome 的 devtools 中勾選 Disable cache 選項,發送的請求會去掉 If-Modified-Since 這個 Header。同時設置 Cache-Control:no-cache Pragma:no-cache,每次請求均為 200)
            • no-store:表示當前請求資源禁用緩存;
            • public:表示緩存的版本可以被代理服務器或者其他中間服務器識別;
            • private:表示只有用戶自己的瀏覽器能夠進行緩存,公共的代理服務器不允許緩存。
          • Expires:HTTP1.0 的特性,標識該資源過期的時間點,它是一個絕對值,格林威治時間(Greenwich Mean Time, GMT),即在這個時間點之后,緩存的資源過期;優先級:Cache-Control 優先級高于 Expires,為了兼容,通常兩個頭部同時設置;瀏覽器默認行為:其實就算 Response Header 中沒有設置 Cache-Control 和 Expires,瀏覽器仍然會緩存某些資源,這是瀏覽器的默認行為,是為了提升性能進行的優化,每個瀏覽器的行為可能不一致,有些瀏覽器甚至沒有這樣的優化。
          1. Last-Modified 與 ETag
          2. Last-Modified(Response Header)與 If-Modified-Since(Request Header)是一對報文頭,屬于 http 1.0。If-Modified-Since 是一個請求首部字段,并且只能用在 GET 或者 HEAD 請求中。Last-Modified 是一個響應首部字段,包含服務器認定的資源作出修改的日期及時間。當帶著 If-Modified-Since 頭訪問服務器請求資源時,服務器會檢查 Last-Modified,如果 Last-Modified 的時間早于或等于 If-Modified-Since 則會返回一個不帶主體的 304 響應,否則將重新返回資源。(注意:在 Chrome 的 devtools 中勾選 Disable cache 選項后,發送的請求會去掉 If-Modified-Since 這個 Header。)
          • ETag 與 If-None-Match 是一對報文頭,屬于 http 1.1。ETag 是一個響應首部字段,它是根據實體內容生成的一段 hash 字符串,標識資源的狀態,由服務端產生。If-None-Match 是一個條件式的請求首部。如果請求資源時在請求首部加上這個字段,值為之前服務器端返回的資源上的 ETag,則當且僅當服務器上沒有任何資源的 ETag 屬性值與這個首部中列出的時候,服務器才會返回帶有所請求資源實體的 200 響應,否則服務器會返回不帶實體的 304 響應。
          • ETag 能解決什么問題?

          a. Last-Modified 標注的最后修改只能精確到秒級,如果某些文件在 1 秒鐘以內,被修改多次的話,它將不能準確標注文件的新鮮度;

          b. 某些文件也許會周期性的更改,但是它的內容并不改變(僅僅改變的修改時間),但 Last-Modified 卻改變了,導致文件沒法使用緩存;

          c. 有可能存在服務器沒有準確獲取文件修改時間,或者與代理服務器時間不一致等情形。

          • 優先級:ETag 優先級比 Last-Modified 高,同時存在時會以 ETag 為準。
          緩存位置

          瀏覽器可以在內存、硬盤中開辟一個空間用于保存請求資源副本。我們經常調試時在 DevTools Network 里看到 Memory Cache(內存緩存)和 Disk Cache(硬盤緩存),指的就是緩存所在的位置。請求一個資源時,會按照優先級(Service Worker -> Memory Cache -> Disk Cache -> Push Cache)依次查找緩存,如果命中則使用緩存,否則發起請求。這里先介紹 Memory Cache 和 Disk Cache。

          200 from memory cache

          表示不訪問服務器,直接從內存中讀取緩存。因為緩存的資源保存在內存中,所以讀取速度較快,但是關閉進程后,緩存資源也會隨之銷毀,一般來說,系統不會給內存分配較大的容量,因此內存緩存一般用于存儲較小文件。同時內存緩存在有時效性要求的場景下也很有用(比如瀏覽器的隱私模式)。

          200 from disk cache

          表示不訪問服務器,直接從硬盤中讀取緩存。與內存相比,硬盤的讀取速度相對較慢,但硬盤緩存持續的時間更長,關閉進程之后,緩存的資源仍然存在。由于硬盤的容量較大,因此一般用于存儲大文件。

          下圖可清晰看出差別:

          200 from prefetch cache

          在 preload 或 prefetch 的資源加載時,兩者也是均存儲在 http cache,當資源加載完成后,如果資源是可以被緩存的,那么其被存儲在 http cache 中等待后續使用;如果資源不可被緩存,那么其在被使用前均存儲在 memory cache。

          CDN Cache

          以騰訊 CDN 為例:X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節點的內存;X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節點的磁盤;X-Cache-Lookup:Hit From Upstream 表示沒有命中 CDN。

          整體流程

          從上圖能感受到整個流程,比如常見兩種刷新場景:

          • 當 F5 刷新網頁時,跳過強緩存,但是會檢查協商緩存;
          • 當 Ctrl + F5 強制刷新頁面時,直接從服務器加載,跳過強緩存和協商緩存

          其他 Web 緩存策略

          IndexDB

          IndexedDB 就是瀏覽器提供的本地數據庫,能夠在客戶端存儲可觀數量的結構化數據,并且在這些數據上使用索引進行高性能檢索的 API。

          異步 API 方法調用完后會立即返回,而不會阻塞調用線程。要異步訪問數據庫,要調用 window 對象 indexedDB 屬性的 open() 方法。該方法返回一個 IDBRequest 對象 (IDBOpenDBRequest);異步操作通過在 IDBRequest 對象上觸發事件來和調用程序進行通信。

          常用異步 API 如下:

          在 16 年曾基于 IndexDB 做過一整套緩存策略,有不錯的優化效果:

          Service Worker

          SW 從 2014 年提出的草案到現在已經發展很成熟了,基于 SW 做離線緩存,讓用戶能夠進行離線體驗,消息推送體驗,離線緩存能力涉及到 Cache 和 CacheStorage 的概念,篇幅有限,不展開了。

          LocalStorage

          localStorage 屬性允許你訪問一個 Document 源(origin)的對象 Storage 用于存儲當前源的數據,除非用戶人為清除(調用 localStorage api 或者清除瀏覽器數據), 否則存儲在 localStorage 的數據將被長期保留。

          SessionStorage

          sessionStorage 屬性允許你訪問一個 session Storage 對象,用于存儲當前會話的數據,存儲在 sessionStorage 里面的數據在頁面會話結束時會被清除。頁面會話在瀏覽器打開期間一直保持,并且重新加載或恢復頁面仍會保持原來的頁面會話。

          定義最優緩存策略

          • 使用一致的網址:如果您在不同的網址上提供相同的內容,將會多次獲取和存儲該內容。注意:URL 區分大小寫!
          • 確定中繼緩存可以緩存哪些資源:對所有用戶的響應完全相同的資源很適合由 CDN 或其他中繼緩存進行緩存;
          • 確定每個資源的最優緩存周期:不同的資源可能有不同的更新要求。審查并確定每個資源適合的 max-age;
          • 確定網站的最佳緩存層級:對 HTML 文檔組合使用包含內容特征碼的資源網址以及短時間或 no-cache 的生命周期,可以控制客戶端獲取更新的速度;
          • 更新最小化:有些資源的更新比其他資源頻繁。如果資源的特定部分(例如 JS 函數或一組 CSS 樣式)會經常更新,應考慮將其代碼作為單獨的文件提供。這樣,每次獲取更新時,剩余內容(例如不會頻繁更新的庫代碼)可以從緩存中獲取,確保下載的內容量最少;
          • 確保服務器配置或移除 ETag:因為 Etag 跟服務器配置有關,每臺服務器的 Etag 都是不同的;
          • 善用 HTML5 的緩存機制:合理設計啟用 LocalStorage、SessionStorage、IndexDB、SW 等存儲,會給頁面性能帶來明顯提升;
          • 結合 Native 的強大存儲能力:善于利用客戶端能力,定制合適的緩存機制,打造極致體驗。

          結語

          通過了解瀏覽器各種緩存機制和存儲能力特點,結合業務制定合適的緩存策略,善用緩存是基本功,可以用于時常審查負責的業務,可能就會發現個別業務并沒有運用到位,共勉。


          主站蜘蛛池模板: 一区二区三区视频| 冲田杏梨高清无一区二区| 精品国产亚洲一区二区三区在线观看| 美女免费视频一区二区三区| 亚洲AV无码一区二区二三区入口| 国产一区二区三区视频在线观看| 99精品一区二区三区无码吞精| 中文字幕永久一区二区三区在线观看| 亚洲一区二区三区在线观看网站| 久久免费精品一区二区| 国产观看精品一区二区三区| 色噜噜一区二区三区| 国产一区二区视频免费| 成人欧美一区二区三区在线视频 | av一区二区三区人妻少妇| 色窝窝无码一区二区三区| 久久久精品一区二区三区| 中文字幕一区二区人妻| 成人影片一区免费观看| 精品一区二区三区四区在线| 久久99久久无码毛片一区二区| 精品乱码一区二区三区在线| 黑人一区二区三区中文字幕| 日本一区二区三区在线视频 | 无码国产精品一区二区免费I6| 国产精品视频一区二区三区| 无码乱码av天堂一区二区| 国产精品久久一区二区三区| 精品无码人妻一区二区三区18| 暖暖免费高清日本一区二区三区| 人妻夜夜爽天天爽一区| 国产精品日韩一区二区三区| 美女免费视频一区二区三区| 国产一区三区三区| 日韩亚洲一区二区三区| 亚洲欧美日韩一区二区三区在线| 狠狠综合久久av一区二区| 内射白浆一区二区在线观看 | 日韩av无码一区二区三区| 国产精品合集一区二区三区 | 另类一区二区三区|