最新消息:看到那些跳动的图片、文字了吗?点击点击 O(∩_∩)O~~

浏览器缓存 —— Browser Cache(HTTP 客户端缓存)

深夜食堂 onlyling 2848浏览

林洋,YMFE 资深工程师,负责去哪儿网 Hybrid(Hy)、React Native(QRN)等移动端方案架构、开发和推进,负责一系列基于 Node 的开源平台(YIcon、YApi 等)、开发工具(小程序构建工具、YDoc、YKit 等)的管理维护工作。专注于移动前端,着眼于工程流程化。

移动互联网时代,各种互联网技术层出不穷,尤其在移动端方面,各种动态化方案如雨后春笋般,在各自的领域蓬勃生长。但是,不管哪种方案,都会涉及到资源的迭代更新问题。如何让用户在更快地使用最新资源的同时,也能结合缓存保证应用的加载效率,是这类方案必须要考虑的。本文将从浏览器缓存谈起,在涵盖 App Cache、SW Cache 等纯 Web 缓存方案的同时,也将站在大前端角度去分析不同方案的差异,最终,让大家对 web 缓存策略有一个详尽的了解。

全文阅读 深入 Web 缓存策略 点击查看

HTTP 缓存机制分为两种,客户端缓存服务端缓存 ,而服务端缓存又分为 代理服务器缓存(例:CDN 服务)和 反向代理服务器缓存(例:Nginx 反向代理服务)。

关于客户端缓存,浏览器缓存是其中的一种实现形式,在浏览器内核中实现基于 HTTP 缓存机制的缓存。当然,在各类网络请求的开发库中,也实现了几乎同样的逻辑。这些逻辑,都是基于 HTTP 协议中的 HEADER 来实现的,根据 HEADER 中相应配置的不同,执行不同的缓存逻辑。

但是客户端怎么根据 HTTP 的 HEADER 来更为细化地控制缓存的呢?其实 HTTP 客户端缓存有两种不同的策略机制:

  • 服务端决策缓存:由服务端决定并告知客户端是否使用缓存。
  • 客户端决策缓存:服务端告知客户端缓存时间后,由客户端判断并决定是否使用缓存。

对于这两种策略机制的区别,最明显的表象是:从 Chrome DevTool 中 Network 面板里看到缓存的请求,服务端决策缓存在 Status 一栏显示的是 304,而客户端决策缓存在 Status 一栏显示的是 200,不过在 Size 一栏会显示 from disk cache

这两种缓存策略机制主要是由 HTTP Header 中的 Cache-Control 来决定和控制使用的。此属性常见的取值有以下6类:

  • public:全部缓存,包括客户端和服务端(时长 365 天)
  • private:仅客户端缓存(时长 365 天)
  • no-cache:不适用客户端的缓存,使用“服务端决策缓存”。并不是表面意义上的“不使用缓存”。
  • no-store:所有内容都不会被缓存,不论哪种策略机制都不会被缓存。不同浏览器对这种情况的实现不同,有些浏览器是不缓存,有些是在特定实际清除缓存,例如当前页面关闭、浏览器关闭等。
  • must-revalidation/proxy-revalidation:如果缓存内容失效,请求必须发送服务器/代理进行验证。也就是当“客户端决策缓存”未命中时,使用“服务端决策缓存”,理论上是最优的缓存策略。不过,只有最新的部分浏览器和网络库支持此配置,还未普及。
  • max-age=<s>:缓存内容在s秒后失效,仅 HTTP 1.1 可用。(HTTP 1.0 可以用 Expires)

对于前端资源,最常用的是 Cache-Control: no-cacheCache-Control: max-age=123,分别对应笔者上文提到的两种策略机制。

而对于数据请求,一般使用 Cache-Control: no-store 来保证每次数据都是新的,而由于前文提到 no-store 的实现方式有异,最好还是加随机参数来避免缓存。

转载请注明:OnlyLing - Web 前端开发者 » 浏览器缓存 —— Browser Cache(HTTP 客户端缓存)