前端架构-CSR、SSR 和 SSG
将从 定义、流程、优缺点和适用场景 四个方面详细说明它们的区别。
一、核心定义
| 缩写 | 英文 | 中文 | 核心思想 |
|---|---|---|---|
| CSR | Client-Side Rendering | 客户端渲染 | 服务器发送一个空的 HTML 壳和 JavaScript bundle，由浏览器下载并执行 JS 来渲染内容。 |
| SSR | Server-Side Rendering | 服务端渲染 | 服务器在每次请求时，动态生成并填充数据的完整 HTML 页面，然后发送给浏览器。 |
| SSG | Static Site Generation | 静态站点生成 | 在项目构建时，就预先生成好完整的、带内容的 HTML 页面。服务器直接返回这些现成的文件。 |
二、详细流程对比
为了更直观地理解三者的区别，下图展示了从用户请求到页面展示的完整流程差异：
通过上图流程可以清晰地看到：
- CSR 的“白屏时间”最长，因为需要等待 JS 下载、执行并完成数据抓取后才会渲染内容。
- SSR 和 SSG 都能快速呈现初始内容，因为它们直接向浏览器提供了完整的 HTML。两者的核心区别在于 HTML 的生成时机：SSR 是“动态生成”，而 SSG 是“预先构建”。
三、优缺点对比
| CSR | SSR | SSG | |
|---|---|---|---|
| 优点 | 1. 前后端分离，开发模式清晰。 2. 服务器压力小，资源消耗低。 3. 首次加载后，后续页面切换极快（SPA体验）。 | 1. 首屏加载快，用户体验好。 2. SEO 友好，搜索引擎可直接抓取。 3. 社交分享预览效果好。 | 1. 性能极致，速度最快（可从CDN分发）。 2. 安全性高，无服务器端逻辑。 3. SEO 友好。 4. 部署简单、成本低。 |
| 缺点 | 1. 首屏加载慢，白屏时间长。 2. SEO 不友好，爬虫难以抓取。 3. 社交分享预览内容为空。 | 1. 服务器压力大，每次请求都渲染。 2. 开发复杂度高，需考虑服务端环境。 3. TTI可能较慢，注水完成前无法交互。 | 1. 不适用于高度动态内容（如 dashboard）。 2. 数据变化需重新构建整个站点。 |
四、如何选择？适用场景是什么？
-
选择 CSR 如果：
- 你的应用是后台管理系统、Dashboard 等对 SEO 毫无要求的场景。
- 你非常看重 SPA 的流畅交互体验，且用户不会频繁刷新页面。
-
选择 SSR 如果：
- 你的应用是内容型网站（新闻站、博客、电商商品页），SEO 和首屏速度是生命线。
- 你需要为每个用户或每次请求生成个性化内容（如用户仪表盘）。
- 你愿意承担更高的服务器成本和开发复杂度。（Next.js, Nuxt.js 等框架极大地降低了复杂度）
-
选择 SSG 如果：
- 你的网站内容主要是静态的，数据不会频繁变更（文档、博客、公司官网、营销落地页）。
- 你追求极致的性能、安全性和低廉的托管成本。
- 你甚至可以接受在内容更新后等待一段构建时间。（Next.js, Gatsby, VuePress, Hugo 等都是优秀的SSG框架）
现代框架的融合趋势
值得注意的是，像 Next.js 这样的现代框架并不强迫你只选择一种模式，而是支持混合模式（Hybrid）：
- 你可以将大部分页面设置为 SSG（如博客文章、产品页）。
- 将少数需要服务器渲染的页面设置为 SSR（如用户订单页）。
- 同时保留 CSR 的交互体验（如网站后台）。
这种“量体裁衣”的方式，让你能为每个页面选择最合适的渲染策略，从而在性能、SEO和开发体验上取得最佳平衡。