你给的那张图描述的是浏览器端的关键渲染路径：`HTML → DOM`，`CSS → CSSOM`，合并成 `RenderTree`，再走 `Layout` 与 `Paint`，最后像素上屏。它非常适合解释 `浏览器` 为什么能把一堆文本与样式变成可见页面。

把场景切到 Angular 应用开启 SSR（Server-Side Rendering）之后，一个很容易产生的误解是：服务器端是不是也把 `DOM/CSSOM/Layout/Paint` 这套流程完整跑了一遍，只不过不是画到用户屏幕，而是画到某个“虚拟屏幕”里？

结论很明确：**不会完整经历**。Angular SSR 在服务器端做的是“把应用运行到某个稳定状态，并把组件树渲染成一段 `HTML` 字符串”，它会用一个“服务器端可用的 `DOM` 实现”去承载 Angular 的渲染指令，但**它不具备浏览器的布局与绘制引擎**，也就不存在真正意义上的 `CSSOM`、`Layout`、`Paint`、合成与 GPU 上屏。服务器端输出的只是 `HTML`（以及少量可序列化状态），真正把它变成像素的工作仍然在浏览器里发生。Angular 官方文档把 SSR 定义为在服务器渲染页面并返回初始 `HTML` 内容的过程。([v17.angular.io][1])

为了讲清楚这件事，最好的方式是把一次打开页面拆成两条流水线：**服务器端的 Angular 渲染流水线** 与 **浏览器端的真实渲染流水线**，再把你那张图逐块对照过去。

---

## 一次 Angular SSR 页面访问，实际上是两条流水线叠在一起

### 流水线 A：服务器端（Node.js）做的事情

1. 浏览器发起导航请求到你的 SSR 服务器（可能是 `Express`、`Fastify`、`Nest`、`Cloudflare Workers` 这类边缘运行时的变体）。
2. 服务器在运行时调用 Angular 的 SSR 入口（例如 `ng add @angular/ssr` 生成的服务器端渲染函数），执行 Angular 应用的渲染逻辑。
3. Angular 在服务器端把组件树渲染成一段 `HTML` 字符串，并把它作为响应返回给浏览器。官方描述强调 SSR 的结果是初始 `HTML` 内容并包含初始页面状态。([v17.angular.io][1])

### 流水线 B：浏览器端做的事情（你图里那套）

1. 浏览器接收服务器返回的 `HTML`。
2. 浏览器解析 `HTML` 得到 `DOM`，解析 `CSS` 得到 `CSSOM`，合并出 `RenderTree`。
3. 浏览器执行 `Layout`、`Paint`、分层、栅格化、合成，最终像素上屏。
4. 同时浏览器还要启动 Angular 的客户端逻辑：要么是传统的“重建 `DOM` 再接管”，要么是现代 Angular 推荐的 `Hydration`：复用服务器产出的 `DOM`，只把事件监听与状态绑定“接”上去。Angular 官方明确说明 `Hydration` 只能用于 SSR 应用，并且用于在客户端复用 SSR 的结果。([Angular][2])

从这两条流水线你会发现：SSR 的“渲染”更像是**应用层渲染**（把组件树变成 `HTML`），浏览器的渲染才是**图形学意义上的渲染**（把 `HTML/CSS` 变成像素）。

---

## 把你那张图逐块对照：哪些会在服务器发生，哪些不会

下面用你图里的关键词来对齐，结论会非常直观。

### 1）`HTML → DOM`：浏览器端是“解析”，服务器端是“生成”

**浏览器端**：收到 `HTML` 字节流后，解析器把它解析成 `DOM`。

**Angular SSR 服务器端**：它通常不是先拿到一段 `HTML` 再去解析成 `DOM`。相反，Angular 是从组件树与模板出发，在服务器端创建一棵“可序列化的 `DOM` 结构”，最终输出 `HTML` 字符串。

关键点在于：服务器端确实需要一个 `document` 来承载节点创建、属性设置、插入删除等操作，否则 Angular 的渲染器无处落脚。Angular 的 `platform-server` 就提供了这种能力，并且官方源码注释里写得很清楚：服务器端的初始 `DOM` 默认会用 `Domino` 来创建。([GitHub][3])

也就是说，服务器端会有“某种 `DOM`”，但它不是浏览器真实 `DOM`，更不是浏览器解析 `HTML` 得来的 `DOM`。它更像一个“能让框架把模板输出为节点树”的容器。

现实里的可观察现象也支持这一点：Angular 官方 SSR 指南明确提醒，服务器端缺少很多浏览器能力，像 `window`、`document`、`navigator`、`location` 这些全局对象都不可用。([Angular][4])
这句话背后隐含的事实是：服务器端不是浏览器环境，哪怕有 `Domino` 提供的 `document`，也不是浏览器的 `window/document` 体系。

---

### 2）`CSS → CSSOM`：服务器端通常不会构建 `CSSOM`，也不会算 `computed style`

**浏览器端**：`CSS` 会被解析成 `CSSOM`，再参与样式计算，最后影响 `RenderTree` 与 `Layout`。

**Angular SSR 服务器端**：通常不会去解析整站 `CSS` 建立 `CSSOM`，也不会为每个节点计算 `computed style`。服务器端输出 `HTML` 时，最多是把组件样式以 `<style>` 或 `<link>` 的形式挂到最终 `HTML` 里，让浏览器稍后去解析与应用。

Angular 官方 SSR 文档在“编写可在服务器运行的组件”部分还点到一个很关键的细节：**某些 `HTMLElement` 的属性在服务器上不可用**。([Angular][4])
这句话通常指向的就是那类与布局、渲染、视口相关的属性或行为。原因并不神秘：没有浏览器的样式系统与布局引擎，就谈不上 `CSSOM` 与 `computed style` 的完整语义。

一个很贴近工程的类比是 `jsdom`：它同样是 Node.js 环境里的 `DOM` 实现，社区里长期存在 `offsetWidth/offsetHeight/getBoundingClientRect` 这类布局相关能力缺失的问题，因为缺少 layout engine。([GitHub][5])
Angular SSR 选择的 `Domino` 与 `jsdom` 并不完全相同，但它们共同指向同一个结论：**Node.js 里的 `DOM` 实现主要服务于结构与选择器查询，不服务于真实排版与绘制**。

---

### 3）`DOM + CSSOM → RenderTree`：服务器端没有真正的 `RenderTree`

在浏览器里，`RenderTree` 的意义是：过滤掉不可见节点、合并样式信息，得到“需要参与布局与绘制”的渲染对象集合。

服务器端没有 `CSSOM`、没有真实样式计算，也没有布局引擎，因此不存在浏览器意义上的 `RenderTree`。服务器端更接近的概念是 Angular 自己的视图数据结构（组件视图、模板指令展开后的节点结构），最终被序列化为 `HTML`。

你可以把它理解为：

* 浏览器的 `RenderTree`：面向“怎么画”。
* Angular SSR 的内部结构：面向“输出什么结构的 `HTML`”。

---

### 4）`Layout` 与 `Paint`：服务器端不会发生

这部分是回答你问题的核心。

`Layout` 需要知道视口、字体度量、换行规则、盒模型计算、浮动与定位算法、媒体查询匹配结果等；`Paint` 需要把绘制指令栅格化并交给合成器与 GPU。服务器端 SSR 不具备这些能力，也没有任何意义去做这些事情，因为服务器端最终要交付的是网络响应而不是像素帧。

Angular 官方的 SSR 指南从能力约束层面已经说明了服务器端缺少浏览器 API 与部分 `HTMLElement` 能力。([Angular][4])
从正面定义层面，官方把 SSR 描述为在服务器渲染并产出初始 `HTML` 内容。([v17.angular.io][1])
把这两条信息拼在一起就能得到严谨结论：**服务器端 SSR 的产物是 `HTML`，不是像素；因此不会走浏览器那套 `Layout/Paint` 的图形渲染链路**。

---

## Angular SSR 在服务器端到底“渲染”了什么：一个更贴近实现的视角

如果你把 Angular SSR 看成一台“组件到字符串”的机器，它通常会做这些事：

* 在 `platform-server` 上启动应用（服务器平台的 Angular runtime）。
* 创建一个服务器端 `document`（默认 `Domino`）作为渲染宿主。([GitHub][3])
* 跑组件构造、依赖注入、生命周期钩子（会受 SSR 兼容性影响）。
* 执行变更检测，把模板展开成节点，写入服务器端 `DOM` 容器。
* 把最终的 `DOM` 序列化成 `HTML` 字符串返回。

这个过程中确实会发生大量你在浏览器里也会发生的 Angular 行为，比如 `HttpClient` 请求、订阅 `Observable`、条件渲染、`*ngFor` 展开、国际化管道处理等。你甚至会看到 SSR 请求把后端接口打爆，因为每个用户请求都触发一轮服务端渲染与数据获取。

Angular 官方文档也明确提到：SSR 与 `Hydration` 期间可以配置 `HttpClient` 的传输缓存，把服务器端的响应复用到浏览器端，避免首屏阶段重复请求。([Angular][4])

这说明什么？说明 SSR 服务器端更像在“跑一遍应用逻辑”，而不是“跑一遍浏览器渲染管线”。

---

## `Hydration` 把两条流水线缝起来：为什么你感觉像“渲染经历了两遍”

很多团队上 SSR 后会有一种体感：页面结构像经历了两次构建。原因在于 SSR 的经典模式确实会出现“服务端 `HTML` 与客户端重新渲染”的交接成本。

Angular 在 v16 之后把 `Hydration` 做成更完整的方案：客户端启动时尽量复用服务器端已经生成的 `DOM`，不再粗暴销毁重建，而是把事件监听、状态绑定、组件实例关联到现有节点上。官方博客把它称为非破坏式 `Hydration`，强调可以复用服务器渲染出的 `DOM` 结构。([Angular Blog][6])

Angular 的 `provideClientHydration()` 文档也写得很工程化：默认启用的能力里就包含 `DOM` 对齐式 `Hydration`，以及 SSR 期间的 `HttpClient` 响应缓存传输到客户端以避免额外请求。([Angular][7])

这两条官方信息对应到真实体验就是：

* **你看见内容更早**：因为服务器返回的 `HTML` 让浏览器可以立刻走 `DOM/CSSOM/Layout/Paint` 上屏。
* **你能更快交互**：因为 `Hydration` 复用现有节点，省掉一轮重建与闪烁。
* **你不再重复打接口**：因为传输缓存让首屏阶段的 `HttpClient` 请求可以复用。([Angular][4])

---

## 真实世界案例：电商商品详情页，SSR 与浏览器渲染各自负责什么

假设你做一个 Angular 电商站点的商品详情页 `/p/:id`：

### 只做 CSR（Client-Side Rendering）时

* 浏览器拿到的 `index.html` 很薄，基本只有 `<app-root></app-root>`。
* 浏览器必须下载 `JS` bundle，启动 Angular，发起接口请求拿商品数据。
* 在慢网或低端机上，用户会看到更长时间的空白或骨架屏，搜索引擎爬虫也可能抓不到完整内容。

### 开启 Angular SSR + Hydration 后

* 浏览器请求 `/p/123`，服务器直接返回已经包含商品标题、价格、首图、摘要的完整 `HTML`。
* 浏览器立刻解析 `HTML`，走你图里的 `DOM/CSSOM/Layout/Paint`，首屏更快出现。
* 客户端 Angular 启动后做 `Hydration`，把点击加入购物车、图片轮播、规格切换这些交互“接”上去。([Angular][2])
* 如果你配置了 `Http` 传输缓存，客户端首屏阶段不会重复请求同一个商品接口。([Angular][4])

你会看到一个非常清晰的分工：

* **服务器端 SSR**：负责“把应用跑到能输出首屏结构与数据的状态”，交付 `HTML`。
* **浏览器渲染管线**：负责“把 `HTML/CSS` 变成像素”，完成布局、绘制与上屏。
* **客户端 Hydration**：负责“把交互能力接回到已有 `DOM` 上”。

---

## 为什么很多 SSR 项目会踩 `window is not defined`：这正好证明服务器端没有浏览器那套东西

Angular 官方 SSR 指南明确提醒：在服务器上不能使用 `window`、`document`、`navigator`、`location` 等浏览器全局对象。([Angular][4])
这不是“写法限制”，而是环境事实：服务器端没有浏览器对象模型，更没有渲染引擎。

所以在 SSR 项目里，像下面这些逻辑就需要改写：

* 直接读 `window.innerWidth` 来做响应式判断
* 在构造函数里调用 `localStorage`
* 在 `ngOnInit` 里调用 `document.querySelector` 并依赖布局结果

处理方式通常是用平台判断把代码分流到浏览器端执行，或用 Angular 提供的注入令牌拿到更可控的抽象。很多最佳实践文章也反复强调这一点：浏览器特有对象在 Node.js 环境不存在。([Angular][4])

---

## SSR 服务器端可能比你想象的更“重”：`inlineCriticalCss` 与 `Critters` 的代价

你之前问过 `inlineCriticalCss` 这类能力，它与今天的问题关系很大：它经常让人误以为服务器端也在“做一部分浏览器渲染”。

更准确的说法是：`inlineCriticalCss` 发生在构建阶段或渲染阶段的一种优化，它尝试从页面结构中提取关键 `CSS` 并内联到 `HTML`，减少 render-blocking `CSS` 对首屏的影响。相关实践文章描述过这种构建期抽取与内联过程。([DEV Community][8])

但这不是浏览器的 `Layout/Paint`。它更像“静态分析 + 选择器匹配”。Angular Universal 社区里甚至有直接的性能讨论：`inlineCriticalCss` 依赖 `critters`，其复杂度会随着 `DOM` 节点数量与选择器数量上升而明显变慢。([GitHub][9])

这会带来一个很现实的工程权衡：

* 你想要更快的 `FCP/LCP`，就可能做关键 `CSS` 内联。
* 你想要更低的服务器响应时间与更高吞吐，就得警惕 SSR 每次请求都做过重的分析。

Angular 官方 SSR 文档也给了另一条路线：**Build-time prerendering**。它在构建期就生成静态 `HTML`，服务器运行时几乎不需要额外工作，适合内容型页面或变化不频繁页面。([Angular][4])

---

## 回到你的问题：服务器端会完整经历那张图的所有步骤吗

把答案压缩成一段更精确的表述：

* 服务器端 Angular SSR **会经历一套“应用渲染步骤”**：启动 `platform-server`、创建服务器端 `document`（默认 `Domino`）、运行组件与变更检测、把模板输出成节点结构并序列化为 `HTML`。([GitHub][3])
* 服务器端 **不会经历浏览器那套“图形渲染步骤”**：不会构建完整 `CSSOM`，不会进行真实 `Layout`，不会 `Paint`，不会分层合成，更不会 GPU 上屏。Angular 官方关于服务器端缺少浏览器对象与部分 `HTMLElement` 能力的说明，已经把这个边界划得很清楚。([Angular][4])
* 浏览器端仍然会把服务器返回的 `HTML/CSS` 走完你那张图的流程，并在此基础上完成 `Hydration`，把交互能力接回去。([Angular][2])

你可以把 SSR 理解为：**服务器替浏览器提前完成了“把组件树展开成可见的 `HTML`”这一段工作**，让浏览器更早拿到可渲染材料；而浏览器真正的布局、绘制、像素合成依旧只发生在浏览器里。

---

## 一个实用的检查清单：用它判断你写的逻辑属于哪条流水线

如果某段代码依赖这些东西，它天然属于浏览器渲染流水线，SSR 里要么不可用，要么必须延后到客户端：

* `window/document/navigator/location/localStorage` 等浏览器对象（SSR 里没有）。([Angular][4])
* `offsetWidth/getBoundingClientRect` 这类布局测量（服务器端没有布局引擎，Node.js DOM 实现普遍缺失）。([GitHub][5])
* 任何需要真实字体度量、媒体查询匹配、视口尺寸的行为。

如果某段代码只依赖可序列化数据与纯业务逻辑，它就更适合 SSR 服务器端运行：

* `HttpClient` 拉取商品数据、文章内容、导航菜单。
* 根据权限与路由条件决定渲染哪些组件。
* 通过 `TransferState` 或 Angular 的传输缓存把 SSR 阶段的数据复用到客户端，避免重复请求。([Angular][4])

---



[1]: https://v17.angular.io/guide/ssr?utm_source=chatgpt.com "Server-side rendering"
[2]: https://angular.dev/guide/hydration?utm_source=chatgpt.com "Hydration"
[3]: https://github.com/angular/angular/blob/main/packages/platform-server/src/tokens.ts?utm_source=chatgpt.com "angular/packages/platform-server/src/tokens.ts at main"
[4]: https://angular.dev/guide/ssr?utm_source=chatgpt.com "Server-side and hybrid-rendering"
[5]: https://github.com/jsdom/jsdom/issues/135?utm_source=chatgpt.com "Implement `HTMLElement` `offsetWidth`, `offsetHeight`, ` ..."
[6]: https://blog.angular.dev/whats-next-for-server-side-rendering-in-angular-2a6f27662b67?utm_source=chatgpt.com "What's next for Server Side Rendering in Angular"
[7]: https://angular.dev/api/platform-browser/provideClientHydration?utm_source=chatgpt.com "provideClientHydration"
[8]: https://dev.to/0xdbe/angular-security-disable-inline-critical-css-2n9g?utm_source=chatgpt.com "Angular Security - Disable Inline Critical CSS"
[9]: https://github.com/angular/universal/issues/2106?utm_source=chatgpt.com "inlineCriticalCss is slow · Issue #2106 · angular/universal"


你给的那张图描述的是浏览器端的关键渲染路径：HTML → DOM，CSS → CSSOM，合并成 RenderTree，再走 Layout 与 Paint，最后像素上屏。它非常适合解释 浏览器 为什么能把一堆文本与样式变成可见页面。

Angular SSR 到底在服务器端“复刻”了浏览器渲染流程吗：一条请求的双重流水线

紫薇堂堂主

前端

架构设计

客户端

Angular SSR服务器端渲染仅生成HTML字符串，不经历浏览器完整的CSSOM/Layout/Paint流程。服务器使用Domino等工具模拟DOM结构输出初始HTML，真正的样式计算和像素渲染仍由浏览器完成。官方文档明确说明SSR只负责应用状态和HTML生成，浏览器端负责最终渲染和Hydration交互接管。

数据结构

服务器

容器

路由

GitHub

4核4G3M云服务器 新用户低至38元/年！

2026采购季 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Angular SSR 到底在服务器端“复刻”了浏览器渲染流程吗：一条请求的双重流水线-腾讯云开发者社区-腾讯云

Angular SSR 到底在服务器端“复刻”了浏览器渲染流程吗：一条请求的双重流水线

Angular SSR 到底在服务器端“复刻”了浏览器渲染流程吗：一条请求的双重流水线

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐