首屏加载慢八成源于CSS选择器低效：深层嵌套（如.header .nav .menu .item a:hover）触发频繁回溯，通配符*和属性选择器强制全量DOM扫描，导致style recalculation时间暴涨2–4倍；应改用BEM单类名、:where()降权及关键CSS内联+异步加载策略。
首屏加载慢，八成和CSS选择器写法有关——不是文件大，而是浏览器在解析时反复回溯、匹配失败太多次。
为什么深层嵌套选择器会拖慢首屏渲染
浏览器解析 .header .nav .menu .item a:hover 是从右往左的：先找所有 a:hover，再逐层向上验证父级是否满足。DOM 越大，右侧节点越多，无效回溯越严重。首屏元素一旦被这类选择器“盯上”，style recalculation 时间可能暴涨 2–4 倍，直接卡住首次内容绘制（FCP）。
- 移动端低端设备上，4 层以上嵌套比单类名慢 3 倍起
- 哪怕只在一个局部规则里用了
div p这种后代选择器，也会污染全局匹配路径 - DevTools 的
Performance面板里看到Recalculate Style占比高，基本可锁定是选择器问题
通配符 * 和属性选择器怎么偷偷拖垮性能
* 不是“看起来无害”，而是强制遍历全部 DOM 节点；[data-id]、[class^="icon-"] 这类属性选择器无法用哈希索引加速，每次都要字符串比对。它们常出现在重置样式或组件封装逻辑里，但首屏一加载就触发全量扫描。
-
* { margin: 0; }应拆成body, h1, p, ul, li { margin: 0; } -
input[type="text"]改用语义类名如.form-input，避免类型+属性双重匹配 - 伪类组合如
:not(.valid) input会让浏览器放弃快速路径，必须重走全量流程
真正有效的替代方案：BEM + 单类名 + :where()
不用改结构、不加 JS，就能让选择器变“轻”。核心是把“靠层级表达关系”转为“靠命名表达关系”。
立即学习“前端免费学习笔记（深入）”；
- ❌ 把
.card .header改成 ✅.card__header（BEM 规范，平级无依赖） - 需要限定作用域时，用
:where(.card) .card__title：降权不降功能，避免嵌套又不提高优先级 - 旧项目难重构？至少把最外层容器加 ID 或 data 属性，然后用
[data-component="card"] .title替代深度后代选择器
首屏 CSS 必须做的三件事
选择器优化只是起点，首屏加载还卡在“等 CSS 解析完才敢画”。光改写法不够，得配合交付策略：
- 用 Chrome DevTools 的
Coverage面板识别首屏实际用到的规则，提取后内联进<style></style> - 其余 CSS 改用
<link rel="preload" as="style" href="non-critical.css" onload="this.rel='stylesheet'">异步加载 - 禁用
@import：它会阻塞并行下载，首屏 CSS 里出现一次，FCP 就多等一个 RTT
复杂点在于：选择器改得再干净，如果首屏样式仍混在 200KB 的 app.css 里一起加载，照样白搭。优化必须从“怎么写”延伸到“怎么送”。
