关键渲染路径阻塞点在于渲染树合成前需同时完成DOM与CSSOM构建，而非HTML语义化问题；link rel="stylesheet"默认阻塞首次绘制，因无CSSOM无法生成渲染树。
关键渲染路径卡在 DOM 和 CSSOM 合成之前，不是 HTML 写得不够“语义化”，而是结构与 CSS 的加载、解析、应用时机没对齐。
为什么 link rel="stylesheet" 放在 <head> 里还会阻塞渲染
浏览器解析 HTML 时，遇到 link rel="stylesheet" 确实会并行下载 CSS，但不会等它下载完才继续解析 HTML；真正卡住的是「首次绘制」——因为没有 CSSOM，就无法生成渲染树。哪怕 CSS 文件只有一行 body { margin: 0 }，只要没解析完，页面就白屏或只显示未样式化的 HTML 文本（Flash of Unstyled Content，FOUC）。
- 阻塞点不在 HTML 解析，而在「渲染树合成前的等待」：DOM + CSSOM 缺一不可
- 如果 CSS 文件体积大、服务器响应慢、或含 @import 嵌套，CSSOM 构建时间会被拉长
-
<link>没加media属性（如media="print"）时，默认按media="all"处理，即视为关键资源
哪些 CSS 规则会让 CSSOM 构建变慢
CSS 解析本身很快，但某些写法会触发额外计算或延迟关键样式可用性：
-
@import在 CSS 文件中出现时，会串行加载被导入的文件，打断并行下载，且必须等上级 CSS 解析到该行才发起请求 - 大量使用通配符选择器（如
* {}）、深层嵌套（如article section div p em）不直接影响解析速度，但会显著增加 CSSOM 树节点数量和匹配开销 - 自定义属性（
--main-color）本身不拖慢，但如果用var(--main-color)在关键路径上且依赖未声明的 fallback，可能造成样式计算延迟 - 字体文件（
@font-face）虽不阻塞 CSSOM 构建，但若设为font-display: block且字体未就绪，会延长文本可见时间
HTML 结构怎么配合 CSS 减少重排（Layout）压力
布局阶段（Layout）是渲染路径中最易被误伤的一环。DOM 节点越多、样式越依赖父级尺寸或兄弟节点位置，重排成本越高。结构设计要提前规避这些陷阱：
立即学习“前端免费学习笔记（深入）”；
- 避免在循环中动态插入带宽高样式的元素（如
display: table或含float的div），它们会强制同步 Layout - 用
transform和opacity替代top/left/width/height做动画，前者走合成层（Composite），不触发 Layout -
visibility: hidden比display: none更轻量——前者保留文档流位置，后者会触发 DOM 重排 - 对频繁切换显示/隐藏的模块（如 Tab 面板），优先用
hidden属性或aria-hidden+ CSS 控制可访问性，而非反复增删 class 触发样式重算
外部 CSS 文件路径和加载方式的实际影响
路径写错只是 404，真正影响渲染的是加载策略和资源粒度：
- 把所有 CSS 打包进一个
app.css，看似简单，但首屏不需要的规则（比如后台管理页的样式）也会拖慢关键 CSSOM 构建 - 用
<link rel="preload" as="style" href="critical.css" onload="this.onload=null;this.rel='stylesheet'">可提前拉取关键 CSS，但注意onload回调必须清除，否则 Safari 会重复执行 - 相对路径（
./css/main.css）比绝对路径（/css/main.css）更易因 base 标签或重写规则出错；建议统一用根相对路径，并在构建时校验 404 - HTTP/2 下多个小 CSS 文件并行加载效率不输单个大文件，但需权衡 TLS 握手和服务器推送策略
最容易被忽略的其实是「CSS 作用域隐式扩张」：一个全局 h2 { margin-top: 1.5em } 看似无害，但当某个组件内部也用 h2 且期望零边距时，开发者往往靠加 !important 或更高优先级选择器覆盖——这不仅污染样式表，还让浏览器在匹配时多做几轮计算。结构上用语义化标签（如 section、article）配合局部作用域类名（如 card__title），比依赖 HTML 元素默认样式更可控。
