浏览器缓存

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第30天，点击查看活动详情

本文主要包含以下内容：

• 什么是浏览器缓存

• 按照缓存位置分类

  • Service Worker
  • Memory Cache
  • Disk Cache
  • Push Cache

• 按照缓存类型分类

  • 强制缓存
  • 协商缓存

• 缓存读取规则

• 浏览器行为

• 实操案例

• 缓存的最佳实践

什么是浏览器缓存

在正式开始讲解浏览器缓存之前，我们先来回顾一下整个 Web 应用的流程。

上图展示了一个 Web 应用最最简单的结构。客户端向服务器端发送 HTTP 请求，服务器端从数据库获取数据，然后进行计算处理，之后向客户端返回 HTTP 响应。

那么上面整个流程中，哪些地方比较耗费时间呢？总结起来有如下两个方面：

• 发送请求的时候
• 涉及到大量计算的时候

一般来讲，上面两个阶段比较耗费时间。

首先是发送请求的时候。这里所说的请求，不仅仅是 HTTP 请求，也包括服务器向数据库发起查询数据的请求。

其次是大量计算的时候。一般涉及到大量计算，主要是在服务器端和数据库端，服务器端要进行计算这个很好理解，数据库要根据服务器发送过来的查询命令查询到对应的数据，这也是比较耗时的一项工作。

因此，单论缓存的话，我们其实在很多地方都可以做缓存。例如：

• 数据库缓存
• CDN 缓存
• 代理服务器缓存
• 浏览器缓存
• 应用层缓存

针对各个地方做出适当的缓存，都能够很大程度的优化整个 Web 应用的性能。但是要逐一讨论的话，是一个非常大的工程量，所以本文我们主要来看一下浏览器缓存，这也是和我们前端开发息息相关的。

整个浏览器的缓存过程如下：

从上图我们可以看到，整个浏览器端的缓存其实没有想象的那么复杂。其最基本的原理就是：

• 浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识
• 浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中

以上两点结论就是浏览器缓存机制的关键，它确保了每个请求的缓存存入与读取，只要我们再理解浏览器缓存的使用规则，那么所有的问题就迎刃而解了。

接下来，我将从两个维度来介绍浏览器缓存：

• 缓存的存储位置
• 缓存的类型

按照缓存位置分类

从缓存位置上来说分为四种，并且各自有优先级，当依次查找缓存且都没有命中的时候，才会去请求网络。这四种依次为：

• Service Worker
• Memory Cache
• Disk Cache
• Push Cache

Service Worker

Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。

使用 Service Worker 的话，传输协议必须为 HTTPS。因为 Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。

Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。

Service Worker 实现缓存功能一般分为三个步骤：首先需要先注册 Service Worker，然后监听到 install 事件以后就可以缓存需要的文件，那么在下次用户访问的时候就可以通过拦截请求的方式查询是否存在缓存，存在缓存的话就可以直接读取缓存文件，否则就去请求数据。.

当 Service Worker 没有命中缓存的时候，我们需要去调用 fetch 函数获取数据。也就是说，如果我们没有在 Service Worker 命中缓存的话，会根据缓存查找优先级去查找数据。

但是不管我们是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示我们是从 Service Worker 中获取的内容。

Memory Cache

Memory Cache 也就是内存中的缓存，主要包含的是当前中页面中已经抓取到的资源，例如页面上已经下载的样式、脚本、图片等。

读取内存中的数据肯定比磁盘快，内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。

那么既然内存缓存这么高效，我们是不是能让数据都存放在内存中呢？

这是不可能的。计算机中的内存一定比硬盘容量小得多，操作系统需要精打细算内存的使用，所以能让我们使用的内存必然不多。

当我们访问过页面以后，再次刷新页面，可以发现很多数据都来自于内存缓存。

Memory Cache 机制保证了一个页面中如果有两个相同的请求。

例如两个 src 相同的 <img>，两个 href 相同的 <link>，都实际只会被请求最多一次，避免浪费。

Disk Cache

Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。

在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。

并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。绝大部分的缓存都来自 Disk Cache。

凡是持久性存储都会面临容量增长的问题，Disk Cache 也不例外。

在浏览器自动清理时，会有特殊的算法去把“最老的”或者“最可能过时的”资源删除，因此是一个一个删除的。不过每个浏览器识别“最老的”和“最可能过时的”资源的算法不尽相同，这也可以看作是各个浏览器差异性的体现。

Push Cache

Push Cache 翻译成中文叫做“推送缓存”，是属于 HTTP/2 中新增的内容。

当以上三种缓存都没有命中时，它才会被使用。它只在会话（Session）中存在，一旦会话结束就被释放，并且缓存时间也很短暂，在 Chrome 浏览器中只有 5 分钟左右，同时它也并非严格执行 HTTP/2 头中的缓存指令。

Push Cache 在国内能够查到的资料很少，也是因为 HTTP2 在国内还不够普及。

这里推荐阅读 Jake Archibald 的 HTTP/2 push is tougher than I thought 这篇文章。

文章中的几个结论：

• 所有的资源都能被推送，并且能够被缓存，但是 Edge 和 Safari 浏览器支持相对比较差
• 可以推送 no-cache 和 no-store 的资源
• 一旦连接被关闭，Push Cache 就被释放
• 多个页面可以使用同一个 HTTP/2 的连接，也就可以使用同一个 Push Cache。这主要还是依赖浏览器的实现而定，出于对性能的考虑，有的浏览器会对相同域名但不同的 tab 标签使用同一个 HTTP 连接。
• Push Cache 中的缓存只能被使用一次
• 浏览器可以拒绝接受已经存在的资源推送
• 你可以给其他域名推送资源