Critical CSS 是提取首屏必需样式并内联到 HTML head 中的技术，以避免浏览器阻塞渲染；它需精准裁剪而非压缩，依赖工具链自动提取并动态维护，否则易导致 FOUC 或样式冲突。
什么是 Critical CSS，为什么不能直接用完整 CSS 文件
首屏渲染卡顿、白屏时间长，往往不是因为 CSS 文件太大，而是浏览器必须下载并解析全部 style.css 才能开始绘制——哪怕其中 90% 的样式只用于滚动到底部才出现的模块。Critical CSS 就是把「当前视口内渲染必需的那部分样式」提前内联到 <head> 中，让浏览器不用等待网络请求就能上屏。
常见错误现象：DOMContentLoaded 延迟、Lighthouse 报「Eliminate render-blocking resources」、实测首屏时间比预期多 300ms+。
关键点：
- 它不是「压缩 CSS」，而是「精准裁剪 + 提前注入」
- 不能靠人工肉眼判断哪些样式关键——DOM 结构、媒体查询、JS 动态类都会影响实际依赖
- 生成后必须替换原始
<link rel="stylesheet">的加载时机，否则会重复应用、引发样式闪烁
如何提取 Critical CSS：工具链选型与实操边界
没有银弹工具，选哪个取决于你的构建流程和页面动态程度。
立即学习“前端免费学习笔记（深入）”；
静态站点（如 Jekyll、Hugo）：
- 用
criticalCLI，指定 URL 或 HTML 文件路径，自动爬取首屏 DOM 并计算样式依赖 - 命令示例：
critical https://example.com --base dist/ --css dist/style.css --inline --html --minify - 注意：必须确保目标页在提取时已部署或本地可访问，且无登录态/AB 测试等拦截
前端框架（React/Vue）：
- 服务端渲染（SSR）场景下，优先在构建时用
critters（Webpack 插件）或next-critical-css（Next.js）做静态提取 - 客户端渲染（CSR）基本无效——首屏 DOM 是空的，提取结果为空或严重误判
- 若用
ReactDOMServer.renderToString生成 HTML，需确保 hydration 前的 DOM 结构与真实首屏一致（比如禁用条件渲染的 loading skeleton）
内联 Critical CSS 后，剩余样式怎么加载才不阻塞
内联完关键样式，剩下的 CSS 必须异步加载，但又不能破坏样式完整性——特别是字体、动画、伪元素等依赖全局规则的部分。
推荐做法：
- 用
rel="preload"提前拉取非关键 CSS：<link rel="preload" href="non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> - 避免用
rel="prefetch"——它是低优先级，可能赶不上用户滚动动作 - 不要用 JS 动态
appendChild创建<link>——会触发额外的 CSSOM 构建，且无法保证执行顺序 - 如果使用
media="print"hack 方式延迟加载（<link media="print" onload="this.media='all'">），务必测试 Safari —— 它对onload的触发时机有差异，可能导致样式闪动
Critical CSS 的维护成本和容易被忽略的坑
它不是「设一次就不管」的优化，而是一个需要持续对齐的脆弱环节。
典型问题：
- 页面结构微调（比如加了个
class="hero-banner"）→ 对应样式没进 Critical → 首屏出现未样式化内容（FOUC） - 响应式断点变化（如从
max-width: 768px改成max-width: 767px）→ 提取时用的 viewport 宽度不匹配 → 关键样式漏掉某类设备 - 构建产物路径变更（如
dist/css/main.a1b2c3.css→dist/css/main.d4e5f6.css）→ 提取脚本仍读旧文件 → Critical CSS 过期失效 - CDN 缓存了带内联样式的 HTML，但新版本 Critical CSS 已更新 → 用户看到的是旧关键样式 + 新非关键样式，冲突风险高
真正难的从来不是第一次提取，而是让提取逻辑稳定嵌入 CI 流程，并监控每次构建后首屏样式覆盖率是否下跌。
