缓存可以说是性能优化中简单⾼效的⼀种优化⽅式了,它可以显著减少⽹络传输所带来的损耗。
对于⼀个数据请求来说,可以分为发起⽹络请求、后端处理、浏览器响应三个步骤。
浏览器缓存可以帮助我们在第⼀和第三步骤中优化性能。
⽐如说直接使⽤缓存⽽不发起请求,或者发起了请求但后端存储的数据和前端⼀致,那么就没有必要再将数据回传回来,这样就减少了响应数据。
从缓存位置上来说分为四种:
并且各⾃有优先级,当依次查找缓存且都没有命中的时候,才会去请求⽹络。
- Service Worker
- Memory Cache
- Disk Cache
- Push Cache
一、Service Worker
service Worker是运行在浏览器背后的独立线程,传输协议必须为https。
service Worker 的缓存与浏览器其他内建的缓存机制不同,它可以让我们⾃由控制,缓存哪些⽂件、如何匹配缓存、如何读取缓存,并且缓存是持续性的。
当 Service Worker 没有命中缓存的时候,我们需要去调⽤ fetch 函数获取数据。也就是说,如果我们没有在 Service Worker 命中缓存的话,会根据缓存查找优先级去查找数据。但是不管我们是从 Memory Cache 中还是从⽹络请求中获取的数据,浏览器都会显示我们是从 Service Worker 中获取的内容。
可以通过拦截请求的方式,查询是否存在缓存,存在缓存的话,就可以直接读取缓存文件,否则就去请求数据。
二、Memory Cache (内存中的缓存)
Memory Cache 也就是内存中的缓存,读取内存中的数据肯定⽐磁盘快。但是内存缓存虽然读取⾼效,可是缓存持续性很短,会随着进程的释放⽽释放。 ⼀旦我们关闭 Tab ⻚⾯,内存中的缓存也就被释放了。
当我们访问过⻚⾯以后,再次刷新⻚⾯,可以发现很多数据都来⾃于内存缓存。
那么既然内存缓存这么⾼效,我们是不是能让数据都存放在内存中呢?
先说结论,这是不可能的。⾸先计算机中的内存⼀定⽐硬盘容量⼩得多,操作系统需要精打细算内存的使⽤,所以能让我们使⽤的内存必然不多。内存中其实可以存储⼤部分的⽂件,⽐如说 JS 、 HTML 、 CSS 、图⽚等等。
Memory Cache在缓存资源时,并不关心返回资源的http缓存头cache-control是什么值,同时资源的匹配也并非仅仅是对url做匹配,还可能会对content-type,cors等其他特征做校验。
三、Disk Cache (硬盘中的缓存)
Disk Cache 也就是存储在硬盘中的缓存,读取速度慢点,但是什么都能存储到磁盘中, ⽐Memory Cache胜在容量和存储时效性上。
在所有浏览器缓存中, Disk Cache 覆盖⾯基本是最⼤的。它会根据 HTTP Header中的字段,判断哪些资源需要缓存,哪些资源可以不请求直接使⽤,哪些资源已经过期需要重新请求。并且即使在跨站点的情况下,相同地址的资源⼀旦被硬盘缓存下来,就不会再次去请求数据,绝大部份缓存,来自硬盘缓存。
对于⼤⽂件来说,⼤概率是不存储在内存中的,反之优先当前系统内存使⽤率⾼的话,⽂件优先存储进硬盘。
四、Push Cache (推送缓存)
Push Cache 是 HTTP/2 中的内容,当以上三种缓存都没有命中时,它才会被使⽤。并且缓存时间也很短暂,只在会话(Session )中存在,⼀旦会话结束就被释放。
在chrome浏览器中只有5分钟左右,同时它也并非严格执行http头中的缓存指令。
- Push Cache 在国内能够查到的资料很少,也是因为 HTTP/2 在国内不够普及,但是 HTTP/2 将会是⽇后的⼀个趋势,所有的资源都能被推送,但是 Edge 和 Safari 浏览器兼容性不怎么好
- 可以推送 no-cache 和 no-store 的资源
- ⼀旦连接被关闭, Push Cache 就被释放
- 多个⻚⾯可以使⽤相同的
- HTTP/2 连接,也就是说能使⽤同样的缓存
- Push Cache 中的缓存只能被使⽤⼀次
- 浏览器可以拒绝接受已经存在的资源推送
- 你可以给其他域名推送资源
五、网络请求
- 如果所有缓存都没有命中的话,那么只能发起请求来获取资源了。
- 那么为了性能上的考虑,⼤部分的接⼝都应该选择好缓存策略。
六、缓存策略
通常浏览器缓存策略分为两种:强缓存和协商缓存,并且缓存策略都是通过设置 HTTP Header 来实现。
强制缓存优先于协商缓存进行,若强制缓存(Expires和Cache-Control)生效,则直接使用缓存。若不生效,则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match),协商缓存由服务器决定是否使用缓存,若协商缓存失效,那么代表该请求的缓存失效,返回200,重新返回资源和缓存标识,再存入浏览器缓存中。生效则返回304,继续使用缓存。
缓存过程:
浏览器与服务器通信的方式:应答模式。即浏览器发送http请求—>服务器响应该请求
浏览器第一次发送http请求,服务器返回请求结果和缓存规则,然后将请求结果和缓存标示存入浏览器缓存。
浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的。
浏览器每次发送请求,都会先在浏览器缓存中查找请求的结果以及缓存标示。
浏览器每次拿到返回的请求结果都会将该结果和缓存标示存入浏览器缓存中。
是否需要向服务器重新发送http请求,将缓存过程分为:强缓存和协商缓存。
1. 强缓存
强缓存不会向服务器发送请求,直接从缓存中读取资源。
强缓存可以通过设置两种 HTTP Header 实现: Expires 和 CacheControl 。
Expires:
Expires 是 HTTP/1 的产物,表示资源会在 Wed, 22 Oct 2018 08:41:00 GMT 后过期,需要再次请求。并且 Expires 受限于本地时间,如果修改了本地时间,可能会造成缓存失效。
Cache-control:
Cache-Control 出现于 HTTP/1.1 ,优先级⾼于 Expires 。该属性值表示资源会在 30 秒后过期,需要再次请求。
Cache-Control 可以在请求头或者响应头中设置,并且可以组合使⽤多种指令。
2. 协商缓存
如果强缓存过期了,就需要浏览器携带缓存标示,向服务器发起请求,由服务器根据缓存标识决定是否使用缓存。
协商缓存可以通过设置两种 HTTP Header 实现: Last-Modified 和 ETag
主要有以下两种情况:
协商缓存生效,返回304和Not Modified
协商缓存失效,返回200和请求结果
1.Last-Modified和If-Modified-Since
当浏览器发起请求验证资源时,如果资源没有做改变,那么服务端就会返回 304 状态码,并且更新浏览器缓存有效期,Last-Modified 和 If-Modified-Since。
Last-Modified 表示本地⽂件最后修改⽇期。
If-Modified-Since 会将 Last-Modified的值发送给服务器,询问服务器在该⽇期后,资源是否有更新,有更新的话就会将新的资源发送回来,否则返回 304 状态码。
注意: Last-Modified 存在⼀些弊端:
1 如果本地打开缓存⽂件,即使没有对⽂件进⾏修改,但还是会造成 Last-Modified 被修改,服务端不能命中缓存导致发送相同的资源
2 因为 Last-Modified 只能以秒计时,如果在不可感知的时间内修改完成⽂件,那么服务端会认为资源还是命中了,不会返回正确的资源。 因为以上这些弊端,所以在 HTTP / 1.1 出现了 ETag
2.ETag和If-None-Match
-
首先在精确度上,Etag要优于Last-Modified。
- ETag 类似于⽂件指纹, If-None-Match 会将当前 ETag 发送给服务器,询问该资源 ETag是否变动,有变动的话就将新的资源发送回来。
-
在性能上,Etag要逊于Last-Modified,毕竟Last-Modified只需要记录时间,而Etag需要服务器通过算法来计算出一个hash值。
-
在优先级上,服务器校验优先考虑Etag。
实际场景应⽤缓存策略
1.频繁变动的资源
对于频繁变动的资源,⾸先需要使⽤ Cache-Control: no-cache。使浏览器每次都请求服务器,然后配合 ETag 或者 Last-Modified 来验证资源是否有效。这样的做法虽然不能节省请求数量,但是能显著减少响应数据⼤⼩。
2、代码⽂件
这⾥特指除了 HTML 外的代码⽂件,因为 HTML ⽂件⼀般不缓存或者缓存时间很短
⼀般来说,现在都会使⽤⼯具来打包代码,那么我们就可以对⽂件名进⾏哈希处理,只有当代码修改后才会⽣成新的⽂件名。基于此,我们就可以给代码⽂件设置缓存有效期⼀年 CacheControl: max-age=31536000 ,这样只有当 HTML ⽂件中引⼊的⽂件名发⽣了改变才会去下载最新的代码⽂件,否则就⼀直使⽤缓存
用户行为对浏览器缓存的影响
打开网页,地址栏输入地址: 查找 disk cache 中是否有匹配。如有则使用;如没有则发送网络请求。
普通刷新 (F5):因为 TAB 并没有关闭,因此 memory cache 是可用的,会被优先使用(如果匹配的话)。其次才是 disk cache。
强制刷新 (Ctrl + F5):浏览器不使用缓存,因此发送的请求头部均带有 Cache-control: no-cache(为了兼容,还带了 Pragma: no-cache),服务器直接返回 200 和最新内容。
状态码:
304: 当浏览器发起请求验证资源时,如果资源没有做改变,那么服务端就会返回 304 状态码,继续使用缓存,并且更新浏览器缓存有效期。
301: 永久跳转。请求的网页已永久移动到新位置。
302: 访问资源不在现有路径。临时性重定向。