内联关键css可将fcp压至300ms内，但须基于真实设备视口（如iphone se 375×667）动态提取首屏实际应用规则，过滤@font-face、@keyframes及不匹配媒体查询，并置于最顶部、体积≤14kb、禁用@import。
直接内联首屏关键CSS是压缩首次内容绘制（FCP）最有效的手段之一，但前提是它真能覆盖首屏真实渲染所需、体积合理、位置正确，且不破坏后续样式逻辑。
关键CSS必须精准提取，不能靠猜或截取
手动写容易漏掉:hover、@media (prefers-color-scheme: dark)、伪元素等实际参与首屏渲染的规则；用宽屏视口（如1920×1080）提取后用于手机端，常导致大量未命中@media (min-width: 1200px)规则塞进HTML，体积虚高、命中率低。
- 模拟真实首屏视口：移动端优先，设viewport为width: 375, height: 667（iPhone SE）或width: 414, height: 896（iPhone 12）
- 工具链推荐：Vite项目用vite-plugin-critical，Webpack用critters，静态站可用critical CLI
- 输出后必须minify，并剔除@font-face、@keyframes、display: none元素相关样式——它们不参与首屏绘制
内联位置和顺序比内容本身还关键
哪怕critical CSS写得再准，只要它后面紧跟一个未处理的，浏览器就会暂停渲染，等那个外部CSS加载完。白屏就卡在这一步。
- 前面不能有任何、<script>或含@import的<style></script>
- 避免在内联
体积控制在14KB以内，否则得不偿失
HTTP/2下单个TCP包的理想大小约14KB（gzip后）。超过这个值，HTML主文档变大，TTFB上升，解析开销增加，反而拉长FCP。
- 目标体积建议≤14KB，开发阶段可设硬性校验（如用critters配置maxSize）
- 超限常见原因：混入非首屏组件样式、未过滤字体声明、保留了未使用的动画帧
- 服务端无法缓存内联样式，体积越大，每次HTML更新传输成本越高
非关键CSS要延迟加载，但不能闪屏或失效
删掉会导致响应式断点、暗色模式、打印样式全部丢失；直接动态插入又易FOUC。关键是让浏览器“先跳过，后激活”。
- 推荐方案：
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">——默认不加载，onload触发后才启用 - 更可控做法：DOMContentLoaded后用JS动态插入，或配合requestIdleCallback避免抢占主线程
- 不要用rel="preload" without onload逻辑：缺少
as="style"和onload切换rel，预加载不会参与CSSOM构建，等于白忙
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
