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

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

模式一:不可变的内容 ,长时间的max-age

Cache-Control: max-age = 31536000
  • 同一个URL对应的内容永不改变
  • 浏览器/CDN 可以缓存这个资源长达一年的时间
  • 被缓存资源的存储时间小于max-age指定的秒数时,该资源可以直接被使用而无需经过服务器。

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

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

<script src="/script-f93bca2c.js"></script>
<link rel="stylesheet" href="/styles-a837cb1e.css">
<img src="/cats-0e9a2ef4.jpg" alt="…">

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

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

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

模式二:可变的内容,总是向服务器发起校验

Cache-Control: no-cache
  • 同一个url对应的内容会改变
  • 任何本地缓存的版本都是不可信的,除非服务器校验通过

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

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

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

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

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

对可变内容使用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(如果可用)

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

这种模式在测试的时候看起来是可以的,但在现实中,会出问题,并且很难追踪。在上面的例子中,服务端确实已经更新了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 & http缓存可以同时使用,不要让他们冲突

正如你所见,你可以绕过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 & 可变内容 也可以很有效

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

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

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

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

03-19 23:35