首屏卡住主因是浏览器必须完成CSSOM构建才能合成渲染树，哪怕仅一行body{margin:0}；该阻塞发生在首次绘制环节，与HTML解析是否继续无关，常见表现为FCP无改善、Performance面板中Parse HTML卡在main.css请求、禁用网络后首屏内容消失。
为什么总在首屏卡住
不是它下载慢，而是浏览器必须等 CSSOM 构建完成才能合成渲染树——哪怕只有一行 body { margin: 0 }，没解析完就白屏。这个阻塞发生在「首次绘制」环节，和 HTML 解析是否继续无关。
常见错误现象：FCP 没改善、DevTools 的 Performance 面板里 Parse HTML 阶段卡在某个 main.css 请求上、禁用网络后首屏内容全消失。
-
link[rel="stylesheet"]默认按media="all"处理，不管实际是否用得上 - 含
@import的 CSS 文件会串行加载，把多个请求压成一条长队列 - 深层嵌套选择器（如
article section div p em）不拖慢解析，但显著增加 CSSOM 匹配开销 -
@font-face不阻塞 CSSOM 构建，但若设font-display: block，字体未就绪时文本不可见时间拉长
关键 CSS 内联必须满足的三个硬条件
内联本身不等于优化，放错位置、塞错内容、超体积，反而让首屏更慢。真正生效的前提是三者同时成立：
-
<style>必须是<head>中第一个非<meta charset>的标签，顺序只能是：<meta charset="utf-8">→<style>→ 其他 - 内联内容必须基于真实视口（如
{ width: 375, height: 667 }）动态提取，只保留首屏 DOM 节点实际用到的选择器，过滤掉@font-face、@keyframes、display: none区块样式、未命中媒体查询（如@media (min-width: 1200px)） - gzip 后体积严格 ≤ 10KB；超过 1KB 就开始拖慢
TTFB，尤其在 3G 弱网下，HTML 主文档传输延迟明显上升
工具推荐：critters（Vite/webpack 插件）或 critical CLI 驱动 Puppeteer 提取；CSS-in-JS 生成的动态类名（如 jsx-abc123）识别率低，建议 SSR 时用 renderStylesToString() 序列化。
立即学习“前端免费学习笔记（深入）”；
非关键 CSS 怎么做到不阻塞又不丢功能
不能靠 display: none 或 visibility: hidden 隐藏对应样式块——这些只是视觉隐藏，规则仍在关键路径上。必须切断它参与初始 CSSOM 构建的链条。
- 对设备特定样式，直接加
media属性：<link href="print.css" rel="stylesheet" media="print">，浏览器根本不会下载 - 对响应式断点中未命中的部分（如移动端无需桌面侧边栏），用
media="(min-width: 1024px)"隔离 - 用
<link rel="preload" as="style" onload="this.rel='stylesheet'">实现异步加载，注意要配<noscript>回退 - 绝对不要在 CSS 文件里写
@import——它比<link>多一层同步阻塞
预加载 as="style" 只改变下载时机，不替代内联；它拉下来的样式仍需后续 <link> 挂载，无法参与初始渲染树构建。
HTML 结构怎么配合 CSS 减少重排压力
布局阶段（Layout）是渲染路径中最易被误伤的一环。结构设计不当会让重排成本指数级上升，尤其在频繁交互场景下。
- 避免在循环中动态插入带高开销样式的元素（如
display: table、含float的div），它们会强制同步 Layout - 动画优先用
transform和opacity，前者走合成层（Composite），不触发 Layout；而top/left/width/height会强制重排 - 对 Tab 面板等频繁切换模块，用
hidden属性或aria-hidden+ CSS 控制可访问性，而非反复增删 class 触发样式重算 - 首屏关键内容必须前置书写——浏览器流式解析，DOM 构建越早完成，CSSOM 就越早能合成渲染树
最常被忽略的是：内联不是万能解药。它把样式耦合进 HTML，导致每次变更都重传整个页面，服务端也无法单独缓存样式。上线前务必验证构建流程是否将 critical.css 作为独立产物注入，而非硬编码在模板里。
