多个<link>标签不会异步加载CSS，而是同步阻塞HTML解析；真正异步方案是rel="preload" as="style"配合JS动态插入stylesheet链接。
多个 <link> 标签本身不会异步加载 CSS
浏览器对 <link rel="stylesheet"> 是同步阻塞解析的，哪怕写十个，也全按顺序下载、编译、应用，页面渲染会等最后一个完成。所谓“异步加载 CSS”，本质是绕过默认阻塞行为，不是靠堆 <link> 标签实现的。
常见错误现象：Network 面板看到多个 CSS 请求并行发出，就以为“异步了”；但 Waterfall 里仍能看到 HTML 解析被卡住，首屏时间没改善。
- 真正起作用的是
rel="preload"+onload注入，或rel="prefetch"（仅预取，不立即应用） -
rel="stylesheet" media="print"可临时解除阻塞，后续用 JS 切换media="all"，但有 FOUC 风险 - 现代方案优先用
rel="preload"配合as="style"和动态<link>插入
rel="preload" + 动态插入才是可靠异步方案
这是目前兼容性好、控制力强的做法：用 <link rel="preload" as="style"> 提前拉取资源（不阻塞），再通过 JS 创建真实 <link rel="stylesheet"> 并插入 DOM。
使用场景：非首屏 CSS（如后台管理页的图表组件样式）、主题切换 CSS、A/B 测试用样式。
立即学习“前端免费学习笔记（深入）”；
-
preload不触发样式应用，必须手动插入新<link>，否则白忙一场 - 插入时机建议在
DOMContentLoaded后，避免干扰主文档解析 - 注意 IE 不支持
preload，需降级为rel="stylesheet" media="x"+ JS 切换
<link rel="preload" as="style" href="chart.css" onload="this.onload=null;this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="chart.css"></noscript>
多个 <link> 标签反而可能拖慢加载
每个 <link> 都是一次独立请求，受 HTTP/1.1 队头阻塞或浏览器并发连接数限制（尤其旧版 Chrome 对同一域名限 6 个）。合并 CSS 文件通常比拆成多个 <link> 更快。
性能影响：HTTP/2 下多路复用缓解了并发问题，但 TCP 连接建立、TLS 握手、缓存失效等开销仍在；且每个 <link> 都要走完整 CSS 解析流程，内存占用和样式计算成本叠加。
- 移动端弱网下，10 个
<link>比 1 个 100KB 的 CSS 多出数倍 RTT 延迟 - CDN 缓存粒度以 URL 为单位，拆分导致缓存命中率下降
- 如果用
media属性做条件加载（如media="(max-width: 768px)"），浏览器仍会下载所有，只是延迟应用
CSS 加载优化真正该关注的三个点
比起纠结 <link> 数量，“怎么让关键 CSS 快速生效、非关键 CSS 延后加载、整体体积最小”才是核心。
- 提取首屏关键 CSS（
critical CSS），内联到<head>中，消除首次请求阻塞 - 剩余 CSS 用
preload+ 动态插入，或rel="stylesheet" media="print"+ JS 切换（注意 FOUC） - 服务端开启 Brotli 压缩、启用 HTTP/2、设置合理
Cache-Control，比前端多写几个<link>管用得多
容易被忽略的是：CSS 解析本身耗 CPU，尤其复杂选择器或大量 @import，这和加载方式无关，但直接影响渲染速度。优化加载只是第一步，别停在这儿。
