在webkaka的網站速度診斷效能優化裡有一項叫指定“Vary:Accept-Encoding”標頭，可能很多人不太明白這是什麼意思，不知道它對網站的影響有多大，不知道如何進行優化，為此，本文將給大家闡述下“Vary:Accept-Encoding”標頭的意義以及設定方法。

指定“Vary:Accept-Encoding”標頭

      指定“Vary: Accept-Encoding”標頭的意義

      指定“Vary: Accept-Encoding”標頭，用一句話來說明它的意義，就是“告訴代理伺服器快取兩種版本的資源：壓縮和非壓縮，這有助於避免一些公共代理不能正確地檢測Content-Encoding標頭的問題。”不過我想很多人都不理解這句話是什麼意思，所以需要更詳細的解釋。

      先來看看下面這幅圖：

網頁從請求到響應的過程

      這個圖顯示了一個網頁從請求到響應的過程。正常情況下，“Response”的結果是可讀文字，但並不是所有的伺服器端都返回這樣的正常的結果到使用者端，有的返回一堆亂碼，這顯然是不正常的。

      當瀏覽器發出一個請求時，會包含一些HTTP頭資訊，伺服器會根據這些頭資訊決定返回什麼樣的東西（這是一個移動客戶端嗎？它能否處理壓縮內容？它是否需要特定的語言支援？）。

      直接訪問是好的，但現在網路使用了中間快取記憶體（cache）和內容分發網路（CDN）。這就產生了一個問題，快取如何使用頭資訊決定返回什麼？它能否複製伺服器端的決策邏輯？

      “Vary”解決了這個問題，“Vary”頭描述什麼資訊“唯一地”標識一個請求——傳入的請求只有完全匹配快取的“Vary”資訊，快取才被使用。

      假如沒有“Vary”頭，那麼如果由於某種原因，客戶端有一個未壓縮的版本在其快取中的檔案，它會不知道隨後再次要求它的壓縮版本，而不是隻從快取中使用未壓縮的檔案。——這就很好的解釋了“Vary”頭資訊的重要意義。

      設想有兩個客戶，一個使用的舊瀏覽器不支援壓縮，一個使用新的瀏覽器支援壓縮，如果他們都請求同一個網頁，那麼取決於誰先請求，壓縮或非壓縮版本便儲存在CDN上。這樣問題就出現了，舊瀏覽器請求常規網頁但獲得快取的壓縮版本，而新瀏覽器會獲得快取的非壓縮版本但嘗試去“解壓”它。無論哪種方式都是壞訊息。解決方法是，源伺服器回送“Vary: Accept-Encoding”。

      現在的中間CDN會儲存獨立的快取條目，一個是Accept-encoding: gzip ，而如果你沒有傳送header，則儲存另一個。

      標頭“Vary:Accept-Encoding”指定方法

      現在的新瀏覽器都支援壓縮了，因此如果網站啟用了GZip，可以無需再指定“Vary: Accept-Encoding”標頭，不過指定“Vary: Accept-Encoding”標頭會有更高的保險，而它並不需要你額外的開銷，為什麼不指定呢？下面是設定方法：

      Apache/.htaccess

      <IfModule mod_headers.c>
        <FilesMatch ".(js|css|xml|gz|html)$">
          Header append Vary: Accept-Encoding
        </FilesMatch>
      </IfModule>

      Nginx

      gzip_vary on

      IIS

      在web.config里加上如下配置，web.config位置在：%windir%\Microsoft.NET\Framework\.net版本號\CONFIG\Web.config 。

      <system.webServer>
        <httpProtocol>
          <customHeaders>
          <remove name="Vary"></remove>
          <add name="Vary" value="Accept-Encoding"></add>
          </customHeaders>
        </httpProtocol>
      </system.webServer>

      指定“Vary:Accept-Encoding”標頭，網站需要啟用GZip，才變得有意義。網站如何啟用GZip？可以看看如下的教程：