SSR 与 CSR：服务端渲染与客户端渲染详解

想象你是一位饥饿的食客，面前有两家餐厅：一家由厨师备好整餐直接上桌（速度快，但修改需回厨房）；另一家提供生食材供桌边自烹如韩式烤肉（起步慢，但可自定义口味）。

同理，Web 开发中决定网页渲染方式的两种核心技术为：服务端渲染（SSR，发送页面前由服务器完成）与客户端渲染（CSR，接收页面后由浏览器完成）。 

CSR 将负载转移至用户浏览器，虽减轻服务器压力，但体验可能偏慢；SSR 则向浏览器发送完全渲染好的页面，用户感知速度更快。

以下是两者的核心区别：

什么是服务端渲染（SSR）？

服务端渲染（SSR）指网页在服务器上加载并渲染。服务器构建包含 UI 和数据的完整 HTML 发送至浏览器，浏览器直接展示该页面，随后再下载 JavaScript 以增强交互性。

SSR 适用于电商、落地页、博客及内容密集型站点，对 SEO 和首屏加载速度至关重要。因服务器发送完整 HTML，内容呈现快且易于搜索引擎抓取索引。

不过，SSR 在高流量下消耗较多服务器资源，且在 Gmail、Notion 等动态应用中体验可能不够流畅（每次重载均需请求服务器）。可通过 WebSockets 实现实时通信，或利用 Cookie、隐藏字段等进行客户端状态管理，以降低服务器负载。

什么是客户端渲染（CSR）？

客户端渲染（CSR）将 HTML 内容及 UI 的构建工作转移至用户浏览器。服务器仅发送极简 HTML 文件，浏览器下载 JavaScript 代码后，通过 API 获取内容并在本地渲染。

CSR 适合打造流畅的应用级体验，如聊天应用、社交信息流及仪表盘，尤其适用于单页应用（SPA），即部分内容更新无需重载整个页面。

其劣势在于：设备性能差或网络慢时，内容显示耗时较长；且对 SEO 不友好，搜索引擎难以索引 JS 渲染的内容（尽管现状正改善）。对于简单静态页，CSR 显得过于复杂。

SSR 与 CSR：核心区别

• 内容渲染位置
• 初始页面加载
• 交互性
• 搜索引擎优化（SEO）
• 服务器负载

两者均将数据、内容和 UI 从服务器传输至浏览器，仅方式不同。现代网站常结合二者：先通过 SSR 提供初始页面保障速度，再切换至 CSR 实现流畅交互——如同先吃开胃菜，主菜再自烹。

具体区别如下：

内容渲染的位置

SSR 在服务器端完成内容与 UI 渲染后再发送至浏览器。JS 后续仅用于增强交互，主要结构与数据已就位。这带来更快的首屏加载和跨设备一致的布局，但随流量增长，服务器处理每个请求的压力增大，需更多基础设施支持。 

CSR 在用户浏览器中渲染内容。JS 从服务器获取数据，在初始极简 HTML 交付后加载至浏览器。此举减轻服务器负载，赋予浏览器更多 UI 控制权，但依赖 JS 启用，且脚本加载完成前内容不可见，可能导致显示延迟。

初始页面加载

SSR 一次性发送完整内容与界面。因页面到达时已构建完毕，用户能更快看到内容，缩短首屏时间，提升性能感知。但若服务器渲染滞后或依赖后置 JS，页面间导航可能变慢。

CSR 快速发送轻量级 HTML，但用户需等待 JS 下载、获取数据并渲染，故首屏较慢。一旦加载完成，CSR 应用内导航更快，因浏览器可在无完整重载的情况下处理更新。

对用户而言，CSR 初期可能显慢，但因 JS 已在本地运行，后续导航表现优异。

交互性

SSR 首屏快，但按钮、表单等动态元素需待 JS 加载并完成“水合”（hydration）后才能工作。水合过程弥合了 SSR 首屏速度与 CSR 强交互能力间的差距。

CSR 极适合开发交互式前端（如聊天室、实时仪表盘、拖放界面）。浏览器负责所有渲染，更新或过渡无需重载页面，体验流畅类原生应用。代价是用户需等待 JS 完全下载解析才能看到内容，可能出现短暂闪烁或延迟。

搜索引擎优化（SEO）

SSR 将内容直接嵌入发送至浏览器的 HTML 中，便于 Google 等搜索引擎抓取排名，非常适合博客等信息类网站。但个性化内容处理较复杂，需在渲染前捕获用户数据。

CSR 内容最初不存在于 HTML 中，仅在浏览器运行 JS 后出现，增加了搜索引擎索引难度，尤其对内容密集或依赖搜索的网站不利。不过，预渲染、静态生成或混合渲染可缓解此问题，且搜索引擎对 JS 页面的索引能力正持续提升。 

服务器负载

SSR 由服务器处理请求、构建 HTML 并实时交付，高负载或复杂页面下资源消耗大，需缓存、查询优化或并行获取等技术支撑。

CSR 大部分工作在浏览器完成，服务器仅发送静态文件或响应 API 请求，负载轻、扩展易、成本低。但对老旧或低性能设备用户而言，本地处理压力较大。