浏览器缓存的这些知识点你都清楚吗?

1、浏览器缓存基本认识

分为强缓存和协商缓存css

一、浏览器在加载资源时,先根据这个资源的一些http header判断它是否命中强缓存,强缓存若是命中,浏览器直接从本身的缓存中读取资源,不会发请求到服务器。好比某个css文件,若是浏览器在加载它所在的网页时,这个css文件的缓存配置命中了强缓存,浏览器就直接从缓存中加载这个css,连请求都不会发送到网页所在服务器。html

二、当强缓存没有命中的时候,浏览器必定会发送一个请求到服务器,经过服务器端依据资源的另一些http header验证这个资源是否命中协商缓存,若是协商缓存命中,服务器会将这个请求返回,可是不会返回这个资源的数据,而是告诉客户端能够直接从缓存中加载这个资源,因而浏览器就又会从本身的缓存中去加载这个资源。前端

强缓存与协商缓存的共同点是:若是命中,都是从客户端缓存中加载资源,而不是从服务器加载资源数据;区别是:强缓存不发请求到服务器,协商缓存会发请求到服务器。java

当协商缓存也没有命中的时候,浏览器直接从服务器加载资源数据。webpack

2、强缓存的原理

2.1 介绍

当浏览器对某个资源的请求命中了强缓存时,返回的http状态为200,在chrome的开发者工具的network里面size会显示为from cache,好比京东的首页里就有不少静态资源配置了强缓存,用chrome打开几回,再用f12查看network,能够看到有很多请求就是从缓存中加载的

强缓存是利用Expires或者Cache-Control这两个http response header实现的,它们都用来表示资源在客户端缓存的有效期。nginx

Expires是http1.0提出的一个表示资源过时时间的header,它描述的是一个绝对时间,由服务器返回,用GMT格式的字符串表示,如:Expires:Thu, 31 Dec 2037 23:55:55 GMT

-git

2.2 Expires缓存原理

一、浏览器第一次跟服务器请求一个资源,服务器在返回这个资源的同时,在respone的header加上Expires,如github

二、浏览器在接收到这个资源后,会把这个资源连同全部response header一块儿缓存下来(因此缓存命中的请求返回的header并非来自服务器,而是来自以前缓存的header)web

三、浏览器再请求这个资源时,先从缓存中寻找,找到这个资源后,拿出它的Expires跟当前的请求时间比较,若是请求时间在Expires指定的时间以前,就能命中缓存,不然就不行ajax

四、若是缓存没有命中,浏览器直接从服务器加载资源时,Expires Header在从新加载的时候会被更新

Expires是较老的强缓存管理header,因为它是服务器返回的一个绝对时间,在服务器时间与客户端时间相差较大时,缓存管理容易出现问题,好比随意修改下客户端时间,就能影响缓存命中的结果。因此在http1.1的时候,提出了一个新的header,就是Cache-Control,这是一个相对时间,在配置缓存的时候,以秒为单位,用数值表示,如:Cache-Control:max-age=315360000

-

2.3 Cache-Control缓存原理

一、浏览器第一次跟服务器请求一个资源,服务器在返回这个资源的同时,在respone的header加上Cache-Control,如:

二、浏览器在接收到这个资源后,会把这个资源连同全部response header一块儿缓存下来

三、浏览器再请求这个资源时,先从缓存中寻找,找到这个资源后,根据它第一次的请求时间和Cache-Control设定的有效期,计算出一个资源过时时间,再拿这个过时时间跟当前的请求时间比较,若是请求时间在过时时间以前,就能命中缓存,不然就不行

四、若是缓存没有命中,浏览器直接从服务器加载资源时,Cache-Control Header在从新加载的时候会被更新

Cache-Control描述的是一个相对时间,在进行缓存命中的时候,都是利用客户端时间进行判断,因此相比较Expires,Cache-Control的缓存管理更有效,安全一些。

这两个header能够只启用一个,也能够同时启用,当response header中,Expires和Cache-Control同时存在时,Cache-Control优先级高于Expires:

=

3、强缓存的管理

前面介绍的是强缓存的原理,在实际应用中咱们会碰到须要强缓存的场景和不须要强缓存的场景,一般有2种方式来设置是否启用强缓存

一、经过代码的方式,在web服务器返回的响应中添加Expires和Cache-Control Header

二、经过配置web服务器的方式,让web服务器在响应资源的时候统一添加Expires和Cache-Control Header

好比在javaweb里面,咱们可使用代码设置强缓存

还能够经过java代码设置不启用强缓存

nginx和apache做为专业的web服务器,都有专门的配置文件,能够配置expires和cache-control,这方面的知识,若是你对运维感兴趣的话,能够在百度上搜索nginx 设置 expires cache-control或 apache 设置 expires cache-control 都能找到很多相关的文章。

因为在开发的时候不会专门去配置强缓存,而浏览器又默认会缓存图片,css和js等静态资源,因此开发环境下常常会由于强缓存致使资源没有及时更新而看不到最新的效果,解决这个问题的方法有不少,经常使用的有如下几种

处理缓存带来的问题

一、直接ctrl+f5,这个办法能解决页面直接引用的资源更新的问题

二、使用浏览器的隐私模式开发

三、若是用的是chrome,能够f12在network那里把缓存给禁掉(这是个很是有效的方法)

四、在开发阶段,给资源加上一个动态的参数,如css/index.css?v=0.0001,因为每次资源的修改都要更新引用的位置,同时修改参数的值,因此操做起来不是很方便,除非你是在动态页面好比jsp里开发就能够用服务器变量来解决(v=${sysRnd}),或者你能用一些前端的构建工具来处理这个参数修改的问题

五、若是资源引用的页面,被嵌入到了一个iframe里面,能够在iframe的区域右键单击从新加载该页面,以chrome为例

六、若是缓存问题出如今ajax请求中,最有效的解决办法就是ajax的请求地址追加随机数

七、还有一种状况就是动态设置iframe的src时,有可能也会由于缓存问题,致使看不到最新的效果,这时候在要设置的src后面添加随机数也能解决问题

八、若是你用的是grunt和gulp、webpack这种前端工具开发,经过它们的插件好比grunt-contrib-connect来启动一个静态服务器,则彻底不用担忧开发阶段的资源更新问题,由于在这个静态服务器下的全部资源返回的respone header中,cache-control始终被设置为不缓存

4、强缓存的应用

强缓存是前端性能优化最有力的工具,没有之一,对于有大量静态资源的网页,必定要利用强缓存,提升响应速度。一般的作法是,为这些静态资源所有配置一个超时时间超长的Expires或Cache-Control,这样用户在访问网页时,只会在第一次加载时从服务器请求静态资源,其它时候只要缓存没有失效而且用户没有强制刷新的条件下都会从本身的缓存中加载,好比前面提到过的京东首页缓存的资源,它的缓存过时时间都设置到了2026年

然而这种缓存配置方式会带来一个新的问题,就是发布时资源更新的问题,好比某一张图片,在用户访问第一个版本的时候已经缓存到了用户的电脑上,当网站发布新版本,替换了这个图片时,已经访问过第一个版本的用户因为缓存的设置,致使在默认的状况下不会请求服务器最新的图片资源,除非他清掉或禁用缓存或者强制刷新,不然就看不到最新的图片效果

文章提到的东西都属于理论上的解决方案,不过如今已经有不少前端工具可以实际地解决这个问题,因为每一个工具涉及到的内容细节都有不少,本文没有办法一一深刻介绍。有兴趣的能够去了解下grunt gulp webpack fis 还有edp这几个工具,基于这几个工具都能解决这个问题,尤为是fis和edp是百度推出的前端开发平台,有现成的文档能够参考:

http://fis.baidu.com/fis3/api...

http://ecomfe.github.io/edp/d...

强缓存还有一点须要注意的是,一般都是针对静态资源使用,动态资源须要慎用,除了服务端页面能够看做动态资源外,那些引用静态资源的html也能够看做是动态资源,若是这种html也被缓存,当这些html更新以后,可能就没有机制可以通知浏览器这些html有更新,尤为是先后端分离的应用里,页面都是纯html页面,每一个访问地址可能都是直接访问html页面,这些页面一般不增强缓存,以保证浏览器访问这些页面时始终请求服务器最新的资源

=

5、协商缓存的原理

5.1 介绍

当浏览器对某个资源的请求没有命中强缓存,就会发一个请求到服务器,验证协商缓存是否命中,若是协商缓存命中,请求响应返回的http状态为304而且会显示一个Not Modified的字符串,好比你打开京东的首页,按f12打开开发者工具,再按f5刷新页面,查看network,能够看到有很多请求就是命中了协商缓存的

查看单个请求的Response Header,也能看到304的状态码和Not Modified的字符串,只要看到这个就可说明这个资源是命中了协商缓存,而后从客户端缓存中加载的,而不是服务器最新的资源

5.2 Last-Modified,If-Modified-Since控制协商缓存

一、浏览器第一次跟服务器请求一个资源,服务器在返回这个资源的同时,在respone的header加上Last-Modified的header,这个header表示这个资源在服务器上的最后修改时间

二、浏览器再次跟服务器请求这个资源时,在request的header上加上If-Modified-Since的header,这个header的值就是上一次请求时返回的Last-Modified的值

三、服务器再次收到资源请求时,根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化,若是没有变化则返回304 Not Modified,可是不会返回资源内容;若是有变化,就正常返回资源内容。当服务器返回304 Not Modified的响应时,response header中不会再添加Last-Modified的header,由于既然资源没有变化,那么Last-Modified也就不会改变,这是服务器返回304时的response header

四、浏览器收到304的响应后,就会从缓存中加载资源

五、若是协商缓存没有命中,浏览器直接从服务器加载资源时,Last-Modified Header在从新加载的时候会被更新,下次请求时,If-Modified-Since会启用上次返回的Last-Modified值

【Last-Modified,If-Modified-Since】都是根据服务器时间返回的header,通常来讲,在没有调整服务器时间和篡改客户端缓存的状况下,这两个header配合起来管理协商缓存是很是可靠的,可是有时候也会服务器上资源其实有变化,可是最后修改时间却没有变化的状况,而这种问题又很不容易被定位出来,而当这种状况出现的时候,就会影响协商缓存的可靠性。因此就有了另一对header来管理协商缓存,这对header就是【ETag、If-None-Match】。它们的缓存管理的方式是

5.3 ETag、If-None-Match控制协商缓存

一、浏览器第一次跟服务器请求一个资源,服务器在返回这个资源的同时,在respone的header加上ETag的header,这个header是服务器根据当前请求的资源生成的一个惟一标识,这个惟一标识是一个字符串,只要资源有变化这个串就不一样,跟最后修改时间没有关系,因此能很好的补充Last-Modified的问题

二、浏览器再次跟服务器请求这个资源时,在request的header上加上If-None-Match的header,这个header的值就是上一次请求时返回的ETag的值

三、服务器再次收到资源请求时,根据浏览器传过来If-None-Match和而后再根据资源生成一个新的ETag,若是这两个值相同就说明资源没有变化,不然就是有变化;若是没有变化则返回304 Not Modified,可是不会返回资源内容;若是有变化,就正常返回资源内容。与Last-Modified不同的是,当服务器返回304 Not Modified的响应时,因为ETag从新生成过,response header中还会把这个ETag返回,即便这个ETag跟以前的没有变化

四、浏览器收到304的响应后,就会从缓存中加载资源。

6、协商缓存的管理

协商缓存跟强缓存不同,强缓存不发请求到服务器,因此有时候资源更新了浏览器还不知道,可是协商缓存会发请求到服务器,因此资源是否更新,服务器确定知道。大部分web服务器都默认开启协商缓存,并且是同时启用【Last-Modified,If-Modified-Since】和【ETag、If-None-Match】,好比apache:

若是没有协商缓存,每一个到服务器的请求,就都得返回资源内容,这样服务器的性能会极差。

【Last-Modified,If-Modified-Since】和【ETag、If-None-Match】通常都是同时启用,这是为了处理Last-Modified不可靠的状况。

有一种场景须要注意

分布式系统里多台机器间文件的Last-Modified必须保持一致,以避免负载均衡到不一样机器致使比对失败;

分布式系统尽可能关闭掉ETag(每台机器生成的ETag都会不同);

京东页面的资源请求,返回的repsones header就只有Last-Modified,没有ETag:

协商缓存须要配合强缓存使用,你看前面这个截图中,除了Last-Modified这个header,还有强缓存的相关header,由于若是不启用强缓存的话,协商缓存根本没有意义

=

7、相关浏览器行为对缓存的影响

若是资源已经被浏览器缓存下来,在缓存失效以前,再次请求时,默认会先检查是否命中强缓存,若是强缓存命中则直接读取缓存,若是强缓存没有命中则发请求到服务器检查是否命中协商缓存,若是协商缓存命中,则告诉浏览器仍是能够从缓存读取,不然才从服务器返回最新的资源。这是默认的处理方式,这个方式可能被浏览器的行为改变:

一、当ctrl+f5强制刷新网页时,直接从服务器加载,跳过强缓存和协商缓存;

二、当f5刷新网页时,跳过强缓存,可是会检查协商缓存

来源:http://blog.poetries.top/2019...

image