【译】缓存的最佳实践以及max-age的陷阱

摘要：可能会延长这些的寿命假设你有以下的这个缓存了和如果命中了缓存，就从缓存中取，否则发起网络请求如果我们更改了，我们会修改中的版本号，触发的更新。

本文翻译自：https://jakearchibald.com/201...
这是一篇2016年的老文章。作者是Chrome浏览器的开发成员。
本文首发于公众号：符合预期的CoyPan

使用正确的缓存可以带来巨大的页面性能上的收益，节省带宽，减少服务器成本。但是许多网站并没有解决好他们的缓存问题，创造了一个race conditions，导致相互依赖的资源之间失去了同步。

绝大多数缓存的最佳实践，都属于下面两种模式：

Cache-Control: max-age = 31536000

同一个URL对应的内容永不改变

浏览器/CDN 可以缓存这个资源长达一年的时间

被缓存资源的存储时间小于max-age指定的秒数时，该资源可以直接被使用而无需经过服务器。

在这种模式下，你不会去改变特定url下的文件内容，你直接改变url：

每一个URL都包含一个跟随文件内容变换的部分。这个部分可以是版本号，修改日期，或者文件内容的hash值。

大多数服务端框架都有工具可以简单的实现这个需求。Node.js下还有更轻量级的工具能够做到同样的事情，比如gulp-rev.

但是，这种模式不适合诸如文章、博客这样的场景。文章和博客的URL是不会有版本号的，而且他们的内容能够随时修改。说真的，如果我在文章中犯了拼写或者语法错误，那么我需要能够快速、频繁的修改文章内容。

Cache-Control: no-cache

同一个url对应的内容会改变

任何本地缓存的版本都是不可信的，除非服务器校验通过

注意：no-cache并不意味着不缓存，而是使用缓存前必须请求服务端进行检查(或者说叫重新校验)。no-store告诉浏览器，根本不要缓存这个文件。同时，must-revalidate也不是说就『must-revalidate』，而是如果本地资源的缓存时间还没有超过设置的max-age的值，就可以直接使用本地资源，否则必须重新校验。

在这种模式下，你可以在响应头里添加一个ETag（你选择的版本ID）或者Last-Modified。客户端下一次请求资源时，会分别带上If-None-Match和If-Modified-Since，服务端会判断说：直接使用你已有的本地资源吧，他们是最新的。这就是最常见的：HTTP 304

如果没有带上ETag/Last-Modified，服务端会再次返回完成的内容。

这种模式总是会发起一个网络请求，而模式一是可以不用通过网络的。

使用模式一时，因为网络基础建设而导致的延时是很常见的，使用模式二时，也很容易遇到网络环境带来的延迟。取而代之的是中间的东西：一个短时间的max-age设置和可变的内容。这是一种十分糟糕的妥协。

不幸的是，这种做法并非不常见。比如，Github pages就是这样的。

想象一下有以下三个url：

/article/

/styles.css

/scripts.js

服务端都是返回的：

Cache-Control: must-revalidate, max-age=600

url对应的内容是变了

如果浏览器缓存了一个资源版本，但是没有到10分钟，会不经过服务器直接使用这个缓存的资源。

否则发起一个网络请求，带上If-Modified-Since或者If-None-Match(如果可用)

这种模式在测试的时候看起来是可以的，但在现实中，会出问题，并且很难追踪。在上面的例子中，服务端确实已经更新了HTML, CSS 和JS，但是页面最终使用了缓存里的HTML，JS，CSS却是从服务端获取的最新的版本。资源版本不匹配导致了页面出错。

通常情况下，当我们对HTML进行重大更改时，我们还可能更改HTML对应的CSS结构，并更新JS以适应样式和内容的更改。这些资源是相互依赖的，但是缓存的header是无法描述这种依赖的。用户最终看到的，可能是一两个新版本的资源，和其他老的资源。

max-age和响应时间有关，因此，如果上述所有的资源都是在同一次访问中请求的，他们大概会在同一时间到期，但是仍然有很小的可能发生竞争。如果你的某些页面并不包含JS或者包含了不同的CSS，那么过期时间可能就不同步了。更糟糕的是，更糟糕的是，浏览器总是从缓存中删除东西，它不知道HTML、CSS和JS是相互依赖的，所以它会很高兴地删除一个而不是其他的。上述的情况，都可能会导致页面资源的版本不匹配。

对用户来说，他们最终会看到错误的页面布局和错误的页面功能，从细微的错误到完全不可用的内容。

谢天谢地，对用户来说还是有补救措施的。

刷新可能会修复这个问题

如果页面作为刷新的一部分加载，浏览器会忽略max-age，向服务器进行验证。因此，如果用户遭遇了因为max-age而造成的错误，刷新是可以解决问题的。当然，强迫用户这样做会降低信任度，因为这会让你感觉到你的网站是不靠谱的。

service worker可能会延长这些bug的寿命

假设你有以下的service worker:

const version = "2";

self.addEventListener("install", event => {
  event.waitUntil(
    caches.open(`static-${version}`)
      .then(cache => cache.addAll([
        "/styles.css",
        "/script.js"
      ]))
  );
});

self.addEventListener("activate", event => {
  // …delete old caches…
});

self.addEventListener("fetch", event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => response || fetch(event.request))
  );
});

这个service-worker

缓存了script和style

如果命中了缓存，就从缓存中取，否则发起网络请求

如果我们更改了CSS/JS，我们会修改service-worker中的版本号，触发service-worker的更新。但是，假如addAll发出的请求经过了HTTP缓存(和其他大多数缓存一样)，我们也会进入到max-age的race condition，缓存不匹配的CSS、JS版本。

一旦他们被缓存了，我们将会一直看到不匹配的CSS和JS，直到我们下一次更新service-worker。而在下一次更新时，我们可能还会陷入另一个race condition。

你可以在service worker中跳过缓存：

self.addEventListener("install", event => {
  event.waitUntil(
    caches.open(`static-${version}`)
      .then(cache => cache.addAll([
        new Request("/styles.css", { cache: "no-cache" }),
        new Request("/script.js", { cache: "no-cache" })
      ]))
  );
});

不幸的是，这个缓存的设置在Chrome/Opera中还不支持，Firefox也是刚刚支持。你可以自己来实现类似的功能：

self.addEventListener("install", event => {
  event.waitUntil(
    caches.open(`static-${version}`)
      .then(cache => Promise.all(
        [
          "/styles.css",
          "/script.js"
        ].map(url => {
          // cache-bust using a random query string
          return fetch(`${url}?${Math.random()}`).then(response => {
            // fail on 404, 500 etc
            if (!response.ok) throw Error("Not ok");
            return cache.put(url, response);
          })
        })
      ))
  );
});

在上述代码中，我用随机数来避免缓存，但是你可以更进一步，在构建的时候为内容增加一个hash值(和sw-precache做的事差不多)。这是一种在js层面的对模式一的实现，但是仅仅对service worker的使用者是有效的，而不是对所有的浏览器和你的CDN都有效。

正如你所见，你可以绕过service worker中糟糕的缓存，但是你最好解决根源的问题。正确的设置缓存能够让你在使用service worker的时候更加轻松，并且对那些不支持service worker的浏览器也是有好处的，还能让你充分的使用你的CDN。

正确的缓存头还意味着你可以大量简化server worker的更新：

const version = "23";

self.addEventListener("install", event => {
  event.waitUntil(
    caches.open(`static-${version}`)
      .then(cache => cache.addAll([
        "/",
        "/script-f93bca2c.js",
        "/styles-a837cb1e.css",
        "/cats-0e9a2ef4.jpg"
      ]))
  );
});

在这里，我将使用模式2（服务器重新验证）缓存根页面，其余资源使用模式1（不可变内容）。每次service worker更新都将触发对根页面的请求，但只有当资源的URL发生更改时，才会下载其余资源。这很好，因为无论你是从以前的版本还是第10个版本更新，它都可以节省带宽并提高性能。

相对于本地应用来说，这是一个巨大的优势。在本地应用中，不管二进制内容有细微和巨大的改变，整个二进制内容都会被下载。而在这里，我们只需要一个小小的下载，就能更新巨大的web app.

service worker的工作最好是作为一个增强方案，而不是变通方案。所以预期与缓存抗争，不如好好利用缓存。

对于可变内容使用max-age一般情况下是一个错误的选择，但也不总是这样。比如，这个页面设置了一个3分钟的max-age. race condition在这个页面是不会成为问题的，因为这个页面没有任何遵循这一种模式的依赖(我的css,js,图片等都遵循模式1-不可变内容)，依赖于此页的任何内容都不会遵循相同的模式。

这种模式意味着，如果我有幸写了一篇热门文章，我的cdn可以让我的服务器散热，而我能忍受用户需要花三分钟时间才看到文章更新。

这种模式不能随便使用。如果我在文章中添加了一个新的部分，并且将这个部分链接到一篇新的文章，那么我就创造了一个会争用的依赖项。用户可以单击链接，并在没有引用部分的情况下获取文章的副本。如果我想避免这种情况，我就得更新第一篇文章，刷新cdn, 等待3分钟，然后在另一篇文章中添加指向他的链接。是的…..你必须非常小心这种模式。

正确使用，缓存能极大的提高性能并且较少带宽消耗。对于任何容易更改的URL，都支持不可变的内容，否则在服务器重新验证时会使其安全。只有当你足够勇敢，并且你确信你没有可能会失去同步的依赖项时，再使用max-age和可变内容的模式。