過去十年，前端項目架構經歷了從簡單 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 渲染，而不必等中央服務響應。

?六、總結

現代前端開發者不只是“寫頁面的人”，而是“體驗調度師”。

在你下次回答“這個項目我們用什么架構”的時候，試著思考：

• 渲染在哪里？

• 數據在哪里？

• 用戶在哪里？

?