一、前言
缓存可以说是性能优化中简单高效的一种优化方式。 一个优化的缓存策略可以缩短网页请求资源的距离,减少延迟,并且由于缓存文件可以重复利用,还可以减少带宽,降低网络负荷。
对于一个数据请求来说,可以分为三个步骤:
1.网络请求 -> 2.后端处理 -> 3.浏览器响应
而浏览器的缓存机制可以协助优化第一和第三步骤。比如:‘直接使用缓存而不发起请求,或者发起了请求但后端存储的数据和前端一致,就没有必要回传数据,这样就减少了响应数据’。
缓存图解:

二、缓存位置
从缓存位置上来说分为四种,并且各自有优先级,当依次查找缓存且都没有命中的时候,才会去请求网络:
1. Service worker
2. Memory Cache
3. Disk Cache
4. 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页面,内存中的缓存也会被释放了
那么既然内存缓存这么高效,是否能让数据都存放在内存中呢?
这是不可能的。计算机中的内存一定比硬盘容量小得多,操作系统需要精打细算内存的使用,所以能让我们使用的内存必然不多
当我们访问过页面之后,再次刷新页面,可以发现很多数据来自于内存缓存

内存缓存中有一块重要的缓存资源是preloader相关指令(例如<link rel="prefetch">)下载的资源。众所周知preloader的相关指令已经是页面优化的常见手段之一,它可以一边解析js/css文件,一边网络请求下一个资源。
需要注意的是:
内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值,同时资源的匹配也并非仅仅是对URL做匹配,还可能会对Content-Type,CORS等其他特征做校验
- Disk Cache
Disk Cache, 存储在硬盘中的缓存,读取数据缓慢,但是任何东西都能存储到硬盘中,相比Memory Cache, 容量更大,存储时效性更长。
在所有浏览器缓存中,Disk Cache覆盖面基本是最大的。 它会根据HTTP Header 中的字段判断哪些资源需要缓存,哪些资源可以不被请求直接使用,哪些资源已经过期需要重新请求。 并且即使在跨站点的情况下,相同地址的资源一旦被硬盘缓存下来,就不会再次去请求数据。绝大部分的缓存都来自 Disk Cache
浏览器会选择哪些文件存储到硬盘中:
1. 对于文件而言, 文件比较大的一般会选择存储到硬盘中,小文件可能会选择内存。具体情况而定。
2. 当前系统内存使用率高的时候,文件优先存进硬盘
- Push Cache
Push Cache : 又称推送缓存,是HTTP/2中的内容,当以上三种缓存都没有被命中时,它才会被使用。
它只在会话(session)中存在,一旦会话结束就被释放,并且缓存时间也很短暂,在Chrome浏览器中只有5分钟左右,同时它也并非严格执行HTTP头中的缓存指令
三、缓存过程分析
浏览器与服务器通信的方式为 应答模式,即是:
浏览器发起HTTP请求 -> 服务器响应该请求
那么浏览器如何确定一个资源是否该缓存,如何去缓存?
浏览器第一次向服务器发起该请求后拿到请求结果后,将请求结果和缓存标识存入浏览器缓存,浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的

总而言之,在整个流程中:
1. 浏览器每次发起请求,都会在浏览器缓存中查找该请求的结果以及缓存标识
2. 浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中
这也是浏览器缓存的关键,它确保了每个请求的缓存存入与读取
四、强缓存
强缓存: 不会向服务器发送请求,直接从缓存中读取资源。
在chrome控制台的Network 选项中,能够看到该请求返回200的状态码,并且size显示 from disk cache 或者 from disk cache.
强缓存可以通过设置两种HTTPHeader 实现:Expires 和 Cache-Control
- 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 后过期,需要再次请求
- Cache-Control
在HTTP/1.1中 ,Cache-Control是最重要的规则,主要用于控制网页缓存。 例子:
当Cache-Control:max-age=300时,则代表在这个请求正确返回时间(浏览器也会记录下来)5分钟内再次加载资源,就会命中缓存。
| 指令 | 作用 |
|---|---|
| public | 表示响应可以被客户端和代理服务器缓存 |
| private | 表示响应只可以被客户端缓存 |
| max-age=30 | 缓存30秒后就过期,需要重新请求 |
| s-maxage=30 | 覆盖max-age,作用一样,只在代理服务器中生效 |
| no-store | 不缓存任何响应 |
| no-cache | 资源被缓存,但是立即失效,下次会发起请求验证资源是否过期 |
| max-stale=30 | 30秒内,即使缓存过期,也使用该缓存 |
| max-fresh | 希望在30秒内获取最新的响应 |
指令介绍
-
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设定的时间之和的响应。
可以将多个指令搭配起来使用:

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 。
5.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的弊端
1. 如果本地打开缓存文件,即使没有对文件进行修改,但还是会造成Last-Modified被修改,服务端不能命中缓存导致发送相同的资源。
2. 因为 Last-Modified 只能以秒计时,如果在不可感知的时间内修改完成文件,那么服务端会认为资源还是命中了,不会返回正确的资源
5.2 ETag和If-None-Match
Etag是服务器响应请求时,返回当前资源文件的一个唯一标识(由服务器生成),只要资源有变化,Etag就会重新生成
浏览器在下一次加载资源向服务器发送请求时,会将上一次返回的Etag值放到request header里的If-None-Match里,服务器只需要比较客户端传来的If-None-Match跟自己服务器上该资源的ETag是否一致,就能很好地判断资源相对客户端而言是否被修改过了。如果服务器发现ETag匹配不上,那么直接以常规GET 200回包形式将新的资源(当然也包括了新的ETag)发给客户端;如果ETag是一致的,则直接返回304知会客户端直接使用本地缓存即可

两者对比
- 首先在精确度上,Etag要优于Last-
Last-Modified的时间单位是秒,如果某个文件在1秒内改变了多次,那么他们的Last-Modified其实并没有体现出来修改,但是Etag每次都会改变确保了精度;
如果是负载均衡的服务器,各个服务器生成的Last-Modified也有可能不一致
- 在性能上,Etag要逊于Last-Modified,毕竟Last-Modified只需要记录时间,而Etag需要服务器通过算法来计算出一个hash值
- 在优先级上,服务器校验优先考虑Etag
六、缓存机制
1. 强制缓存优先于协商缓存进行,若强制缓存(Expires和Cache-Control) 生效则直接使用缓存,
若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)
2. 协商缓存由服务器决定是否使用缓存,若协商缓存失效,那么代表该请求的缓存失效,返回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 种:
1. 打开网页,地址栏输入地址: 查找 disk cache 中是否有匹配。如有则使用;如没有则发送网络请求
2. 普通刷新 (F5):因为 TAB 并没有关闭,因此 memory cache 是可用的,会被优先使用(如果匹配的话)。
其次才是 disk cache。
3. 强制刷新 (Ctrl + F5):浏览器不使用缓存,因此发送的请求头部均带有 Cache-control: no-cache
(为了兼容,还带了 Pragma: no-cache),服务器直接返回 200 和最新内容。