rel="preconnect"能加速资源加载，但仅在严格满足四条件时生效：HTTPS跨域域名、href为协议+域名、置于<head>顶部、带正确crossorigin属性，可减少50–300ms连接耗时。
什么是 rel="preconnect"，它真能加速资源加载？
能，但只在特定条件下生效。rel="preconnect" 告诉浏览器提前与目标域名建立 TCP 连接（含 TLS 握手），跳过后续请求时的连接开销。但它不下载任何资源，也不触发 DNS 查询以外的其他动作——除非你显式声明了 href 且域名可解析。
常见误判是以为加了就一定快：如果目标域名响应慢、证书链异常、或浏览器已存在空闲连接，preconnect 可能被忽略甚至造成轻微竞争开销。
preconnect 的正确写法和必须满足的条件
必须同时满足以下四点，浏览器才会真正发起预连接：
-
rel属性值严格为"preconnect"（大小写敏感） -
href必须是完整协议+域名，例如https://fonts.googleapis.com；不能是相对路径、带路径的 URL（如https://cdn.example.com/js/）或仅域名（example.com） - 该域名后续确实有资源要加载（如
<link rel="stylesheet" href="https://cdn.example.com/main.css">），否则 Chrome 等浏览器可能在几秒后中止连接 - 页面中
preconnect标签需尽早出现（建议放在<head>顶部），越晚写入，越可能错过关键渲染时机
示例正确用法：
立即学习“前端免费学习笔记（深入）”；
<link rel="preconnect" href="https://cdn.jsdelivr.net"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
什么时候必须加 crossorigin？不加会怎样？
当目标域名返回的资源带有 CORS 头（比如字体、部分 CDN 上的 JS/CSS），而你的页面又需要读取其内容（如通过 fetch() 或 Web Font API），就必须加 crossorigin 属性。否则浏览器会静默降级为匿名模式，导致预连接失败或后续请求触发额外预检。
典型场景包括：
- 加载 Google Fonts 的字体文件（
fonts.gstatic.com） - 从非同源 CDN 加载带
Access-Control-Allow-Origin: *的脚本或样式 - 使用
rel="preload"配合as="font"时，对应preconnect也需带crossorigin
错误示范：<link rel="preconnect" href="https://fonts.gstatic.com"> → 实际无效；正确应为：<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
实际性能影响有多大？怎么验证是否生效？
真实提升通常在 50–300ms（取决于网络延迟和 TLS 复杂度），对首屏 CSS/JS 加载时间影响明显，尤其在 3G 或高 RTT 网络下。但它无法替代 dns-prefetch（更轻量，只做 DNS 查询）或 prefetch（用于后续导航资源）。
验证方式（Chrome DevTools）：
- 打开 Network 面板 → Filter 输入
domainlookup或看 Initiator 列是否有preconnect - 在 Timing 标签页中，检查某资源的
Connect Start是否显著早于Request Start - 命令行运行
chrome://net-internals/#events，筛选HOST_RESOLVER_IMPL_REQUEST和SSL_SOCKET_CONNECT事件，确认对应域名是否提前触发
容易被忽略的一点：多个 preconnect 会竞争有限的浏览器并发连接数（通常 6 个），盲目添加反而拖慢主资源；优先级顺序应是「当前页必用域名 > 字体服务 > 分析 SDK 域名」，最多保留 2–3 个。
