rel="prerender"在真实项目中基本不可用，因其仅Chromium支持、条件苛刻（同源无参无hash）、易被丢弃且不记录网络请求；rel="prefetch"才是跨页面预加载的可靠选择，全浏览器支持且语义明确。
link rel="prerender" 在真实项目中基本不可用，别浪费时间配置它。
为什么 rel="prerender" 几乎总失效
它不是“生成静态 HTML”的预渲染，而是让 Chrome 在后台悄悄打开一个隐藏 tab 渲染目标页——但条件苛刻到几乎无法满足：
- 仅 Chrome/Edge（Chromium 内核）支持，Firefox 和 Safari 完全忽略
- 必须同源、无查询参数、无 hash（
https://a.com/page✅，https://a.com/page?id=1❌） - 用户切走标签页、内存紧张、系统节电，Chrome 会立刻丢弃预渲染页
- DevTools 的 Network 面板里根本看不到请求——它跳过标准网络管线，也不记录日志
- 即使你手动开启
chrome://flags/#prerender2，真实业务场景下也极少触发
rel="prefetch" 才是跨页面预加载的可靠选择
它被所有现代浏览器支持（Chrome、Firefox、Safari 16.4+、Edge），语义清晰：「用户可能下一次需要这个 HTML，空闲时低优先级下载」。
- 必须指定
as="document"，否则默认按as="fetch"处理，可能绕过缓存策略 - 路径只能是根相对或绝对路径（如
/product/123），不能带查询参数 - 不要和
preload混用：preload只对当前页有效，跳转后即丢弃 - 验证方式：Network 面板筛选
prefetch请求，Initiator 列应显示prefetch，Priority 为Low，跳转后目标页状态码应为200 (from memory cache)或304
真正解决 SEO 和首屏性能，得靠构建时预渲染
rel="prerender" 和服务端渲染（SSR）、静态站点生成（如 Next.js 的 generateStaticParams）完全不是一回事——它不产出真实 HTML 文件，对爬虫抓取零贡献。
立即学习“前端免费学习笔记（深入）”；
- SEO 场景下的「预渲染」必须在构建阶段完成，比如用
vite-plugin-prerender或prerender-spa-plugin - 动态路由需提前声明所有可能路径（如商品 ID 列表），否则无法生成对应 HTML
- 若页面重度依赖客户端 JS 数据，构建时预渲染可能拿到空内容，需配合 hydration 或 fallback 策略
真正要落地预渲染，先想清楚：你要解决的是「用户点击后跳转慢」，还是「搜索引擎抓不到内容」？前者看 prefetch，后者必须绕过 link 标签，进构建流程。
