link rel="preload" 用于高优先级预加载关键资源（如字体、CSS、首屏图片），需指定 as 属性以确保正确请求头和缓存策略，避免与 prefetch 混淆；preconnect 优于 dns-prefetch，可提前完成 DNS+TCP+TLS，但须谨慎使用以防连接数抢占；验证需通过 Chrome DevTools Network 面板检查 Initiator 和 Priority；注意 Safari/iOS 兼容性及动态参数导致的重复下载问题。
怎么用 link rel="preload" 提前加载关键资源
页面首屏渲染卡顿，往往不是 JavaScript 执行慢，而是字体、关键 CSS 或首屏图片还没下载完。link rel="preload" 是 HTML5 原生支持的预加载机制，它不阻塞渲染，但会以高优先级提前发起请求。
常见错误是把 preload 当成 prefetch 用——后者用于未来路由可能需要的资源，优先级低、时机晚；而 preload 必须指定 as 属性，否则浏览器无法正确设置请求头和缓存策略。
-
as="style"用于 CSS 文件（如<link rel="preload" href="main.css" as="style">），避免 FOUC -
as="font"加载字体时必须加crossorigin属性（<link rel="preload" href="bold.woff2" as="font" type="font/woff2" crossorigin>），否则会被浏览器忽略 - 不要对
script盲目preload：若脚本无async或defer，preload反而可能引发重复下载
link rel="preconnect" 和 dns-prefetch 该选哪个
当页面要从第三方域名（如 CDN、字体服务、分析 SDK）加载资源时，建立 TCP 连接和 TLS 握手耗时明显。preconnect 提前完成 DNS + TCP + TLS 全流程，dns-prefetch 只做 DNS 查询。
现代浏览器（Chrome 73+、Edge 79+、Firefox 81+）已全面支持 preconnect，且效果更直接。但注意两点：
立即学习“前端免费学习笔记（深入）”；
- 只对真正会在当前页面使用的第三方域名使用
preconnect，滥用会抢占主域连接数（浏览器通常限制 6 个并发 TCP 连接） - 不要在
preconnect后立即请求资源：建议至少间隔 100ms，否则可能因连接未就绪而重试 -
dns-prefetch仅适用于老浏览器兜底，例如：<link rel="dns-prefetch" href="https://fonts.googleapis.com">
如何验证预加载是否生效
光写标签没用，得看浏览器是否真发出了请求、是否被复用、有没有被降级。打开 Chrome DevTools → Network 面板，筛选 type=other 或直接搜索资源名，观察以下字段：
- 查看
Initiator列：应显示preload，而非parser或script - 检查
Priority列：preload资源应为Highest或High（取决于资源类型） - 对比相同资源在未加
preload时的Time：理想情况可减少 200–600ms 的等待时间（尤其在弱网或高延迟 DNS 场景） - 如果看到
Failed to load resource: net::ERR_CONNECTION_REFUSED，说明href路径错误或服务未响应，preload不会静默失败
容易被忽略的兼容性与副作用
preload 在 Safari 11.1+、Chrome 50+、Firefox 56+ 支持良好，但 iOS Safari 对 as="font" 的支持直到 iOS 14.5 才稳定；IE 完全不支持，需配合 if (!('preload' in document.createElement('link'))) 特性检测降级。
更隐蔽的问题是缓存干扰：如果预加载的资源带了动态参数（如 ?v=123），而后续真实引用时参数不同（如 ?v=124），浏览器会当成两个资源，导致重复下载。
另外，preload 不会触发 onload 事件，也无法通过 JavaScript 动态插入后生效（必须由 HTML parser 解析时声明）。
