第1563期缓存最佳实践 & max-age的陷阱

Posted 2021-04-15 前端早读课

前言

今日早读文章由腾讯@CoyPan翻译授权分享。

@CoyPan，一名符合预期的前端工程师

正文从这开始～～

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

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

模式一：不可变的内容 ，长时间的max-age

Cache-Control: max-age = 31536000

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

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

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

在这种模式下，你不会去改变特定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对应的内容会改变

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

注意：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设置和可变的内容。这是一种十分糟糕的妥协。

对可变内容使用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 & 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和可变内容的模式。

他曾分享过

为你推荐