使用 HTTP 缓存防止不必要的网络请求

Ilya Grigorik
Ilya Grigorik

通过网络提取资源既缓慢又成本高昂:

  • 较大的响应需要在浏览器与服务器之间进行多次往返。
  • 只有在网页的所有关键资源均完全下载完毕后,该网页才会加载。
  • 如果有人使用数量有限的移动流量套餐访问您的网站,那么每项不必要的网络请求都是在浪费他们的金钱。

如何避免不必要的网络请求?浏览器的 HTTP 缓存是您的第一道防线这不一定是最强大或最灵活的方法,您对缓存响应的生命周期的控制也有限,但它很有效,在所有浏览器中都受支持,并且不需要太多工作。

本指南介绍了有效 HTTP 缓存实现的基础知识。

浏览器兼容性

实际上,并不存在一个名为 HTTP Cache 的单一 API。它是一系列网络平台 API 的通用名称。所有浏览器都支持以下 API:

HTTP 缓存的工作原理

浏览器发出的所有 HTTP 请求都会先路由到浏览器缓存,以检查是否有可用于实现请求的有效缓存响应。如果匹配,则从缓存中读取响应,这消除了网络延迟和传输产生的数据费用。

HTTP 缓存的行为由请求标头响应标头的组合控制。在理想情况下,您可以同时控制 Web 应用的代码(确定请求标头)和 Web 服务器的配置(确定响应标头)。

如需了解更深入的概念性概览,请参阅 MDN 的 HTTP 缓存文章。

请求标头:坚持使用默认值(通常)

虽然 Web 应用的传出请求中应包含许多重要的标头,但浏览器在发出请求时几乎总是会代表您设置这些标头。影响新鲜度检查的请求标头(如 If-None-MatchIf-Modified-Since)只是根据浏览器对 HTTP 缓存中当前值的理解而显示。

这是好消息 - 这意味着您可以继续在 HTML 中添加 <img src="my-image.png"> 等标记,浏览器会自动为您处理 HTTP 缓存,而无需额外费心。

响应标头:配置您的网络服务器

HTTP 缓存设置中最重要的部分是网络服务器添加到每个传出响应的标头。以下标头都会影响有效的缓存行为:

  • Cache-Control。服务器可以返回 Cache-Control 指令,以指定浏览器和其他中间缓存应如何缓存各个响应以及缓存多长时间。
  • ETag。当浏览器发现过期的缓存响应时,可以向服务器发送一个小令牌(通常是文件内容的哈希值),以检查文件是否发生了更改。如果服务器返回相同的令牌,则文件是相同的,无需重新下载。
  • Last-Modified。此标头的用途与 ETag 相同,但与 ETag 的基于内容的策略不同,它使用基于时间的策略来确定资源是否已更改。

某些网络服务器内置了对默认设置这些标头的支持,而其他服务器则会完全排除标头(除非您明确配置它们)。关于如何配置标头的具体细节会因您使用的 Web 服务器而异,您应该查阅服务器的文档以获得最准确的详细信息。

为省时省力,请参考下面有关如何配置一些常用 Web 服务器的说明:

退出 Cache-Control 响应标头不会停用 HTTP 缓存!浏览器会实际猜测哪种类型的缓存行为对给定类型的内容最有意义。您可能想要获得比这提供的更多控制权,因此请花些时间配置响应标头。

您应使用哪些响应标头值?

配置 Web 服务器的响应标头时,您应涵盖两种重要场景。

版本化网址的长期缓存

带版本号的网址如何帮助您的缓存策略
对网址进行版本控制是一种很好的做法,因为这样做可以更轻松地使缓存响应失效。

假设您的服务器指示浏览器将某个 CSS 文件缓存 1 年 (Cache-Control: max-age=31536000),但设计人员刚刚进行了一项紧急更新,您需要立即发布这项更新。如何通知浏览器更新文件的“过时”缓存副本? 您无法更改资源,至少不能更改资源的网址。浏览器缓存响应后,缓存版本将一直使用,直到它不再处于最新状态(由 max-ageexpires 确定),或由于某种其他原因(例如,用户清除了浏览器缓存)从缓存中逐出为止。因此,在构建网页时,不同的用户可能最终使用的是文件的不同版本:刚刚获取了资源的用户使用的是新版本,而缓存了较早(但仍有效)副本的用户使用的是旧版本的响应。如何才能做到两全其美:客户端缓存和快速更新?您可以更改资源的网址,并在资源内容发生变化时强制用户下载新响应。通常情况下,可以通过在文件名中嵌入文件的指纹或版本号(例如 style.x234dff.css)来实现此目的。

在响应针对包含“fingerprint”或版本控制信息的网址的请求,并且这些网址的内容绝不会更改时,请在响应中添加 Cache-Control: max-age=31536000

设置此值可告知浏览器,当需要在接下来的一年内随时(31,536,000 秒;支持的最大值)加载同一网址时,它可以立即使用 HTTP 缓存中的该值,而无需向您的网络服务器发出网络请求。太棒了,您可以立即享受到避开网络所带来的可靠性和速度!

webpack 等构建工具可以自动执行向资源网址分配哈希指纹的过程

针对无版本控制的网址的服务器重新验证

遗憾的是,您加载的所有网址都未经过版本化处理。也许您无法在部署 Web 应用之前包含构建步骤,因此不能向资源网址添加哈希值。每个 Web 应用都需要 HTML 文件,因为这些文件(几乎!)永远都不会包含版本控制信息,因为如果需要记住要访问的网址为 https://example.com/index.34def12.html,没有人会使用您的 Web 应用。那么,您可以对这些网址做些什么呢?

这时,你需要承认失败。单独的 HTTP 缓存功能无法完全避开网络。(别担心,您很快就会了解 Service Worker,它们将提供所需的支持,使我们重新赢得对你的青睐。)但是,您可以采取几个步骤来确保网络请求尽可能快速高效。

以下 Cache-Control 值可帮助您微调无版本控制网址的缓存位置和方式:

  • no-cache。这会指示浏览器必须在每次使用网址的缓存版本之前向服务器重新验证。
  • no-store。这会指示浏览器和其他中间缓存(如 CDN)绝不存储文件的任何版本。
  • private。浏览器可以缓存文件,但中间缓存无法缓存。
  • public。任何缓存都可以存储响应。

请参阅附录:Cache-Control 流程图,直观地了解确定要使用哪个 Cache-Control 值的过程。另请注意,Cache-Control 可以接受以英文逗号分隔的指令列表。请参阅附录:Cache-Control 示例

除此之外,设置另外两个响应标头中的一个也会有所帮助:ETagLast-Modified。如响应标头中所述,ETagLast-Modified 的用途相同:确定浏览器是否需要重新下载已过期的缓存文件。建议使用 ETag 方法,因为它更准确。

ETag 示例

假设自首次提取以来已经过了 120 秒,并且浏览器对同一资源发起了新请求。首先,浏览器会检查 HTTP 缓存,并找到之前的响应。遗憾的是,由于该响应现已过期,因此浏览器无法使用之前的响应。此时,浏览器可以发出新的请求并获取新的完整响应。但是,这样做效率低下,因为如果资源未发生变化,那么您就没有理由下载缓存中已有的那些信息!这正是 ETag 标头中指定的验证令牌旨在解决的问题。服务器生成并返回任意令牌,该令牌通常是文件内容的哈希值或某种其他指纹。浏览器不需要知道指纹是如何生成的,只需在下一个请求中将其发送到服务器即可。如果指纹仍然相同,则表示资源并未更改,因此浏览器可以跳过下载。

通过设置 ETagLast-Modified,您最终会提高重新验证请求的效率。它们最终会触发请求标头中提到的 If-Modified-SinceIf-None-Match 请求标头。

当经过正确配置的 Web 服务器看到这些传入请求标头时,可以确认浏览器在其 HTTP 缓存中已包含的资源版本是否与 Web 服务器上的最新版本相匹配。如果匹配,服务器可以使用 304 Not Modified HTTP 响应来做出响应,响应等同于“Hey, keep using what you've already get!”发送此类响应时要传输的数据非常少,因此这通常比必须实际发回所请求资源的副本要快得多。

客户端请求资源以及服务器使用 304 标头进行响应的示意图。
浏览器向服务器请求 /file 并包含 If-None-Match 标头,以指示服务器仅在服务器上的 ETag 与浏览器的 If-None-Match 值不一致时返回完整文件。在本示例中,这两个值确实匹配,因此服务器会返回 304 Not Modified 响应,其中会说明应将文件缓存多长时间 (Cache-Control: max-age=120)。

摘要

HTTP 缓存可以减少不必要的网络请求,是提高加载性能的有效方式。所有浏览器都支持此功能,并且设置起来不会花费太多工作。

不妨先从以下 Cache-Control 配置着手:

  • Cache-Control: no-cache,适用于应在每次使用前通过服务器重新验证的资源。
  • Cache-Control: no-store,适用于绝不应缓存的资源。
  • Cache-Control: max-age=31536000,适用于版本化资源。

ETagLast-Modified 标头可以帮助您更高效地重新验证过期的缓存资源。

了解详情

如果您希望更深入地了解使用 Cache-Control 标头的基础知识,请参阅 Jake Archibald 的缓存最佳实践和 max-age 陷阱指南。

如需了解如何针对回访者优化缓存用量,请参阅喜爱缓存

附录:更多提示

如果您有更多时间,可以通过以下几种方式优化 HTTP 缓存的使用:

  • 使用一致的网址。如果您在不同网址上提供相同的内容,系统会多次提取和存储这些内容。
  • 最大限度地降低流失率。如果资源的一部分(例如 CSS 文件)经常更新,而文件的其余部分(例如库代码)不经常更新,请考虑将频繁更新的代码拆分到单独的文件中,并为频繁更新的代码使用短时间缓存策略,而为不经常更改的代码使用长缓存持续时间策略。
  • 如果您的 Cache-Control 政策可以接受一定程度的过时,请查看新的 stale-while-revalidate 指令。

附录:Cache-Control 流程图

流程图

附录:Cache-Control 示例

Cache-Control 说明
max-age=86400 浏览器和中间缓存可将响应缓存长达 1 天(60 秒 x 60 分钟 x 24 小时)。
private, max-age=600 浏览器(而不是中间缓存)可以将响应缓存长达 10 分钟(60 秒 x 10 分钟)。
public, max-age=31536000 响应可以由任何缓存存储 1 年。
no-store 不允许缓存响应,必须在每个请求中完整提取响应。