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://flags/#prerender2 即使手动开启，也只在极苛刻条件下（前台、空闲、内存充足、未节电、同源、无查询参数、无 hash）才可能触发，而这些条件在真实业务中几乎无法满足。
speculationrules 是当前唯一可用的声明式预渲染机制
它不是 HTML5 标准，而是 Chromium（Chrome/Edge 94+）原生支持的机制，需通过 <script type="speculationrules"> 声明规则：
-
source: "document"：自动扫描页面内所有<a>链接，依赖用户悬停或聚焦行为 -
source: "list"：显式指定 URL 列表，必须同源、完整路径（如"/article/123"），不能是相对路径或带查询参数 -
eagerness必须显式写出："eager"（进视口即触发）、"moderate"（悬停后约 200ms）、"conservative"（mousedown 瞬间）；漏写则整条规则被忽略 - Firefox/Safari 完全不识别
type="speculationrules"，但可 fallback 到prefetch规则
prefetch 才是跨浏览器真正可靠的“下一页”预加载
所有现代浏览器都支持，且语义明确：“用户可能下一次需要这个资源，请空闲时低优先级下载”：
- 必须加
as="document"，否则默认按as="fetch"处理，可能绕过缓存策略 - 路径必须为根相对或绝对路径（如
/product/123），不能含查询参数（/product?id=123会失效） - 不要和
preload混用：preload只对当前页有效，跳转后即丢弃；prefetch才是为“下一页”准备的 - 验证是否生效：Network 面板筛选
prefetch请求，Initiator应显示prefetch，Priority应为Low，跳转后目标 HTML 状态码应为200 (from memory cache)或304
HTML 结构顺序直接影响预读效果
浏览器 parser 是单线程流式解析，resource hint 的位置决定它何时被识别：
立即学习“前端免费学习笔记（深入）”；
-
<link rel="preconnect">必须放在<meta charset>和<title>之后、首个<link rel="stylesheet">之前，否则可能错过 DNS 查询时机 -
<link rel="preload">若写在<body>里，浏览器直接忽略——它只在<head>解析阶段生效 - 多个
<script>若没加defer或async，即使位置靠后，也会阻塞 parser，导致后续prefetch指令延迟数秒才被读取 -
<link rel="prefetch">放在<head>末尾比放在<body>开头更早被识别
rel="prerender" 无关。它早已不是“优化选项”，而是文档兼容层里的一个空壳。现在能落地的，只有结构精准的 preconnect、语义正确的 prefetch、以及位置严苛的 preload。 
