作者：Firefox 49 发布时包含了Cache-Control: Immutable 功能，允许网站提示哪些 HTTP 资源永远不会更改。几乎同时，Facebook 开始广泛部署此更改的服务器端。他们使用一种 URI 版本控制开发模型，该模型与 immutable 非常匹配。这极大地影响了 Firefox 中 Facebook 重新加载的性能。看起来其他内容提供商也将采用它。
immutable 的好处在于，当页面刷新时（这是一种非常常见的社交媒体场景），之前使用 HTTP 响应标头标记为 immutable 的元素无需与服务器重新验证。缺少此提示，浏览器需要猜测哪些对象在重新加载时可能更改或可能不更改——一方面浪费时间，另一方面冒着网站不兼容的风险。
对于较小的对象，通过 304 HTTP 响应代码进行此重新验证的工作量几乎与完全传输响应一样多。
事实证明，这可以节省大量工作。页面的 JavaScript、字体和样式表在重新加载之间不会更改。更重要的是，数十张图像也不会改变——标记可能会包含不同的图像，但单个图像的内容不会改变。实际上，唯一可能改变的是标记本身。
对于重新加载 Facebook 内容的 Firefox 用户来说，这是一个巨大的福音——最快的请求是一个从未发出的请求，而这正是刷新 Facebook 页面时一遍又一遍发生的事情。在我的测试中，一个典型的 Feed 最初可能包含 150 个不同的资源。在 Firefox 49 中按下刷新只会生成 25 个网络请求。
正如您可能想象的那样，这极大地加快了速度。在我的测试中，它通常可以将页面重新加载时间缩短一半。Facebook 也是 Brotli 压缩编码的早期采用者。他们使用它来减少动态标记的带宽使用量（无法缓存），与旧的 gzip 标准相比，节省了大约 20% 的传输字节。Brotli 在 Firefox 44 之后一直可用。
当然，Facebook 的服务器也是最大的赢家——从未发出的请求节省了带宽和 CPU 利用率，而这些资源可以反过来用于为其他请求加快网站速度。
“此更改有效地消除了来自最新版 Firefox 的重新验证请求，这在许多情况下可以将加载时间缩短几秒。” – Nathan Schloss，Facebook 软件工程师
我们正在发展壮大
Facebook 一直是这项工作的优秀合作伙伴。最近，我一直在宣传 immutable，其他开发人员也开始采用它。
BBC 已在试用阶段采用了它
@mcmanusducksong 我只快速浏览了一下，但 immutable 对我们来说似乎也运行良好。额外的好处是它易于实现 :-)
— Neil Craig (@tdp_org) 2016年10月27日
据轶事报道，BBC 发现重新加载时间最多提高了近 50%，并且发现 immutable 消除了 90% 的请求。
像星际文件系统 这样面向未来的实现也对此很感兴趣
@bergie @mcmanusducksong @jaffathecake 事实上，go-ipfs 从 v0.4.2 开始就设置了 Cache-Control: immutable :)
— IPFS (@IPFSbot) 2016年10月28日
还有像Squid 代理 这样久负盛名的产品
它现在在现实世界中积累了足够的经验，可以强烈推荐使用。为了确保充分的文档，它也被纳入了IETF 的标准轨道。您只需要一个正确的缓存标头 即可开始开发。
关于 Patrick McManus
Mozilla 的首席工程师，专注于平台网络
28 条评论