边缘计算一：现代前端架构演进图谱 —— 从 SPA 到边缘渲染

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

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

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

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

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

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

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

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

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

 二、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 渲染，而不必等中央服务响应。

 六、总结

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

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

• 渲染在哪里？

• 数据在哪里？

• 用户在哪里？