前端技术演化史

CDN与静态托管

Properties1
tags部署, 托管, cdn, 静态托管, 边缘缓存

11分钟阅读

🌐 CDN 与静态托管

一句话定性

CDN 是”算力位置一路向用户靠近”这条主线上的第一步:它不改变代码在哪渲染,只是把已经生成好的静态产物复制到全球边缘节点,让用户就近取货。它把”延迟”这个物理问题,从”加快服务器”变成了”缩短距离”。

一、它是什么 & 出现的时代

CDN(Content Delivery Network,内容分发网络) 是一张遍布全球的边缘服务器网络,把同一份静态资源(JS/CSS/图片/字体/HTML)缓存到离用户最近的节点。用户请求时,DNS 把他导向最近的边缘节点,而不是远在另一个大洲的源站(origin)。

  • 起源:CDN 本身是 1998 年 Akamai 就有的老技术,最初服务于大文件分发(视频、软件下载)。
  • 真正成为前端标配:是在 2013-2018 SPA时代——当前端产物从”服务器现拼的页面”变成”一堆固定的静态文件”时,CDN 才与前端命运绑定。

关键认知

CDN 不是”渲染层”,而是”分发层”。它本身不执行业务逻辑、不渲染页面,只做一件事:把静态字节尽可能贴近用户地缓存住。理解这一点,才能理解后来 Edge边缘运行时的飞跃——Edge 是”让分发层也能跑代码”。

二、为什么会出现(解决上一代什么痛点)

在 2005-2013 Ajax时代及更早,资源都从单一源站发出。问题是物理的:

中心化源站的硬伤

  1. 延迟由距离决定:用户在悉尼,服务器在弗吉尼亚,一个 round-trip 就是几百毫秒,光速是上限,优化代码也救不了距离。
  2. 源站带宽 = 瓶颈 = 单点:所有用户的所有请求都砸向同一台(组)机器,流量高峰直接打垮源站。
  3. 重复传输浪费:同一个 jquery.min.js,每个用户都从源站完整下载一遍。

CDN 的答案直击本质:既然延迟由距离决定,那就把内容搬到离用户更近的地方。 这是典型的第一性原理——不去对抗光速,而是缩短传输距离。

三、核心机制 & 为什么流行

边缘缓存的工作流

首次请求(缓存未命中 / cache miss)
 用户 ──► 最近边缘节点 ──(回源)──► 源站 origin ──► 拿到资源
                  └─► 缓存一份在边缘 ──► 返回给用户

后续请求(缓存命中 / cache hit)
 用户 ──► 最近边缘节点 ──► 直接命中缓存,毫秒级返回(不再回源)
  • 就近:DNS / Anycast 把用户路由到地理或网络上最近的节点,延迟从”跨洲”降到”同城”。
  • 缓存:静态资源带上长缓存头(Cache-Control: max-age)+ 文件名哈希(app.a1b2c3.js)→ 内容变了文件名就变,既能永久缓存又能即时更新(cache busting)。
  • 卸载源站压力:绝大多数请求在边缘就被消化,源站只在 cache miss 时被回源打扰,轻松扛住流量洪峰。

为什么 SPA / SSG 时代 CDN 成了标配

静态化与 CDN 是天作之合

  • 2013-2018 SPA时代的 SPA:产物就是一个 index.html 壳 + 一堆带哈希的 JS/CSS chunk——全是静态文件,天然适合往 CDN 上一扔。
  • SSG(见 渲染模式演进史):构建时就把所有页面预渲染成静态 HTML,部署目标天生就是 CDN。SSG 的”最快最便宜”恰恰是因为它把渲染结果变成了可被 CDN 缓存的静态字节。

这就是为什么 渲染模式演进史里渲染策略的选择,永远和部署目标深度纠缠:渲染产物越静态,CDN 就越好用。

静态托管平台的兴起

当前端产物变成”纯静态文件”后,部署门槛骤降——不需要服务器,只需要一个能托管文件 + 套 CDN 的地方。于是一批”零运维静态托管”平台崛起:

平台特点时代意义
GitHub Pages(2008)直接把仓库里的静态文件免费托管让”个人/开源项目零成本上线”成为常态
GitLab Pages / Surge / Firebase Hosting一行命令推静态文件把”部署”从运维活变成开发活
Netlify(2015 起)Git push 即构建即部署 + 全球 CDN把静态托管推向”工作流”层面,直接催生了 Jamstack

从"上传文件"到"连接仓库"

早期静态托管还是手动 ftp / rsync 上传产物;GitHub Pages 让”提交即发布”;Netlify 更进一步——连接 Git 仓库,push 自动构建 + 自动分发到 CDN。部署彻底变成了开发者工作流的一部分,这正是 Jamstack 工作流的雏形。

四、带来的新问题 / 副作用

CDN 不是免费的午餐

  1. 缓存失效的心智复杂度:什么该缓存、缓存多久、如何即时刷新(purge)——CDN 缓存、浏览器缓存、源站缓存层层叠加,“为什么我改了线上没变?”成了经典难题。
  2. 只能缓存”静态”内容:CDN 的本事是缓存对所有人都一样的资源。一旦内容要因人而异(登录态、个性化推荐、地区定价),传统 CDN 就无能为力——因为它不会执行逻辑。这个边界,正是后来 Edge边缘运行时要突破的。
  3. 动态页面回源 = 延迟优势消失:SSR(见 渲染模式演进史)每个请求都要回源站现渲染,CDN 在中间只能透传,反而多了一跳。静态能缓存,动态不能——这道鸿沟贯穿整个部署史。

五、为什么会衰落 / 现状

CDN 没有衰落,而是”长进了骨头里”,并向上进化。

  • 作为分发层,CDN 是今天每一个前端项目的默认基础设施,只是越来越透明——Netlify / Vercel / Cloudflare 把 CDN 内置进部署流程,开发者甚至感知不到它的存在。
  • 真正的进化是:CDN 节点从”只会缓存静态文件”变成了”能跑代码”。Cloudflare Workers、Edge边缘运行时让边缘节点拥有了计算能力——这意味着”个性化的动态内容”也能在离用户最近的地方生成。CDN 不再只是货架,它变成了前置厨房。
传统 CDN          Edge 运行时
[只缓存静态]  ──►  [边缘也能跑逻辑]
 货架              货架 + 前置厨房

六、对后续技术的影响(因果链)

中心化源站(延迟由距离决定,源站是单点瓶颈)
   │ "既然延迟由距离决定,就把内容搬近用户"(第一性原理)
   ▼
CDN(边缘缓存静态资源,就近分发)
   │ SPA/SSG 产物天然静态 ──► CDN 成为前端标配
   ▼
静态托管平台(GitHub Pages → Netlify "push 即部署 + 自带 CDN")
   │ "部署"从运维活变成开发工作流
   ▼
[[Jamstack]](预构建静态 + CDN 分发 + 客户端调 API)
   │ 但 CDN 只能缓存"对所有人一样"的内容,个性化/动态无解
   ▼
[[Edge边缘运行时]](让边缘节点也能跑代码 ──► 动态内容也能像静态一样快)

历史地位

CDN 是”算力向用户靠近”这条主线的起点和地基。它先解决了”静态资源的延迟”问题,把延迟从代码问题还原为距离问题,再用就近缓存化解。但它有一道无法逾越的墙——只能伺候静态、不能伺候个性化。这道墙立在那里近二十年,直到 Edge边缘运行时让边缘也能计算,墙才被推倒。理解 CDN 的能力边界,就理解了 Jamstack 为什么火、又为什么不够,以及 Edge 为什么是当前前沿。

🔗 相关:部署与托管演进史 | Jamstack | Serverless与FaaS | Edge边缘运行时 | 渲染模式演进史 | 2013-2018 SPA时代 | 2018-2023 工程化时代

关系图谱

反向链接