Prerender2 并不是 HTML5 标准中定义的原生技术，也不是开发者可直接调用的 HTML5 API。它是 Chromium 浏览器（Chrome、Edge 等）从 M94 版本起在底层引擎中启用的一项**浏览器内部优化机制**，专为提升页面加载体验而设计，不开放给网页代码直接控制或配置。
Prerender2 是什么，它能做什么？
Prerender2.0 是 Chromium 实现的预渲染升级版，核心目标是：在用户尚未点击链接前，悄悄将高概率访问的目标页面（如搜索结果页、导航栏下一页）在后台完成完整加载（HTML 解析、JS 执行、DOM 构建、资源下载、甚至首屏渲染），待用户真正跳转时，瞬间切换到已就绪页面，实现“秒开”效果。
它依赖两个关键技术基础：
- MPArch（多页面架构）：一个 WebContents 进程内可管理多个页面（可见/不可见），大幅降低内存与 CPU 开销；
- 精准触发策略：仅对用户行为强暗示即将访问的链接（如鼠标悬停时间长、焦点停留、历史点击模式匹配）才启动，避免盲目预渲染浪费资源。
注意：该机制完全由浏览器自动决策，网页无需写任何 HTML 或 JS 来“开启 Prerender2”，也无法通过 <link rel="prerender"> 等标签手动触发——这类旧式标签在现代 Chromium 中已被废弃且无效。
立即学习“前端免费学习笔记（深入）”；
网页开发者能做的实际优化方向
虽然不能直接调用 Prerender2，但你可以通过配合浏览器策略，显著提升被成功预渲染的概率，并确保预渲染后体验连贯：
-
使用标准语义化链接：确保跳转链接是原生
<a href="/product/123">，而非@click="router.push(...)"或window.location调用；浏览器只对真实<a>标签做预测分析； -
保持页面轻量 & 快速可交互：预渲染页面若 JS 执行卡顿、资源超大或存在阻塞逻辑（如同步 fetch、长任务），会导致预渲染失败或被中止；建议关键 JS 使用
defer，非首屏资源懒加载； - 避免运行时强依赖客户端状态：例如预渲染时 localStorage 为空、未登录态下渲染了需鉴权的内容，会导致 CSR 接管后闪白或报错；应让服务端或骨架层兼容无状态初始渲染；
- 检查是否被禁用：部分企业环境、隐私模式、或低功耗设备会默认关闭 Prerender；可通过 Chrome DevTools 的 Application → Rendering → “Prerendering” 面板确认当前页面是否被预渲染及原因。
替代方案：主动可控的预渲染（适合 SEO 和确定性秒开）
若需稳定保障首屏秒开（尤其对 SEO 敏感或流量入口页），推荐采用服务端或构建时预渲染，而非依赖浏览器不可控的 Prerender2：
-
构建时预渲染（SPA 场景）：Vue CLI 项目可用
prerender-spa-plugin，Nuxt/Next 则内置generate或SSG模式，输出静态 HTML 文件，部署即秒开； - 服务端预渲染（SSR）：用 Nuxt、Vue Server Renderer、Remix 等框架，在请求到达时动态生成带数据的 HTML，兼顾实时性与首屏性能；
- 边缘预渲染（ESG）：Vercel、Cloudflare Pages 支持按需在边缘节点生成并缓存 HTML，兼顾 CDN 速度与动态能力。
这些方案产出的是真实 HTML，无论用户用什么浏览器、是否支持 Prerender2，都能获得一致的首屏体验。
关于“秒开跳转”的常见误解
有人误将 <meta http-equiv="Refresh"> 或 setTimeout(location.href) 当作“秒开”，其实这是强制延时跳转，与 Prerender2 的零感知切换有本质区别。前者仍需重新发起请求、解析、渲染；后者是切换已有渲染树，毫秒级完成。
真正的秒开跳转，只发生在浏览器已完成预渲染且用户点击了对应链接的场景下——你无法用前端代码“制造”它，但可以通过规范编码和合理架构，让它更大概率发生。
