link rel="stylesheet"卡住首次绘制是因为浏览器必须等待CSSOM构建完成才能合成渲染树，而非下载慢；它默认按media="all"处理，会阻塞关键渲染路径。
link rel="stylesheet"为什么卡住首次绘制
不是它下载慢，而是浏览器必须等 CSSOM 构建完成才能合成渲染树——哪怕只有一行 body { margin: 0 }。这个阻塞发生在「首次绘制」环节，和 HTML 解析是否继续无关。
常见错误现象包括：FCP（首次内容绘制）无改善、DevTools 的 Performance 面板里 Parse HTML 阶段卡在某个 main.css 请求上、禁用网络后首屏内容全消失。
-
link[rel="stylesheet"]默认按media="all"处理，不管实际是否用得上 - 含
@import的 CSS 文件会串行加载，把多个请求压成一条长队列 - 深层嵌套选择器（如
article section div p em）不拖慢解析，但显著增加 CSSOM 匹配开销 -
@font-face不阻塞 CSSOM 构建，但若设font-display: block，字体未就绪时文本不可见时间拉长
link放在head里≠样式一定及时生效
link 放在 <head> 是基础条件，但不能解决“首屏样式等 CSS 文件”的本质延迟。网络往返、TLS 握手、服务器响应时间，都会让外部 CSS 至少延迟几百毫秒。
检查三件事：
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools 的 Network 面板确认 CSS 文件返回状态码是
200，且响应体含有效 CSS 规则（不是404、空文件或 HTML 错误页） - 检查是否被
@import拖累：@import在<style>块内是同步阻塞的，且无法并行下载，比link更慢；应避免在内联<style>中写@import url() - 运行
document.styleSheets查看长度，再逐个检查sheet.cssRules是否为空或报SecurityError（跨域 CSS 不允许 JS 访问规则）
关键CSS必须内联，且有硬性约束
内联本身不等于优化，放错位置、塞错内容、超体积，反而让首屏更慢。真正生效的前提是三者同时成立：
-
<style>必须是<head>中第一个非<meta charset>的标签，顺序只能是：<meta charset="utf-8">→<style>→ 其他 - 内联内容必须基于真实视口（如
{ width: 375, height: 667 }）动态提取，只保留首屏 DOM 节点实际用到的选择器，过滤掉@font-face、@keyframes、display: none区块样式、未命中媒体查询（如@media (min-width: 1200px)） - gzip 后体积严格 ≤
10KB；超过1KB就开始拖慢TTFB，尤其在 3G 弱网下，HTML 主文档传输延迟明显上升
media属性没加就是默认all，这点常被忽略
link 标签没加 media 属性时，默认按 media="all" 处理，被当作关键资源，强制参与关键渲染路径。即使你只是为打印准备的样式，不加 media="print"，浏览器照样会下载、解析、构建 CSSOM，白白占用主线程。
正确做法：
- 对设备特定样式，直接加
media属性：<link href="print.css" rel="stylesheet" media="print">，浏览器根本不会下载 - 对响应式断点中未命中的部分（如移动端无需桌面侧边栏），用
media="(min-width: 1024px)"隔离 - 用
<link rel="preload" as="style" onload="this.rel='stylesheet'">实现异步加载，注意要配<noscript>回退
绝对不要在 CSS 文件里写 @import——它比 link 多一层同步阻塞。
