跳到主要内容

前端渲染架构简记

前言​

前端渲染不再只是简单区分 CSR 和 SSR。

渲染方式的差异体现在：

  • 页面默认在哪里生成
  • 交互代码什么时候下发
  • 是否需要整页水合
  • 是否可以局部激活 / 渐进激活
  • 服务端逻辑是在中心节点还是边缘节点执行

这一轮演进的核心背景，基本都绕不开一个词：Hydration Tax（水合开销）。

概念区分​

有些词是渲染模式，有些词更像是增强策略。

更像“渲染模式”的​

  • CSR
  • SSR
  • SSG
  • ISR
  • Islands
  • RSC / Server-First
  • Resumability

更像“增强策略”或“运行位置”的​

  • Streaming SSR：更像服务端渲染的传输 / 展示策略
  • Edge Rendering：更像服务端逻辑运行在边缘节点的部署策略

所以：

  • Streaming 不等于一种独立于 SSR 的全新渲染模式
  • Edge 也不等于一种和 CSR / SSR 平级的页面渲染模型

几种常见模式​

1. CSR​

客户端拿到一个壳，然后主要在浏览器里执行 JavaScript、拉数据、渲染页面。

特点：

  • 前端交互自由度高
  • 首屏更依赖 JS 下载和执行
  • SEO 通常不如 SSR / SSG

适合：

  • 后台系统
  • SaaS 工作台
  • 控制面板
  • 高交互、低 SEO 需求页面

2. SSR​

每次请求到来时，服务端直接生成 HTML 返回给浏览器。

特点：

  • 首屏内容更快出现
  • SEO 友好
  • 服务端压力更高
  • 传统同构 SSR 仍然常常需要客户端继续 hydration

适合：

  • SEO 敏感页面
  • 商品详情页
  • 新闻、门户、营销站

3. SSG​

构建时预生成静态 HTML，部署后直接从 CDN 或静态资源服务器返回。

特点：

  • 非常快
  • 成本低
  • 内容更新不够灵活

适合：

  • 博客
  • 文档站
  • 营销页
  • 几乎不频繁变化的内容站点

4. ISR​

本质上还是静态生成路线，但允许页面在后台按策略重新生成。

特点：

  • 兼顾静态访问速度和内容更新能力
  • 比纯 SSG 更灵活
  • 会引入缓存与再生成策略复杂度

适合：

  • 内容更新频率中等的网站
  • 商品页
  • CMS 驱动内容页

5. RSC / Server-First​

RSC 虽然也有服务端介入渲染，但核心不是“把整页 SSR 一遍”这么简单，而是：

  • 能放在服务端执行的组件，就尽量放服务端
  • 只有真正需要交互的部分，才进入客户端组件边界

特点：

  • 客户端 JS 可以更少
  • 数据获取能更靠近服务端
  • 更强调 server/client component 的边界拆分

适合：

  • 需要兼顾内容展示和交互的现代 React 应用
  • Next.js App Router 一类项目

要注意：

RSC 的核心是 组件执行与产物边界：能放在服务端的组件就在服务端执行（其代码默认不进客户端包）；只有真正需要交互的部分，才再标成 Client Component。它常与 SSR / Streaming 组合使用，但不等于传统“整页 SSR 再整页水合”。

6. Islands​

页面大部分内容先作为静态 HTML 输出，只有局部交互区域单独激活。

特点：

  • 默认静态
  • 局部 hydration
  • 非交互区域几乎没有多余 JS 负担

适合：

  • 内容为主、交互点零散的网站
  • 电商详情页
  • 博客、文档、品牌官网

7. Resumability​

代表思路是：不是在客户端重新执行整套 hydration，而是把服务端状态“恢复执行”。

特点：

  • 尽量避免传统 hydration 的重放成本
  • 交互代码更细粒度按需加载
  • 模型先进，但心智门槛和生态门槛也更高

适合：

  • 对启动成本特别敏感的场景
  • 想进一步压低客户端首包和恢复成本的项目

Streaming 和 Edge 应该怎么看​

Streaming SSR​

Streaming SSR 的重点不是“换了一种新的渲染流派”，而是：

服务端不必等整页都准备好，能先把骨架或先到的数据流式发给浏览器。

所以它更像：

  • SSR 的增强手段
  • Suspense 驱动的渐进呈现策略

适合：

  • 页面里有快慢数据源混合
  • 希望更早把骨架、头部、主布局先展示出来

Edge Rendering​

Edge Rendering 的重点不是页面生成逻辑本身，而是：

让服务端逻辑在离用户更近的边缘节点执行。

所以它更像：

  • SSR / RSC / API 响应的运行位置优化
  • 用基础设施缩短 RTT 和首字节延迟

适合：

  • 全球用户分布明显
  • 对地理位置、Cookie、AB Test 有快速个性化需求

一张表先看区别​

模式页面主要在哪生成JS 负担SEO更适合什么代表栈（举例）
CSR客户端高纯 CSR 且无预渲染时一般后台系统、强交互应用CRA / Vite SPA
SSR服务端按请求生成 HTML；交互仍常需水合中到高好SEO 页面、动态内容页Next pages SSR 等
SSG构建时生成低好博客、文档、静态内容站多数文档站
ISR以静态为主，后台再生低到中好商品页、CMS 内容站Next ISR
RSC / Server-First服务端优先，客户端只保留交互边界更低好现代 React 混合应用Next App Router
Islands大部分静态，局部激活低好内容站、零散交互页面Astro / Fresh
Resumability服务端序列化后客户端恢复很低好对启动成本极度敏感的场景Qwik
flowchart TB
    subgraph Modes["渲染模式"]
        CSR
        SSR
        SSG
        ISR
        RSC
        Islands
        Resumability
    end
    subgraph Transport["传输策略"]
        Streaming[Streaming SSR]
    end
    subgraph Runtime["运行位置"]
        Edge[Edge Rendering]
        Origin[中心源站]
    end
    SSR --> Streaming
    RSC --> Streaming
    SSR --> Edge
    RSC --> Edge
    SSR --> Origin

怎么选​

高交互、低 SEO​

  • CSR
  • 或 Server-First 下更偏 Client Components 的方案

典型场景：

  • SaaS 后台
  • 复杂控制面板
  • 数据操作频繁的工作台

内容优先、SEO 优先、交互零散​

  • SSG
  • ISR
  • Islands

典型场景：

  • 官网
  • 博客
  • 文档站
  • 电商详情页

想同时兼顾服务端数据获取和细粒度交互​

  • RSC / Server-First
  • Streaming SSR

典型场景：

  • 现代 React 全栈应用
  • 希望减小客户端包体积的内容 + 交互混合页面

对启动成本和弱网体验特别敏感​

  • Resumability
  • 或 Edge + Streaming 的组合优化

注意事项​

  • 不要把 RSC 和 SSR 当成同义词
  • 不要把 Streaming 当成独立于 SSR 的新渲染大类
  • 不要把 Edge Rendering 当成和 CSR / SSR 同一层级的页面渲染模式
  • 真实项目里通常不是单选，而是混合：例如 SSG + Islands、RSC + Streaming、SSR + Edge

一句话总结：

现代前端渲染架构的核心，不是争论“到底用 CSR 还是 SSR”，而是根据页面的内容密度、交互强度、SEO 需求和网络环境，把渲染位置、JS 负担和激活时机拆开来单独优化。