在React项目的性能优化清单里，Critical CSS（关键CSS）内联是回报率相当高的一项。它的核心逻辑很直接：浏览器渲染页面前必须先构建CSSOM，如果样式放在外部CSS文件里，浏览器就要先下载、解析这个文件才能开始绘制，网络稍差就会出现一段白屏。而把首屏必需的少量样式直接写进HTML的head中，页面可以立即开始渲染，剩下的样式再异步加载，首屏时间自然就降下来了。
渲染阻塞的原理：为什么CSS会卡住首屏
浏览器渲染流程中，DOM和CSSOM必须都构建完成才能生成渲染树。这就意味着，任何在head中被同步加载的CSS文件，都会阻塞后续的渲染过程。注意这里的阻塞是渲染阻塞而非解析阻塞，HTML的解析通常可以继续进行，但页面不会显示任何内容。
举个典型的React单页应用场景：构建工具把所有组件的样式打包成一个几百KB的main.css，放在index.html的head里。用户打开页面后，浏览器要下载完这整个文件才能画出第一屏，而这个文件里可能有80%的样式属于用户根本还没看到的路由页面。这就是所谓的渲染阻塞资源问题，也是Lighthouse审计中常见的扣分项。
解决思路是把CSS拆成两部分：首屏必需的关键样式内联到HTML中（内联样式不受网络请求制约，解析即生效），非关键样式改成不阻塞渲染的方式加载，例如给link标签加上media属性切换，或者用JavaScript动态插入。这个思路对任何技术栈都适用，React项目只是实现方式上有一些特点。
在React项目中提取关键CSS的几种方案
方案一：手动提取。适合页面结构简单、样式稳定的项目。做法是打开浏览器开发者工具的Coverage面板，录制一次页面加载，查看哪些CSS规则实际被首屏用到，把这些规则手动复制到index.html的style标签里。这种方式直观可控，但维护成本高，一旦组件样式改版就要重新提取，团队协作时容易遗漏，只建议在小型落地页项目中使用。
方案二：构建时自动提取。社区里成熟的工具有critters、beasties、critical等。以Create React App ejected后的项目为例，可以在webpack配置中接入critters插件：
const Critters = require('critters');
module.exports = {
// ...其他webpack配置
plugins: [
new Critters({
// 预加载剩余样式的策略
preload: 'swap',
// 是否压缩提取出的关键CSS
compress: true,
// 内联字体的处理方式
inlineFonts: true,
// 日志级别
logLevel: 'warn'
})
]
};critters会在构建产物生成后分析HTML与CSS的对应关系，找出首屏用到的规则内联进HTML，同时把完整样式表转换为非阻塞加载。它的优势是全自动、对业务代码零侵入；缺点是它基于静态HTML做分析，对于完全由客户端渲染的React应用，如果首屏内容依赖JS执行后才出现，工具能提取到的关键样式会有限。所以这套方案通常配合服务端渲染（SSR）或静态生成（SSG）效果最好。
方案三：样式层面的根治——CSS-in-JS或组件级样式。像styled-components、emotion这类方案，在SSR场景下会把首屏组件的样式自动收集并内联到返回的HTML里，相当于天然实现了Critical CSS。如果项目本来就在用CSS Modules配合SSR，也可以结合used-styles这类库，在服务端只注入当前路由实际用到的样式文件，从源头减少CSS体积。
Next.js中的实践与效果验证
Next.js从某个版本起已经内置了类似的优化，开发者几乎不需要额外配置。如果你想更精细地控制，可以在next.config.js中调整：
// next.config.js
module.exports = {
experimental: {
// 优化CSS加载，减少关键请求链
optimizeCss: true
}
};对于自建SSR的React项目，一个实用的做法是在服务端渲染时，用styled-components的ServerStyleSheet收集样式并输出到HTML字符串中：
import { ServerStyleSheet } from 'styled-components';
import { renderToString } from 'react-dom/server';
function renderPage(App) {
const sheet = new ServerStyleSheet();
const html = renderToString(sheet.collectStyles(<App />));
const styleTags = sheet.getStyleTags(); // 拿到内联样式字符串
sheet.seal();
return { html, styleTags };
}拿到styleTags后，把它拼进返回的HTML模板head部分即可。这样首屏样式随HTML一次性到达，无需额外请求。
验证优化效果要用数据说话。打开Chrome DevTools的Lighthouse面板，优化前通常会看到渲染阻塞资源列表里列着CSS文件；优化后这个列表应该清空，对应的指标关注FCP（首次内容绘制）和LCP（最大内容绘制）。也可以在Network面板中勾选Slow 3G限速，直观对比优化前后的白屏时长。一般来说，关键CSS控制在14KB以内（TCP初始拥塞窗口的大小）是最理想的，超出部分说明首屏样式本身需要瘦身了。
最后提醒两个常见的坑：一是内联样式无法被浏览器缓存，如果关键CSS体积过大，反而会让每次HTML请求都携带冗余数据，所以提取之后务必控制体积；二是使用了异步加载非关键CSS时，要处理好友好的降级体验，避免样式切换造成明显的布局跳动（FOUC），可以给异步加载加一个短暂的过渡，或者在关键CSS中保留基础布局规则，让首屏和完整样式之间的差异尽量小。
Critical CSSReact性能优化渲染阻塞修改时间：2026-09-13 05:24:28