# CSR 的痛点 · 为什么要把渲染搬回服务端

> 纯客户端渲染(CSR)把「空壳 HTML + 一大包 JS」发给浏览器，首屏白屏、SEO 抓不到、请求瀑布、社交分享没预览——这四个痛点，正是把渲染推回服务端的原因。

- 作者：David（道雾轩）
- 专栏：SSR 从入门到精通（https://daiw.org/manual/ssr.md）
- 最后更新：2026-07-14
- 原文：https://daiw.org/manual/ssr/csr-pain
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# CSR 的痛点 · 为什么要把渲染搬回服务端

要理解 SSR 为什么会「回来」，得先看清它要解决的问题——**纯客户端渲染(CSR)的痛**。

CSR 是单页应用(SPA)的默认模式：服务器只发一个几乎**空的 HTML 壳**，内容全靠浏览器下载并执行 JavaScript 后**现场画出来**。这个壳长这样：

```html
<body>
  <div id="root"></div>              <!-- 空的,啥也没有 -->
  <script src="/app.bundle.js"></script>  <!-- 全部内容都在这一大包 JS 里 -->
</body>
```

浏览器拿到它之后，要走一长串**串行**步骤才能看到内容：

```mermaid
flowchart LR
  A["请求页面"] --> B["拿到空 HTML 壳"]
  B --> C["下载 JS bundle"]
  C --> D["解析 + 执行 JS"]
  D --> E["发起数据请求"]
  E --> F["拿到数据"]
  F --> G["渲染出内容"]
```

问题就藏在这条链里。逐个看。

## 痛点一：首屏白屏

从「拿到空壳」到「渲染出内容」之间的每一步，用户看到的都是**一片空白**（或一个转圈）。在这条链走完之前，页面上什么有意义的东西都没有。

这直接拖垮两个关键指标：**FCP（首次内容绘制）** 和 **LCP（最大内容绘制）**。JS 包越大、网络越慢、设备越差，白屏越久。低端手机上，「下载 + 解析 + 执行」一大包 JS 可能就要好几秒——这几秒里，用户对着白屏，很可能已经走了。

<Callout type="info">
  CSR 的白屏，本质是**把「渲染工作」全压到了用户设备上**。服务器很轻松（只发个静态壳），但代价是每个用户的浏览器都要从零算一遍。你的服务器越省事，用户的首屏就越慢——这笔账，CSR 是让用户来付的。
</Callout>

## 痛点二：SEO 抓不到

搜索引擎和社交平台的爬虫来抓你的页面，拿到的是那个**空壳**——`<div id="root"></div>` 里什么都没有。内容要等 JS 执行完才出现，而很多爬虫**不执行 JS，或执行得不完整、有延迟、有预算限制**。

结果：你辛辛苦苦写的内容，搜索引擎可能根本没「看见」，自然也就不给你排名。对于内容站、电商、博客这种**靠搜索引流**的站点，CSR 的这个痛点是致命的。

## 痛点三：请求瀑布

看回那张流程图，注意它是**一条直线**——每一步都得等上一步做完：

**下载 HTML → 下载 JS → 执行 JS → 才知道要请求哪些数据 → 请求数据 → 渲染。**

数据请求**排在 JS 执行之后**，因为「要请求什么数据」这个信息本身写在 JS 里。于是形成一个**串行瀑布**：该早点开始的数据请求，被硬生生推到了很后面。本可以并行的事被串起来做，首屏就更慢了。

## 痛点四：社交分享没预览

把 CSR 页面的链接发到微信、Twitter、Slack，它们的爬虫抓到空壳、读不到 `<title>` 和 `og:` 元数据（那些也可能是 JS 动态设置的）——于是**分享出去不成卡片**，只有一个光秃秃的链接。

<Callout type="info">
  这正是[「元数据决定分享卡片」](https://daiw.org/manual/ssr/what-is-ssr)的现实意义：分享卡片、SEO 摘要，都依赖**初始 HTML 里就有**正确的 `<title>` / `<meta>` / `og:image`。CSR 把这些交给运行时的 JS，爬虫往往等不到。要让链接分享成卡片，内容和元数据必须**在服务端就写进 HTML**——这就指向了 SSR。
</Callout>

## 痛点五：包体与设备

CSR 把整个应用的渲染逻辑、路由、状态管理全塞进 JS 包。应用越大，包越大；包越大，「下载 + 解析 + 执行」越久。而这笔开销**每个用户、每次首次访问都要付一遍**，且在低端设备上被放大——CPU 弱，解析执行 JS 就慢。你在高端开发机上体验流畅，不代表用户的千元机上也流畅。

## CSR 也不是一无是处

得公平地说：CSR 有它的主场。**登录后的后台、仪表盘、内部工具**——这些页面 SEO 无关紧要、用户会长时间停留（首屏那点慢一次就摊平了）、交互极其频繁——CSR 的「一次加载、之后全在客户端流畅切换」反而很香。**CSR 的问题不在于它错，而在于它被用错了地方**：拿它去做面向公众、靠搜索引流、首屏敏感的内容站，就是灾难。

## 小结与下一章

CSR 把渲染全压到客户端，换来了「一次加载后交互流畅」，却付出了**首屏白屏、SEO 抓不到、请求瀑布、分享无预览**的代价。这些痛点有一个共同的解法：**让服务器把带内容的 HTML 直接发出来**——这就是 SSR。

下一章，我们就看这件事到底怎么做：一次请求打到服务器后，SSR 在服务端走了怎样一段旅程，才把一份「开箱即用」的 HTML 交到浏览器手里。👉 [SSR 是什么：一次请求的服务端旅程](https://daiw.org/manual/ssr/what-is-ssr)。

## 参考文献

- [1] web.dev.「Rendering on the Web.」https://web.dev/articles/rendering-on-the-web —— CSR / SSR / SSG 的权威对比。
- [2] MDN.「Core Web Vitals / LCP.」https://developer.mozilla.org/en-US/docs/Web/Performance —— FCP、LCP 等指标定义。
- [3] Google Search Central.「JavaScript SEO Basics.」https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics —— 爬虫对 JS 渲染内容的处理。