渲染光谱 · CSR / SSR / SSG / ISR 一图看清

CSR、SSR、SSG、ISR 四个词,本质是同一个问题的不同答案——「什么时候、在哪里,把页面渲染出来」。这一章把它们摆进一张全景图,讲清各自的新鲜度、TTFB、扛量与场景,也为后面的缓存讨论立好坐标系。

作者 David更新于 第 4 篇(共 17 篇)

渲染光谱 · CSR / SSR / SSG / ISR 一图看清

CSR、SSR、SSG、ISR——这四个缩写是 SSR 世界里最容易让人晕的地方。但只要抓住一个核心问题,它们立刻就理顺了:

页面到底是「什么时候」、在「哪里」被渲染出来的?

「什么时候」有三个答案:构建时、请求时、运行时(在客户端)。四种策略,就是这几个答案的不同组合。

四种策略,各在光谱的一端

CSR(客户端渲染) —— 运行时,在用户的浏览器里渲染。服务器只发空壳。→ 上一站讲过的痛点全在这。

SSR(服务端渲染) —— 每次请求时,在服务器上渲染。每个请求都现算一份 HTML。→ 首屏快、内容实时,但每请求都要渲染,贵。

SSG(静态站点生成,Static Site Generation) —— 构建时,一次性把所有页面渲染成静态 HTML 文件。之后所有用户拿到的是同一份预先生成好的 HTML,直接由 CDN 分发。→ 快到飞起、几乎零服务器成本,但内容冻结在构建那一刻,要更新就得重新构建。

ISR(增量静态再生,Incremental Static Regeneration) —— SSG + 定期 / 按需再生。先像 SSG 一样发预生成的静态页(快),但会在后台按一定策略重新生成(比如「最多 60 秒旧」),让静态页也能「渐渐更新」。→ 兼得 SSG 的速度和「内容不至于太旧」。这是 SSG 和 SSR 之间的中间态,后面专门一章细讲。

一张全景表

把它们并排比较,取舍就清楚了:

策略何时渲染每个用户看到的新鲜度TTFB扛并发典型场景
CSR客户端运行时各自现画实时快(空壳)好(服务器轻)后台、仪表盘、内部工具
SSR服务端每请求服务器现画实时慢差(须靠缓存)个性化页、高频变动数据
SSG构建时一次同一份静态构建那刻(旧)极快极好博客、文档、营销页
ISR构建 + 定期再生同一份(定期换新)近实时极快极好电商列表、新闻、榜单

盯着「新鲜度」和「扛并发」这两列看,你会发现一条核心矛盾:

越新鲜,越难扛量;越好扛,越不新鲜。

SSR 最新鲜(每请求现算),但正因为每请求现算,最难扛并发。SSG 最好扛(静态文件、CDN 分发),但内容最旧(冻在构建时)。这条矛盾,是整个渲染策略选择的主轴——而缓存,正是用来在这条轴上「作弊」的:它想让你既拿到接近 SSR 的新鲜度,又拿到接近 SSG 的扛量。这也是为什么本专栏把缓存当成重点。

关键:它们不是「四选一」

一个常见误解是「一个站点只能选一种」。其实现代框架里,渲染策略是「每个页面(甚至每个组件)分别选」的:

  • 博客文章页 → SSG(内容不常变,构建时生成)。
  • 商品列表页 → ISR(内容会变但能容忍几十秒延迟)。
  • 用户个人中心 → SSR(强个性化,必须实时)。
  • 后台仪表盘 → CSR(SEO 无关,交互极频繁)。

同一个站点,不同页面用不同策略,是常态、也是最优解。 「精通 SSR」很大程度上就是「精通为每个页面挑对策略」。

你可能还听过 SSG + 客户端补充(先发静态壳,再在客户端拉动态部分)、PPR(Partial Prerendering,部分预渲染) 等更细的组合。别被名词吓到——它们全都是在这张「构建时 / 请求时 / 运行时」的光谱上做混搭:哪部分能提前算就提前算(偏 SSG),哪部分必须实时就实时(偏 SSR)。抓住「何时渲染」这根轴,再花哨的组合都能看穿。

小结与下一章

CSR / SSR / SSG / ISR,本质是「何时、何地渲染」的不同答案,核心矛盾是新鲜度 vs 扛量,而缓存是用来突破这个矛盾的手段。它们不是四选一,而是按页面混搭。

渲染的地基打完了。第二站,我们看 SSR 这些年是怎么「变聪明」的——它没有停在「每请求傻傻地整页渲染」,而是学会了边算边发。下一章讲流式渲染:让浏览器不必等整页渲染完,而是一块一块地收到 HTML。👉 流式渲染:别等全部,边算边发。

参考文献

本页目录