所谓页面闪烁，专业上称为FOUC（Flash of Unstyled Content），指的是用户访问页面时先看到一段没有样式或者样式错乱的内容，几百毫秒后样式表加载完成，页面才恢复正常外观。这种体验非常糟糕，用户会感觉网站廉价且不稳定。闪烁的根源在于<link>标签引入的外链CSS是渲染阻塞资源，浏览器在样式表下载解析完成之前不会渲染任何已解析的内容，而一旦渲染时机与样式加载时机不同步，就会出现无样式内容先展示、随后跳变成有样式页面的现象。本文将详细分析这个问题的成因，并给出以关键CSS内联为核心的完整解决方案。
一、理解闪烁的成因：浏览器渲染流程与外链CSS的阻塞机制
要解决闪烁问题，必须先明白浏览器是如何渲染页面的。浏览器从网络收到HTML字节流后，会经历解析HTML构建DOM树、解析CSS构建CSSOM树、将两者合并生成渲染树、计算布局、绘制像素这样一条流水线。其中关键的一点是：CSSOM树构建完成之前，浏览器不会渲染任何内容。这是CSS被设计为渲染阻塞资源的原因，目的是避免用户先看到无样式内容再跳变。
既然CSS阻塞渲染理论上应该避免闪烁，为什么实际中还会出现FOUC呢？主要有几种情况。第一种是样式表放在了页面底部，浏览器边解析边渲染，先渲染出了无样式内容，之后样式才加载完成触发重排，典型的写法是把<link>标签放在</body>之前。第二种是使用了@import引入样式，@import会串行加载，CSS文件内部再@import其他文件时会造成请求链，延迟样式生效时间。第三种是网络慢或样式表体积大，白屏时间过长，用户感知为明显的卡顿与跳变。
用一段问题代码来说明。下面这种写法在网络稍慢的环境下几乎必然出现闪烁：
<!-- 问题写法：样式放在底部，且使用@import --> <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>闪烁示例</title> </head> <body> <h1>页面标题</h1> <p>一段正文内容</p> <link rel="stylesheet" href="/css/all.css"> </body> </html>
浏览器解析到<h1>和<p>时样式还没加载，部分浏览器会先绘制无样式内容，等底部样式表就绪后再重新绘制，用户就看到了一次明显的样式跳变。理解了成因，解决思路也就清晰了：要么让样式在首次绘制之前就绪，要么让首屏内容自带样式。
二、关键CSS内联：把首屏样式直接写进HTML
关键CSS（Critical CSS）指的是首屏渲染所必需的最小样式集合，通常包括头部导航、首屏区块、字体设置、基础布局等。把这些样式用<style>标签直接内联在HTML的<head>中，浏览器解析HTML时立即就能应用这些样式，首次绘制就是正确的样子，闪烁自然消失。而首屏之外的样式，比如页脚、折叠区域、弹窗组件，可以保持外链方式异步加载。
来看一个标准的实践写法：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>关键CSS内联示例</title>
<style>
/* 关键CSS：首屏必需的最小样式集合 */
body {
margin: 0;
font-family: "Microsoft YaHei", sans-serif;
background: #fff;
color: #333;
}
.header {
height: 60px;
background: #1a73e8;
color: #fff;
display: flex;
align-items: center;
padding: 0 24px;
}
.hero {
padding: 48px 24px;
text-align: center;
}
</style>
<!-- 非关键CSS异步加载 -->
<link rel="preload" href="/css/rest.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/rest.css"></noscript>
</head>
<body>
<header class="header">站点导航</header>
<section class="hero"><h1>首屏内容</h1></section>
<footer class="footer">首屏之外的样式走外链异步加载</footer>
</body>
</html>
这里用rel="preload"配合onload的方式实现了非关键样式的异步加载：preload让浏览器尽早开始下载但不阻塞渲染，下载完成后通过JavaScript把rel改回stylesheet使样式生效。<noscript>中的回退写法保证了禁用JavaScript的用户也能拿到完整样式，这是一个容易被忽略但非常重要的细节。
关键CSS的体积需要严格控制，一般建议控制在14KB以内，因为这是HTTP首次TCP拥塞窗口的大小，内联样式能随HTML第一次请求就完整到达。如果内联了几十上百KB的CSS，就失去了意义，反而拖慢了HTML本身的传输。提取关键CSS可以手动完成，也可以借助工具自动化，常用的工具有PurgeCSS、Critical、beastcrit等，其中Critical可以配合构建流程自动生成每页的关键CSS并注入HTML模板。
三、辅助优化手段：媒体查询拆分与加载顺序控制
除了关键CSS内联，还有一些辅助手段能进一步减少闪烁与白屏。第一个是利用媒体查询拆分样式表。<link>标签的media属性可以让样式只在特定条件下阻塞渲染，例如打印样式就不应该阻塞屏幕渲染：
<!-- 打印样式：不阻塞屏幕渲染 --> <link rel="stylesheet" href="/css/print.css" media="print"> <!-- 宽屏样式：窄屏设备上不阻塞渲染 --> <link rel="stylesheet" href="/css/wide.css" media="(min-width: 1200px)"> <!-- 主样式：正常阻塞渲染，必须放在head中 --> <link rel="stylesheet" href="/css/main.css">
第二个手段是彻底避免@import。@import的问题在于它把串行请求藏在了CSS文件内部，浏览器要先下载外层CSS，解析后才发现还有内层CSS要下载，往返延迟翻倍。正确做法是把所有@import改写成多个<link>标签并列写在<head>中，让浏览器并行下载。如果一定要在构建产物中合并CSS，请使用打包工具在构建阶段完成合并，而不是运行时用@import拼装。
第三个手段是给首屏图片和字体设置合理的占位，避免样式加载后图片撑开导致的二次跳动。字体方面可以使用font-display: swap配合字体预加载，减少文字闪现替换的突兀感：
@font-face {
font-family: "CustomFont";
src: url("/fonts/custom.woff2") format("woff2");
font-display: swap; /* 先用回退字体渲染，字体就绪后替换 */
font-weight: 400;
}
综合来看，解决闪烁问题的完整策略是：关键CSS内联保证首屏首次绘制正确，非关键CSS异步加载不阻塞渲染，@import全部消除，打印与条件样式通过媒体查询隔离。这套组合拳在Lighthouse等性能审计工具中通常能把First Contentful Paint指标提升30%以上。
四、方案对比与注意事项
关键CSS内联并非没有代价，需要根据项目实际情况权衡。它的缺点主要有三点：一是内联样式无法被浏览器缓存，每次访问HTML都要重新传输这部分CSS，对于用户回访频繁的站点会增加流量；二是如果站点有多个页面且首屏各不相同，每个页面需要独立提取关键CSS，构建流程复杂度上升；三是HTML与样式耦合，维护成本略有增加。对于小型站点或首屏统一的单页应用，内联收益明显；对于超大型多页站点，可能只需要保证样式表放在head中并压缩合并，就能达到可接受的效果。
还有几个实操细节值得注意。提取关键CSS时务必在真实视口尺寸下测试，移动端和桌面端的首屏范围差异很大；异步加载非关键CSS时一定要写<noscript>回退，否则禁用JS的用户会看到永久无样式的页面；内联的关键CSS应当经过压缩，去掉注释与多余空白；如果使用了服务端渲染框架，很多框架（如Next.js）已经内置了关键CSS自动提取能力，优先使用框架自带方案而不是自己造轮子。
最后建议用Chrome DevTools的Performance面板和Network节流功能验证效果，将网络限速到Slow 3G后刷新页面，观察是否还存在无样式内容闪现。只有模拟了弱网环境的测试才算真正完成，因为闪烁问题在快速网络下往往被掩盖，而恰恰是网络慢的用户对体验问题最敏感。通过关键CSS内联加上非关键样式异步加载这套方案，页面闪烁问题可以得到彻底解决，首屏体验也会显著提升。