prerender 已被主流浏览器完全弃用，chrome 120+ 彻底移除、firefox/safari 从未支持；当前应聚焦 preload、prefetch、preconnect 等有效 resource hint 的 html 结构优化与合理组合。
Prerender 在现代浏览器中已基本被弃用（Chrome 120+ 完全移除，Firefox 从未支持），当前没有主流浏览器实际执行 prerender 指令。所谓“优化 HTML 结构以适配 prerender”，本质是误判前提——你没法优化一个不存在的机制。
为什么 prerender 标签现在完全无效
浏览器早已移除对 <link rel="prerender"> 的支持：
- Chrome 自 2023 年起逐步降级为
prefetch行为，2024 年正式废弃，120 版本彻底删除解析逻辑 - Firefox 从未实现该特性，
rel="prerender"被忽略且不报错 - Safari 从未支持，也无计划加入
- 所有现代 Lighthouse、WebPageTest 工具不再检测或报告 prerender 状态
如果你在代码里还留着 <link rel="prerender" href="next-page.html">，它不会触发任何预渲染，也不会报错，只是安静地躺在 DOM 里占个位置。
prerender 和 prefetch 的关键区别必须分清
这两个标签常被混淆，但行为和兼容性天差地别：
-
prerender：曾尝试完整加载并渲染目标页面（含 JS 执行、布局、绘制），内存开销大，隐私风险高（如自动播放视频、触发 tracker），因此被果断淘汰 -
prefetch：仅下载资源（HTML、JS、CSS），不执行、不渲染，优先级低，空闲时进行，目前仍被 Chrome/Firefox/Safari 支持 -
preload：只针对当前页面必需资源，强制高优先级下载，as值错误即失效 —— 这才是你该花时间调准的部分
把 prerender 当成“高级 prefetch”来用，会错过真正有效的 resource hint 组合。
真正影响预读效果的 HTML 结构细节
虽然 prerender 不复存在，但浏览器对后续资源的“预读”（如 DNS prefetch、TCP preconnect、resource preload）高度依赖 HTML 结构位置与顺序：
-
<link rel="preconnect">必须放在<meta charset>和<title></title>之后、首个<link rel="stylesheet">之前，否则可能错过 DNS 查询时机 -
<link rel="preload">若写在里，浏览器直接忽略 —— 它只在解析阶段生效 - 多个
<script></script>标签若没加defer或async，即使位置靠后，也会阻塞 HTML parser，导致后续prefetch指令延迟数秒才被读取 -
<link rel="prefetch">放在末尾比放在开头更早被识别，因后者需等 parser 进入 body 阶段
结构不是越“规范”越好，而是越贴近浏览器 parser 流程越有效。比如 <meta charset> 必须是 第一个或第二个标签，错位会导致整个 重解析，连带让所有 resource hint 失效。
替代 prerender 的务实做法
想实现类似“用户点击前页面已就绪”的体验，应组合使用以下已被广泛支持的方案：
- 对导航链路明确的下一页（如分页按钮、下一步表单），用
<link rel="prefetch" href="next.html">+<link as="document">（注意：as 值必须是document，写成fetch或漏写会降级为低优先级 fetch） - 首屏关键资源用
<link rel="preload">精准声明，确保字体、LCP 图片、关键 CSS 提前发起请求 - 对 SPA 应用，在路由切换前主动调用
fetch()获取下一页 HTML，并缓存到sessionStorage或Cache API，比依赖浏览器预读更可控 - 用
IntersectionObserver监听靠近视口的链接区域，在用户大概率点击前 300ms 触发prefetch，避免全局预取浪费带宽
真正容易被忽略的点是：prefetch 的资源必须在后续真实导航中被复用（比如用 fetch() 读取同一 URL），否则浏览器会在几秒后丢弃，且控制台会打印警告 “was prefetched but not used”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
