现代前端渲染模式
约 1365 字大约 5 分钟
2026-01-21
1.SPA
SPA(Single Page Application)单页应用,通常指代 "客户端渲染" 的 Vue/React 应用。它的特点是:只有一个 HTML 页面入口,页面切换通过前端路由实现,内容由 JS 渲染生成
SPA 应用的具体流程
- 浏览器请求 SPA 应用
- 服务器返回空壳 HTML 与 JS/CSS 资源
- 浏览器开始下载资源并执行脚本,脚本发起数据请求并生成 DOM
由于需要等待脚本与数据到位,因此首屏常见的现象是白屏或 Loading,而当脚本加载完成后,页面进入高交互、低刷新成本的状态,路由切换只是局部 DOM 更新,不再需要重新加载完整页面
相关信息
首屏内容必须等待脚本下载与执行,任何网络波动、包体积膨胀或数据接口延迟都会直接拉长首屏时间。也就是说客户端渲染把 "是否可见" 的决定权交给了 JS
从体验角度看,SPA 能提供接近原生应用的切换流畅度与交互一致性;从工程角度看,组件化、前端路由与统一状态管理会显著提升复杂交互的可维护性。与此同时,SPA 也会把大量逻辑推到客户端,使首屏依赖的 JS 体积变大,SEO 也会因为 "空壳 HTML" 而变得困难,这些代价在大型项目中尤其明显
2.SSG
SSG(Static Site Generation)静态站点生成,SSG 的逻辑是把渲染前移到构建阶段,构建时会为每个路由生成完整 HTML 文件,部署后用户请求直接命中静态文件,速度接近纯静态站点。由于首屏 HTML 已经完整生成,SEO 通常非常友好,且服务器开销较小。
相关信息
SSG 的限制在于 "内容变更成本" 一旦页面数据发生变化,就需要重新构建并部署才能生效,因此它更适合内容更新频率较低的站点,例如文档、博客或营销页
3. SSR
SSR(Server Side Rendering)服务端渲染,其核心在于由服务端先生成完整的 HTML,再将结果返回给浏览器进行展示,无需等待 JS 执行
这种方式兼顾了 SEO 与首屏性能,是 SPA 在这两个维度上的重要优化手段,但每次请求都要在服务器端渲染,因此对服务器资源与工程复杂度提出更高要求
注
SSR 用更高的服务器成本换取更快的首屏与更好的 SEO 并通过 Hydration 保留 SPA 的交互体验。代价是必须同时兼顾服务端与客户端环境,处理数据预取、状态注水与渲染一致性等问题
这里以 Vue + Node 中间层的实现为例,说明 SSR 的核心流程与关键节点
双入口与双产物
SSR 会在构件时产生两份产物,分别为运行在 Node 环境中的
server bundle与运行在浏览器环境中的client bundle。两份 bundle 共享同一套组件与路由简要的请求过程
请求链路, 以请求
/home为例- Node 接收请求后,为该请求创建一个全新的 SSR 应用实例
- 服务端创建路由并将其推进到当前 URL,然后等待
router.isReady(),以保证路由解析完成并与目标页面匹配 - 服务端执行数据预取逻辑,确保渲染前数据齐全
- 服务端调用
renderToString()将应用渲染为 HTML 字符串,得到appHtml - 服务端将
appHtml注入到 HTML 模板的占位符中 - 浏览器收到 HTML 后立即渲染页面内容,此时页面可见但还不可交互
- 浏览器下载
client_bundle.js并执行客户端入口脚本,创建客户端应用实例并恢复初始状态 - 客户端执行 Hydration,将已有 DOM 与虚拟 DOM 对齐并绑定事件,页面转为可交互的 SPA
- 后续的路由切换与状态更新都发生在客户端,表现为常规 SPA 的体验
模板注入
服务端渲染的核心产物是 HTML 字符串,它通常会被注入到模板中,形成最终响应
模板.html<body> <div id="app"><!--app--></div> <script src="/client_bundle.js"></script> </body>当
<!--app-->被appHtml替换后,浏览器得到的是可直接渲染的完整内容,这就是 SSR 首屏快的根本原因数据预取与状态注水
为避免 "服务端已渲染、客户端还要再请求一遍" 的重复开销,SSR 会在服务端中先完成数据预先获取,再把数据写入本次请求的 store 实例,然后在将状态序列化为
window.__INITIAL_STATE__注入页面,该过程被称为 脱水 dehydrate后续客户端启动时将会读取这份初始状态并将其恢复到客户端 store,以保证两端首屏内容一致并减少额外请求,该过程被称为 注水 rehydrate