过去十年，前端项目架构经历了从简单 HTML 文件到复杂框架的飞跃，但很多开发者忽略了**“渲染位置”与“资源交付方式”**对体验与性能的根本性影响。

从最初的浏览器渲染，到现在“在离用户最近的地方动态返回 HTML”，架构正在悄悄改变。

这篇文章我们用一张思维图，梳理：

• 前端架构渲染方式演进的五个阶段

• 每种方式的核心逻辑、优缺点

• 当前趋势：边缘渲染（Edge Rendering）为何成了“显学”

一、前端架构五阶段演进图

静态 HTML → SPA → SSR → SSG → ISR → Edge SSR

我们按时间和复杂度拆解：

渲染方式	特征	代表框架	部署平台
静态 HTML	页面全写死	无	任意静态空间
SPA（客户端渲染）	JS 驱动 DOM	React, Vue	任意 CDN
SSR（服务端渲染）	Node 渲染 HTML	Next.js, Nuxt	Node 服务器
SSG（静态生成）	构建时产出 HTML	Gatsby, Next.js	CDN
ISR（增量静态渲染）	按需构建、可回源	Next.js ISR	Vercel / Netlify
Edge SSR	离用户最近处实时渲染	Next.js App Router	Cloudflare, Vercel Edge

 二、SPA：从“快”到“慢”的误解

最早的 React/Vue SPA 项目“快得飞起”，但后来大家发现：

• 首屏加载慢（JS 巨大）

• SEO 效果差（HTML 是空壳）

• 数据都等 JS 跑完后才加载

原因是：所有渲染都在浏览器端完成，HTML 是个“壳子”。

三、SSR 与 SSG：性能与 SEO 的回归

为了解决 SPA 的问题，我们开始：

• SSR：在服务器上生成完整 HTML → 提升首屏 + SEO

• SSG：构建阶段生成 HTML → 快得像静态页，但不能频繁变动内容

但：

• SSR 受限于服务器性能，用户远了就慢

• SSG 内容一旦多，需要频繁重新构建

四、ISR：让静态页“活”起来

ISR（Incremental Static Regeneration）是个妙招：

• 页面首次访问时构建

• 后续访问使用缓存

• 设定过期时间或 tag 控制更新

优势是：无需每次部署全量构建，也保留 CDN 加速的性能

五、Edge SSR：渲染靠近用户，真正意义上的“前端后端化”

为什么需要 Edge SSR？

传统 SSR 服务器 → 可能在东京

中国用户访问 → 经历 300ms 网络时延

Edge SSR → 在香港、北京、上海的边缘节点直接执行渲染逻辑

提升的是：全局用户的首屏体验和动态内容交付能力

如何实现？

• 利用平台如 Vercel Edge Functions、Cloudflare Workers

• 使用 Next.js App Router + middleware + edge config

这就意味着你的 React 应用可以在 CDN 的边上完成动态 HTML 渲染，而不必等中央服务响应。

 六、总结

现代前端开发者不只是“写页面的人”，而是“体验调度师”。

在你下次回答“这个项目我们用什么架构”的时候，试着思考：

• 渲染在哪里？

• 数据在哪里？

• 用户在哪里？