Hi! 这里是JustHappy,我们前端说的渲染是什么？页面是如何渲染的？这次我们来一起画画图，聊聊吧
我们前端所说的渲染是什么？
在前端的技术视角中，“渲染”大多数情况下是指将“数据”变成“页面”这一过程，不考虑浏览器内核的渲染过程，我们可以理解我们平时所说的“渲染”指的就是「生成 HTML 的过程」。
我们有多少手段生成HTML呢？来盘点一下吧👇
服务端渲染 —— SSR（Server-Side Rendering）
概念：服务器生成完整 HTML 返回给浏览器。
原理：
SSR的本质就是服务器执行模板引擎、React或者Vue 的renderToString之类的函数，把 页面内容转成一大段 HTML 字符串，然后作为 HTTP 响应体 传给浏览器，浏览器就可以直接解析渲染这个HTML，但是此时的页面是不具有交互属性的，要使得其具有交互属性，我们还需要加载Javascript，并执行Hydration，才能挂载交互（JS 接管 DOM）
基本流程：
用户发起请求 → 服务器执行渲染逻辑，生成 HTML → 服务器返回 HTML → 浏览器解析并展示 → 浏览器下载 JS → 执行 Hydration，挂载交互。
-
特点：
- ✅ 首屏渲染速度快，用户可迅速看到完整页面，弱网体验好。
- ✅ 天生对 SEO 友好，搜索引擎爬虫可直接抓取内容。
- ❌ 每次请求都需服务端实时渲染，服务器压力大，访问量大时必须配合缓存策略。
- ❌ 首屏虽然可见快，但交互要等前端脚本加载并 Hydration 完成，可交互时间（TTI）可能偏长。
-
图解：
客户端渲染 —— CSR（Client-Side Rendering）
-
概念
客户端渲染，所有页面结构在浏览器端由 JavaScript 动态生成。 -
原理
CSR 的核心思想是服务端只返回一个几乎空的 HTML（通常只包含挂载节点<div id="app"></div>），页面所需的数据和逻辑都打包在前端的 JS Bundle 中，浏览器加载 JS 后执行渲染逻辑（如 ReactDOM.render 或 Vue 的mount），在客户端把数据转成 DOM，插入页面，绑定事件并管理状态。 -
渲染流程
用户发起请求 → 服务器返回空壳 HTML + JS Bundle → 浏览器加载 HTML → 浏览器下载并执行 JS → JS 拉取数据（可选） → 生成 DOM → 挂载交互。 -
特点
- ✅ 纯前端渲染，后端只需提供静态文件，部署简单、灵活，适合交互性强、对 SEO 没要求的后台或管理系统。
- ✅ 页面之间路由切换快，天然支持单页应用（SPA）体验。
- ❌ 首屏依赖前端 JS 下载和执行，弱网或低端机首屏白屏时间可能较长。
- ❌ 默认不利于 SEO（除非使用预渲染或 SSR）。
-
图解：
静态站点生成，也叫构建时预渲染 —— SSG（Static Site Generation）
-
概念
静态站点生成，所有页面在构建阶段预先生成好 HTML 文件，用户访问时直接读取静态文件。 -
原理
SSG 在构建时执行一次数据拉取和页面渲染，把所有可能的页面都写成静态 HTML 文件，通常配合 CDN 发布，用户访问时直接返回静态内容，浏览器加载后若需要交互，同样会执行前端脚本挂载事件（Hydration）。 -
渲染流程
项目构建阶段生成静态 HTML → 部署到 CDN 或静态服务器 → 用户访问直接获取 HTML → 浏览器解析渲染 → 加载前端 JS → Hydration 挂载交互。 -
特点
- ✅ 首屏极快（CDN 可直接返回静态文件），对 SEO 友好。
- ✅ 不依赖实时后端，可脱离动态服务器，运维成本低。
- ❌ 仅适用于内容更新不频繁或可预知页面（如文档站、博客）。
- ❌ 对需要实时数据的场景不友好，更新内容需要重新构建和发布。
-
图解：
以上三种渲染模式是目前最主流、最基础的三种，下面的渲染模式基本上都是混合了以上三种的不同特性和实现，具体的落地有不同的方案，受限于小弟能力，暂时就不画图了😭😭
增量静态生成 —— ISR（Incremental Static Regeneration）
-
概念
增量静态生成，是 SSG 的增强版，结合了静态和动态的优势。 -
原理
先在构建时生成一批静态页面，用户首次访问命中旧版本，后台在预设时间内自动触发增量重新渲染（revalidate），并替换缓存，下一次访问获取最新内容。这让页面既能快速返回静态文件，又能动态保持最新。 -
渲染流程
构建阶段生成初始静态 HTML → 部署到 CDN → 用户访问命中缓存 → CDN 后台触发增量更新（按设定时间 revalidate） → 更新静态文件 → 下一次访问命中新版本 → 浏览器解析并 Hydration。 -
特点
- ✅ 首屏加载快，支持静态文件的高效缓存和分发。
- ✅ 允许在不重新构建全站的情况下，增量更新页面，兼顾了可维护性和性能。
- ❌ 需要配套支持的框架和服务（如 Next.js），对部署环境要求更高。
- ❌ 后端增量更新时有可能出现首个访问用户命中过期数据。
部分预渲染 —— PPR（Partial Prerendering）
-
概念
部分预渲染，把页面拆分为可预渲染部分和需实时生成部分，组合输出。 -
原理
PPR 将不变或稳定的部分在构建时预渲染（生成静态 HTML），动态部分在请求时按需填充或合成，可结合流式渲染（Streaming SSR）输出，实现页面首屏尽快可见，剩余部分异步加载。 -
渲染流程
构建阶段生成可预渲染区域 → 用户访问时服务端拼接动态部分 → 边流式输出静态块 → 动态块按需加载 → 浏览器解析可用部分 → 前端脚本执行并挂载剩余交互。 -
特点
- ✅ 兼顾 SSG 的首屏快和 SSR 的实时性，适合大体量、复杂页面。
- ✅ 可将页面按块缓存、按需更新，减少重复渲染压力。
- ❌ 实现逻辑相对复杂，需要拆分页面结构，设计可组合的输出。
- ❌ 对框架支持和部署能力有依赖（如 React 18 Streaming、Next.js App Router）。
边缘侧渲染 —— ESR（Edge Side Rendering）
-
概念
Edge Side Rendering，指在离用户物理距离更近的边缘节点（Edge Server）实时执行服务端渲染。 -
原理
相比传统 SSR 在中心化服务器执行渲染，ESR 会把渲染逻辑部署到全球分布的边缘节点（如 CDN 边缘、边缘函数 Edge Functions），当用户请求页面时，就近节点动态生成 HTML 并返回，减少跨区域请求延迟，加速首屏加载，同时降低中心服务器负载。 -
渲染流程
用户发起请求 → 最近的边缘节点（CDN POP）执行 SSR → 动态生成 HTML → 直接返回给浏览器 → 浏览器解析页面 → 加载 JS → Hydration 接管交互。 -
特点
- ✅ 动态渲染能力下沉到离用户最近的边缘，提高全球访问速度。
- ✅ 可结合缓存策略，将可缓存部分与动态生成部分拆分组合。
- ✅ 适合有区域内容差异（如多语言、多区域个性化）的页面交付。
- ❌ 需要支持边缘函数（如 Vercel Edge、Cloudflare Workers），对部署环境要求高。
- ❌ 部分运行时或依赖库可能不兼容边缘执行（如某些 Node API）。
本地侧渲染 —— NSR（Native Side Rendering）
-
概念
Native Side Rendering，主要用于混合应用（如 App、小程序）中，指由端内的原生容器或客户端线程执行页面渲染，生成视图。 -
原理
NSR 典型场景是移动端 App 内嵌前端页面时，部分页面渲染工作直接放在原生层（Native）执行，比如 Flutter、React Native、或小程序的渲染层。页面数据可由前端发起，也可由端内通过原生 API 提供，最终渲染在端内生成视图树，而非单纯依赖浏览器内核。 -
渲染流程
用户操作触发页面请求 → 原生容器获取数据 → Native 渲染引擎生成页面结构 → 在端内显示 → 前端逻辑（JS Bridge）与原生层通信，实现交互。 -
特点
- ✅ 渲染直接由原生层执行，性能可控，加载体验好，弱网也可离线渲染。
- ✅ 便于做端内优化（预加载、离线包），可充分利用端侧能力。
- ✅ 适合高性能、高交互需求的 App 页面、小程序。
- ❌ 实现需要跨端技术栈（前端 + Native），对团队要求高。
- ❌ 可移植性低，依赖具体端侧环境，难以完全复用到纯 Web 场景。
🚀 一句话总结：
前端渲染的本质是：把数据变成 HTML。
不同的渲染模式，就是选择在 何时、何地、如何 把这份 HTML 准备好，传给浏览器，并赋予交互能力。
