link标签本身不阻塞HTML解析，但rel="stylesheet"会阻塞渲染和后续脚本执行；其他rel值如preload、icon、preconnect均不阻塞解析或渲染。
link 标签本身不阻塞 HTML 解析，但 rel="stylesheet" 会阻塞渲染（paint）和后续脚本执行——这是关键分水岭。其他 rel 值如 preload、icon、preconnect 均不阻塞解析或渲染。
为什么 rel="stylesheet" 会卡住页面？
浏览器在解析 HTML 遇到 <link rel="stylesheet" href="main.css"> 时，必须暂停构建渲染树，直到 CSSOM 构建完成。这不是“加载慢”导致的卡顿，而是规范强制行为：CSS 是渲染必需资源，未就绪前不能显示任何内容（防止 FOUC）。
- 即使 CSS 文件体积很小，只要没返回 200 + 完整响应体，后续 DOM 渲染和
<script>执行都会挂起 - 多个
rel="stylesheet"按顺序串行阻塞：第二个要等第一个 CSSOM 构建完才开始请求 - 写在
<body>里也没用——浏览器仍会回溯查找并同步处理，且可能触发重排
如何让关键 CSS 不阻塞首屏？
核心思路是把首屏必需样式内联（<style>），非关键 CSS 异步加载。但若必须用 link，可用以下方式绕过阻塞：
- 对非关键 CSS，加
media="print"（或任意不匹配当前设备的媒体查询），再用 JS onload 后切换为media="all"，例如：<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'"> - 用
rel="preload"+as="style"提前下载，再手动激活：<link rel="preload" href="critical.css" as="style" onload="this.rel='stylesheet'">（注意：不能同时存在另一个同 href 的rel="stylesheet"，否则 Safari 会重复请求） - 避免在
<head>底部堆砌多个 CSSlink，优先级会逐级下降，首屏资源可能被挤出关键路径
哪些 link 会悄悄拖慢首屏？
不是所有 link 都“安全”。这些值容易因配置错误变成性能负优化：
立即学习“前端免费学习笔记（深入）”；
-
rel="prefetch"指向大图或视频：浏览器空闲时下载，但会抢占带宽，影响首屏资源 TCP 连接数和吞吐量 -
rel="preconnect"写错格式，例如href="https://cdn.example.com/fonts/"（带路径）→ 浏览器忽略，连接未建立；正确写法是href="https://cdn.example.com"，且需每个域名单独一条 -
rel="preload"缺as属性：Chrome/Firefox 直接降级为普通link，失去高优先级，还可能引发二次请求 -
rel="icon"缺sizes和type：浏览器 fallback 到根目录/favicon.ico，多一次 404 请求，尤其在部署路径非根目录时
真正影响首屏的是资源加载时机与依赖关系，而不是 link 标签本身。最容易被忽略的一点：所有预加载类 rel（preload、preconnect、dns-prefetch）必须静态写在 HTML 的 <head> 最顶部——JS 动态插入的 link 在解析阶段已失效，等于没写。
