智能工具库

添加 CDN 缓存后网站反而变慢?这是我忽略的数学题

添加 CDN 缓存后网站反而变慢?这是我忽略的数学题

作者在静态站点部署 CDN 缓存后,响应时间看似降低,但爬虫检测显示慢页面翻倍。本文剖析了原因:冷启动流量导致 MISS 成本高,以及爬虫与热用户的区别。

2026-08-28 0来源:freeCodeCamp

添加 CDN 缓存后网站反而变慢?这是我忽略的数学题

很多开发者都有这样的直觉:给静态网站加上 CDN 缓存,性能一定能起飞。但现实往往并不总是线性的。最近,有开发者尝试给一个静态站点部署 CDN,结果却事与愿违——网站不仅没有变快,反而因为性能评分下降而不得不回滚。这背后的原因并非技术本身失效,而是忽略了流量模型中的关键变量。

背景与现状

这次的主角是一个基于 Astro 构建的静态网站,全站共 77 个 HTML 页面,没有任何服务器端渲染(SSR)或数据库依赖。网站的基础设施非常简单:免费版 Cloudflare 面板,源站部署在印度孟买的 Navi Mumbai。

虽然流量极其有限,平均每天只有约 9 位访客,但 Google Search Console 的报告显示,平均响应时间高达 711ms。根据 Google 的性能指南,首字节时间(TTFB)应控制在 200ms 以内。显然,711ms 的延迟是一个显而易见的问题。

问题诊断

在检查 Cloudflare 的状态时,开发者发现了一个令人困惑的现象:静态资源(JS、CSS、图片)缓存正常,但 HTML 页面完全没有被缓存。

通过查看 HTTP 头信息,状态显示为 DYNAMIC。这意味着每次访问,请求都会穿透 Cloudflare,直接到达位于印度的源站。之所以出现这种情况,是因为源站服务器发送了 Cache-Control: no-cache 头。这是过去为了确保部署后能立即生效而做出的有意设计。

既然 HTML 未被缓存,且源站距离较远,逻辑上通过 CDN 缓存 HTML 应该能解决问题。然而,这一直觉判断忽略了几个关键细节。

尝试修复

为了解决 HTML 缓存问题,开发者对配置做了两处修改:

  1. 调整源站 HTTP 头Cache-Controlno-cache 改为: Cache-Control: public, max-age=0, s-maxage=31536000, must-revalidate

    解读: 这里使用了一个经典的组合策略。max-age=0, must-revalidate 保证了浏览器在每次请求时都会重新验证,从而确保代码部署后用户能立即看到更新。而 s-maxage=31536000(1 年)则专门针对共享缓存(如 CDN),允许 CDN 在一年内直接返回缓存内容,而不需要询问源站。

  2. 添加 Cloudflare 缓存规则 开发者发现仅靠 HTTP 头是不够的。在测试中,即使设置了 s-maxage,Cloudflare 依然返回 DYNAMIC。必须显式创建一个“缓存规则”,标记扩展名为 HTML 的响应为可缓存对象。这一步是启用 CDN 缓存的关键开关。

结果与反转

配置生效后,对于热用户(即已经访问过页面的用户),效果立竿见影。在印度的测试环境下,页面从源站获取的 TTFB 从约 0.28s 下降到了 0.17s。看起来,优化非常成功。

然而,当下一次爬虫(Crawler)再次扫描网站时,数据却令人大跌眼镜:原本标记为慢的页面数量从 38 个激增至 75 个。不仅没有变快,反而接近翻倍。

原因分析

为什么优化了热用户的速度,全局评分却反而下降了?核心原因在于 “冷启动流量”

1. MISS 不是免费的

对于已经访问过的页面,CDN 会命中缓存,速度极快。但对于从未访问过的页面,或者爬虫的第一次访问,CDN 会返回 MISS 状态,并回源站获取数据。

由于源站位于印度,且 HTML 原本未被缓存,每一次 MISS 都意味着昂贵的网络延迟和源站计算成本。对于每天只有 9 位真实用户的站点,绝大多数流量(尤其是爬虫)都是“冷”的。

2. 爬虫是永远的冷用户

爬虫(搜索引擎或其他索引器)通常会频繁且全面地抓取网站。对于这些爬虫而言,它们几乎永远不会命中缓存。因此,尽管对热用户(真实访客)体验提升,但对爬虫来说,每次请求都要经过漫长的跨国网络传输。

如果站点流量足够大,热用户的收益会远超爬虫的损耗。但对于低流量站点,爬虫造成的“冷流量”拖累了整体性能评分。

经验教训与建议

这次经历给开发者敲响了警钟:在优化前,必须先做“流量模型”的计算。

如果你正在维护一个低流量的静态站点,或者你的站点主要依赖爬虫收录,那么盲目开启全站 HTML 缓存可能弊大于利。你需要考虑:开启缓存后,爬虫带来的 MISS 次数是否会超过缓存带来的收益?

建议在部署任何缓存策略前,先进行简单的预估:

  1. 评估冷流量占比: 真实访客是否足够多,能够覆盖爬虫带来的源站压力?
  2. 权衡部署体验: 是否愿意为了牺牲一点爬虫抓取速度,来换取真实用户的加载体验?

有时候,保持 HTML 不缓存,虽然牺牲了极致的 TTFB,但能确保搜索引擎能更快地收录你的新内容,这或许才是低流量站点更值得追求的平衡点。

本文基于 freeCodeCamp 的公开内容,由 AI 辅助整理改写后发布。

原标题:I Added a CDN Cache to My Site and It Got Slower. Here's the Math I Should Have Done First.

阅读原文