啥是 XXR ？认识前端项目渲染模式们

发布时间：2025-11-05 16:00:57 来源：云智核 作者：域名

这是认识我们团队 @许滨楠 同学做的内部分享，科普当下流行的前端 CSR、SSR、项目渲染SSG 等渲染模式的模式们原理与优劣势，相当有料。认识

PS：我们是前端字节游戏中台前端团队，日常学习氛围浓厚，项目渲染最近听说要 10-7-5 了，模式们还有大量 HC，认识欢迎自荐。前端

一、项目渲染啥是模式们「啥是 XXR ?」?

前端研发中有许多常见场景，根据不同的认识构建、渲染过程有不同的前端优劣势和适用情况。如现代 UI 库加持下常用的项目渲染 CSR、具有更好 SEO 效果的 SSR (SPR)、转换思路主打构建时生成的 SSG、大架构视野之上的 ISR、DPR，还有更少听到的 NSR、亿华云ESR 等等。

诸多方案的提出和完善带来了更多的技术选型可能，迅速涌现的生态支持也让不同方案的开发体验、心智负担渐渐趋于便捷、开发者无感。

但：

希望这篇文章能帮助解决上述这样的疑惑，这就是「啥是 XXR ?」。

若尚不完整或有失偏颇，欢迎讨论 & 指教。

二、渲染模式——概念与对比

这里所说的 ✌🏻 渲染模式 ✌🏻，包括：

页面 / 应用在开发完成之后的产物编译方式;

部署上线之后的服务形态;

资源存储与分发的方式;

用户访问时的免费源码下载启动与渲染过程;

这几方面不同的实现和规范。

本节将介绍各种渲染模式的基本特点、运作方式，还有对应的优缺点比较。

2.1 CSR for Client Side Rendering

顾名思义的“客户端渲染”，是当下用于渲染各类 UI 库构建的前端项目的最常见方案。

2.1.1 啥是 CSR?

在这种模式下，页面托管服务器只需要对页面的访问请求响应一个类似这样的空页面：

可以看到页面中留出一个用于填充渲染内容的视图节点 (div#root)，并插入指向项目编译压缩后的 JS Bundle 文件的 script 节点和指向 CSS 文件的 link.stylesheet 节点等。

浏览器接收到这样的文档响应之后，会根据文档内的链接加载脚本与样式资源，并完成以下几方面主要工作：执行脚本、进行网络访问以获取在线数据、使用 DOM API 更新页面结构、绑定交互事件、注入样式，以此完成整个渲染过程。香港云服务器

2.1.2 优劣相依

CSR 模式有以下几方面优点：

优劣相依，这样的模式也具有以下缺陷：

2.2 SSR for Server Side Rendering

“事物的发展是螺旋上升的。”

2.2.1 啥是 SSR?

SSR 的概念，即与 CSR 相对地，在服务端完成大部分渲染工作，其实这就是一开始还没有如今的前端的时候，页面的呈现方式——服务器在响应站点访问请求的时候，就已经渲染好可供呈现的页面。但不同于刀耕火种时代通过后端模板之类方案生成页面，如今的 SSR 能力已经越来越强大，部分情况下甚至能做到“开发者低感知”的状态——开发 SSR 与 CSR 项目并没有太多不同(如厂内框架 Jupiter 的 SSR 支持)。这有赖于社区生态的发展，上面提到 CSR 的框架/类库(当然还有没提到，笔者本身也很少实践的 Angular、Svelte 等)，都有非常优秀的 SSR 方案。

2.2.2 简述原理

— “在服务端完成页面渲染，岂不是要在服务端模拟一个浏览器?”

— “是，但不完全是。”

像 React、Vue 这样的 UI 生态巨头，其实都有一个关键的 Virtual DOM (or VDOM) 概念——浏览器 DOM API 太慢，先自己建模处理视图表现与更新、再批量调 DOM API 完成视图渲染更新。这就带来了一种 SSR 方案：

VDOM 是自建模型，是一种抽象的嵌套数据结构，也就可以在 Node 环境(或者说一切服务端环境)下跑起来，把原来的视图代码拿来在服务端跑，通过 VDOM 维护，再在最后拼接好字符串作为页面响应，生成文档作为响应页面，此时的页面内容已经基本生成完毕，把逻辑代码、样式代码附上，则可以实现完整的、可呈现页面的响应。

在此基础上，另外对于一些需要在客户端激活的内容，如 Vue 实例接管组件行为、React Effect 在客户端的触发执行，则由编译时生成 Bundle，并在响应页面内的超链接脚本额外附着。

2.2.3 先扬后抑

SSR 方案发展在 CSR 之后再次得到推进，很大程度上就是为了解决 CSR 的一些问题，这也是 SSR 相较之下突出的优势：

2.2.4 SPR for Serverless Pre-Rendering

无服务预渲染，这是 Serverless 话题之下的一项渲染技术。SPR 是指在 SSR 架构下通过预渲染与缓存能力，将部分页面转化为静态页面，以避免其在服务器接收到请求的时候频繁被渲染的能力，同时一些框架还支持设置静态资源过期时间，以确保这部分“静态页面”也能有一定的即时性。

这是对 SSR 服务运行计算成本高、服务负载大的一种针对性优化，如今也已经有不少前沿框架支持，开发者可以非常方便地引入。

2.3 SSG for Static Site Generation

某种形式上的缝合怪 —— but in a good way.

2.3.1 啥是 SSG?

说它是缝合怪，是因为它与 CSR 一样，只需要页面托管，不需要真正编写并部署服务端，页面资源在编译完成部署之前就已经确定;但它又与 SSR 一样，属于一种 Prerender 预渲染操作，即在用户浏览器得到页面响应之前，页面内容和结构就已经渲染好了。当然形式和特征来看，它更接近 SSR。

如果说 CSR 与 Prerender 差异在于渲染工作重心的抉择，同是 Prerender 的 SSR 和 SSG 则是渲染——或者是这其中非常重要的“注水”——填充内容操作在时机上的抉择。

又或者从另一个角度来说，不同于把大部分渲染工作留到请求时做的 CSR 和 SSR，SSG 在站点项目构建部署的时候，就把页面内容大致填充好了。

最终 SSG 模式的有点真正“返璞归真”的意思，原本日益动态化、交互性增强的页面，变成了大部分已经填充好，托管在页面服务 / CDN 上的静态页面。

2.3.2 平衡得够好吗?

SSG 兼收了传统 CSR 和 SSR 的优点的同时，对这两者的短板也做到较好的互补。服务负担低、加载性能与体验佳、SEO 友好，这些 SSG 的取各家之长的优势此处不必单独分析，但还有一些好处源自这个模式本身：

页面内容都是静态生成过的，页面部署只需要简单的页面托管服务器，甚至只需要放在 CDN 之上，大量减少了动态性，还有服务器对页面加载、渲染工作的干预，也就让恶意攻击少了很多可乘之机;

SSG 的不足之处也值得提出来讨论：

随着应用的拓展和复杂化，预渲染页面的数量增长速度很快。SSG 项目有较高的构建和部署开销，应用越复杂，需要构建出来的静态页面就会越多，对于功能丰富的大型站点，每次构建需要渲染成千上万个页面都是有可能的，这必然带来较高的部署、更新成本;

高度静态化带来非即时性，用户访问到的页面内 SSG 生成的部分，确保有效性的时间节点是上一次构建，使该模式下的应用失去了部分时效性，这部分缺陷需要通过定时构建、或者部分非 SSG 来弥补，这也是 SSG 的主要问题。

2.4 BTW

既然说到了，那就说一说。

还有一些 XXR，并不是 CSR / SSR 那样的大阵营或整体方案，而是一些性能策略、优化手段，同时还依赖更大架构下的技术能力支持，这里罗列并简单介绍。

2.4.1 NSR for Native Side Rendering *

Native 就是客户端，万物皆可分布式，可以理解为这就是一种分布式的 SSR，不过这里的渲染工作交给了客户端去做而不是远端服务器。在用户即将访问页面的上级页面预取页面数据，由客户端缓存 HTML 结构，以达到用户真正访问时快速响应的效果。

NSR 见于各种移动端 + Webview 的 Hybrid 场景，是需要页面与客户端研发协作的一种优化手段。

2.4.2 ESR for Edge Side Rendering *

Edge 就是边缘，类比前面的各种 XSR，ESR 就是将渲染工作交给边缘服务器节点，常见的就是 CDN 的边缘节点。这个方案主打的是边缘节点相比核心服务器与用户的距离优势，利用了 CDN 分级缓存的概念，渲染和内容填充也可以是分级进行并缓存下来的。

ESR 之下静态内容与动态内容是分流的，边缘 CDN 节点可以将静态页面内容先响应给用户，然后再自己发起动态内容请求，得到核心服务器响应之后再返回给用户，是在大型网络架构下非常极致的一种优化，但这也就依赖更庞大的技术基建体系了。

2.4.3 ISR for Incremental Site Rendering

直译，增量式网站渲染。也很好理解，就是对待页面内容小刀切，有更细的差异化渲染粒度，能渐进、分层地进行渲染。常见的选择是：对于重要页面如首屏、访问量较大的直接落地页，进行预渲染并添加缓存，保证最佳的访问性能;对于次要页面，则确保有兜底内容可以即时 fallback，再将其实时数据的渲染留到 CSR 层次完成，同时触发异步缓存更新。

对于“异步缓存更新”，则需要提到一个常见的内容缓存策略：Stale While Revalidate，CDN 对于数据请求始终首先响应缓存内容，如果这份内容已经过期，则在响应之后再触发异步更新——这也是对于次要元素或页面的缓存处理方式。

基于此，CDN 做的事情是直接响应用户的每个请求，并在用户触发 fallback、当前预渲染过的页面过期失效且再次被用户访问的时候更新缓存的预渲染资源;客户端在感知上则有以下不好的体验：

2.4.4 DPR for Distributed Persistent Rendering

DPR 是一家云计算公司 Netlify 在几个月前 (2021/04) 才发出的一个 「新提案」(https://github.com/jamstack/jamstack.org/discussions/549)，它是基于 ISR 基本模型的一种升级，也是针对 ISR 在即时性上的不足的优化。

看过定义和提案之后我对 DPR 的译名斟酌不定，大概是“分布式持续/持久化渲染”，因为其利用了 CDN 分布节点进行渲染请求——分布(而且渲染时机也是分布在构建 / 请求时的);又是一个按需渐进的过程——持续;同时在 CDN 基础上架设了缓存能力——持久化。

这听起来在分布式方面跟上面刚刚说到的 NSR 有点像，又跟 ESR 很接近，实际上这里的分布式跟前者完全不同，但与 ESR 确实有很多相似之处，甚至可以说是其升级版本。这里借用提案中的图简单介绍： 

左边虚线框是构建过程，中间 DPR functions 可以是一些 Serverless 的或是在核心页面服务器上的按需构建函数，然后是 CDN 缓存节点，最后到用户浏览器。

Build 阶段就会完成 generate site 的操作，这一步并不会完成所有构建，而只生成关键部分的资源，部署到页面托管服务或者 CDN 之上;而对于其他内容，有一个按需处理的过程—— CDN 会在收到首个访问请求的时候实时要求构建，并将最新构建结果返回给用户，同时将这部分内容加入原有缓存资源中;缓存的资源也会在下一次构建更新的时候被失效。

三、如何选择

— 现在我选眼花了 😵‍💫

这些方案并非完全并列，较难完全“分支化决策”，这里列出几个考虑中的关注点：

特性关注点：

是否关注 SEO

是否具有丰富可交互性、需要用户能力、差异化渲染

页面结构 & 路由是否复杂、数据更新是否频繁、是否依赖实时数据接口

依赖关注点：

是否接受引入服务器运维成本

旧有实现中是否有浏览器依赖如 UI 框架内对 DOM、BOM，或 Hybrid 场景下的 JSBridge 的使用

以上考虑点都不产生限制，那就选用优缺点最能满足项目特征的、有比较完备的技术基建支持的模式吧～

本文转载自微信公众号「Tecvan」

相关文章