❶ 關於瀏覽器緩存
首先瀏覽器緩存分為 內存緩存 和 文件緩存 。
內存緩存是瀏覽器自己控制的，不受 Cache-Control 影響，跟計算機內存空間大小有關，並且關閉瀏覽器就會消失。
文件緩存 就是我們常說的瀏覽器緩存。
文件緩存分為2種： 強制緩存 和 協商緩存 。
強制緩存 就是通過Header上配置Cache-Control:public,max-age=300這種形式實現的，Cache-Control可以客戶端在請求Header配置，也可以服務端在響應Header配置。
強制緩存 比較適合用在變化頻率比較低的文件上，比如圖片，js，css都可以，通常我們都使用這種緩存再配合文件hash後綴實現緩存文件的即時更新。
協商緩存 是一種服務端控制文件緩存的策略，機制是服務端會根據最新更改時間和文件標識判斷響應的時候是否要返回內容。雖然每次都會向服務端發起請求，但是如果服務端確定緩存，會返回很少響應內容。
這種方式比較適合需要頻繁更新的文件，需要配合Cache-Control:no-cache阻止強制緩存。另外html不要配置強制緩存，通常我們請求的html文件地址不會加hash。
協商緩存 主要通過2組Header標簽讓客戶端與服務端確認來達成：首先服務端在響應的時候會加上 Last-Modified 和 Etag ，前者表示文件最後更新時間，後者表示文件唯一標識；然後客戶端再次請求的時候會帶上 If-Modified-Since 和 If-None-Match ，值分別跟服務端的 Last-Modified 和 Etag 一致。
參考：
瀏覽器緩存
❷ ☆前端優化：瀏覽器緩存技術介紹
在前端開發中，性能一直都是被大家所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。 其中提高網頁反應速度的一個方式就是使用緩存 。緩存技術一直一來在WEB技術體系中扮演非常重要角色，是快速且有效地提升性能的手段。
一個優秀的緩存策略可以縮短網頁請求資源的距離，減少延遲，並且由於緩存文件可以重復利用，還可以減少帶寬，降低網路負荷。
所以，緩存技術是無數WEB開發從業人員在工作過程中不可避免的一大問題。 在產品開發的時候我們總是想辦法避免緩存產生，而在產品發布之時又在想策略管理緩存提升網頁的訪問速度 。了解瀏覽器的緩存命中原理，是開發WEB應用的基礎，本文著眼於此，學習瀏覽器緩存的相關知識，總結緩存避免和緩存管理的方法，結合具體的場景說明緩存的相關問題。希望能對有需要的人有所幫助。
在實際WEB開發過程中，緩存技術會涉及到不同層、不同端，比如：用戶層、系統層、代理層、前端、後端、服務端等， 每一層的緩存目標都是一致的，就是盡快返回請求數據、減少延遲 ，但每層使用的技術實現是各有不同，面對不同層、不同端的優劣，選用不同的技術來提升系統響應效率。所以，我們首先看下各層的緩存都有哪些技術，都緩存哪些數據，從整體上，對WEB的緩存技術進行了解，如下圖所示：
本篇文章重點講的就是上面紅色框部分緩存內容。
當瀏覽器請求一個網站的時候，會載入各種各樣的資源，比如：HTML文檔、圖片、CSS和JS等文件。對於一些不經常變的內容，瀏覽器會將他們保存在本地的文件中，下次訪問相同網站的時候，直接載入這些資源，加速訪問。
那麼如何知曉瀏覽器是讀取了緩存還是直接請求伺服器？如下圖網站來做個示例：
第一次打開該網站後，如果再次刷新頁面。會發現瀏覽器載入的眾多資源中，有一部分size有具體數值，然而還有一部分請求，比如圖片、css和js等文件並沒有顯示文件大小，而是顯示了 from dis cache 或者 from memory cache 字樣。這就說明了，該資源直接從本地硬碟或者瀏覽器內存讀取，而並沒有請求伺服器。
瀏覽器啟用緩存至少有兩點顯而易見的好處： （1）減少頁面載入時間；（2）減少伺服器負載；
瀏覽器是否使用緩存、緩存多久，是由伺服器控制的 。准確來說，當瀏覽器請求一個網頁（或者其他資源）時， 伺服器發回的響應的「響應頭」部分的某些欄位指明了有關緩存的關鍵信息 。下面看下，HTTP報文中與緩存相關的首部欄位：
根據上面四種類型的首部欄位不同使用策略， 瀏覽器中緩存可分為強緩存和協商緩存 ：
當瀏覽器對某個資源的請求命中了強緩存時， 返回的HTTP狀態為200 ，在chrome的開發者工具的network裡面 size會顯示為from cache ，比如：京東的首頁里就有很多靜態資源配置了強緩存，用chrome打開幾次，再用f12查看network，可以看到有不少請求就是從緩存中載入的：
Expires是HTTP 1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由伺服器返回，用GMT格式的字元串表示 ，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了Expires頭標簽的文件，就說明瀏覽器對於該文件緩存具有非常大的控制權。
例如，一個文件的Expires值是2020年的1月1日，那麼就代表，在2020年1月1日之前，瀏覽器都可以直接使用該文件的本地緩存文件，而不必去伺服器再次請求該文件，哪怕伺服器文件發生了變化。
所以， Expires是優化中最理想的情況，因為它根本不會產生請求 ，所以後端也就無需考慮查詢快慢。它的緩存原理，如下：
Expires是較老的強緩存管理header， 由於它是伺服器返回的一個絕對時間 ，在伺服器時間與客戶端時間相差較大時，緩存管理容易出現問題， 比如：隨意修改下客戶端時間，就能影響緩存命中的結果 。所以在HTTP 1.1的時候，提出了一個新的header， 就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒為單位，用數值表示 ，如：Cache-Control:max-age=315360000，它的緩存原理是：
Cache-Control描述的是一個相對時間 ，在進行緩存命中的時候， 都是利用客戶端時間進行判斷 ，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。
這兩個header可以只啟用一個，也可以同時啟用， 當response header中，Expires和Cache-Control同時存在時，Cache-Control優先順序高於Expires ：
此外，還可以為 Cache-Control 指定 public 或 private 標記。 如果使用 private，則表示該資源僅僅屬於發出請求的最終用戶，這將禁止中間伺服器（如代理伺服器）緩存此類資源 。對於包含用戶個人信息的文件（如一個包含用戶名的 HTML 文檔），可以設置 private，一方面由於這些緩存對其他用戶來說沒有任何意義，另一方面用戶可能不希望相關文件儲存在不受信任的伺服器上。需要指出的是，private 並不會使得緩存更加安全，它同樣會傳給中間伺服器（如果網站對於傳輸的安全性要求很高，應該使用傳輸層安全措施）。 對於 public，則允許所有伺服器緩存該資源 。通常情況下，對於所有人都可以訪問的資源（例如網站的 logo、圖片、腳本等）， Cache-Control 默認設為 public 是合理的 。
當瀏覽器對某個資源的請求沒有命中強緩存， 就會發一個請求到伺服器，驗證協商緩存是否命中，如果協商緩存命中，請求響應返回的http狀態為304並且會顯示一個Not Modified的字元串 ，比如你打開京東的首頁，按f12打開開發者工具，再按f5刷新頁面，查看network，可以看到有不少請求就是命中了協商緩存的：
查看單個請求的Response Header， 也能看到304的狀態碼和Not Modified的字元串，只要看到這個就可說明這個資源是命中了協商緩存，然後從客戶端緩存中載入的 ，而不是伺服器最新的資源：
【Last-Modified，If-Modified-Since】的控制緩存的原理，如下 ：
【Last-Modified，If-Modified-Since】都是根據伺服器時間返回的header，一般來說， 在沒有調整伺服器時間和篡改客戶端緩存的情況下，這兩個header配合起來管理協商緩存是非常可靠的，但是有時候也會伺服器上資源其實有變化，但是最後修改時間卻沒有變化的情況 ，而這種問題又很不容易被定位出來，而當這種情況出現的時候，就會影響協商緩存的可靠性。 所以就有了另外一對header來管理協商緩存，這對header就是【ETag、If-None-Match】 。它們的緩存管理的方式是：
Etag和Last-Modified非常相似，都是用來判斷一個參數，從而決定是否啟用緩存。 但是ETag相對於Last-Modified也有其優勢，可以更加准確的判斷文件內容是否被修改 ，從而在實際操作中實用程度也更高。
協商緩存跟強緩存不一樣，強緩存不發請求到伺服器， 所以有時候資源更新了瀏覽器還不知道，但是協商緩存會發請求到伺服器 ，所以資源是否更新，伺服器肯定知道。大部分web伺服器都默認開啟協商緩存，而且是同時啟用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如apache:
如果沒有協商緩存，每個到伺服器的請求，就都得返回資源內容，這樣伺服器的性能會極差。
【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同時啟用，這是為了處理Last-Modified不可靠的情況。有一種場景需要注意：
比如，京東頁面的資源請求，返回的repsonse header就只有Last-Modified，沒有ETag：
協商緩存需要配合強緩存使用，上面這個截圖中，除了Last-Modified這個header，還有強緩存的相關header， 因為如果不啟用強緩存的話，協商緩存根本沒有意義 。
如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到伺服器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從伺服器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，如下：
❸ 前端瀏覽器緩存機制
在前端開發中，性能是一個永恆的話題，沒有最好，只有更好。判斷一個網站性能好壞，一個直入眼觀的即是網頁的反應速度，有一個方式就是使用緩存，一個優秀的緩存策略可以縮短網頁請求的時間，減少延遲，並且網頁可以重復利用，還可以減少帶寬，降低網路負荷。
1： 為什麼需要緩存？
a：緩存可以減少用戶等待時間，提升用戶體驗
b：減少網路帶寬消耗
c：降低伺服器壓力
Note：緩存使用不當，也會造成『臟數據』問題
2：常見的緩存類型
強緩存 -
Expires伺服器端設置，表示該資源的過期時間，會有弊端，客戶端時間和伺服器時間不一致的問題。
Cache-Control：max-age表示緩存資源的最大生命周期，單位是秒
所以Expires 結合 Cache-Control 一起使用，大型網站中一般比較適用
協商緩存-
Last-Modified：值為資源的最後更新時間，隨伺服器response返回
If-Modified-Since：通過比較兩個時間來判斷資源在兩次請求期間是否有過修改，如果沒有，則命中協商緩存
Etag：表示資源內容的唯一標識，即資源的消息摘要
If-None-Match：伺服器通過比較請求頭中的If-None-Match與當前資源的Etag是否一致來判斷資源是否在兩次請求期間有過修改
3：緩存流程圖示：
a：瀏覽器會先檢測強緩存類型（Cache-Control 或者 Expires）是否有效；命中直接瀏覽器本地獲取緩存資源
b：未命中。伺服器會根據請求頭Request Header驗證這個資源是否命中協商緩存，稱之為HTTP二次驗證，命中，伺服器返回請求，但返回資源，而是告訴客戶端直接中直接從瀏覽器緩存中獲取
Note：
1.強緩存不會發生請求，協商緩存存在伺服器請求
2.當協商緩存也未命中時，則伺服器會將資源發送到客戶端
3.F5刷新頁面，會跳過強緩存
4.Ctrl+F5刷新頁面，跳過強緩存和協商緩存
5.不會緩存的情況
HTTPS POST請求 根據Cookie獲取認證信息 Request Header Cache-Control：no-cache， max-age=0
6.小故事大道理
上文對整個概念做了闡述，還是不夠形象，我們來通過幾個小故事生動理解一下：
故事一：Last-Modified
瀏覽器：Hi，我需要 jartto.min.js 這個文件，如果是在 Last-Modified: Fri Feb 15 2019 19:57:31 GMT 之後修改過的，請發給我。
伺服器：（檢查文件的修改時間）
伺服器：Oh，這個文件在那個時間之後沒有被修改過，你已經有最新的版本了。
瀏覽器：太好了，那我就顯示給用戶了。
故事二：ETag
瀏覽器：Hi，我需要 jartto.css 這個文件，有沒有不匹配 3c61f-1c1-2aecb436 這個串的
伺服器：（檢查 ETag…）
伺服器：Hey，我這里的版本也是 3c61f-1c1-2aecb436，你已經是最新的版本了
瀏覽器：好，那就可以使用本地緩存了
❹ 前端HTTP緩存
在面試的時候總是遇到緩存相關問題，回答總是停留緩存就是從瀏覽器中獲取，不向伺服器發送請求，回答的不讓面試官滿意，索性抽點時間整理一下前端相關的緩存，希望下次回答的時候能夠多講點。
前端緩存分為 強緩存 和 協商緩存 ，強緩存就是在緩存未失效時，不在請求服務端，協商緩存就是去跟伺服器比較是否需要重新獲取資源 。
強緩存分為兩種， Cache-control 和 Expires ， Expires 是HTTP1.0的東西，它的值是一個格林時間，比如 Expires: Wed, 21 Oct 2015 07:28:00 GMT ，由於伺服器端和瀏覽器端的時間差異問題，瀏覽器比伺服器時間快，會導致緩存失效。 Cache-control 是HTTP1.1時代的新東西，設置的是一個相對時間， Cache-Control:public, max-age=31536000 ，在31536000秒後才緩存才失效， Cache-control 有很多取值。
強緩存在緩存失效內，不會從原始伺服器獲取新的數據，假如在緩存時段內伺服器有資源更新，會導致資源獲取不及時。
協商緩存有兩組報文
❺ 瀏覽器緩存機制簡單概括和分析
對於訪問的頁面和請求，為了縮短網頁請求資源的距離，減少延遲，並且由於緩存文件可以重復利用，還可以減少帶寬，降低網路負荷，瀏覽器和伺服器都有可能會對請求資源進行緩存，接下來的文章就簡單介紹和分析瀏覽器的緩存機制。
深入理解瀏覽器的緩存機制： https://www.jianshu.com/p/54cc04190252
這篇文章已經有詳細的講解，這里就概括一下：
以首頁的請求為例：
1、強制緩存策略(Expires和Cache-Control) ：當瀏覽器發起http請求的時候，如果配置了緩存策略且緩存在有效期內，會直接使用瀏覽器緩存。 不使用強制緩存 （ Cache-Control=no-chache， 或者 max-age=0 ）
（1）、圖中請求伺服器：是 max-age=0 的情況，瀏覽器直接請求伺服器資源，而不是用本地緩存
（2）、圖中磁碟緩存和內存緩存：就是瀏覽器使用了本地緩存而不再請求伺服器資源
2、協商緩存策略（Last-Modified和If-Modified-Since， ETag和If-None-Match）： 當瀏覽器發起http請求的時候，如果 強制緩存策略 失效，或者者禁用了強制緩存，這時候會根據 If-Modified-Since 中的值與伺服器中這個資源的最後修改時間對比，如果沒有變化，返回304和空的響應體，直接從緩存讀取，如果If-Modified-Since的時間小於伺服器中這個資源的最後修改時間，說明文件有更新，於是返回新的資源文件和200。
不使用協商緩存 （ Cache-Control=no-store ），這個參數同時也會 禁用強制緩存。
（1）、伺服器資源返回無更新，瀏覽器使用上次請求的資源
（2）、伺服器資源有更新，返回200並返回最新的資源
3、不使用緩存策略（Cache-Control=no-store）： 所有內容都不會被緩存，即不使用強制緩存，也不使用協商緩存。當response head 設置了no-store，瀏覽器不會對返回的資源做緩存，每次請求都是直接請求伺服器。這可以保證瀏覽器每次都能拿最新的資源，即使資源對比上次請求沒有任何更新，但同時也降低了頁面的響應速度，和增加了網路的IO與伺服器的壓力。
可以明顯的看到請求時間，請求伺服器資源時間 >> 請求磁碟緩存 > 請求內存緩存，所以合適的緩存策略，可以在不影響業務的情況下，極大地提升客戶體驗和後台伺服器壓力。
❻ 瀏覽器緩存及刷新
1、伺服器開啟Cache-Control緩存控制（優先順序更高）
（相對時間，在這個時間之前不會和伺服器通信，本地拿過來直接用）
Cache-Control:max-age=3600，這里是3600秒過期，過期前不會和伺服器通信，直接用本地緩存
Cache-Control:no-cache，不使用本地緩存
2、伺服器開啟Expires（過期時間，絕對時間）
Expires:Thu,21 Jan 2017 23:39:02 GMT
1、Last-Modified（伺服器返回此文件最肢搏後修改時間）
If-Modified-Since（客戶端第二次請求該資源帶著上跡信次伺服器返回的此文件最後修改時間，比對是否相同）
2、Etag（優先順序更高）（第一次請求資源伺服器返回一個Etag值）
If-None-Match（第二次請求資源客戶端帶著之歷州祥前的Etag值給伺服器進行比對）
如果多個參數同事存在時：
強緩存優先順序更高，而在強緩存中，Cache-Control比Expires優先順序高
協商緩存中，Etag比Last-Modified優先順序高
1、正常操作：地址欄輸入url，跳轉鏈接，前進後退等
2、手動刷新：F5，點擊刷新按鈕，右鍵菜單刷新
3、強制刷新：ctrl+F5
1、正常操作：強制緩存有效，協商緩存有效
2、手動刷新：強制緩存失效，協商緩存有效
3、強制刷新：強制緩存失效，協商緩存失效
❼ 瀏覽器緩存和伺服器緩存
一、瀏覽器緩存
瀏覽器緩存即http緩存；瀏覽器緩存根據是否需要向伺服器重新發起HTTP請求將緩存過程分為兩個部分，分別是 強制緩存 和 協商緩存 。
瀏覽器第一次請求資源的時候伺服器會告訴客戶端是否應該緩存資源，根據響應報文中HTTP頭的緩存標識，決定是否緩存結果，是則將請求結果和緩存標識存入瀏覽器緩存中。如下圖：
1.強制緩存 ：瀏覽器會對緩存進行查找，並根據一定的規則確定是否使用緩存。
強制緩存的緩存規則？
HTTP/1.0 Expires 這個欄位是絕對時間，比如2018年6月30日12:30，然後在這個時間點之前的請求都會使用瀏覽器緩存，除非清除了緩存。
這個欄位的缺點就是只會同步客戶端的時間，這就有可能修改客戶端時間導致緩存失效。
HTTP/1.1 cache-Control 這個是1.1的時候替換Expires的，它會有幾種取值：
public ：所有內容都將被緩存（客戶端和代理伺服器都可緩存）
private ：所有內容只有客戶端可以緩存， Cache-Control的默認取值
no-cache ：客戶端緩存內容，但是是否使用緩存則需要經過協商緩存來驗證決定
no-store ：所有內容都不會被緩存，即不使用強制緩存，也不使用協商緩存
max-age=xxx (xxx is numeric) ：緩存內容將在xxx秒後失效
比如max-age=500，則在500秒內再次請求會直接只用緩存。
優先性：cache-Control > Expires
如果同時存在，cache-Control會覆蓋Expires。
這個欄位的缺點就是：
如果資源更新的速度是秒以下單位，那麼該緩存是不能被使用的，因為它的時間單位最低是秒。
如果文件是通過伺服器動態生成的，那麼該方法的更新時間永遠是生成的時間，盡管文件可能沒有變化，所以起不到緩存的作用。
上圖中瀏覽器緩存中存在該資源的緩存結果，並且沒有失效，就會直接使用緩存的內容。
上圖中瀏覽器緩存中沒有該資源的緩存結果和標識，就會直接向伺服器發起HTTP請求。
2.協商緩存： 瀏覽器的強制緩存失效後(時間過期)，瀏覽器攜帶緩存標識請求伺服器，由伺服器決定是否使用緩存。
伺服器決定的規則？
控制協商緩存的欄位有 Last-Modified / If-Modified-Since 和 Etag / If-None-Match。
①Last-Modified 是伺服器返回給瀏覽器的本資源的最後修改時間。
當下次再次請求的時候，瀏覽器會在請求頭中帶 If-Modified-Since ,即上次請求下來的 Last-Modified 的值，
然後伺服器會用這個值和該資源最後修改的時間比較，如果最後修改時間大於這個值，則會重新請求該資源，返回狀態碼200。
如果這個值和最後修改時間相等，則會返回304，告訴瀏覽器繼續使用緩存。
② Etag 是伺服器返回的一個hash值。
當下次再次請求的時候，瀏覽器會在請求頭中帶 If-None-Match ,即上次請求下來的 Etag 值，
然後伺服器會用這個值和該資源在伺服器的 Etag 值比較，如果一致則會返回304，繼續使用緩存；如果不一致，則會重新請求，返回200。
二、伺服器緩存
上面是一個簡單的流程圖：
用戶1訪問A頁面，伺服器解析A頁面返回給用戶1，同時在伺服器內存上做一定映射，把A頁面緩存在硬碟上面
用戶2訪問A頁面，伺服器直接根據內存上的映射找到對應的頁面緩存，直接返回給用戶2，這樣就減少了伺服器對同一頁面的重復解析
伺服器緩存和瀏覽器緩存的區別：
伺服器緩存是把頁面緩存到伺服器上的硬碟里，而瀏覽器緩存是把頁面緩存到用戶自己的電腦里
Nginx伺服器
Nginx是一個高性能的HTTP和反向代理伺服器。具有非常多的優越性：
在連接高並發的情況下，Nginx是Apache伺服器不錯的替代品，Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟體平台之一。
Nginx提供了expires、etag、if-modified-since指令來實現瀏覽器緩存控制。
nginx -s reload#重新載入配置文件
nginx -s reopen#重新打開log文件
nginx -s stop#快速關閉nginx服務
nginx -s quit #優雅的關閉nginx服務，等待工作進程處理完所有的請求
Nginx設置靜態文件的緩存過期時間
location ~.*\.(js|css|html|png|jpg)$ {
expires 3d;
}
expires 3d;//表示緩存3天
expires 3h;//表示緩存3小時
expires max;//表示緩存10年
expires -1;//表示永遠過期。
如果設置為-1在js、css等靜態文件在沒有修改的情況下返回的是http 304，如果修改返回http 200
對於靜態資源會自動添加ETag，可以通過添加etag off指令禁止生成ETag。如果是靜態文件，那麼Last-Modified值為文件的最後修改時間。
在開發調試web的時候，經常會碰到因瀏覽器緩存(cache)而經常要去清空緩存或者強制刷新來測試的煩惱，提供下apache不緩存配置和nginx不緩存配置的設置。在常用的緩存設置裡面有兩種方式，都是使用add_header來設置：分別為Cache-Control和Pragma。
location ~ .*\.(css|js|swf|php|htm|html )$ {
add_header Cache-Control no-store;
add_header Pragma no-cache;
}
nginx gzip壓縮
使用 gzip 壓縮可以降低網站帶寬消耗，同時提升訪問速度。
主要在nginx服務端將頁面進行壓縮，然後在瀏覽器端進行解壓和解析，
目前大多數流行的瀏覽器都遲滯gzip格式的壓縮，所以不用擔心。
默認情況下，Nginx的gzip壓縮是關閉的，同時，Nginx默認只對text/html進行壓縮
gzip on;
ersio #開啟gzip壓縮輸出
gzip_http_vn 1.0 ;#默認1.1
#其中的gzip_http_version的設置，它的默認值是1.1，就是說對HTTP/1.1協議的請求才會進行gzip壓縮
#如果我們使用了proxy_pass進行反向代理，那麼nginx和後端的upstream server之間是用HTTP/1.0協議通信的。
gzip_vary on ;
#和http頭有關系，加個vary頭，給代理伺服器用的，有的瀏覽器支持壓縮，有的不支持，
#所以避免浪費不支持的也壓縮，所以根據客戶端的HTTP頭來判斷，是否需要壓縮
gzip_comp_level 6;
#設置gzip壓縮等級，等級越底壓縮速度越快文件壓縮比越小，反之速度越慢文件壓縮比越大 1-9
gzip_proxied any;
#Ngnix作為反向代理的時候啟用
#expample:gzip_proxied no-cache;
# off – 關閉所有的代理結果數據壓縮
# expired – 啟用壓縮，如果header中包含」Expires」頭信息
# no-cache – 啟用壓縮，如果header中包含」Cache-Control:no-cache」頭信息
# no-store – 啟用壓縮，如果header中包含」Cache-Control:no-store」頭信息
# private – 啟用壓縮，如果header中包含」Cache-Control:private」頭信息
# no_last_modified – 啟用壓縮，如果header中包含」Last_Modified」頭信息
# no_etag – 啟用壓縮，如果header中包含「ETag」頭信息
# auth – 啟用壓縮，如果header中包含「Authorization」頭信息
# any – 無條件壓縮所有結果數據
gzip_types text/html ;#壓縮的文件類型
#設置需要壓縮的MIME類型,非設置值不進行壓縮
#param:text/html|application/x-javascript|text/css|application/xml
gzip_buffers 16 8k; #設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間
#設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間
# param1:int 增加的倍數
# param2:int(k) 後面單位是k
# example: gzip_buffers 4 8k;
# Disable gzip for certain browsers.
gzip_disable 「MSIE [1-6].(?!.*SV1)」; #ie6不支持gzip，需要禁用掉ie6
❽ 瀏覽器緩存策略
瀏覽器緩存策略分為兩種 強緩存 （本地緩存） 和 協商緩存 （弱緩存）。
瀏覽器在發請求前，先檢查強緩存，若沒有需要的內容（未命中），則發起請求判斷是否需要用弱緩存。
強緩存 是不發起請求，直接使用緩存內的內容的。瀏覽器將 js 、 css 、 image 、 font-family 等存到內存(存小文件)或者磁碟（存大文件）中，下次用戶再訪問的時候就從內存中取，以便提升性能。
協商緩存 需要往後台發請求， 通過判斷來決定是使用協商緩存。如果請求內容沒發生變化，則請求返回304（伺服器收到請求，但內容無變化），瀏覽器就用緩存內的內容。
如果伺服器返回的響應標頭中包含 Expires (時間戳)，那麼客戶端發起請求的時間在 Expires 之前的話，就觸發強緩存。
伺服器在上一次響應請求時，返回一個帶 Last-Modified 的響應頭，值為一個時間戳，表示該資源最後一次在伺服器修改的時間。當客戶端再一次請求這個資源的時候， 請求頭就會帶上 If-Modified-Since ，值為上次伺服器發來的 Last-Modified ， 伺服器收到後，就和該資源最後修改時間比對， 沒變化就返回304， 觸發協商緩存。
弊端 ： 時間間隔最小為1s，如果請求的資源在1s內發生了改變，是可能會觸發協商緩存的， 導致無法獲取到最新的資源。
為解決間隔最小1s的問題， If-None-Match 和 Etag 就誕生了。 Etag 是由伺服器世孫廳生成的， 是每個資源搜隱的唯一標識字元串， 隨資源變化而改變。 判斷過程和http1.0的一致，請求的時候攜帶 If-None-Match ，然後伺服器比較這兩個值，沒變化就返回304， 觸發協商緩存。
弊端凱銷 ： 佔用伺服器資源較多， 雖然准確度高，但是性能上不如 Last-Modified & If-Modified-Since 的方法。不過實際的影響不會很大， 基本上可以忽略不計。
即便我們沒有配置緩存策略，瀏覽器也會採用自己的演算法來緩存資源。
❾ 緩存是什麼 深入解析網頁緩存機制
緩存是指在計算機系統中，將數據暫時存儲在高速緩存中，以提高數據訪問速度的一種技術。在網頁瀏覽器中，也存在著網頁緩存機制，它可以使用戶在訪問同一網頁時，不必每次都從伺服器重新獲取數據，而是從本地緩存中讀取數據，從而提高網頁的訪問速度。
緩存是指在計算機系統中，將數據暫時存儲在高速緩存中，以提高數據訪問速度的一種技術。在網頁瀏覽器中，也存在著網頁緩存機制，它可以使用戶在訪問同一網頁時，不必每次都從伺服器重新獲取數據，而是從本地緩存中讀取數據，從而提高網頁的訪問速度。
協商緩存是指在第一次訪問網頁時，伺服器返回的響應頭中包含了緩存標識，瀏覽器會將該網頁緩存在本地，並在下次訪問時將該緩存標識發送給伺服器，詢問伺服器該網頁是否有更新。如果伺服器返回的響應頭中包含了「304 Not Modified」配咐的狀培森純態碼，則表示該網頁沒有更新，瀏覽器會直接從本地緩存中讀取數據，否則就從伺服器上重新獲取數據。
網頁緩存是指將已經訪問過的網頁內容保存在用戶的本地存儲中，以便下次訪問時可以更快速地載入頁面。當用戶訪問一個網頁時，瀏覽器會首先查看本地緩存中是否存在該網頁的春枝副本，如果存在，則直接從緩存中讀取，否則就從伺服器上重新獲取數據。
強制緩存是指在第一次訪問網頁時，伺服器返回的響應頭中包含了緩存時間，瀏覽器會將該網頁緩存在本地，並在緩存時間內不會向伺服器發送請求。當緩存時間過期後，瀏覽器會再次向伺服器發送請求，重新獲取數據。
緩存是指在計算機系統中，將數據暫時存儲在高速緩存中，以提高數據訪問速度的一種技術。在網頁瀏覽器中，也存在著網頁緩存機制，它可以使用戶在訪問同一網頁時，不必每次都從伺服器重新獲取數據，而是從本地緩存中讀取數據，從而提高網頁的訪問速度。
❿ 什麼是瀏覽器緩存
什麼是瀏覽器緩存
瀏覽器緩存(BrowerCaching)是瀏覽器在本地磁碟對用戶最近請求過的文檔進行存儲，當訪問者再次訪問同一頁面時，瀏覽器就可以直接從本地磁碟載入文檔。
瀏覽器緩存的優點有：
減少了冗餘的數據傳輸，節省了網費
減少了伺服器的負擔，大大提升了網站的性能
加快了客戶端載入網頁的速度
在前端開發面試中，瀏覽器緩存是web性能優化面試題中很重要的一個知識點，從而說明瀏覽器緩存是提升web性能的一大利器，但是瀏覽器緩存如果使用不當，也會產生很多問題，正所謂是，想說愛你，並不是很容易的事。所以，結合最近遇到的案例，本文對瀏覽器緩存相關的悉兄知識進行總結歸納，希望對讀者睜逗襲有所幫助。
瀏覽器緩存的分類
瀏覽器緩存主要有兩類：緩存協商和徹底緩存，也有稱之為協商緩存和強緩存。
瀏覽器在第一次請求發生後，再次請求時：
瀏覽器會先獲取該資源緩存的header信息，根據其中的expires和cahe-control判斷是否命中強緩存，若命中則直接從緩存中獲取資源，包括緩存的header信息，本次請求不會與伺服器進行通信;
如果沒有命中強緩存，瀏覽器會發送請求到伺服器，該請求會攜帶第一次請求返回的有關緩存的header欄位信息(Last-Modified/IF-Modified-Since、Etag/IF-None-Match),由伺服器根據請求中的相關header信息來對比結果是否命中協商緩存，若命中，則伺服器返回新的響應header信息更新緩存中的對應header信息，但是並不返回資源內容，它會告知瀏覽器可以直接從緩存獲取;否則返回最新的資源內容
強緩存
強緩存是利用http的返回頭中的Expires或者Cache-Control兩個欄位來控制的，用來表示資源的緩存時間。
Expires
該欄位是http1.0時的規范，它的值為一個絕對時間的GMT格式的時間字元串，比如Expires:Mon,18Oct206623:59:59GMT。這個時間代表著這個資源的失效時間，在此時間之前，北京電腦培訓建議指伏即命中緩存。這種方式有一個明顯的缺點，由於失效時間是一個絕對時間，所以當伺服器與客戶端時間偏差較大時，就會導致緩存混亂。