前言
缓存可以说是性能优化中比较简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离,减少延迟,并且由于缓存文件可以重复利用,还可以减少宽带,降低网络负荷。
对于一个数据请求来说,可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求,亦或者发起了请求但后端数据没有改变,那么就没有必要再将数据回传回来了,这样就减少了响应数据。
缓存过程分析
浏览器与服务器通信的方式为应答模式,就是:浏览器发起HTTP请求-服务器响应该请求,**那么浏览器时怎么确定一个资源该不该缓存,如何去缓存的呢?**浏览器第一次向服务器发起该请求后拿到结果后,将请求结果和缓存标识存入浏览器缓存,浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的。
第一次发送请求
由上图可以知道:
- 浏览器每次发起请求,都会先在浏览器缓存中查找该请求的结果以及缓存标识
- 浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中
以上两点就是浏览器缓存机制的关键,它确保了每个请求的缓存存入与读取,只要我们再理解浏览器缓存的使用规则,那么所有问题就迎刃而解了,本文也将围绕这这点进行详细分析,为了方便大家理解,这里我们根据是否需要向服务器重新发起HTTP请求将缓存过程分为两部分,分别是强缓存和协商缓存,在此之前,我们先了解一下浏览器缓存的位置
缓存位置
从缓存位置上来说可以分为4种,并且各自有优先级,当依次查找缓存且都没有命中的时候,才会去请求网络(排名从优先级高-低)
- Memory Cache
- Service Worker
- Disk Cache
- Push Cache
Memory Cache
Memory Cache 就是内存中的缓存,主要包含的是当前页面中已经抓取到的资源,例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快,内存缓存虽然读取高效,可是缓存持续性很短,会随着进程的释放而释放,一旦我们关闭Tab页面,内存中的缓存也就被释放了
既然内存缓存读取这么高效,我们是不是能让数据都存放到内存中呢?
显然,这是不可能的。计算机中的内存一定比硬盘容量小得多,操作系统需要精打细算内存的使用,所以能让我们使用的内存必然不多
内存缓存中有一块重要的缓存资源是preloader相关指令(例如 <link rel="prefetch")下载的资源,总说周知,preloader的相关指令已经是页面优化的常见手段之一,它可以一边解析js/css文件,一边网络请求下一个资源
内存缓存在缓存资源时,并不关心返回资源的HTTP资源投Cache-Control是什么值,同时资源的匹配也并非仅仅是对URL做匹配,还可能会对Content-Type,CORS等其他特征做校验
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中获取的内容
Disk Cache
Disk Cache 也就是储存在硬盘中的缓存,读取数据比较慢,但是什么都能存储,与Memory Cache相比的话,胜在容量和存储时效性
在所有浏览器缓存中,Disk Cache覆盖面基本是最大的。**它会根据HTTP Hearder中的字段判断哪些资源需要缓存,哪些资源可以不请求直接使用,哪些资源过期了需要重新请求。并且即使在跨站点的情况下,相同地址的资源一旦被磁盘缓存下来,就不会再次去请求数据。**绝大部分的缓存都来自Disk Cache
那么问题来了,**究竟浏览器会将哪些文件放在内存中,哪些放到硬盘中呢?**说法不一,但个人认为:对于大文件,大概率不会存储到内存中,反之优先;当前系统内存使用率高的话,文件优先存储到硬盘
Push Cache
Push Cache(推送缓存) 是HTTP/2中的内容,当以上三种缓存都没有命中时,它才会被使用。**它只在会话(Session)中存在,一旦会话结束就会被释放,并且缓存时间也很短暂。**在Chrome浏览器中只有大概五分钟左右,同时它也并非严格执行HTTP头中的缓存指令;总结了Push Cache的几个结论:
- 所有资源都能被推送,并且能够被缓存,但是Edge和Safari浏览器支持相对比较差
- 可以推送no-cache和no-store的资源
- 一旦连接被关闭,Push Cache就被释放
- Push Cache中的缓存只能被使用一次
- 浏览器可以拒绝接受已经存在的资源推送
- 多个页面可以使用同一个HTTP/2的连接,也就可以使用同一个Push Cache。这主要还是依赖浏览器的实现而定,但出于对性能的考虑,有的浏览器会对相同域名但不同tab标签使用同一个HTTP连接
如果上面四种缓存都没有被命中的话,只有发起请求来获取资源了
因此,为了考虑性能问题,大部分的接口都应该选择好缓存策略,通常浏览器缓存策略分为两大类:(Expires/Cache-control) / (Last-Modified/if-Modified-Since / Etag/if-None-Match) (下面会讲)
两大缓存策略
Expires和Cache-Control
这两个方法的特点是:不会向服务器发送请求,直接从缓存中读取资源,在Chrome控制台的Network选项中可以看到该请求返回200的状态码,并且Size显示from disk cache 或from memory cache。可以通过设置两种HTTP Header 实现:Expires和Cache-Control
Expires
缓存过期时间,用来指定资源到期的时间,是服务器端的具体的时间点,怎么说呢?也就是:Expires=max-age +请求时间,需要和Last-modified结合使用。Expires是Web服务器响应消息头字段,在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存读取数据,而无需再次请求
值得一提的是,Expires是HTTP/1的产物,受限于本地时间,如果修改了本地时间,可能会造成缓存失效
Cache-Control
**在HTTP/1.1中,Cache-Control是最重要的规则,主要用于控制网页缓存。比如当Cache-Control:max-age=300时,则代表在这个请求正确返回时间(浏览器也会记录下来)**的五分钟内再次加载资源,就会命中(Expires/Cache-Control),而Caceh-Control可以在请求头或者响应头中设置,并且可以组合使用多种指令:
public:将所有内容都将被缓存(客户端和代理服务器都可缓存),具体来说响应可被任何中间节点缓存,如Server=>Proxy1=>proxy2=>Browser,中间的proxy可以缓存资源,比如下次再请求同一资源proxy1直接把自己缓存的东西给Browser而不再向proxy2要
private:所有内容只有客户端可以缓存,Cache-Control的默认取值。具体来说,表示中间节点不允许缓存,对于Server=>Proxy1=>proxy2=>Browser,proxy会老老实实把Server返回的数据发送给proxy1,自己不缓存任何数据。当下次Browser再次请求时,proxy会做好请求转发而不是自作主张给自己缓存的数据
no-cache:客户端缓存内容,是否使用缓存则需要经过(Last-Modified/if-Modified-Since / Etag/if-None-Match)来验证决定。表示不使用Cache-Control的缓存控制方式做前置验证,而是使用Etag或者Last-Modified字段来控制缓存。需要注意的是,no-cache这个名字有一点误导。设置了no-cache后,并不是说浏览器就不再缓存数据,只是浏览器在使用缓存数据时,需要先确认一下数据是否还跟服务器保持一致
no-store:所有内容都不会被缓存,即使不使用**(Expires/Cache-control),也不使用(Last-Modified/if-Modified-Since / Etag/if-None-Match)**
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其实事过时的产物,现阶段它的存在只是一种兼容性的写法
使用Expires或Cache-Control来判断是否缓存的一句来自于是否超出某个时间或某个时间段,而不关心服务器端文件是否已经更新,这可能会导致加载文件不是服务器端最新的内容,那么我们如何获知服务器端内容是否已经发生了更新呢?此时我们就需要用到** (Last-Modified/if-Modified-Since / Etag/if-None-Match)**
Last-Modified 和 Etag
Last-Modified 和 Etag就是在Expires和cache-Control缓存失效后,浏览器携带缓存标识向服务器发起请求,由服务器根据缓存标识来决定是否使用缓存的过程,可通过设置两种HTTP Header实现:Last-Modified和ETag,大致分为两种情况:
Expires和Cache-Control失效两种情况:
Expires和Cache-Control生效,返回304和Not Modified
Expires和Cache-Control失效,返回200和请求结果
Last-Modified和If-Modified-Since
浏览器在第一次访问资源时,服务器返回资源的同时,在response header
中添加Last-Modified的header,值是这个资源在服务器上的最后修改时间,浏览器接收后缓存文件和header;
Last-Modified: Fri, 23 Jul 2023 14:26:00 GMT
浏览器下一次请求这个资源,浏览器检测到有Last-Modified这个header,于是添加if-Modified-Since这个header,值就是Last-Modified中的值;服务器再次收到这个资源请求,会根据If-Modified-Since中的值与服务器中这个资源的最后修改时间对比,如果没有发生变化,返回304和空的响应体,直接从缓存读取**,如果If-Modified-Since的时间小于服务器中的这个资源的最后修改时间**,说明文件有更新,于是返回新的资源文件和200
弊端
如果本地打开缓存文件,即使没有对文件进行修改,但还是会造成Last-Modified 被修改,服务端不能命中缓存导致发送相同的资源
因为Last-Modified 只能以秒计时,如果在不可感知的时间内修改完成文件,那么服务端会认为资源还是命中了,不会返回正确的资源
既然根据文件修改时间来决定是否缓存尚有不足,那么能否可以直接根据文件内容是否修改来决定缓存策略? 在HTTP/1.1出现了ETag 和If-None-Match
ETag和If-None-Match
ETag是服务器响应请求时,返回当前资源文件的一个唯一标识(由服务器生成),只要资源有变化,ETag就会重新生成。浏览器在下一次加载资源向服务器发送请求时,会将上一次返回的ETag值放到request header里的If-None-Match里,服务器只需要比较客户端传来的If-None-Match跟自己服务器上该资源的ETag是否一致,就能很好的判断资源相对客户端而言是否被修改过了。如果服务器发现ETag匹配不上,那么直接以常规GET 200 回包形式将新的资源(也包含了新的ETag)发给客户端;如果ETag是一致的,则直接返回304告知客户端直接使用本地缓存即可
两者区别
精度上:ETag优先于Last-Modified;Last-Modified的时间单位是秒,如果某个文件在1秒内改变了多次,那么他们的Last-Modified其实并没有体现出来修改,但是ETag每次都会改变确保了精度;如果是负载均衡的服务器,各个服务器生成的Last-Modified也可能不一致
性能上:ETag要逊于Last-Modified,毕竟Last-Modified只需要记录时间,而ETag需要服务器通过算法来计算出一个hash值或版本号
优先级上:服务器校验优先考虑ETag(根据精度和灵活性)
浏览器缓存机制
Expires和Cache-Control优先于Last-Modified和ETag,若Expires/Cache-Control生效则直接使用缓存,若不生效则进行Last-Modified/ETag,使用(Last-Modified/ETag)由服务器决定是否试用缓存,若(Last-Modified/ETag)失效,那么代表该请求的缓存失效,返回200,重新返回资源和缓存标识,再存入浏览器缓存中;生效则返回304,继续使用缓存
那么如果什么缓存策略都没设置,那么浏览器会怎么处理?
对于这种情况,浏览器会采用一个启发式的算法,通常会去响应头中的Date减去Last-Modified的值10%作为缓存时间
为什么需要浏览器缓存?
对于浏览器的缓存,主要针对的事前端的静态资源,最好的效果就是,在发起请求之后,拉取相应的静态资源,并保存在本地,如果服务器的静态没有更新,那么在下次请求的时候,就可以直接从本地上读取即可**,这样就可以大大的减少了请求的次数,提高了网站的性能,减少了服务器的负担,加快了客户端加载网页的加载速度,减少了多余网络数据传输**
实际场景应用
频繁变动的资源
Cache-Control:no-cache
对于频繁变动的资源,首先需要使用Cache-Control:no-cache是浏览器每次都请求服务器,然后配合ETag或者Last-Modeified来验证资源是否有效,这样的做法虽然不能节省请求数量,但是能显著减少响应数据大小
不常变化的资源
Cache-Control:max-age=31636000
通常处理这类资源时,给它们的Cache-Control配置一个很大的max-age,这样浏览器之后请求相同的URL会命中Expires/Cache-Control。而为了解决更新的问题,就需要在文件名(或者路径)中添加hash、版本号等动态字符,之后更改动态字符,从而达到更改引用URL的目的,让之前的Cache-Control失效(并不是立即失效,而是不再使用了)(lodash.min.js,jq3.3.1.min.js)均是采用这个模式
用户行为对浏览器缓存的影响
用户行为对浏览器缓存的影响,指的是用户在浏览器如何操作时,会触发怎么样的缓存策略;大致分为3种:
- 打开网页,地址栏输入地址,查找disk-cache中是否有匹配。如果有则使用;没有则发送请求
- 普通刷新(F5):因为tab并没有关闭,因此memory cache 是可用的,会被优先使用(能匹配上的情况下).其次就是disk cache
- 强制刷新(Ctrl +F5):浏览器不使用缓存,因此发送的请求头均带有Cache-Control:no-cache(为了兼容还带上了Param:no-cache),服务器直接返回200和最新的内容