聊聊浏览器缓存策略那些事儿

864 阅读26分钟

前言

谈起性能优化,大家一开始就能想到缓存,缓存可以说是软件开发领域进行性能优化最简单高效的一种方式。好的缓存策略可以有效减少数据获取的代价(这里的代价抽象来说就是:传输距离、传输耗时和传输体积)。

譬如,在前端领域使用合适的HTTP缓存可以缩短网页请求资源的距离,减少延迟,并且由于缓存文件可以重复利用,还可以减少带宽,降低网络负荷。基于浏览器本地存储方案进行数据缓存可以有效减少重复的数据请求和解析工作,让用户数据更快展现。

浏览器缓存从缓存类型类型来说可以分为资源缓存和数据缓存,资源缓存也就是常说的HTTP缓存,其可以包含有HTTP Header 缓存机制、缓存位置两个内容,本文将全面梳理浏览器缓存中涉及的知识点,希望为大家提供一些参考。

本文思维导图:

1.png

浏览器缓存

资源缓存

资源缓存的主要对象是web站点的html、js、css、image、video、audio等静态资源文件。浏览器识别这些资源类型主要通过 Content-Type 实体头部,Content-Type标识着资源的MIME类型。

资源缓存因为缓存数据的特殊性(无需解析响应数据体,整个响应体是纯文本数据),可以采用多级缓存方式进行共享存储。也就是说可以在浏览器和服务器之间在加一层或多层代理缓存,代理缓存接受并转发浏览器的请求,然后接收服务器的响应并缓存到本地。

根据是否加油代理缓存,可以将资源缓存归为两类:私有缓存与共享缓存。

共享缓存

共享缓存可以被多个用户使用。例如,ISP 或你所在的公司可能会架设一个 web 代理来作为本地网络基础的一部分提供给用户。这样热门的资源就会被重复使用,减少网络拥堵与延迟。

私有缓存

共享缓存存储的响应能够被多个用户使用。私有缓存只能用于单独用户。所以你在自己浏览器上的看到的缓存资源就是一种私有缓存。这些资源不能跨浏览器共享,更不能跨机器共享。

下图分别示例了无缓存、共享缓存、私有缓存的模式:

image.png

数据缓存

这里的数据缓存是限定在浏览器的缓存,跟服务端的缓存不是一回事儿。

那么浏览器的数据缓存是怎么做到呢?

答案就是 Cookie,Web Storage,IndexDB 三种浏览器本地数据存储API。关于这三种API除了IndexDB大家不常使用外,其他两种应该是用得很频繁吧。所以啊,其实在大家在日常工作中已经大量使用了数据缓存技术。

资源缓存过程分析

资源缓存过程其实是HTTP缓存机制运作的过程:

3.webp

上图给出了浏览器首次(之前从没访问过改站点)发起HTTP请求的大致过程,可以发现:

  • 浏览器每次发起请求,都会先在浏览器缓存中查找该请求的结果以及缓存标识
  • 浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中

HTTP缓存机制发起的时机比我们想象中要更早,在正式发起HTTP网络请求前就已经开始,其最早触发的阶段是浏览器根据缓存标志在“本地”搜索缓存。

image.png

在服务器返回响应后,浏览器会做两件事:

  1. 解析响应资源,是csshtml资源就开始渲染dom,是js资源就启动js引擎执行脚本;
  2. 提取Response Header里的缓存标识,将缓存标识和响应一并缓存。 然后,进入下一轮HTTP请求循环。

HTTP缓存机制

在前端世界里,一个资源(这里主要指js,css,html,image等静态资源)获取过程可以分为发起网络请求、服务端处理、浏览器解析数据三个步骤。浏览器HTTP缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求,或者发起了请求但服务器存储的数据和前端一致,那么就没有必要再将数据回传回来,这样就减少了响应数据量。

缓存位置

HTTP资源缓存位置有四种,并且各自有优先级,当依次查找缓存且都没有命中的时候,才会去请求网络。缓存位置按照优先级排序依次是:

  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 实现缓存功能一般分为三个步骤:

  1. 首先需要先注册 Service Worker
  2. 监听到 install 事件以缓存需要的文件
  3. 查询缓存全局,主要是通过拦截请求的方式查询是否存在缓存,存在缓存的话就可以直接读取缓存文件,否则就去请求数据。

当 Service Worker 没有命中缓存的时候,就需要去调用 xhr/fetch API获取数据。也就是说,如果没有在 Service Worker 命中缓存的话,会根据缓存查找优先级去查找数据。但是不管我们是从 Memory Cache 中还是从网络请求中获取的数据,浏览器都会显示我们是从 Service Worker 中获取的内容。

使用Service Worker 缓存图片demo,效果:

image.png

Memory Cache

Memory Cache 是内存中的缓存(Disk Cache就是磁盘上的缓存)。按照操作系统的常理:先读内存,再读硬盘。

几乎所有的网络请求资源都会被浏览器自动加入到 Memory Cache 中。但是也正因为数量很大但是浏览器占用的内存不能无限扩大这样两个因素,Memory Cache 注定只能是个“短期存储”。常规情况下,浏览器的 TAB 关闭后该次浏览的 Memory Cache 便告失效 (为了给其他 TAB页 腾出内存空间)。而如果极端情况下 (例如一个页面的缓存就占用了超级多的内存),那可能在 TAB 没关闭之前,排在前面的缓存就已经失效了。

刚才提过,几乎所有的请求资源 都能进入 Memory Cache,细分一下有如下几块:

  1. 通过 preloader 加载的资源。如果你对这个机制不太了解,这里做一个简单的介绍,详情可以参阅Web Performance Calendar这篇文章。

    一般来讲,在浏览器打开网页的过程中,会先请求 HTML 然后解析。之后如果浏览器发现了 jscss 等需要解析和执行的资源时,它会使用 CPU 资源对它们进行解析和执行。在古老的年代(大约 2007 年以前),“请求 js/css - 解析执行 - 请求下一个 js/css - 解析执行下一个 js/css” 这样的“串行”操作模式在每次打开页面之前进行着。很明显在解析执行的时候,网络请求是空闲的,这就有了发挥的空间:能不能一边解析执行 js/css,一边去请求下一个(或下一批)资源呢?

    这就是 preloader 要做的事情。不过 preloader 没有一个官方标准,所以每个浏览器的处理都略有区别。例如有些浏览器还会下载 css 中的 @import 内容或者 <video>poster等。

    而这些被 preloader 请求够来的资源就会被放入 Memory Cache 中,供之后的解析执行操作使用。

  2. preload指令标记的资源 (跟上面相比没有‘er’)。实际上这个大家应该更加熟悉一些,例如 <link rel="preload">。这些显式指定的预加载资源,也会被放入 Memory Cache 中。

  3. 根据 HTTP header 标识缓存的资源,这里后面讲HTTP Header缓存控制时会详细介绍。

Memory Cache 机制保证了一个页面中如果有两个相同的请求 (例如两个 src 相同的 <img>,两个 href 相同的 <link>)都实际只会被请求最多一次,避免浪费。

在从 Memory Cache 获取缓存内容时,浏览器会忽视例如 Cache-Control: max-age=0, Cache-Control: no-cache 等缓存头部。例如页面上存在几个相同 src 的图片,即便它们可能被设置为不缓存,但依然会从 Memory Cache 中读取。这是因为 Memory Cache 只是短期使用,大部分情况生命周期只有一次浏览而已。而 Cache-Control: max-age=0 在语义上普遍被解读为“不要在下次浏览时使用”,所以和 Memory Cache 并不冲突。

对于站点中的某个资源,如果是真心不想让其进入缓存,就连短期也不行,那就需要使用 Cache-Control: no-store。存在这个头部配置的话,即便是 Memory Cache 也不会存储。

Disk Cache

Disk Cache 也叫 HTTP Cache,顾名思义是存储在硬盘上的缓存,因此它是持久存储的,是实际存在于文件系统中的。而且它允许相同的资源在跨会话,甚至跨站点的情况下使用,例如两个站点都使用了同一张图片。

Disk Cache 会严格根据 HTTP 头信息中的各类字段来判定哪些资源可以缓存,哪些资源不可以缓存;哪些资源是仍然可用的,哪些资源是过时需要重新请求的。当命中缓存之后,浏览器会从硬盘中读取资源,虽然比起从内存中读取慢了一些,但比起网络请求还是快了不少的。绝大部分的缓存都来自 Disk Cache。

凡是持久性存储都会面临容量增长的问题,Disk Cache 也不例外。在浏览器自动清理时,会有自适应算法去把“最老的”或者“最可能过时的”资源删除,因此是一个一个删除的。不过每个浏览器识别“最老的”和“最可能过时的”资源的算法不尽相同,可能也是它们差异性的体现。

一个疑问:浏览器会把哪些文件丢进内存中?哪些丢进硬盘中?
关于这点,网上说法不一,有博主根据试验得到了如下结论(仅供参考):

  1. 如果开启了Service Worker首先会从Service Worker中拿;
  2. 如果新开一个以前打开过的页面缓存会从Disk Cache中拿(前提是命中强缓存);
  3. 刷新当前页面时浏览器会根据当前运行环境内存来决定是从 Memory Cache 还是 从Disk Cache中拿(可以看到下图最后几个文件有时候是从 Memory Cache中拿,有时候是从Disk Cache中拿)。

Push Cache

Push Cache(推送缓存)是 HTTP/2 中的内容,当以上三种缓存都没有命中时,它才会被使用。

Push Cache只在会话(Session)中存在,一旦会话结束就被释放。并且缓存时间也很短暂,在Chrome浏览器中只有5分钟左右,同时它也并非严格执行HTTP头中的缓存指令。

Push Cache 在国内能够查到的资料很少,也是因为 HTTP/2 在国内不够普及。这里推荐阅读Jake ArchibaldHTTP/2 push is tougher than I thought 这篇文章,文章中的几个结论:

  • 所有的资源都能被推送,并且能够被缓存,但是 Edge 和 Safari 浏览器支持相对比较差
  • 可以推送 no-cache 和 no-store 的资源
  • 一旦连接被关闭,Push Cache 就被释放
  • 多个页面可以使用同一个HTTP/2的连接,也就可以使用同一个Push Cache。这主要还是依赖浏览器的实现而定,出于对性能的考虑,有的浏览器会对相同域名但不同的tab标签使用同一个HTTP连接。
  • Push Cache 中的缓存只能被使用一次
  • 浏览器可以拒绝接受已经存在的资源推送
  • 你可以给其他域名推送资源

HTTP Header缓存控制

在缓存查找阶段,浏览器会按照顺序依次在上面四种缓存位置进行搜索,如果都没有命中,那么只能发起请求来获取资源了。

发起请求获取资源也就意味着HTTP Header缓存控制即将登场。通常HTTP Header缓存策略分为两种:强缓存和协商缓存。 这两种缓存策略都是通过设置 HTTP Header 来实现的。

强缓存

强缓存:不会向服务器发送请求,直接从缓存中读取资源,在chrome控制台的Network选项中可以看到该请求返回200的状态码,并且Size显示 disk cache 或 memory cache(Chrome浏览器中),比如访问 baidu 首页,多刷新几次就能看到缓存效果:

百度缓存.png

强缓存可以通过设置两种 HTTP Header 实现:Expires 和 Cache-Control(Pragma)。

Expires

缓存过期时间,用来指定资源到期的时间,是服务器端的具体的时间点(时间精确到秒)。也就是说,Expires = max-age + 请求时间,需要和Last-Modified结合使用。Expires 是Web 服务器响应消息头字段,在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据,而无需再次请求。

Expires 是 HTTP/1 的产物,受限于本地时间,如果修改了本地时间,可能会造成缓存失效Expires: Wed, 22 Oct 2021 08:41:00 GMT表示资源会在 Wed, 22 Oct 2021 08:41:00 GMT 后过期,需要再次请求。

因此,Expires这个字段设置时有两个明显的缺点:

  1. 由于是绝对时间,用户可能会将客户端本地的时间进行修改,而导致浏览器判断缓存失效,重新请求该资源。此外,即使不考虑自信修改,时差或者误差等因素也可能造成客户端与服务端的时间不一致,致使缓存失效。
  2. 写法太复杂了。表示时间的字符串多个空格,少个字母,都会导致非法属性从而设置失效。

Cache-Control

在HTTP/1.1中,Cache-Control是最重要的缓存控制头,控制站点资源强缓存逻辑。当Cache-Control:max-age=300时,则代表在这个请求正确返回时间(浏览器也会记录下来)的5分钟内再次加载资源,就会命中强缓存。

Cache-Control是通用头,在请求头或者响应头中均可设置,并且可以组合使用多种指令:

image.png

其中有一些属性是需要特别关注的:

  1. public:该指令表示该响应可以被任何中间人(比如中间代理、CDN等)缓存。若指定了public,则一些通常不被中间人缓存的页面,比如 带有HTTP验证信息(帐号密码)的页面 或 某些特定状态码的页面),将会被其缓存。上文提到的共享缓存其实就是一个proxy,所以为了让资源支持共享缓存,应该显示设置Cache-Control:public(因为private是默认值)。
  2. private所有内容只有客户端可以缓存Cache-Control的默认取值。
  3. no-cache:每次有请求发出时,浏览器 or 代理服务器 会将此请求发到服务器(该请求应该会带有与本地缓存相关的验证字段),服务器端会验证请求中所描述的缓存是否过期,若未过期(实际就是返回304),则缓存才使用本地缓存,否则使用服务器上返回资源并更新本地缓存。需要注意的是,no-cache这个名字有一点误导。设置了no-cache之后,并不是说浏览器就不再缓存数据,只是浏览器在使用缓存数据时,需要先确认一下数据是否还跟服务器保持一致。
  4. no-store:缓存中不得存储任何关于客户端请求和服务端响应的内容。每次由客户端发起的请求都会下载完整的响应内容。

上面列表中的属性值可以混合使用,例如 Cache-Control:public, max-age=36000。在混合使用时,它们的优先级如下图

image.png

Pragma

Pragma 是HTTP/1.0标准中定义的一个header属性,请求中包含Pragma的效果跟在头信息中定义Cache-Control: no-cache相同,但是HTTP的响应头没有明确定义这个属性,所以它不能拿来完全替代HTTP/1.1中定义的Cache-Control头。通常定义Pragma以向后兼容基于HTTP/1.0的客户端。

Progma头只有一个属性值:no-cache

由于 Pragma 在 HTTP 响应中的行为没有确切规范,所以不能可靠替代 HTTP/1.1 中通用首部 Cache-Control,尽管在请求中,假如 Cache-Control 不存在的话,它的行为与 Cache-Control: no-cache 一致。建议只在需要兼容 HTTP/1.0 客户端的场合下应用 Pragma 首部。

所以,大家对于Progma只需要了解就行,实际中基本用不到。

Expires 和 Cache-Control对比

其实这两者差别不大,区别就在于 Expires 是http1.0的产物,Cache-Control是http1.1的产物,两者同时存在的话,Cache-Control优先级高于Expires;在某些不支持HTTP1.1的环境下,Expires就会发挥用处。Expires其实是历史的产物,现阶段它的存在只是一种兼容性的写法。

强缓存模式下,客户端判断是否使用缓存的依据是当前缓存是否在有效期内,而不关心服务器端文件是否已经更新,这时候如果服务端更新了资源文件,那就可能导致客户端资源其实是过时的,对用户使用带来一定困扰。

看到这是大家可能会问:设置no-cache时不是会请求服务器做一次缓存有效判断嘛?那应该不会出现使用过时缓存的情况呀。理想很丰满,现实很残酷。结合在文章最开始说到的缓存位置,如果某个 header 设置为Cache-Control:no-cache的资源缓存位置是Memory Cache,那么浏览器将不会去请求服务器做一次缓存鉴别,而是直接从Memory Cache读取资源!

那如何确保本地的缓存跟服务端资源及时同步呢? 此时就需要用到协商缓存策略。

协商缓存

强协商的优先级高于协商缓存,当强缓存失效后,协商缓存机制开始发挥作用。此时,浏览器将携带缓存标识向服务器发起请求,由服务器根据缓存标识决定是否使用缓存的过程,主要有以下两种情况:

  • 协商缓存生效,返回304和Not Modified

image.png

  • 协商缓存失效,返回200和请求结果

image.png

控制协商缓存的 HTTP header 有两类:Last-Modified(响应头)/If-Modified-Since(请求头) 和 ETag(响应头)/If-None-Match(请求头),接下来将会分别讲述这两类控制头的控制机制。

Last-Modified / If-Modified-Since

Last-Modified是响应头,标识这当前资源在服务器上的最后修改时间(精确到秒)。浏览器接收后缓存文件和header:

Last-Modified  是一个响应首部,其中包含源头服务器认定的资源做出修改的日期及时间。 它通常被用作一个验证器来判断接收到的或者存储的资源是否彼此一致。由于精确度比  ETag 要低,所以这是一个备用机制。包含有  If-Modified-Since 或 If-Unmodified-Since 首部的条件请求会使用这个字段。

image.png

Last-Modified / If-Modified-Since 的配合过程是这样的:浏览器下一次请求这个资源时,浏览器检测到有Last-Modified这个header,于是添加If-Modified-Since这个header到请求头中,其值就是Last-Modified中的值;服务器收到这个资源请求后,会根据 If-Modified-Since 中的值与服务器中这个资源的最后修改时间对比,如果没有变化,返回304状态码和空的响应体;如果If-Modified-Since的时间早于服务器中这个资源的最后修改时间,说明文件有更新,于是返回新的资源文件和200状态码。下图是缓存还在有效期,响应304的流程图

image.png

但是 Last-Modified 还是存在一些不足:

  • 如果本地打开缓存文件,即使没有对文件进行修改,但还是会造成 Last-Modified 被修改,服务端判断不缓存失效从而发送相同的资源到客户端;
  • Last-Modified 记录的修改时间只能精确到秒,服务端如果在秒级时间内完成了资源更新,会造成Last-Modified记录的时间戳没有变化,那么服务端会认为前端缓存资源还是有效的,不会返回正确的最新资源。

根据文件修改时间来决定是否缓存尚有不足,能否可以直接根据文件内容是否修改来决定缓存策略?

答案就是: ETagIf-None-Match

ETag / If-None-Match

ETagHTTP响应头是资源的特定版本的标识符。如果给定URL中的资源更改,则一定要生成新的Etag值(这一般是web容器的自主行为)。 对于响应头中拥有ETag字段的资源,浏览器在下一次请求该资源时,会将上一次返回的Etag值放到请求头里的If-None-Match里,服务器只需要比较客户端传来的If-None-Match跟自己服务器上该资源的ETag是否一致,就能判断当前资源是否为最新资源。在服务端,如果ETag匹配不上,那么服务端将返回 200 状态码并在响应体中加上新的资源文件;如果匹配成功,则返回304状态码和空的响应体。

是不是跟Last-Modified / If-Modified-Since的匹配过程很类似?是的,流程完全一致,只是匹配标识由时间戳变为了一个hash值。

下图是 ETag / If-None-Match匹配成功流程:

image.png

两类协商缓存的对比

Last-Modified / If-Modified-SinceETag / If-None-Match都属于HTTP/1.1协议里的Header,两者的出现没有时间的先后顺序。那么为什么要设计这两套协商缓存策略呢?

为了满足不同的使用场景,有些场景对缓存失效精度要求较高,有些要求精度要求低但对服务器资源损耗较为敏感,所以就设计了两套协商缓存。两者主要特点对比如下:

  • 在精确度上,Etag要优于Last-Modified;

    Last-Modified的时间单位是秒,如果某个文件在1秒内改变了多次,那么他们的Last-Modified其实并没有体现出来修改,但是Etag每次都会改变确保了精度;如果是负载均衡的服务器,各个服务器生成的Last-Modified也有可能不一致。

  • 在性能上,Etag要逊于Last-Modified,毕竟Last-Modified只需要记录时间,而Etag需要服务器通过算法来计算出一个hash值。

  • 在优先级上,服务器校验优先考虑Etag

缓存新鲜度

缓存驱逐

理论上来讲,当一个资源被缓存存储后,该资源应该可以被永久存储在缓存中。由于缓存只有有限的空间用于存储资源副本,所以缓存会定期地将一些副本删除,这个过程叫做缓存驱逐。

缓存失效计算

在客户端缓存了资源后,如何保证缓存资源的更新呢?

由于HTTP是C/S模式的协议,服务器更新一个资源时,不可能直接通知客户端更新缓存,所以双方必须为该资源约定一个过期时间,在该过期时间之前,该资源(缓存副本)就是新鲜的,当过了过期时间后,该资源(缓存副本)则变为陈旧的。

对于含有特定头信息的请求,浏览器会去计算缓存寿命,该寿命就代表这缓存新鲜度,计为变量:freshnessLifetime。接下来用术语expiresValue来表明 Expires 头域的值;用术语maxAgeValue(单位:秒)来表示 Cache-Control 头域里max-age控制指令的值。

Cache-Control:max-age 指令优先于 Expires 头域执行,所以如果 max-age 出现在响应里,那么定义如下:

freshnessLifetime = maxAgeValue 

否则,若 Expires 头域出现在响应里,定义如下:

freshnessLifetime = expiresValue - dateValue 

其中,dateValueDate头域的值。

注意上述运算不受时钟误差影响,因为所有信息均来自源服务器。

同样,如果响应有Last-Modified(其值记为lastModifiedTime),启发式过期值应不大于从那个时间开始到现在(Date头的值,记为:dateValue)这段时间间隔的某个分数(典型设置为间隔的 10% )。

freshnessLifetime = (dateValue - lastModifiedTime) / 10

有了缓存新鲜度,就可以很容易得到缓存的失效时间,缓存失效时间计算公式如下:

expirationTime = responseTime + freshnessLifetime - currentAge

上式中,responseTime 表示浏览器接收到此响应的那个时间点,currentAge为当前缓存年龄,详见rfc2626文档第51页。

HTTP Header缓存全流程

image.png

上图是HTTP Header缓存机制全流程图,由图可知:

  1. 强缓存优先于协商缓存进行,若强制缓存(ExpiresCache-Control)生效则直接使用缓存,若不生效则进行协商缓存(Last-Modified / If-Modified-SinceEtag / If-None-Match)
  2. 协商缓存需要向服务器发送请求,确认缓存有效性以决定是否使用缓存,若协商缓存失效,返回 200状态和新的资源及其缓存标识,存入浏览器缓存中;缓存生效则返回304,继续使用缓存。

数据缓存

内容相比资源缓存不太复杂,这里就直接传送吧:深入了解浏览器存储--从cookie到WebStorage、IndexedDB

浏览器刷新动作对于强缓存和协商缓存的影响

  1. 浏览器地址栏中写入URL,按下回车访问页面时,浏览器会按照缓存位置查找缓存,当发现缓存中有这个文件,则不继续请求而直接去缓存拿资源。否则发送请求获取该资源;

  2. F5刷新网页时(正常重新加载),浏览器会先按缓存位置查找缓存,没有命中时则跳过强缓存,直接执行协商缓存检查过程;

  3. 当用户使用Ctrl+F5强制刷新网页时(硬性重新加载),会跳过缓存查找、强缓存、协商缓存阶段,直接从服务器加载资源。

实际场景应用缓存策略

  1. SPA入口文件 SPA入口文件一般就是index.html
# 推荐策略
Cache-Control: no-store

强制不缓存!是的,入口文件不要缓存,设置no-cache都不保险。

还记得本文讲缓存位置Memory Cache时提到的吗?

在从 Memory Cache 获取缓存内容时,浏览器会忽视例如 cache-control: max-age=0, cache-control: no-cache 等头部配置。

所以,如果资源被缓存在了Memory Cache,那么在用户没有关闭Tab时,后台资源发生了更新浏览器端是获取不到最新的资源的。而当资源被缓存到了Disk Cache,即使关闭Tab重新打开都有可能使用本地缓存而不请求最新资源。

  1. 频繁变动的资源
# 推荐策略
Cache-Control: no-cache

使用Cache-Control: no-cache 是确保浏览器每次都请求服务器,然后配合 ETag 或者 Last-Modified 来验证资源是否有效。这样的做法虽然不能节约网络请求数,但是能显著减少响应数据大小,提高响应速度。

  1. 不常变化的资源
# 推荐策略
Cache-Control: max-age=N(N可以为一个较大的值,比如:315360001年】)

通常在处理这类资源时,给它们的 Cache-Control 配置一个很大的 max-age=31536000 (一年),这样浏览器之后请求相同的 URL 会命中强制缓存。而为了解决更新的问题,就需要在文件名(或者路径)中添加 hash, 版本号等动态字符,之后更改动态字符,从而达到更改引用 URL 的目的,让之前的强制缓存失效 (其实并未立即失效,只是不再使用了而已)。

在线提供的类库 (如 jquery-3.6.0.js 就采用这个模式。

image.png

总结

  1. 缓存查找是浏览器缓存机制启动的第一步,缓存查找按照优先级从四个缓存位置中依次搜索资源。
  2. 缓存资源的缓存位置按照优先级排序有:Service Worker > Memory Cache > Disk Cache > Push Cache。
  3. 浏览器强缓存主要控制头有:ExpiresCache-ControlPragma,三者的优先级是 Cache-Control > Pragma > Expires
  4. 协商缓存主要的控制头有两套,分别是:Last-Modified / If-Modified-SinceETag / If-None-Match。两者的优先级是 ETag / If-None-Match > Last-Modified / If-Modified-Since
  5. ETag协商缓存精度高但计算hash值过程耗费更多服务资源,Last-Modified精度低但是对服务资源消耗更少,使用时应根据业务场景来选择。
  6. 当缓存位置在Memory Cache时,浏览器会直接忽略 强缓存/协商缓存 控制头,这会引发一定的风险,所以对SPA系统入口文件,应该直接设置:Cache-Control: no-store,禁止缓存。

参考

  1. HTTP 缓存
  2. rfc2626
  3. Chrome memory cache vs disk cache
  4. The State of Browser Caching, Revisited
  5. HTTP/2 push is tougher than I thought
  6. service worker 实现离线缓存
  7. 浏览器缓存控制机制
  8. 深入理解浏览器的缓存机制
  9. 一文读懂前端缓存