2009年，Steve Souders在《Even Faster Web Sites》中写道：“CSS是阻塞渲染的资源。“十五年后，这句话依然准确，但背后的技术图景已经发生了深刻变化。

HTTP Archive对1600万网站的分析显示：18.86%的网站仍在使用CSS @import，这个被性能专家反复警告的做法在2024年依然广泛存在。更令人担忧的是，这些网站的首屏渲染时间平均被推迟了数百毫秒——在移动互联网时代，这足以让用户放弃等待。

CSS的渲染阻塞不是浏览器实现上的缺陷，而是Web平台设计的必然结果。理解这个"为什么”，比记住一堆优化规则更重要。

浏览器渲染管道：为什么CSS必须是阻塞的

当浏览器收到HTML文档后，它需要完成一系列步骤才能在屏幕上绘制像素。这个过程被称为关键渲染路径（Critical Rendering Path）。

DOM与CSSOM：两个必须完成的构建

HTML是渐进式解析的。浏览器收到HTML字节流后，会将其转换为token，再转换为节点，最终构建成DOM树。这个过程是增量的——浏览器可以在收到部分HTML时就开始渲染。

但CSS完全不同。

CSS解析是全量阻塞的。当浏览器遇到CSS——无论是内联的<style>标签还是外部的<link rel="stylesheet">——它必须完整下载并解析整个样式表后才能继续渲染。

这不是浏览器开发者的偷懒，而是CSS本身的设计决定的。CSS的C代表"Cascade”（层叠），后面的规则可以覆盖前面的规则。考虑这个例子：

/* 文件开头 */
.title { color: blue; }

/* 文件末尾 */
.title { color: red; }

如果浏览器增量应用CSS，用户会先看到蓝色的标题，然后突然变成红色——这种闪烁被称为FOUC（Flash of Unstyled Content）。为了避免这种糟糕的用户体验，浏览器必须等待整个CSSOM（CSS Object Model）构建完成。

MDN文档明确指出：CSS是渲染阻塞资源，浏览器会阻塞页面渲染直到它接收并处理完所有CSS。

CSSOM构建的内部机制

CSSOM的构建过程与DOM类似但更复杂：

  1. 字节流转换：CSS字节流被解码为字符
  2. Tokenization：字符被解析为CSS token
  3. 解析：token被转换为CSS规则节点
  4. CSSOM树构建：节点根据层叠规则组织成树结构

关键区别在于：CSSOM构建过程中不能进行任何渲染。浏览器必须知道每个元素的最终计算样式，才能确定其在屏幕上的位置和外观。

渲染树：DOM与CSSOM的汇合

当DOM和CSSOM都构建完成后，浏览器会将它们合并为渲染树（Render Tree）。渲染树只包含可见的元素——<head>中的内容、display: none的元素都不会出现在渲染树中。

渲染树的构建过程对每个DOM节点执行样式计算：

graph TD
    A[DOM节点] --> B{遍历所有CSS规则}
    B --> C[匹配选择器]
    C --> D[计算最终样式]
    D --> E[添加到渲染树]

这个过程的时间复杂度取决于两个因素：DOM节点数量和CSS规则复杂度。一个包含5000个DOM元素和3000条CSS规则的页面，样式计算可能需要数百毫秒。

@import陷阱：串行瀑布流如何摧毁首屏性能

CSS @import是最容易被忽视的性能杀手。它的实现机制决定了它必然导致串行加载。

为什么@import比<link>慢

当浏览器遇到<link rel="stylesheet" href="a.css">时，preload scanner可以提前发现这个资源并开始下载。即使主解析器被阻塞，网络层也能并行工作。

但@import完全不同。考虑这个场景：

<link rel="stylesheet" href="main.css">

/* main.css */
@import url("fonts.css");
@import url("theme.css");

浏览器必须：

  1. 下载并完全解析main.css
  2. 发现@import规则
  3. 开始下载fonts.css和theme.css

关键的延迟在于：在步骤1完成之前，浏览器根本不知道fonts.css和theme.css的存在。这创建了一个必然的串行依赖链。

Erwin Hofman在2024年的研究中提供了具体的WebPageTest演示数据：

配置 Start Render时间 说明
default.html 1.2秒 单个CSS文件
importing.html 1.5秒 一个CSS文件@import另一个
差值 +300ms 纯粹的@import延迟

这个300ms的延迟在3G网络下会放大到更严重的程度。

真实世界的性能数据

Vipio.com的案例提供了RUM（Real User Monitoring）数据。该网站通过@import嵌套了Typekit字体，形成了三级串行加载：

main.css → use.typekit.net/xxx.css → p.typekit.net/yyy.css

移除@import并改用<link>标签后：

指标 优化前 优化后 提升
FCP (P80, 移动端) 2782ms 1872ms 32.7%
firstByteToFCP 1995ms 1177ms 41%

WooCommerce网站的案例更加极端：仅仅移除一个用于搜索组件的Google Font @import，firstByteToFCP就提升了37.1%。

HTTP Archive的大规模数据

Paul Calvano对1600万网站的分析揭示了@import的普遍性：

  • 总使用率：18.86%（约306万网站）
  • 第三方资源：15.16%（247万网站，主要是字体服务）
  • 第一方资源：5.50%（89万网站）

Google Fonts是最常见的罪魁祸首。168万网站使用fonts.googleapis.com，其中22.2%（约37万网站）使用@import方式引入。这意味着数十万网站在无意中损害了自己的首屏性能。

选择器匹配：右到左算法的性能代价

CSS选择器的匹配机制是开发者经常误解的领域。理解这个机制对于编写高性能CSS至关重要。

右到左匹配算法

当浏览器需要为一个DOM元素计算样式时，它不会"从上到下"遍历CSS规则。相反，它使用右到左的匹配策略。

考虑这个选择器：

.wrapper .section .title .link { color: blue; }

浏览器的匹配过程是：

  1. 首先查找所有具有.link类的元素
  2. 对于每个匹配的元素，检查其祖先是否有.title
  3. 如果有，再检查更上层的祖先是否有.section
  4. 最后检查是否有.wrapper祖先

这种看似反直觉的算法实际上是为了优化。DOM树的元素数量通常远大于CSS规则数量，右到左匹配可以快速排除大部分不相关的元素。

选择器复杂度的真实影响

Microsoft Edge团队在2023年的博客中提供了一个案例研究。一个包含5000个DOM元素的图片库页面，当切换相机筛选器时，样式重计算耗时超过900毫秒。

性能分析工具识别出的高成本选择器包括：

/* 高成本：需要遍历所有后代元素 */
.gallery .photo .meta ::selection { }

/* 高成本：属性选择器需要子串匹配 */
[class*=" gallery-icon--"]::before { }

/* 极高成本：通用选择器匹配所有元素 */
* { box-sizing: border-box; }

优化策略包括：

  1. 简化选择器：.photo-meta替代.gallery .photo .meta li
  2. 避免属性选择器：.gallery-icon.camera替代[class*=" gallery-icon--"]
  3. 精确应用box-sizing：移除通用选择器，只在需要的元素上应用

优化后，样式重计算时间从900ms降至300ms——67%的性能提升。

选择器性能的黄金法则

Edge团队的结论值得铭记：

“过度优化选择器可能使CSS更难阅读和维护，而实际收益可能微乎其微。在优化之前，先用DevTools测量你的真实场景。”

大多数现代浏览器中，简单选择器和复杂选择器的性能差异通常在微秒级别。只有在以下情况下才值得优化：

  • DOM节点数量超过数千个
  • CSS规则数量超过数千条
  • 页面频繁触发样式重计算（如动画、滚动）
  • 目标设备性能较低（移动设备、低端PC）

回流与重绘：隐形性能杀手

CSS性能问题不仅发生在初始渲染阶段。页面加载后的交互性能同样受到CSS的深刻影响。

回流的代价

**回流（Reflow/Layout）**是浏览器计算元素几何属性（位置和尺寸）的过程。与样式计算不同，回流通常影响整个文档——改变一个元素的位置可能导致所有其他元素重新计算。

Google的web.dev文档指出：

“回流几乎总是作用于整个文档。如果你有大量元素，计算出它们的位置和尺寸将花费很长时间。”

以下CSS属性会触发回流：

/* 几何属性 */
width, height, padding, margin
left, top, right, bottom
font-size, line-height

/* 布局属性 */
display, position, float, clear
flex, grid相关属性

Layout Thrashing：最危险的模式

**强制同步布局（Forced Synchronous Layout）**是最常见的性能反模式。它发生在JavaScript读取布局属性后立即修改样式：

// 危险！每次迭代都触发回流
for (let i = 0; i < paragraphs.length; i++) {
  paragraphs[i].style.width = box.offsetWidth + 'px';
}

浏览器被迫在每次写入后立即执行布局计算，因为下一次读取需要最新的值。这被称为Layout Thrashing，可以将简单的循环变成性能噩梦。

正确的模式是批量读写：

// 先读取所有需要的值
const width = box.offsetWidth;
// 然后批量写入
for (let i = 0; i < paragraphs.length; i++) {
  paragraphs[i].style.width = width + 'px';
}

CSS Containment：现代浏览器的优化利器

CSS Containment是解决回流性能问题的重要工具。contain属性告诉浏览器元素的渲染边界，允许浏览器进行优化：

.isolated-component {
  contain: layout;  /* 内部布局不影响外部 */
  contain: paint;   /* 内部绘制不溢出边界 */
  contain: size;    /* 元素尺寸不依赖内容 */
  contain: content; /* 等同于 layout paint */
  contain: strict;  /* 等同于 layout paint size */
}

Rachel Andrew在CSS-Tricks的文章中建议：

“如果你正在构建组件库，contain: content是一个很好的默认选择。每个组件通常都是独立的事物，不会影响页面上的其他元素。”

SpeedKit的实地测试显示，在复杂页面中正确使用CSS Containment可以将渲染时间减少20-40%。

关键CSS提取：工程化的性能优化

Critical CSS提取是最有效的首屏渲染优化技术之一，但它的实现需要权衡多个因素。

基本原理

关键CSS技术的核心思想是：

  1. 识别首屏（above-the-fold）可见内容所需的最小CSS规则集
  2. 将这些规则内联到HTML的<style>标签中
  3. 异步加载剩余的CSS

这打破了CSS的渲染阻塞，因为浏览器不需要等待外部CSS文件下载就能开始渲染。

web.dev的案例展示了视觉效果：

配置 首帧 渲染时间
外部CSS 空白页面 6帧后显示
内联关键CSS 立即显示内容 第1帧即有意义

工具对比与选型

三种主流的关键CSS提取工具各有特点：

工具 自动检测样式表 内联与压缩 多分辨率支持 适用场景
Critical ✓ ✓ ✓ 通用场景
criticalCSS ✗ ✗ ✗ 需要精细控制
Penthouse ✗ ✗ ✓ 大型CSS、动态注入

Critical是最易用的选择。它会自动检测HTML中的样式表，提取关键CSS，并直接生成包含内联样式的HTML。

Penthouse使用Puppeteer，能够处理动态注入的CSS（常见于Angular等框架）。它需要显式指定HTML和CSS文件，但可以并行处理多个任务。

内联CSS的权衡

关键CSS内联并非没有代价：

优势：

  • 消除CSS请求的往返延迟
  • 首屏渲染不再被外部CSS阻塞
  • 在慢速网络下效果显著

劣势：

  • 内联CSS无法跨页面缓存
  • 每个页面需要生成独立的关键CSS
  • 增加HTML文档大小

Harry Roberts在CSS Wizardry的文章中提醒：

“关键CSS只有在CSS是你最大的渲染阻塞瓶颈时才有帮助。通常情况并非如此。”

这意味着在实施关键CSS之前，应该先确认CSS确实是性能瓶颈。Lighthouse的"Eliminate render-blocking resources"审计可以帮助做出这个判断。

性能影响的数据

PageSpeedMatters的研究提供了关键CSS性能影响的量化数据：

  • FCP提升范围：500ms至2秒
  • 在3G网络下效果更加显著
  • 对于CSS文件较大的网站，提升更明显

一个具体的最佳实践是：首屏内容的CSS保持在14KB（压缩后）以内，这允许浏览器在单个TCP数据包中传输完整的关键样式。

现代浏览器的优化机制

理解浏览器内部的优化机制，有助于开发者写出更高效的CSS。

增量渲染与渐进式显示

现代浏览器（特别是Firefox和Chrome）实现了增量渲染。当遇到渲染阻塞资源时，浏览器不再阻塞整个页面的渲染，而是只阻塞该资源以下的DOM内容。

这意味着将CSS放在<head>中比放在<body>末尾要好——即使CSS阻塞渲染，用户也能更快看到页面上方的内容。

Preload Scanner

浏览器的preload scanner是一个辅助解析器，在主解析器被阻塞时，它会扫描HTML中尚未解析的部分，提前发现需要下载的资源。

这就是为什么<link rel="stylesheet">比@import快——preload scanner可以提前发现<link>标签，但无法穿透CSS文件内部的@import规则。

样式计算缓存

浏览器会缓存样式计算结果。当DOM变化时，浏览器不需要重新计算所有元素的样式，只需要更新受影响的部分。

这就是CSS Containment有效的原理——通过明确声明元素的渲染边界，浏览器可以缩小需要重新计算的范围。

性能分析工具箱

优化CSS性能需要正确的测量工具。

Chrome DevTools Coverage面板

Coverage面板可以识别未使用的CSS：

  1. 打开DevTools → More Tools → Coverage
  2. 点击录制按钮并刷新页面
  3. 查看每个CSS文件的使用率

DebugBear的分析显示，许多网站的CSS文件中超过50%的代码未被使用。移除这些代码可以同时减少下载时间和样式计算时间。

Performance面板与Selector Stats

Chrome 109引入了Selector Stats功能，可以识别高成本的CSS选择器：

  1. 打开Performance面板
  2. 启用"Enable advanced rendering instrumentation"
  3. 录制性能轨迹
  4. 选择样式重计算块
  5. 查看Selector Stats标签页

这个功能直接显示了每个选择器的处理时间和匹配次数，是优化选择器的利器。

Lighthouse审计

Lighthouse提供了两个相关的审计：

  • Eliminate render-blocking resources：识别阻塞渲染的CSS和JavaScript
  • Reduce unused CSS：识别未使用的CSS规则

这两个审计可以帮助开发者确定优化的优先级。

决策框架：何时优化，优化什么

CSS性能优化不是盲目的规则应用，而是基于测量的理性决策。以下是一个决策框架：

第一优先级：移除@import

这是投入产出比最高的优化。用<link>替代@import几乎总是正确的选择，特别是对于第三方资源（Google Fonts、Typekit等）。

对于无法控制的第三方CSS（如Typekit），使用preload作为折中方案：

<link rel="preload" href="https://use.typekit.net/xxx.css" as="style">
<link href="https://use.typekit.net/xxx.css" rel="stylesheet">

第二优先级：移除未使用的CSS

使用DevTools Coverage面板识别未使用的CSS。优先移除整块的未使用样式表，而不是逐条删除规则。

第三优先级：关键CSS内联

当CSS确实是渲染阻塞瓶颈时（Lighthouse明确提示），考虑关键CSS提取。对于单页应用，需要权衡内联CSS带来的缓存失效问题。

第四优先级：选择器优化

只有在性能测量明确显示样式重计算是瓶颈时，才进行选择器优化。优先处理通用选择器（*）和深度嵌套选择器。

第五优先级：CSS Containment

对于组件库和复杂的动态内容区域，添加contain: content作为预防性优化。

从理论到实践

CSS性能优化是一场持续的技术博弈。浏览器在不断优化渲染引擎，Web平台在不断引入新的API，开发者需要持续学习和适应。

核心原则从未改变：测量优先，优化其次。在DevTools中看到真实的数据，比记住十条优化规则更有价值。

当用户在3G网络下等待你的页面渲染时，那多出来的300毫秒可能就是他们离开的理由。而那300毫秒，可能就藏在一个被忽视的@import中。

参考资料

  1. web.dev. “Understand the critical path.” https://web.dev/learn/performance/understanding-the-critical-path (2023)
  2. MDN Web Docs. “Critical rendering path.” https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Critical_rendering_path (2025)
  3. DebugBear. “Optimizing The Critical Rendering Path.” https://www.debugbear.com/blog/optimizing-the-critical-rendering-path (2025)
  4. Erwin Hofman. “The curious (performance) case of CSS @import.” https://calendar.perfplanet.com/2024/the-curious-performance-case-of-css-import/ (2024)
  5. Microsoft Edge Blog. “The truth about CSS selector performance.” https://blogs.windows.com/msedgedev/2023/01/17/the-truth-about-css-selector-performance/ (2023)
  6. web.dev. “Extract critical CSS.” https://web.dev/articles/extract-critical-css (2019)
  7. web.dev. “Avoid large, complex layouts and layout thrashing.” https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing (2015)
  8. CSS-Tricks. “Helping Browsers Optimize With The CSS Contain Property.” https://css-tricks.com/helping-browsers-optimize-with-the-css-contain-property/ (2020)
  9. Harry Roberts. “Critical CSS? Not So Fast!” https://csswizardry.com/2022/09/critical-css-not-so-fast/ (2022)
  10. HTTP Archive. “CSS @import Usage Analysis.” https://httparchive.org/ (2024)