link rel="stylesheet" 会拖慢 Lighthouse 首屏评分，因为它阻塞 HTML 解析与渲染直至 CSSOM 构建完成，直接影响 FCP 和 Speed Index；即使小体积 CSS 未加载完，首屏内容也可能延迟渲染 300ms+。
为什么 link rel="stylesheet" 会拖慢 Lighthouse 首屏评分
因为浏览器遇到 link rel="stylesheet" 时，会立即发起请求，并**阻塞 HTML 解析与渲染**，直到 CSSOM 构建完成。Lighthouse 的「First Contentful Paint」和「Speed Index」直接受此影响——哪怕样式表只有 10KB，只要没加载完，首屏文字/图片就可能延迟渲染 300ms+。
- 关键路径上（
内）的同步 CSS 是「渲染阻塞资源」，Lighthouse 会在「Eliminate render-blocking resources」建议里明确标出 - HTTP/2 下多个
link并发请求不解决阻塞问题，只解决排队问题 - 内联小 CSS（
<style></style>）能绕过请求，但超过 ~3KB 就可能触发浏览器重排开销，反而更慢
怎么判断哪些 CSS 真正需要「首屏加载」
不是所有 CSS 都该进主样式表。Lighthouse 报告里的「Coverage」面板（DevTools → More Tools → Coverage）能直接告诉你：当前页面实际用到的 CSS 占比。常看到的结果是「仅 15% 的 main.css 被执行」——剩下 85% 是轮播图、弹窗、后台管理页等非首屏代码。
- 打开 Coverage 面板 → 刷新页面 → 查看 .css 文件右侧的红色/绿色比例条
- 红色部分 = 下载了但没用到的 CSS，可安全拆出或异步加载
- 特别注意第三方 UI 库（如
element-plus、antd）的全量引入，它们贡献了最多「无用 CSS」
media 和 onload 怎么配合避免阻塞
用 media="print" 声明的 link 不会阻塞渲染，浏览器会先下载但不解析；等真正需要时（比如用户点打印），再切换 media 值触发解析。配合 onload 回调，就能实现「加载完即用」。
<link rel="stylesheet" href="critical.css" media="all"> <link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'"> <noscript><link rel="stylesheet" href="non-critical.css"></noscript>
-
media="print"是 trick，不是真为打印准备，只为骗过初始阻塞检查 -
onload在 CSS 加载完成后触发，此时切回media="all"才真正生效 - 必须保留
<noscript></noscript>降级，否则禁用 JS 的用户看不到非关键样式
Lighthouse 评分对「CSS-in-JS」和「CSS 拆包」特别敏感
像 styled-components 或 emotion 默认在运行时注入样式，Lighthouse 会把它算作「动态插入」，不计入初始阻塞资源——但代价是首次 JS 执行完才能出样式，FCP 可能变差。而 Webpack/Vite 的 CSS 提取（mini-css-extract-plugin）若把所有 CSS 打包进一个 main.css，又回到阻塞老路。
立即学习“前端免费学习笔记（深入）”；
- 服务端渲染（SSR）项目务必开启「critical CSS 提取」，把首屏所需样式内联，其余异步加载
- Vite 用户注意
build.cssCodeSplit默认为 true，但拆出的 chunk 若仍被link同步引入，没意义 - Lighthouse 9+ 开始更严格计算「Layout Shift」，CSS 加载时机错乱会导致按钮跳动，直接扣分
真正卡分的往往不是文件大小，而是 CSS 加载与 DOM 渲染的时序错位——改一个 media 属性，或挪一行 link 标签位置，Lighthouse 分数就可能跳 10 分。
