rel="prerender"在2026年已完全不可用：Chrome v110+默认禁用，Edge同步弃用，Firefox/Safari从未支持；它不下载HTML、不执行JS、不触发网络请求，仅可能做DNS/TCP预连接，实际业务中几乎无法满足苛刻触发条件。
rel="prerender" 在 2026 年已完全不可用，写它等于没写——Chrome v110+ 默认禁用，Edge 同步弃用，Firefox 和 Safari 从未识别。它不下载 HTML，不执行 JS，不触发任何网络请求，也不会提升导航速度。
rel="prerender" 为什么在 Network 面板里看不到请求
- 浏览器解析到该标签后直接跳过，不进入预渲染管线，也不记录日志或报错
- Chrome DevTools 的 Application → Rendering 面板中查不到任何
prerendered page实例 - 即使你手动开启
chrome://flags/#prerender2，也只在极苛刻条件下（前台、空闲、内存充足、未节电、同源、无查询参数、无 hash）才可能触发，而这些条件在真实业务中几乎无法满足 - 它和构建时预渲染（如 Next.js 的
generateStaticParams）或服务端渲染（SSR）是两回事：前者是运行时投机行为，后者产出真实 HTML 文件
rel="prefetch" 是跨页面预加载的唯一可靠选择
- 它被所有现代浏览器支持（Chrome、Firefox、Safari 16.4+、Edge），且语义明确：“用户可能下一次需要这个资源，请空闲时低优先级下载”
- 必须指定
as="document"才能正确预取 HTML（否则默认当as="fetch"处理，可能绕过缓存策略） - 路径必须为根相对或绝对路径（如
/product/123），不能带查询参数（/product?id=123会失效） - 不要和
preload混用：后者只对当前页有效，跳转后即丢弃；前者才是为“下一页”准备的 - 验证是否生效：Network 面板筛选
prefetch请求，Initiator 列应显示prefetch，Priority 应为Low，跳转后目标 HTML 状态码应为200 (from memory cache)或304
preload 和 preconnect 才是当前页真正能落地的优化
-
preload必须放在<head>最前面（紧贴<meta charset>后），且必须配as属性（如as="font"）和必要属性（字体必加crossorigin） -
preconnect适合提前建连 CDN 或 API 域名，但不要超过 4–6 个，且需加crossorigin（Safari 和旧版 Chrome 否则忽略） - 三者组合才有效：
preconnect→prefetch→ 关键资源preload，而不是幻想靠一个prerender标签解决所有问题
真正影响首屏性能的是 HTML 是否真实存在、CSS 是否阻塞、字体是否及时可用——这些都和 prerender 无关。它早已不是“优化选项”，而是文档兼容层里的一个空壳。
