前端中高级进阶(一)----浏览器缓存策略,你知多少?

161 阅读3分钟

大家好,我是简清,今天和大家分享的是浏览器的缓存策略,在浏览器缓存机制中按照其在浏览器获取请求资源时的优先级依次进行分析如下:

(1)Memory Cache

  • 是指存在内存中的缓存。从优先级上来说,它是浏览器最先尝试去命中的一种缓存。从效率上来说,它是响应速度最快的一种缓存。浏览器秉承的是“节约原则”,我们发现,Base64 格式的图片,几乎永远可以被塞进 memory cache,这可以视作浏览器为节省渲染开销的“自保行为”;此外,体积不大的 JS、CSS 文件,也有较大地被写入内存的几率——相比之下,较大的 JS、CSS 文件就没有这个待遇了,内存资源是有限的,它们往往被直接甩进磁盘。

(2)Service Worker Cache

  • Service Worker 是一种独立于主线程之外的 Javascript 线程。它脱离于浏览器窗体,因此无法直接访问 DOM。这样独立的个性使得 Service Worker 的“个人行为”无法干扰页面的性能,这个“幕后工作者”可以帮我们实现离线缓存、消息推送和网络代理等功能。我们借助 Service worker 实现的离线缓存就称为 Service Worker Cache。这也是google推出service worker核心点。

(3)HTTP Cache

  • http Cache又分为强缓存和协商缓存。优先级较高的是强缓存,在命中强缓存失败的情况下,才会走协商缓存。
  • 对一条http get 报文的基本缓存处理过程包括7个步骤:
    • 接收
    • 解析
    • 查询,缓存查看是否有本地副本可用,如果没有,就获取一份副本
    • 新鲜度检测, 缓存查看已缓存副本是否足够新鲜,如果不是,就询问服务器是否有任何更新。
    • 创建响应,缓存会用新的首部和已缓存的主体来构建一条响应报文。
    • 发送,缓存通过网络将响应发回给客服端。
    • 日志
  • 强缓存
    • 强缓存是利用 http 头中的 Expires 和 Cache-Control 两个字段来控制的。强缓存中,当请求再次发出时,浏览器会根据其中的 expires 和 cache-control 判断目标资源是否“命中”强缓存,若命中则直接从缓存中获取资源,不会再与服务端发生通信。Cache-Control 相对于 expires 更加准确,它的优先级也更高。当 Cache-Control 与 expires 同时出现时,我们以 Cache-Control 为准。
  • 协商缓存
    • 协商缓存依赖于服务端与浏览器之间的通信。协商缓存机制下,浏览器需要向服务器去询问缓存的相关信息,进而判断是重新发起请求、下载完整的响应,还是从本地获取缓存的资源。如果服务端提示缓存资源未改动(Not Modified),资源会被重定向到浏览器缓存,这种情况下网络请求对应的状态码是 304。

(4) Push Cache

  • Push Cache 是指 HTTP2 在 server push 阶段存在的缓存。
  • Push Cache 是缓存的最后一道防线。浏览器只有在 Memory Cache、HTTP Cache 和 Service Worker Cache 均未命中的情况下才会去询问 Push Cache。
  • Push Cache 是一种存在于会话阶段的缓存,当 session 终止时,缓存也随之释放。
  • 不同的页面只要共享了同一个 HTTP2 连接,那么它们就可以共享同一个 Push Cache。

本文仅限学习分享,喜欢的可以加个关注,在成长的道路上共同学习,未经本人同意禁止转载,如文中涉及侵权您的作品,尽快联系我将快速删除,谢谢。