深入理解浏览器缓存原理

前言

缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离，减少延迟，并且由于缓存文件可以重复利用，还可以减少带宽，降低网络负荷。

对于一个数据请求来说，可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求，或者发起了请求但后端存储的数据和前端一致，那么就没有必要再将数据回传回来，这样就减少了响应数据。

接下来的内容中我们将通过缓存位置、缓存策略以及实际场景应用缓存策略来探讨浏览器缓存机制。

接下来我将通过以下几个部分来探讨浏览器缓存机制：

• 缓存位置
• 缓存策略
• 缓存机制
• 实际场景应用缓存策略

缓存位置

浏览器缓存位置分为四种，其优先级顺序如下：

1. Service Workers
2. Memory Cache
3. Disk Cache
4. Push Cache

当上述四个缓存位置中的缓存都没有命中时，则会向服务器发起请求。

Service Workers

Service Workers 是一个注册在指定源和路径下的事件驱动 worker。它采用 JavaScript 控制关联的页面或者网站，拦截并修改访问和资源请求，细粒度地缓存资源。 我们可以通过谷歌开发者工具中的 Application -> Service Workers 查看当前缓存的资源。

Memory Cache

Memory Cache 即内存中的缓存，其特点是容量小、读取高效、持续性短，会随着进程的释放而释放。 所以，在内存使用率低、缓存小尺寸资源时，会以 Memory Cache 为优先，否则使用 Disk Cache。

Disk Cache

Disk Cache 即磁盘中的缓存，其特点是容量大、读取缓慢、持续性长，任何资源都能存储到磁盘中。 所以，在内存使用率高、缓存大尺寸资源时，会以 Disk Cache 为优先。

Push Cache

Push Cache 是 HTTP 2.0 中的内容，其缓存时间也很短暂，只在会话（Session）中存在，一旦会话结束就被释放。

缓存策略

浏览器与服务器通信的方式为应答模式，即是：浏览器发起 HTTP 请求 – 服务器响应该请求，那么浏览器怎么确定一个资源该不该缓存，如何去缓存呢？浏览器第一次向服务器发起该请求后拿到请求结果后，将请求结果和缓存标识存入浏览器缓存，浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的。具体过程如下图：

由上图我们可以知道：

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

• 浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中

以上两点结论就是浏览器缓存机制的关键，它确保了每个请求的缓存存入与读取，只要我们再理解浏览器缓存的使用规则，那么所有的问题就迎刃而解了，本文也将围绕着这点进行详细分析。为了方便大家理解，这里我们根据是否需要向服务器重新发起 HTTP 请求将缓存过程分为两个部分，分别是强缓存和协商缓存。

强缓存

强缓存：不会向服务器发送请求，直接从缓存中读取资源，在 chrome 控制台的 Network 选项中可以看到该请求返回200的状态码，并且 Size 显示 from disk cache 或 from memory cache。强缓存可以通过设置两种 HTTP Header 实现：Expires 和 Cache-Control。

Expires

缓存过期时间，用来指定资源到期的时间，是服务器端的具体的时间点。也就是说，Expires = date。Expires 是 Web 服务器响应消息头字段，在响应 http 请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。

Expires: Wed, 07 Dec 2022 03:38:53 GMT 表示资源会在 Wed, 07 Dec 2022 03:38:53 GMT 后过期，需要再次请求。

Expires 是 HTTP/1 的产物，受限于本地时间，如果修改了本地时间，可能会造成缓存失效。 所以，Expires 字段几乎不被使用了。现在的项目中，我们并不推荐使用Expires，强缓存功能通常使用 cache-control 字段来代替 Expires 字段。

Cache-Control

在 HTTP/1.1中，Cache-Control 是最重要的规则，主要用于控制网页缓存。比如当 Cache-Control: max-age = 300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。

Cache-Control 可以在请求头或者响应头中设置，并且可以组合使用多种指令：

属性	描述
max-age=30	缓存30秒后过期，需要重新请求
s-maxage=30	覆盖max-age，作用一样，只在代理服务器中生效
public	表示资源可以被浏览器和代理服务器缓存
private	表示资源只能被浏览器缓存
no-cache	资源被缓存但立即失效，后续进行协商缓存
no-store	表示不缓存任何资源
max-stale=30	30秒内，即使缓存过期，也使用该缓存
min-fresh=30	希望30秒内，获取最新的资源

Expires 和 Cache-Control 两者对比

1. 其实这两者差别不大，区别就在于 Expires 是 http1.0的产物，Cache-Control 是 http1.1的产物，两者同时存在的话，Cache-Control 优先级高于 Expires；
2. 在某些不支持 HTTP1.1 的环境下，Expires 就会发挥用处。所以 Expires 其实是过时的产物，现阶段它的存在只是一种兼容性的写法。

Cache-Control可以看成是Expires的替代品，但是有时候需要考虑到向下兼容，还是会需要用到Expires。

强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段，而不关心服务器端文件是否已经更新，这可能会导致加载文件不是服务器端最新的内容，那我们如何获知服务器端内容是否已经发生了更新呢？此时我们需要用到协商缓存策略。

协商缓存

协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况：

1. 协商缓存生效，返回304和 Not Modified：

2. 协商缓存失效，返回200和请求结果：

协商缓存可以通过设置两种 HTTP Header 实现：Last-Modified 和 ETag。

Last-Modified 和 If-Modified-Since：

Last-Modified 是服务器端在响应请求时用来说明资源的最后修改时间。在协商缓存过程中，浏览器发送的 HTTP 请求中 Header 中会带上 If-Modified-Since 字段，值为缓存资源 Last-Modified 属性的值。

当服务器端接收到带有 If-Modified-Since 的请求时，则会将 If-Modified-Since 的值与被请求资源的最后修改时间做对比。如果相同，说明资源没有新的修改，则响应 HTTP Status Code 304，浏览器会继续使用缓存资源；如果最后修改时间比较新，则说明资源被修改过，则响应 HTTP Status Code 200，并返回最新的资源。

ETag 和 If-None-Match

Etag 是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)，只要资源有变化，Etag 就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的 Etag 值放到 request header 里的 If-None-Match 里，服务器只需要比较客户端传来的 If-None-Match 跟自己服务器上该资源的 ETag 是否一致，就能很好地判断资源相对客户端而言是否被修改过了。如果服务器发现 ETag 匹配不上，那么直接以常规 GET 200回包形式将新的资源（当然也包括了新的 ETag）发给客户端；如果 ETag 是一致的，则直接返回304知会客户端直接使用本地缓存即可。

Last-Modified 和 ETag 的区别：

1. 首先在精确度上，Etag 要优于 Last-Modified。

• Last-Modified 的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的 Last-Modified 其实并没有体现出来修改，但是 Etag 每次都会改变确保了精度；
• 如果是负载均衡的服务器，各个服务器生成的 Last-Modified 也有可能不一致。

2. 第二在性能上，Etag 要逊于 Last-Modified，毕竟 Last-Modified 只需要记录时间，而 Etag 需要服务器通过算法来计算出一个 hash 值。
3. 第三在优先级上，服务器校验优先考虑 Etag。

Last-Modified 和 ETag 的相同点：

从流程上来说，两者是一样的，前者是对比的资源最后一次修改时间，后者是对比文件内容的hash值是否相同。

缓存机制

强制缓存优先于协商缓存进行，若强制缓存(Expires 和 Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，返回200，重新返回资源和缓存标识，再存入浏览器缓存中；生效则返回304，继续使用缓存。具体流程图如下：

看到这里，不知道你是否存在这样一个疑问:如果什么缓存策略都没设置，那么浏览器会怎么处理？

对于这种情况，浏览器会采用一个启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存时间。

实际场景应用缓存策略

频繁变动的资源

Cache-Control: no-cache

对于频繁变动的资源，首先需要使用 Cache-Control:no-cache 使浏览器每次都请求服务器，然后配合 ETag 或者 Last-Modified 来验证资源是否有效。这样的做法虽然不能节省请求数量，但是能显著减少响应数据大小。

不常变化的资源

Cache-Control: max-age=31536000

通常在处理这类资源时，给它们的 Cache-Control 配置一个很大的 max-age=31536000 (一年)，这样浏览器之后请求相同的 URL 会命中强制缓存。而为了解决更新的问题，就需要在文件名(或者路径)中添加 hash， 版本号等动态字符，之后更改动态字符，从而达到更改引用 URL 的目的，让之前的强制缓存失效 (其实并未立即失效，只是不再使用了而已)。在线提供的类库 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用这个模式。

用户行为对浏览器缓存的影响

所谓用户行为对浏览器缓存的影响，指的就是用户在浏览器如何操作时，会触发怎样的缓存策略。主要有 3 种：

• 打开网页，地址栏输入地址： 查找 disk cache 中是否有匹配。如有则使用；如没有则发送网络请求。

• 普通刷新 (F5)：因为 TAB 并没有关闭，因此 memory cache 是可用的，会被优先使用(如果匹配的话)。其次才是 disk cache。

• 强制刷新 (Ctrl + F5)：浏览器不使用缓存，因此发送的请求头部均带有 Cache-control:no-cache(为了兼容，还带了 Pragma:no-cache),服务器直接返回 200 和最新内容。