使用正确的缓存可以带来巨大的页面性能上的收益，节省带宽，减少服务器成本。但是许多网站并没有解决好他们的缓存问题，创造了一个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对应的内容会改变
- 任何本地缓存的版本都是不可信的，除非服务器校验通过
在这种模式下，你可以在响应头里添加一个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和可变内容的模式。