前端快取最佳實踐

  • 2019 年 10 月 10 日
  • 筆記

前言

快取，這是一個老生常談的話題，也常被作為前端面試的一個知識點。

本文，重點在於探討在實際項目中，如何進行快取的設置，並給出一個較為合理的方案。

強快取和協商快取

在介紹快取的時候，我們習慣將快取分為強快取和協商快取兩種。兩者的主要區別是使用本地快取的時候，是否需要向伺服器驗證本地快取是否依舊有效。顧名思義，協商快取，就是需要和伺服器進行協商，最終確定是否使用本地快取。

兩種快取方案的問題點

強快取

我們知道，強快取主要是通過http請求頭中的Cache-Control和Expire兩個欄位控制。Expire是HTTP1.0標準下的欄位，在這裡我們可以忽略。我們重點來討論的Cache-Control這個欄位。

一般，我們會設置Cache-Control的值為「public, max-age=xxx」，表示在xxx秒內再次訪問該資源，均使用本地的快取，不再向伺服器發起請求。

顯而易見，如果在xxx秒內，伺服器上面的資源更新了，客戶端在沒有強制刷新的情況下，看到的內容還是舊的。如果說你不著急，可以接受這樣的，那是不是完美？然而，很多時候不是你想的那麼簡單的，如果發布新版本的時候，後台介面也同步更新了，那就gg了。有快取的用戶還在使用舊介面，而那個介面已經被後台幹掉了。怎麼辦？

協商快取

協商快取最大的問題就是每次都要向伺服器驗證一下快取的有效性，似乎看起來很省事，不管那麼多，你都要問一下我是否有效。但是，對於一個有追求的碼農，這是不能接受的。每次都去請求伺服器，那要快取還有什麼意義。

最佳實踐

快取的意義就在於減少請求，更多地使用本地的資源，給用戶更好的體驗的同時，也減輕伺服器壓力。所以，最佳實踐，就應該是儘可能命中強快取，同時，能在更新版本的時候讓客戶端的快取失效。

在更新版本之後，如何讓用戶第一時間使用最新的資源文件呢？機智的前端們想出了一個方法，在更新版本的時候，順便把靜態資源的路徑改了，這樣，就相當於第一次訪問這些資源，就不會存在快取的問題了。

偉大的webpack可以讓我們在打包的時候，在文件的命名上帶上hash值。

entry:{      main: path.join(__dirname,'./main.js'),      vendor: ['react', 'antd']  },  output:{      path:path.join(__dirname,'./dist'),      publicPath: '/dist/',      filname: 'bundle.[chunkhash].js'  }

綜上所述，我們可以得出一個較為合理的快取方案：

  • HTML：使用協商快取。
  • CSS&JS&圖片：使用強快取，文件命名帶上hash值。

哈希也有講究

webpack給我們提供了三種哈希值計算方式，分別是hash、chunkhash和contenthash。那麼這三者有什麼區別呢？

  • hash：跟整個項目的構建相關，構建生成的文件hash值都是一樣的，只要項目里有文件更改，整個項目構建的hash值都會更改。
  • chunkhash：根據不同的入口文件(Entry)進行依賴文件解析、構建對應的chunk，生成對應的hash值。
  • contenthash：由文件內容產生的hash值，內容不同產生的contenthash值也不一樣。

顯然，我們是不會使用第一種的。改了一個文件，打包之後，其他文件的hash都變了，快取自然都失效了。這不是我們想要的。

那chunkhash和contenthash的主要應用場景是什麼呢？在實際在項目中，我們一般會把項目中的css都抽離出對應的css文件來加以引用。如果我們使用chunkhash，當我們改了css程式碼之後，會發現css文件hash值改變的同時，js文件的hash值也會改變。這時候，contenthash就派上用場了。

ETag計算

Nginx

Nginx官方默認的ETag計算方式是為"文件最後修改時間16進位-文件長度16進位"。例：ETag：「59e72c84-2404」

Express

Express框架使用了serve-static中間件來配置快取方案，其中，使用了一個叫etag的npm包來實現etag計算。從其源碼可以看出，有兩種計算方式：

  • 方式一：使用文件大小和修改時間
function stattag (stat) {    var mtime = stat.mtime.getTime().toString(16)    var size = stat.size.toString(16)      return '"' + size + '-' + mtime + '"'  }
  • 方式二：使用文件內容的hash值和內容長度
function entitytag (entity) {    if (entity.length === 0) {      // fast-path empty      return '"0-2jmj7l5rSw0yVb/vlWAYkK/YBwk"'    }      // compute hash of entity    var hash = crypto      .createHash('sha1')      .update(entity, 'utf8')      .digest('base64')      .substring(0, 27)      // compute length of entity    var len = typeof entity === 'string'      ? Buffer.byteLength(entity, 'utf8')      : entity.length      return '"' + len.toString(16) + '-' + hash + '"'  }

ETag與Last-Modified誰優先

協商快取，有ETag和Last-Modified兩個欄位。那當這兩個欄位同時存在的時候，會優先以哪個為準呢？

在Express中，使用了fresh這個包來判斷是否是最新的資源。主要源碼如下：

function fresh (reqHeaders, resHeaders) {    // fields    var modifiedSince = reqHeaders['if-modified-since']    var noneMatch = reqHeaders['if-none-match']      // unconditional request    if (!modifiedSince && !noneMatch) {      return false    }      // Always return stale when Cache-Control: no-cache    // to support end-to-end reload requests    // https://tools.ietf.org/html/rfc2616#section-14.9.4    var cacheControl = reqHeaders['cache-control']    if (cacheControl && CACHE_CONTROL_NO_CACHE_REGEXP.test(cacheControl)) {      return false    }      // if-none-match    if (noneMatch && noneMatch !== '*') {      var etag = resHeaders['etag']        if (!etag) {        return false      }        var etagStale = true      var matches = parseTokenList(noneMatch)      for (var i = 0; i < matches.length; i++) {        var match = matches[i]        if (match === etag || match === 'W/' + etag || 'W/' + match === etag) {          etagStale = false          break        }      }        if (etagStale) {        return false      }    }      // if-modified-since    if (modifiedSince) {      var lastModified = resHeaders['last-modified']      var modifiedStale = !lastModified || !(parseHttpDate(lastModified) <= parseHttpDate(modifiedSince))        if (modifiedStale) {        return false      }    }      return true  }

我們可以看到，如果不是強制刷新，而且請求頭帶上了if-modified-since和if-none-match兩個欄位，則先判斷etag，再判斷last-modified。當然，如果你不喜歡這種策略，也可以自己實現一個。

補充：後端需要怎麼設置

上文主要說的是前端如何進行打包，那後端怎麼做呢？我們知道，瀏覽器是根據響應頭的相關欄位來決定快取的方案的。所以，後端的關鍵就在於，根據不同的請求返回對應的快取欄位。以nodejs為例，如果需要瀏覽器強快取，我們可以這樣設置：

res.setHeader('Cache-Control', 'public, max-age=xxx');

如果需要協商快取，則可以這樣設置：

res.setHeader('Cache-Control', 'public, max-age=0');  res.setHeader('Last-Modified', xxx);  res.setHeader('ETag', xxx);

當然，現在已經有很多現成的庫可以讓我們很方便地去配置這些東西。寫了一個簡單的demo，方便有需要的朋友去了解其中的原理，有興趣的可以閱讀源碼

總結

在做前端快取時，我們儘可能設置長時間的強快取，通過文件名加hash的方式來做版本更新。在程式碼分包的時候，應該將一些不常變的公共庫獨立打包出來，使其能夠更持久的快取。

以上，如有錯漏，歡迎指正！

@Author: TDGarden

完

VirMach 便宜 VPS

QNews

QNews