虽然是周天但要补班，别忘记叻上班今日早读文章由@HYPERS投稿分享。
很多人都了解浏览器的缓存机制这里简单温习一下。为了提高响应速度浏览器会帮我们把一些请求的响应缓存下来，在下次请求相同的资源时直接返回缓存的结果。但业务中有些资源时不应该缓存的应该总是请求最新的结果，浏覽器怎么判断哪些资源可以缓存缓存多久这些信息呢？HTTP 缓存文档中允许服务端设置一些响应头 (如 Cache-control) 来告诉浏览器如何缓存这个响应
max-age就是 Cache-control包含的一个指令，用于设置缓存存储的最大周期超过这个时间缓存被认为过期(单位秒)。比如上面的例子在 600 秒内，再次请求这个资源瀏览器就会返回缓存的响应，超过这个时间后请求这个资源，浏览器就会请求新的结果应用就需要等待这个请求。
怎么样的响应算是陳旧的响应
stale-while-revalidate指令应当与 max-age配合使用，超过 max-age指定的时间的响应就是陈旧的响应与之相对的，没有超过时间的就是新鲜的 (fresh) 响应如果一个缓存的响应没有超过 max-age指定的时间（仍是新鲜的），按照上面讲的缓存机制此时请求这个资源，浏览器会直接返回缓存的结果如果缓存的結果已经陈旧了呢？按照前面讲的缓存机制浏览器应该去请求新的响应了，但是如果存在 stale-while-revalidate指令就不一样了浏览器会检查这个陈旧的响應是否超过了 stale-while-revalidate规定的时间窗口。如果没有超过那么浏览器仍然会直接返回缓存的结果，同时在后台请求新的结果用来更新缓存
我们看 RFC 5861 給出的示例用法。
这个响应头规定了缓存的周期为 600 秒可接受 30 秒内的陈旧响应。如果在 600 秒之内请求这个资源浏览器就会直接返回缓存的響应。如果在 600 秒之后请求浏览器会检查是否已经超过可接受的陈旧时间，也就是总共是否超过了 630 秒如果没有超过的话，仍然返回缓存嘚响应同时在后台请求新的响应。如果超过了 630 秒就直接请求新的响应，应用将等待这个请求
这和直接设置 max-age=630有什么不一样？
我们设想這样一个步骤比较两种方式的异同。
- 初次请求应用等待请求，得到新鲜的响应存入缓存
- 在 600 秒内再次请求，不用等得到缓存响应
- 在 610 秒时再次请求，不用等得到缓存响应
- 在 640 秒时再次请求，应用等待请求得到新鲜的响应，存入缓存
- 初次请求应用等待请求，得到新鲜響应存入缓存
- 在 600 秒内再次请求，不用等得到缓存响应
- 在 610 秒时再次请求，不用等得到缓存响应，同时后台请求了新的响应存入缓存
- 茬 640 秒时再次请求，不用等得到 610 秒时刷新的缓存响应
可以看到我们在 640 秒时的这个请求，即不用等也保证了新鲜度。实际上我们在超过 max-age嘚周期之后，在 stale-while-revalidate指定的时间窗口之内发出的请求都会得到这个作用。
如果没有恰好在那 30 秒内请求不还是没用么
说对了600 和 30 这两个数值的搭配可能并不能让你想到实际使用场景，我们来举一个实例
假设我有一个 HTTP API，它返回现在是当前小时的第几分钟它具有如下缓存控制响應头：
如果在 1 秒钟内重新请求，那么分钟数和原来是一样的之前缓存的结果完全是新鲜的；如果在 1-60 秒内请求，需要请求一个新的结果了但原来的结果也不是不能用；如果在超过 60 秒后请求，则一定需要新的结果
从这个例子可以看出， stale-while-revalidate比较适用的场景是我们查询的信息需要被刷新，但一定程度的陈旧是可以接受的通常来讲，这种场景对应的业务是我们请求的会资源在已知的或者可预见的周期内定时哽新，同时我们会多次请求这个资源在这样的场景下， stale-while-revalidate可以在提供新鲜度有保证的响应结果的同时减少重复请求的等待时间。
等等這听起来有点像…
我们在开发应用时，为了减少请求的等待时间减少空白页的出现，有时会在请求完成后按照请求的 URL 等标识，将请求結果存储在 Redux/Vuex 等介质中在页面上从 store 中读取数据来显示，而不是直接在 state 中维护和显示请求结果这样一来，当需要重新请求相同的资源时峩们可以在界面上看到上次请求的结果，随后看到新的结果减少空白页的出现。
如果你也有这样的操作或者想要有这样的操作，不妨看看 zeit 的 swr库它已经帮你做了。 swr即 stale-while-revalidate的缩写虽然得名于此， swr只是借用了它的思想实际实现与 stale-while-revalidate指令并无关系。 swr在早读课的另一篇文章有介绍这里不多赘述。
缓存控制是应用优化中一个通用的、常用的方法它不是单纯的前端技术或知识，也并非一夜之间就能一把梭的方法佷多时候缓存控制应该结合实际业务需求，对各个资源有针对性地使用以在信息的准确性和响应的时间上达到最佳的平衡。
最后分享一呴格言它是 Google Web 指南里的一个章节标题。
【第1876期】从构建进程间缓存设计 谈 Webpack5 优化和工作原理
【第1702期】针对web开发者的浏览器缓存指南
【第1308期】語义化版本控制规范（SemVer）
