link 标签引入 css 会阻塞渲染，浏览器解析 html 时遇 立即发起请求并暂停 dom 构建与渲染，直至 css 下载解析完成；关键优化包括内联首屏关键 css、用 media 延迟非关键样式、禁用 @import、结合 preload 异步加载及利用 http/2 多路复用。
link 标签引入 CSS 会阻塞渲染
浏览器解析 HTML 时，遇到 <link rel="stylesheet"> 会立即发起 CSS 请求，并暂停 DOM 构建和页面渲染，直到该 CSS 资源下载、解析完成。这是关键阻塞点，尤其当 CSS 文件体积大或服务器响应慢时，首屏白屏时间明显拉长。
常见错误现象包括：DOMContentLoaded 延迟触发、First Contentful Paint (FCP) 拖后、Lighthouse 报告中 “Eliminate render-blocking resources”。
- 内联小量关键 CSS（如首屏样式）可绕过请求，但仅限
<style></style>中不超过 ~2KB 的内容 - 非关键 CSS（如打印样式、深页交互样式）应通过
media属性延迟加载：<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'"> - 避免在
底部放<link>—— 浏览器仍会提前预扫描并阻塞，无效
@import 在 CSS 中引入会加重阻塞
@import 不是 HTML 层面的资源声明，而是 CSS 规则，必须等父 CSS 下载解析后才开始请求被导入的文件，形成串行加载链。一个 @import 可能导致多轮 RTT 延迟，比并行 <link> 慢 2–3 倍。
使用场景极少：仅适合动态构建 CSS 工具链中做条件合并（如 sass @import），但最终输出必须是扁平化单 CSS 文件，不能保留运行时 @import。
立即学习“前端免费学习笔记（深入）”；
- 绝对不要在生产 CSS 文件里写
@import url("theme.css") - 构建工具（如 webpack/Vite）中配置
css-loader时，确保importLoaders不开启运行时 import 解析 - 用 chrome DevTools 的 Network → Filter “CSS” 查看是否出现串行请求瀑布流，就是
@import在作祟
preload 和 media 切换能实现“无阻塞加载”
<link rel="preload"> 本身不执行解析，只提前发起高优先级请求；配合 onload 动态挂载，可实现 CSS 加载不阻塞渲染。
这适合异步加载非首屏样式（如模态框、图表组件专属 CSS），但需注意 js 执行时机与样式应用顺序。
- 写法示例：
<link rel="preload" href="chart.css" as="style" onload="this.onload=NULL;this.rel='stylesheet'"> - 必须加
as="style"，否则浏览器按fetch优先级处理，可能降权 -
this.onload=null防止重复执行（某些浏览器会触发多次 onload） - 如果组件 JS 已依赖该 CSS，需在
onload后再初始化组件，否则样式未生效就渲染
HTTP/2 和 HTTP/3 对 link 并发有实质影响
HTTP/1.1 下多个 <link> 会受限于域名并发连接数（通常 6 个），而 HTTP/2 支持多路复用，多个 CSS 请求可在单连接上并行传输，实际加载耗时接近最大单个文件耗时。
但这不等于可以随意拆分 CSS —— 过多小文件会增加 TLS 握手、队头阻塞（HTTP/2）、以及构建/缓存管理成本。
- 推荐策略：首屏关键 CSS 内联 + 其余合并为 1–2 个主 CSS，再配合
preload或media分离非关键部分 - 检查是否启用 HTTP/2：chrome devtools → Network → Protocol 列，看到
h2或h3即生效 - 若用 CDN，确认其支持 HTTP/2 且未强制回退到 HTTP/1.1（例如某些老旧 nginx 配置）
实际优化中最容易被忽略的是：把“CSS 拆得更细”当成万能解，却没验证是否真由网络瓶颈主导。多数情况下，真正卡住的是未压缩的字体、未设置 media 的 print CSS、或者构建产物里混入了根本不用的第三方样式。先抓 Waterfall，再动代码。