为什么需要建立缓存策略
缓存对于web应用有着重要作用,通常我们需要对静态资源进行缓存。
缓存通常分为三种: 服务器端缓存,CDN缓存,浏览器端缓存。 其中浏览器端的缓存不会发起HTTP请求,所以耗时最短。在大型应用或者资源比较多的情况下,合理的缓存的策略能大大提高页面的加载速度,和降低带宽成本。
缓存策略是服务器端来进行配置的,但作为有追求的前端er,需要掌控全场。
什么是缓存策略
通常使用的缓存控制分为两种:强缓存和协商缓存。
强缓存
在HTTP1.0时代,缓存是交由header下边的expires来控制的,其值为一个具体时间。但因为会有这种case: 客户端的时间和服务器端的时间相差很大,导致缓存策略出错。
所以在HTTP1.1时代,新增了一个专门管理缓存的属性: Cache-Control
其常用值有:no-store
, no-cache
, max-age
, s-maxage
, private
, public
在强缓存策略中,我们通常需要给 cache-control
设置为 max-age=num
,num表示缓存的有效期是多少秒。
因为 Cache-Control
是新标准,所以优先级高于 expires
。
no-store
: 静态资源是不进行重用的,也就是不缓存的。
no-cache
: 每次请求都需要重新验证,不走三层缓存结构中的最后一层。也就是不走强缓存,但会走协商缓存。
max-age
: 表示资源的有效期
s-maxage
:表示公共缓存区(CDN)的资源有效期,优先级高于max-age
,通常需要搭配pubic
使用
public
: 公共缓存区即CDN
private
: 本地缓存区即浏览器的缓存区
协商缓存
协商缓存是需要向服务器发送请求来协商使用哪种缓存策略。对应的配置有:
last-modified && if-modified-since
Etag && if-none-match
先来说说 Last-modified
,这是服务器向浏览器返回的该文件的最后修改时间,这样在浏览器下次请求服务器的时候会在请求头上带上 if-modified-since
,服务器会对 if-modified-since
和 last-modified
进行比对,如果一致,就返回304。如果不一致,就重新返回最新文件,状态码就还是200。
但是会有这种case:
当文件内容未修改,但是文件的修改日期被改变了。
那么我们不希望再重新读取文件,还应该返回304最合适。
所以 Etag
应运而生。 Etag
是对文件内容的 Hash 值,所以只要文件内容未改变,Etag
就不会改变。当服务端给浏览器返回 Etag
之后,下次浏览器去请求的时候就会携带 if-none-match
,服务器会比对两者,从而做相应处理。和 last-modified
类似。但是需要注意的是,Etag
的优先级是要高于 last-modified
的。
以上的策略串联成一个思维导图: