关键CSS内联必须位于<head>中<meta charset>之后首个位置，禁用@import，体积压缩后≤1KB，仅包含首屏真实渲染所需样式，非首屏HTML应延迟注入而非display: none。
关键CSS内联必须紧贴后面
浏览器按顺序解析HTML，<style>标签的位置直接决定它能否抢在阻塞资源前生效。如果它被放在任何<link rel="stylesheet">之后，哪怕只隔一个<meta>或<title>，浏览器就会先暂停渲染去加载那个外部CSS。
常见错误现象：FCP没改善、甚至变差，DevTools里看到Parse HTML阶段卡在某个main.css请求上——说明关键CSS没抢到“首发位”。
-
<style>必须是<head>中第一个非<meta charset>的标签，顺序应为：<meta charset="utf-8">→<style>→ 其他 - 禁止在
<style>内部使用@import，它会触发同步网络请求，等价于新增一个阻塞点 - 如果用了
<link rel="preload" as="style">，它不能替代内联，只能辅助非关键CSS；预加载的样式仍需后续<link>挂载，无法参与初始渲染树构建
提取关键CSS不能靠截取main.css前10KB
手动剪切CSS文件开头部分，或用Webpack插件无差别打包src/css/index.css，大概率把@keyframes、@font-face、暗色模式媒体查询、display: none区块的样式全塞进去了——这些规则不参与首屏绘制，却白白增大HTML体积、拖慢TTFB。
真正有效的提取，必须基于真实视口和首屏DOM节点动态捕获：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用
critters（Vite/webpack）或criticalCLI驱动Puppeteer，模拟{ width: 375, height: 667 }（iPhone SE）访问页面 - 手动验证时禁用网络后刷新，还能正常显示的标题、按钮、轮播容器，其对应的选择器才值得保留
- CSS-in-JS生成的动态类名（如
jsx-abc123）识别率低，建议SSR时用renderStylesToString()序列化关键样式，而非依赖工具提取
内联体积超1KB反而拉长首屏时间
很多人以为“越多越快”，但实测表明：内联CSS从1KB涨到5KB，在3G弱网下会使HTML主文档传输延迟增加400ms以上，TTFB和初始解析都受影响。服务端也无法缓存这部分样式，每次HTML变更都得重传全部内联内容。
精简不是靠删代码，而是靠精准控制作用域：
- 登录页只需
.logo、.login-form、.submit-btn的基础尺寸、颜色、边距；动画、主题色切换、响应式断点全部剔除 - 剔除所有含
url()的声明（背景图、字体），这类资源改用<link rel="preload" as="image" crossorigin>提前调度 - 确保最终
<style>标签内容压缩后≤1KB（可用gzip预估体积，不要只看源码字符数）
非首屏HTML结构必须“零渲染”而非display: none
display: none只是不绘制，DOM节点照常创建、CSSOM照常计算、布局引擎照常处理——它仍占用内存、延长DOM构建时间，并可能触发无谓的重排。真正的优化是让这部分HTML根本不进入初始解析流。
实操上更有效的方式是延迟注入：
- 轮播图下方的推荐列表、评论区，用
<template id="recommend">包裹，初始不参与解析 - tab切换类内容，只保留当前激活tab的HTML，其余用
data-html属性暂存字符串，切换时再innerHTML挂载 - 避免在
<head>里放大量第三方<script>，尤其未声明async的统计脚本——它们虽不阻塞CSSOM，但会抢占主线程，间接拖慢样式计算
