Vercel 的缓存控制，你注意过吗？ | 竹林里有冰的博客

Vercel 默认的缓存配置其实并不合理，但鲜有人注意。

先看效果#

图一

图二

分析#

测试方案#

这两张图都是我博客在 PageSpeed Insights 上测得的，测试步骤如下：

部署
在 PageSpeed Insights 进行第一次测试
等待 120s，防止 PageSpeed Insights 拿之前的结果糊弄你
进行第二次测试，取第二次测试的结果

取第二次结果的目的是为了让 PageSpeed Insights 所命中的 Vercel CDN 节点完成回源，并将内容缓存在 CDN 节点上，这样第二次访问的时候就会直接从 CDN 的缓存中得到结果，不需要回源。

那我们看图一的测试结果，正常吗？针对首页的单个 html 加载时长达到了 450ms，看着不算慢，但其实细究下来是有问题的。

Vercel 采用的是 Amazon 提供的全球 CDN 网络，在我们的首次访问之后，CDN 节点应当该已经缓存了首页的内容，第二次访问的时候应该是直接从 CDN 节点的缓存中获取内容。

合理的时长是多久呢？#

TCP 建立连接的三次握手，需要 1.5 个往返时延（RTT），再加上 TLS 1.3 握手的 1 个 RTT，共计 2.5 个 RTT。
HTML 文件大小 18KB，初始拥塞窗口（IW）10 MSS ≈ 1460 字节 ≈ 14.6KB，理论上应该可以在两个 RTT 内传输完毕。

共计 4.5 个 RTT。

PageSpeed Insights 测试时使用的节点大概率是在美国，Amazon CDN 在美国的节点覆盖非常广泛，单个 RTT 时长控制在 5ms 以内绰绰有余，所以理论加载时长应该在 22.5ms 左右。加上 DNS 解析时长（这个也不多，因为两分钟前有过一次访问，这次不是冷启动）和一些不可控的网络抖动，50ms 以内应该是完全没有问题的。

但实际测得的时长却高达 450ms，差了近 9 倍，这就很不合理了。

我们再来看图二的结果，单个 HTML 加载时长降到了 41ms，完全符合预期。

为什么会有这么大的差异呢？原因就在于 Vercel 对缓存控制的设置上。

在 Vercel 上部署的网站，默认情况下，Vercel 会对 HTML 文件设置如下的缓存控制头：

cache-control: public, max-age=0, must-revalidate

这个设置的含义是：

public：响应可以被任何缓存区缓存，包括浏览器和 CDN。
max-age=0：响应的最大缓存时间为 0 秒，意味着响应一旦被缓存后立即过期。
must-revalidate：一旦响应过期，缓存必须向源服务器验证其有效性。

结合这三个指令，Vercel 实际上是告诉 CDN 节点：你可以缓存这个 HTML 文件，但每次在使用缓存之前都必须回源验证其有效性。由于 max-age=0，缓存一旦存储就立即过期，因此每次请求都会触发回源验证。

尽管 HTTP/1.1 和 HTTP/2 中的缓存验证通常使用条件请求（如文件的 ETag 或 Last-Modified 头）来节省传输流量，但这仍然需要与源服务器进行往返通信，从而增加了额外的延迟开销。

所以，在 Vercel 默认配置下，任何请求的响应都不会被 CDN 节点直接缓存，大致的流程如下：

sequenceDiagram
    participant Client
    participant CDN
    participant Vercel
    Client->>CDN: 请求 HTML 文件
    CDN->>Vercel: 条件请求验证缓存
    Vercel->>CDN: 返回最新的 HTML 文件或 304 Not Modified
    CDN->>Client: 返回 HTML 文件

解决方案#

要解决这个问题，我们需要调整 Vercel 上的缓存控制设置，使得 HTML 文件能够被 CDN 节点缓存一段时间，而不需要每次都回源验证。

Vercel 允许我们在项目的根目录下创建一个 vercel.json 文件以对 Vercel 的部署行为进行一系列的配置，其中就包括 HTTP 的响应头的配置。

我的博客采用 Nuxt.js 框架构建，生成的构建产物大概分为两类：

HTML 文件：这些文件的内容可能会频繁变化，不能设置过长的缓存时间；
静态资源文件：包括 JavaScript、CSS 等，这些文件的文件名通常带有 hash 值，可以设置较长的缓存时间甚至被标记为不可变（immutable）。

在部署流程上，我的博客在每次推送后会先 Github Actions 中构建成静态页面，再部署到 Vercel 上，所以我在我项目的 public 目录下创建了 vercel.json 文件（这样 vercel.json 文件就会在构建产物的根目录），内容如下：

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        {
          "key": "Cache-Control",
          "value": "public, max-age=0, s-maxage=600, must-revalidate"
        }
      ]
    },
    {
      "source": "/(.*)\\.(css|js)",
      "headers": [
        {
          "key": "Cache-Control",
          "value": "public, max-age=31536000, immutable"
        }
      ]
    }
  ]
}

这里我对所有的 CSS 和 JS 文件设置了 max-age=31536000, immutable，这样这些静态资源文件就可以被浏览器和 CDN 长时间缓存。而对于所有其他文件（主要是 HTML 文件），我设置了 max-age=0, s-maxage=600, must-revalidate，这样 HTML 文件就可以被 CDN 缓存 10 分钟，在这 10 分钟内的请求都可以直接从 CDN 节点的缓存中获取内容，而不需要回源验证。

这样一来，经过修改后的缓存控制设置，HTML 文件的请求流程变成了：

sequenceDiagram
    participant Client
    participant CDN
    Client->>CDN: 请求 HTML 文件
    CDN->>Client: 直接返回缓存的 HTML 文件

从而大大减少了请求的延迟，提高了页面加载速度。

其他#

Vercel 所采用的架构并不是传统的「源站 - CDN」架构，而是更接近「全球多区域存储 + CDN边缘缓存」的架构，所以即使是回源请求，Vercel 也会尽量从离用户最近的存储节点获取内容，从而减少延迟。但这并不意味着回源请求的延迟可以忽略不计，尤其是在追求极致的加载速度时，合理的缓存控制仍然是非常重要的。

推荐订阅源

竹林里有冰的博客

先看效果#

分析#

测试方案#

合理的时长是多久呢？#

解决方案#

其他#

参见#