2026 年 8 月我们给一个官网做关键 CSS 内联，首屏渲染时间从 1.6 秒提前到 1.2 秒。改动只有一件事：把首屏需要的样式写进 HTML 的 head 里，剩下的样式延后加载。
为什么 CSS 会阻塞渲染
浏览器要先拿到 CSS 才能确定页面长什么样，所以在 CSS 下载完成之前，它不会渲染任何内容。
一个 200KB 的样式文件，在 3G 网络下要下两秒。这两秒里用户看到的是白屏，即使 HTML 已经到了。
关键 CSS 怎么抽
关键 CSS 指的是渲染首屏可见区域所必需的样式。写一个工具扫一遍页面，把首屏元素的样式挑出来，通常只有十几 KB。
原则是宁少勿多。内联的每一 KB 都拖慢 HTML 的传输，收益抵不过成本。
我们的经验是控制在 4KB 以内，压缩后 2KB 左右。超过这个数，说明把不该内联的样式也塞进去了。
剩余样式怎么异步加载
常见写法是 preload 加 onload 切换成样式表，或者用媒体查询的 hack。
这两种做法都有个副作用：样式加载完之前，页面可能闪一下无样式的内容。所以关键 CSS 必须覆盖首屏，否则会看到明显的跳动。
现在更稳的做法是用构建工具自动处理整个流程，别手写。
三个常见坑
第一个，内联太多。有人把整份样式表塞进 HTML，结果 HTML 变成 300KB，首屏更慢。
第二个，首屏判断错。工具按视口高度判定首屏，但用户实际看到的第一屏和工具算的不一样，尤其是移动端。要人工看一眼。
第三个，动态样式。主题切换、深色模式这类样式不在静态 CSS 里，内联会漏掉，导致闪烁。
怎么验证
改之前和改之后各测一次，看两个数：首次内容绘制和最大内容绘制。
测的时候一定要禁用缓存，并且用移动端配 4G 降速。桌面端加缓存测出来的差异很小，容易误判。
还要看真实用户的变化。实验室数据能证明改动生效，CrUX 才能证明用户感知到了。
一个折中做法
如果站点有几百个页面模板，逐个内联不现实。我们通常只对三类页面做：首页、核心产品页、投放落地页。
这三类页面吃掉了大部分首屏流量，其余页面用正常的样式表加载。这个取舍比全站上构建工具简单得多。
一个判断
关键 CSS 内联适合首屏简单、样式集中的页面，比如官网首页、落地页、文章页。
对于交互复杂、首屏依赖大量组件样式的应用，内联效果有限，优先做代码分割和延迟加载。
这件事的收益在几百毫秒量级，不是决定性的。但如果首屏本来就卡在 3 秒附近，这半秒能把它推进合格线。
元析智能
为软件公司做 SEO 和 GEO 优化