前端缓存大全

作者: A郑家庆 | 来源:发表于2021-07-31 11:10 被阅读0次

前端缓存大全
前端缓存大全
HTTP-缓存
Android工具类之缓存目录大全
前端缓存
前端缓存
一文读懂http缓存（超详细）
Android开发技术点
axios cache前端数据缓存
前端缓存接口数据的实现

前言

缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的速度，减少延迟，并且由于缓存文件可以重复利用，还可以减少带宽，降低网络负荷。根据缓存的不同可以分为http缓存和浏览器缓存（本地缓存）。

http缓存

对于一个资源请求来说，可以分为发起网络请求、后端处理、浏览器响应三个步骤。http缓存可以帮助我们在第一个和第三个步骤中优化性能。比如强缓存是直接使用缓存而不发起请求，协商缓存是发起了请求但如果请求后端的资源没有改变，那么就不需要再将数据返回，这样就减少了响应时间。

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

缓存位置

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

Service Worker
Memory Cache
Disk Cache
Push Cache

Service Worker

Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必须为 HTTPS。

Memory Cache

Memory Cache 也就是内存中的缓存，主要包含的是当前中页面中已经抓取到的资源，例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比硬盘快，内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。一旦我们关闭 Tab 页面，内存中的缓存也就被释放了，而且内存容量要比硬盘小的多。

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

WX20210730-142350@2x.png

需要注意的事情是，内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值，同时资源的匹配也并非仅仅是对URL做匹配，还可能会对Content-Type，CORS等其他特征做校验。

Disk Cache

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

在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP头部字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。绝大部分的缓存都来自 Disk Cache，关于 HTTP 的协议头中的缓存字段，我们会在下文进行详细介绍。

浏览器会把哪些文件丢进内存中？哪些丢进硬盘中？
关于这点，网上说法不一，不过以下观点比较靠得住：

对于大文件来说，大概率是不存储在内存中的，反之优先
当前系统内存使用率高的话，文件优先存储进硬盘

Push Cache

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

如果以上四种缓存都没有命中的话，那么只能发起请求来获取资源了。

那么为了性能上的考虑，大部分的接口都应该选择好缓存策略，通常http缓存策略分为两种：强缓存和协商缓存，并且缓存策略都是通过设置 HTTP Header 来实现的。

缓存过程分析

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

由上图我们可以知道:

http每次发起请求,都会先在浏览器缓存中查找该请求的结果以及缓存标识
浏览器每次拿到请求结果和缓存标识都会存入浏览器缓存中
以上两点就是http缓存机制的关键，它确保了每个请求的缓存存入和读取，只要我们理解http缓存的使用规则，那么所有的问题就会迎刃而解了，本文也将围绕着这点进行详细分析。为了方便大家理解，这里我们根据是否需要向服务器重新发起HTTP请求将缓存分为强缓存和协商缓存。

强缓存

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

Expires

缓存过期时间，Expires=请求日期，它告诉浏览器在过期日期前浏览器可以直接从浏览器缓存读取数据而无需再次请求。

Expires是HTTP/1.0的产物，受限于客户端时间，如果服务器和客户端时间偏差较大，可能会造成缓存失效。Expires: Wed, 22 Oct 2018 08:41:00 GMT表示资源会在 Wed, 22 Oct 2018 08:41:00 GMT 后过期，需要再次请求。

Cache-Control

主要用于控制网页缓存。例如Cache-Control：max-age=300，表示这个请求在5分钟内(浏览器也会记录下来)再次加载资源，就会命中强缓存。

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

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.

Last-Modified和If-Modified-Since

浏览器在第一次请求服务器时，服务器在返回资源的同时，会在响应头中添加Last-Modified，值是这个资源在服务器上的最后修改时间，浏览器接收后缓存文件和Last-Modified这个响应头；

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只能以秒计时，如果在1s内修改了文件，那么服务端还是会认为资源被命中了，不会返回最新的资源。

既然根据文件修改时间来决定是否命中缓存有缺陷,能否可以直接根据文件内容是否修改来决定缓存策略?所以在HTTP/1.1出现了Etag和If-None-Match

Etag和If-None-Match

Etag是服务器响应请求时返回当前资源文件的一个唯一标识(由服务器生成),只有资源发生变化,Etag就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到请求头里的If-None-Match里，服务器只需要比较客户端传来的If-None-Match跟自己服务器上资源的Etag是否一致，就能判断资源是否修改过。如果一致则直接返回304告知客户端直接使用本地缓存即可，如果不一致那么返回新的资源文件和200(当然也包括了新的Etag)发给客户端。

两者对比

首先在精度上，Etag要优于Last-Modified：Last-Modified的时间单位是秒，如果某个文件在1秒内被修改了，那么服务端还是会认为资源被命中了，不会返回最新的资源。
第二在性能上，Last-Modified要优于Etag，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法计算出一个hash值。
第三在优先级上，服务器校验优先考虑Etag。

缓存机制

强制缓存优先于协商缓存进行，若强制缓存(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 使用协商缓存。这样的做法虽然不能节省请求数量，但是能显著减少响应资源时间。

不常变化的资源

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和最新内容。

**`总结：