深层嵌套选择器导致首屏变慢，因浏览器从右向左匹配，如.header .nav .menu li a先查所有a再逐层验证父级，DOM越大、a越多，无效回溯越严重。
为什么深层嵌套选择器会让首屏变慢
浏览器匹配 CSS 选择器是**从右往左**进行的，不是按你写的顺序。比如 .header .nav .menu li a，它会先找所有 a，再逐层向上验证父级是否满足条件。DOM 越大、a 越多，无效回溯越严重。实测在低端安卓机上，4 层嵌套比单类名慢 3 倍起；DevTools 的 Performance 面板里如果 Recalculate Style 占比高，基本就是这类问题。
哪些选择器该立刻替换掉
以下写法看似“结构清晰”，实际是性能黑洞：
-
div.container ul.nav li a→ 改成.nav-link（用类名表达语义，不靠层级） -
* { margin: 0; padding: 0; }→ 拆成html, body, h1, p, ul, li { margin: 0; padding: 0; } -
input[type="text"]→ 改用.form-input，避免属性匹配+标签双重开销 -
:not(.valid) input→ 浏览器会放弃快速路径，必须全量扫描，尽量拆成两个独立规则
如何低成本落地优化
不用推翻现有结构，也能见效：
- 用 Chrome DevTools 的
Coverage面板识别首屏实际用到的 CSS 规则，提取后内联进<head><style> - 非关键 CSS 改用
<link rel="preload" as="style" href="non-critical.css" onload="this.rel='stylesheet'">异步加载 - 老项目难改？至少给外层容器加
data-component="xxx"，把.card .title换成[data-component="card"] .title - 优先用
:where()替代深度嵌套：比如:where(.card) .card__title既降权又保留作用域
容易被忽略的兼容性与副作用
:where() 和 contain 这类新特性虽好，但 Safari 15.4 之前不支持 :where()，iOS 15.6 之前不支持 contain: layout paint size。别只看 Can I Use 数据——真实用户里仍有约 7% 使用旧版 Safari。另外，盲目用 ID 选择器（如 #header）虽快，但破坏组件复用性；而过度依赖 !important 会干扰后续样式覆盖逻辑，调试时更难定位冲突源。
立即学习“前端免费学习笔记（深入）”；
