预渲染
面试速答（30 秒版 TL;DR）
- 预渲染（Prerender） 的核心思想是：在用户真正看到页面之前，提前把目标页准备成更接近“可直接展示”的状态。
- 这个词在工程里容易混淆，常见至少有两种语境：
- 构建时预渲染：提前产出某些路由的 HTML，常用于文档站、营销页、内容页
- 导航前预渲染：用户还没跳过去，就先把下一页准备好
- 它的本质收益是：减少用户真正导航时的等待，把工作前移。
- 面试里最好先澄清：你说的是 SSG/静态导出式预渲染，还是浏览器导航前预渲染？
一、先把概念讲清：为什么这一题容易答乱？
因为很多人会把下面这些东西全部混成“预渲染”：
- SSR（服务端渲染）
- SSG（静态生成）
- SPA 的爬虫预渲染
- 浏览器对下一页的提前准备
它们并不完全相同，但共同点是：
让用户或爬虫在真正消费页面时，尽量少等一点。
所以更稳的答法不是直接背定义，而是先按“准备发生在什么时候”分类。
二、按时机拆分：预渲染主要有哪两类？
1. 构建时预渲染
也可以理解成：
- 提前把某些确定路由输出为静态 HTML
- 用户请求到来时，服务器直接返回已经准备好的结果
这类方案特别适合：
- 文档站
- 博客文章页
- 营销页
- 商品详情页中相对稳定的公开内容
优点是首屏稳定、TTFB 可控、SEO 友好；缺点是动态性差，内容变化快时更新链路更复杂。
2. 导航前预渲染
它不是在构建阶段做，而是在用户还没点进去时，就尝试把下一跳页面提前准备好。
典型触发信号：
- 用户 hover 某个链接
- 链接出现在视口且点击概率高
- 框架根据路由规则做提前准备
这类方案更偏“交互提速”，目标是缩短页面切换等待。
三、和 CSR / SSR / SSG 的关系怎么说？
可以用下面这张表快速拉开差异：
| 方案 | 页面内容何时准备 | 首屏速度 | SEO 友好度 | 适合场景 |
|---|---|---|---|---|
| CSR | 用户请求后，浏览器拿壳再执行 JS | 一般 | 一般到较弱 | 后台系统、强交互页面 |
| SSR | 每次请求时服务端实时渲染 | 较好 | 较好 | 动态内容多、首屏要求高 |
| SSG | 构建时生成静态页面 | 很好 | 很好 | 文档、博客、营销站 |
| 预渲染 | 把未来页面提前准备 | 取决于实现 | 通常较好 | 高概率访问的稳定页面 |
面试里更像工程师的说法是：
- SSG 可以看作构建期预渲染的一种典型形式
- 导航前预渲染则更像用户行为驱动的提前准备
四、它为什么能加速？
因为它把原本发生在“用户已经在等”的那部分工作，尽量提前做掉。
先记核心判断：有没有提前准备过，决定用户等待是不是落在关键路径里。
它提前做掉的工作，可能包括：
- HTML 生成
- 数据请求
- JS/CSS 下载
- 路由组件解析
- 页面初始渲染
具体做多少，取决于你的技术栈和实现方式。
五、最适合哪些页面？
很适合
- 内容稳定的公开页面
- 承接搜索流量的页面
- 首页、落地页、活动页
- 文档详情页、博客文章页
- 用户下一跳路径高度可预测的场景
不太适合
- 强个性化页面
- 实时数据变化非常频繁的页面
- 权限校验复杂的页面
- 页面很多但长尾访问概率极低的场景
原因也很直接：
- 页面越稳定，提前准备的复用价值越高
- 页面越个性化，提前准备越容易浪费，甚至出现内容不一致
六、一个常见工程思路：关键路由静态化
如果你维护的是内容型站点，常见做法是：
- 先识别哪些页面内容相对稳定
- 在构建阶段把这些页面产出为静态 HTML
- 用户访问时直接返回结果
- 动态区域再按需 hydration 或补充请求
这一套思路的收益通常体现在：
- 首屏更快
- 白屏时间更短
- 爬虫更容易拿到完整内容
- 服务端运行时压力更可控
这也是为什么文档站、博客站、营销站特别适合这类方案。
七、导航前预渲染的风险是什么？
它不是没有成本。
如果你提前准备了一个用户最终没访问的页面，这部分工作就浪费了。风险主要包括：
- 白白消耗流量
- 白白消耗 CPU
- 占用内存
- 可能挤占当前页真正关键资源
所以导航前预渲染的关键不是“能不能做”，而是：
你能不能较准确地判断下一跳概率。
一些更稳妥的实践是：
- 只对少数高概率链接做
- 在空闲时做，而不是和当前首屏抢资源
- 对低端机、弱网环境更保守
- 对登录态、强个性化页面慎用
八、面试里怎么回答更稳？
一个比较完整的表达可以是：
- 先定义预渲染是“把未来页面准备工作前移”
- 再区分构建期预渲染和导航前预渲染
- 再说适合稳定公开页，不适合强个性化实时页
- 最后补一句：收益来自减少用户真正等待时的工作量，但代价是可能产生无效准备
这样回答会比只背“预渲染可以提升 SEO 和首屏速度”更完整。
九、典型题与标准答法
Q1：什么是预渲染？
答法：
预渲染本质上是把页面的准备工作前移，让用户真正访问目标页时，页面更接近可直接展示的状态。工程里常见有构建时预渲染和导航前预渲染两类。
Q2：它和 SSR / SSG 有什么关系？
答法：
SSG 可以看作构建期预渲染的一种典型实现，提前把页面生成好；SSR 则是在每次请求到来时实时渲染。预渲染更强调“提前准备”，而 SSR 更强调“请求时生成”。
Q3：预渲染适合什么场景？
答法：
适合文档、博客、活动页、营销页、商品详情这类稳定公开页面，也适合下一跳路径比较可预测的场景。不太适合强个性化、实时变化快、权限复杂的页面。
Q4：为什么不能对所有页面都做？
答法：
因为提前准备也有成本。如果页面最终没人访问，CPU、网络、内存都白白浪费；如果页面个性化很强，还可能出现数据过期或内容不一致的问题。
十、常见误区
-
误区 1：把预渲染和 SSR 完全等同。 它们有交集，但不是一回事。
-
误区 2：只会说“为了 SEO”。 预渲染也服务首屏交付和切页体验，不只是给爬虫看。
-
误区 3：对动态页面无脑预渲染。 个性化越强，浪费和错配风险越高。
-
误区 4：忽略前移工作本身的成本。 预渲染不是免费午餐。
十一、速记要点
- 预渲染 = 把未来页面准备工作前移。
- 常见两类：构建时预渲染、导航前预渲染。
- 适合稳定公开页，不适合强个性化实时页。
- 收益是更快展示，代价是可能出现无效准备。
- 回答时要先澄清语境，再谈方案。