Lighthouse对CSS敏感因其将其视为渲染阻塞资源，重点评估其对FCP/LCP、未使用代码覆盖率及重排重绘的影响；优化需手动提取关键CSS内联、异步加载非关键样式、谨慎删除未用规则，并结合Coverage面板与真实体验验证。
直接内联关键CSS、异步加载非关键样式、移除未使用规则——这是提升Lighthouse CSS相关得分最有效的三步，其他操作基本是边际收益。
为什么Lighthouse对CSS这么敏感？
Lighthouse把CSS当作“渲染阻塞资源”来评估。它会检测：render-blocking 样式表是否延迟了FCP/LCP；是否引入了大量未使用的CSS（通过覆盖率分析）；是否触发了过多的重排重绘（间接影响CLS和TBT）。这些不是理论问题，而是真实影响主线程空闲时间的瓶颈。
常见错误现象包括：页面白屏超过1秒、首屏文字闪动、滚动卡顿、Lighthouse报告中反复出现“Eliminate render-blocking resources”和“Remove unused CSS”这两条建议。
关键点在于：Lighthouse不关心你用了多少行CSS，只关心浏览器解析和应用它花了多少毫秒、占了多少带宽、是否干扰了用户可交互时间。
立即学习“前端免费学习笔记（深入）”；
内联关键CSS必须手动提取
自动工具（如critters或Webpack插件）在构建时提取关键CSS容易出错：它们常把悬停态、媒体查询断点、JS动态插入的类误判为“非关键”，导致首屏样式缺失或布局偏移（CLS飙升）。
实操建议：
- 用Chrome DevTools的Coverage面板（
Ctrl+Shift+P→ 输入“Coverage”）打开，刷新页面，看哪些CSS文件/规则实际被用到（绿色高亮） - 只把
<head>中首屏可见区域（above-the-fold）真正需要的样式复制进<style></style>标签，不加任何@media或伪类，除非它们在初始视口内立即生效 - 外部CSS文件统一加上
media="print"或media="(min-width: 0px)"再配合onload切换，避免被Lighthouse识别为阻塞资源
“Remove unused CSS”建议不能全信
Lighthouse的未使用CSS检测基于单页单路径的覆盖率快照，对SPA、条件渲染组件、暗色模式切换等场景完全失效。强行删除可能让React.lazy加载的模块样式丢失，或导致useEffect里动态注入的类名失效。
更稳妥的做法：
- 确认该CSS确实未在任何路由、状态、设备尺寸下被调用（可用
document.styleSheets+getComputedStyle交叉验证） - 优先删
node_modules里整包引入的UI库样式（如bootstrap.css），改用按需导入（import 'bootstrap/scss/buttons.scss'） - 对CSS-in-JS方案（如Emotion、Styled Components），确保启用
css prop或extractCritical服务端提取，避免运行时注入冗余规则
字体和动画CSS最容易拖累CLS和LCP
未声明font-display: swap的自定义字体，会导致文本不可见（FOIT）或闪烁（FOUT），直接影响FCP和CLS；用top/left做动画会强制同步布局计算，抬高TBT。
必须检查的配置：
-
@font-face中必须含font-display: swap，且preload关键字体：<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin> - 所有动画改用
transform和opacity，禁用width/height/margin等触发布局的属性 - 图片、广告、嵌入内容必须显式声明
width和height，否则Lighthouse会因无法预估尺寸而扣CLS分
复杂点在于：CSS优化效果高度依赖页面结构和运行时行为。一个display: none的组件，其CSS是否“未使用”，Lighthouse根本判断不了。别迷信自动化报告，要结合Coverage面板、Performance录制、以及真实设备上的视觉反馈交叉验证。
