共计 7017 个字符，预计需要花费 18 分钟才能阅读完成。
一、前言
缓存能够说是性能优化中简略高效的一种优化形式了。一个优良的缓存策略能够缩短网页申请资源的间隔，缩小提早，并且因为缓存文件能够反复利用，还能够缩小带宽，升高网络负荷。
对于一个数据申请来说，能够分为发动网络申请、后端解决、浏览器响应三个步骤。浏览器缓存能够帮忙咱们在第一和第三步骤中优化性能。比如说间接应用缓存而不发动申请，或者发动了申请但后端存储的数据和前端统一，那么就没有必要再将数据回传回来，这样就缩小了响应数据。
接下来的内容中咱们将通过缓存地位、缓存策略以及理论场景利用缓存策略来探讨浏览器缓存机制。
二、缓存地位
从缓存地位上来说分为四种，并且各自有优先级，当顺次查找缓存且都没有命中的时候，才会去申请网络。
- Service Worker
- Memory Cache
- Disk Cache
- Push Cache
1.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 中获取的内容。
2.Memory Cache
Memory Cache 也就是内存中的缓存，次要蕴含的是以后中页面中曾经抓取到的资源, 例如页面上曾经下载的款式、脚本、图片等。读取内存中的数据必定比磁盘快, 内存缓存尽管读取高效，可是缓存持续性很短，会随着过程的开释而开释。一旦咱们敞开 Tab 页面，内存中的缓存也就被开释了。
那么既然内存缓存这么高效，咱们是不是能让数据都寄存在内存中呢？
这是不可能的。计算机中的内存肯定比硬盘容量小得多，操作系统须要精打细算内存的应用，所以能让咱们应用的内存必然不多。
当咱们拜访过页面当前，再次刷新页面，能够发现很多数据都来自于内存缓存
内存缓存中有一块重要的缓存资源是 preloader 相干指令（例如<link rel="prefetch">）下载的资源。总所周知 preloader 的相干指令曾经是页面优化的常见伎俩之一，它能够一边解析 js/css 文件，一边网络申请下一个资源。
须要留神的事件是，内存缓存在缓存资源时并不关怀返回资源的 HTTP 缓存头 Cache-Control 是什么值，同时资源的匹配也并非仅仅是对 URL 做匹配，还可能会对 Content-Type，CORS 等其余特色做校验。
3.Disk Cache
Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，然而什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。
在所有浏览器缓存中，Disk Cache 覆盖面根本是最大的。它会依据 HTTP Herder 中的字段判断哪些资源须要缓存，哪些资源能够不申请间接应用，哪些资源曾经过期须要从新申请。并且即便在跨站点的状况下，雷同地址的资源一旦被硬盘缓存下来，就不会再次去申请数据。绝大部分的缓存都来自 Disk Cache，对于 HTTP 的协定头中的缓存字段，咱们会在下文进行具体介绍。
浏览器会把哪些文件丢进内存中？哪些丢进硬盘中？
对于这点，网上说法不一，不过以下观点比拟靠得住：
- 对于大文件来说，大概率是不存储在内存中的，反之优先
- 以后零碎内存使用率高的话，文件优先存储进硬盘
4.Push Cache
Push Cache（推送缓存）是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被应用。它只在会话（Session）中存在，一旦会话完结就被开释，并且缓存工夫也很短暂，在 Chrome 浏览器中只有 5 分钟左右，同时它也并非严格执行 HTTP 头中的缓存指令。
Push Cache 在国内可能查到的材料很少，也是因为 HTTP/2 在国内不够遍及。这里举荐浏览 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 中的缓存只能被应用一次
- 浏览器能够拒绝接受曾经存在的资源推送
- 你能够给其余域名推送资源
如果以上四种缓存都没有命中的话，那么只能发动申请来获取资源了。
那么为了性能上的思考，大部分的接口都应该抉择好缓存策略，通常浏览器缓存策略分为两种：强缓存和协商缓存，并且缓存策略都是通过设置 HTTP Header 来实现的。
三、缓存过程剖析
浏览器与服务器通信的形式为应答模式，即是：浏览器发动 HTTP 申请 – 服务器响应该申请，那么浏览器怎么确定一个资源该不该缓存，如何去缓存呢 ？浏览器第一次向服务器发动该申请后拿到申请后果后，将申请后果和缓存标识存入浏览器缓存， 浏览器对于缓存的解决是依据第一次申请资源时返回的响应头来确定的。具体过程如下图：
由上图咱们能够晓得：
- 浏览器每次发动申请，都会先在浏览器缓存中查找该申请的后果以及缓存标识
- 浏览器每次拿到返回的申请后果都会将该后果和缓存标识存入浏览器缓存中
以上两点论断就是浏览器缓存机制的要害，它确保了每个申请的缓存存入与读取，只有咱们再了解浏览器缓存的应用规定，那么所有的问题就迎刃而解了，本文也将围绕着这点进行详细分析。为了不便大家了解，这里咱们依据是否须要向服务器从新发动 HTTP 申请将缓存过程分为两个局部，别离是强缓存和协商缓存。
四、强缓存
强缓存：不会向服务器发送申请，间接从缓存中读取资源，在 chrome 控制台的 Network 选项中能够看到该申请返回 200 的状态码，并且 Size 显示 from disk cache 或 from memory cache。强缓存能够通过设置两种 HTTP Header 实现：Expires 和 Cache-Control。
1.Expires
缓存过期工夫，用来指定资源到期的工夫，是服务器端的具体的工夫点。也就是说，Expires=max-age + 申请工夫，须要和 Last-modified 联合应用。Expires 是 Web 服务器响应音讯头字段，在响应 http 申请时通知浏览器在过期工夫前浏览器能够间接从浏览器缓存取数据，而无需再次申请。
Expires 是 HTTP/1 的产物，受限于本地工夫，如果批改了本地工夫，可能会造成缓存生效 。Expires: Wed, 22 Oct 2018 08:41:00 GMT 示意资源会在 Wed, 22 Oct 2018 08:41:00 GMT 后过期，须要再次申请。
2.Cache-Control
在 HTTP/1.1 中，Cache-Control 是最重要的规定，次要用于管制网页缓存。比方当 Cache-Control:max-age=300 时，则代表在这个申请正确返回工夫（浏览器也会记录下来）的 5 分钟内再次加载资源，就会命中强缓存。
Cache-Control 能够在申请头或者响应头中设置，并且能够组合应用多种指令：
public：所有内容都将被缓存（客户端和代理服务器都可缓存）。具体来说响应可被任何两头节点缓存，如 Browser <– proxy1 <– proxy2 <– Server，两头的 proxy 能够缓存资源，比方下次再申请同一资源 proxy1 间接把本人缓存的货色给 Browser 而不再向 proxy2 要。
private：所有内容只有客户端能够缓存，Cache-Control 的默认取值。具体来说，示意两头节点不容许缓存，对于 Browser <– proxy1 <– proxy2 <– Server，proxy 会老老实实把 Server 返回的数据发送给 proxy1, 本人不缓存任何数据。当下次 Browser 再次申请时 proxy 会做好申请转发而不是自作主张给本人缓存的数据。
no-cache：客户端缓存内容，是否应用缓存则须要通过协商缓存来验证决定。示意不应用 Cache-Control 的缓存管制形式做前置验证，而是应用 Etag 或者 Last-Modified 字段来管制缓存。须要留神的是，no-cache 这个名字有一点误导。设置了 no-cache 之后，并不是说浏览器就不再缓存数据，只是浏览器在应用缓存数据时，须要先确认一下数据是否还跟服务器保持一致。
no-store：所有内容都不会被缓存，即不应用强制缓存，也不应用协商缓存
max-age：max-age=xxx (xxx is numeric)示意缓存内容将在 xxx 秒后生效
s-maxage（单位为 s)：同 max-age 作用一样，只在代理服务器中失效（比方 CDN 缓存）。比方当 s -maxage=60 时，在这 60 秒中，即便更新了 CDN 的内容，浏览器也不会进行申请。max-age 用于一般缓存，而 s -maxage 用于代理缓存。s-maxage 的优先级高于 max-age。如果存在 s -maxage，则会笼罩掉 max-age 和 Expires header。
max-stale：能容忍的最大过期工夫。max-stale 指令标示了客户端违心接管一个曾经过期了的响应。如果指定了 max-stale 的值，则最大容忍工夫为对应的秒数。如果没有指定，那么阐明浏览器违心接管任何 age 的响应（age 示意响应由源站生成或确认的工夫与以后工夫的差值）。
min-fresh：可能容忍的最小新鲜度。min-fresh 标示了客户端不违心承受新鲜度不多于以后的 age 加上 min-fresh 设定的工夫之和的响应。
从图中咱们能够看到，咱们能够将多个指令配合起来一起应用，达到多个目标。比如说咱们心愿资源能被缓存下来，并且是客户端和代理服务器都能缓存，还能设置缓存生效工夫等等。
3.Expires 和 Cache-Control 两者比照
其实这两者差异不大，区别就在于 Expires 是 http1.0 的产物，Cache-Control 是 http1.1 的产物，两者同时存在的话，Cache-Control 优先级高于 Expires；在某些不反对 HTTP1.1 的环境下，Expires 就会施展用途。所以 Expires 其实是过期的产物，现阶段它的存在只是一种兼容性的写法。
强缓存判断是否缓存的根据来自于是否超出某个工夫或者某个时间段，而不关怀服务器端文件是否曾经更新，这可能会导致加载文件不是服务器端最新的内容，那咱们如何获知服务器端内容是否曾经产生了更新呢？此时咱们须要用到协商缓存策略。
五、协商缓存
协商缓存就是强制缓存生效后，浏览器携带缓存标识向服务器发动申请，由服务器依据缓存标识决定是否应用缓存的过程，次要有以下两种状况：
- 协商缓存失效，返回 304 和 Not Modified
- 协商缓存生效，返回 200 和申请后果
协商缓存能够通过设置两种 HTTP Header 实现：Last-Modified 和 ETag。
1.Last-Modified 和 If-Modified-Since
浏览器在第一次拜访资源时，服务器返回资源的同时，在 response header 中增加 Last-Modified 的 header，值是这个资源在服务器上的最初批改工夫，浏览器接管后缓存文件和 header；
Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT浏览器下一次申请这个资源，浏览器检测到有 Last-Modified 这个 header，于是增加 If-Modified-Since 这个 header，值就是 Last-Modified 中的值；服务器再次收到这个资源申请，会依据 If-Modified-Since 中的值与服务器中这个资源的最初批改工夫比照，如果没有变动，返回 304 和空的响应体，间接从缓存读取，如果 If-Modified-Since 的工夫小于服务器中这个资源的最初批改工夫，阐明文件有更新，于是返回新的资源文件和 200
然而 Last-Modified 存在一些弊病：
- 如果本地关上缓存文件，即便没有对文件进行批改，但还是会造成 Last-Modified 被批改，服务端不能命中缓存导致发送雷同的资源
- 因为 Last-Modified 只能以秒计时，如果在不可感知的工夫内批改实现文件，那么服务端会认为资源还是命中了，不会返回正确的资源
既然依据文件批改工夫来决定是否缓存尚有有余，是否能够间接依据文件内容是否批改来决定缓存策略？所以在 HTTP / 1.1 呈现了 ETag 和If-None-Match
2.ETag 和 If-None-Match
Etag 是服务器响应申请时，返回以后资源文件的一个惟一标识(由服务器生成)，只有资源有变动，Etag 就会从新生成。浏览器在下一次加载资源向服务器发送申请时，会将上一次返回的 Etag 值放到 request header 里的 If-None-Match 里，服务器只须要比拟客户端传来的 If-None-Match 跟本人服务器上该资源的 ETag 是否统一，就能很好地判断资源绝对客户端而言是否被批改过了。如果服务器发现 ETag 匹配不上，那么间接以惯例 GET 200 回包模式将新的资源（当然也包含了新的 ETag）发给客户端；如果 ETag 是统一的，则间接返回 304 知会客户端间接应用本地缓存即可。
3. 两者之间比照：
- 首先在精确度上，Etag 要优于 Last-Modified。
Last-Modified 的工夫单位是秒，如果某个文件在 1 秒内扭转了屡次，那么他们的 Last-Modified 其实并没有体现进去批改，然而 Etag 每次都会扭转确保了精度；如果是负载平衡的服务器，各个服务器生成的 Last-Modified 也有可能不统一。
- 第二在性能上，Etag 要逊于 Last-Modified，毕竟 Last-Modified 只须要记录时间，而 Etag 须要服务器通过算法来计算出一个 hash 值。
- 第三在优先级上，服务器校验优先思考 Etag
六、缓存机制
强制缓存优先于协商缓存进行，若强制缓存 (Expires 和 Cache-Control) 失效则间接应用缓存，若不失效则进行协商缓存(Last-Modified / If-Modified-Since 和 Etag / If-None-Match)，协商缓存由服务器决定是否应用缓存，若协商缓存生效，那么代表该申请的缓存生效，返回 200，从新返回资源和缓存标识，再存入浏览器缓存中；失效则返回 304，持续应用缓存。具体流程图如下：
看到这里，不晓得你是否存在这样一个疑难:如果什么缓存策略都没设置，那么浏览器会怎么解决？
对于这种状况，浏览器会采纳一个启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存工夫。
七、理论场景利用缓存策略
1. 频繁变动的资源
Cache-Control: no-cache
对于频繁变动的资源，首先须要应用Cache-Control: no-cache 使浏览器每次都申请服务器，而后配合 ETag 或者 Last-Modified 来验证资源是否无效。这样的做法尽管不能节俭申请数量，然而能显著缩小响应数据大小。
2. 不常变动的资源
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 和最新内容。
