放在 会阻塞 HTML 解析与 DOM 构建，即使样式仅用于页面底部；media 属性可使非关键 CSS 异步加载，preload 可提前拉取关键 CSS，内联 CSS 应控制在 4–8KB（gzip 后）。
为什么
浏览器遇到 会立即发起 CSS 请求，并**阻塞后续 HTML 解析与 DOM 构建**，直到该 CSS 被下载、解析完成。哪怕样式表只用在页面底部，只要它在 中，整个 HTML 解析就会卡住 —— 这不是“加载慢”，而是“解析被强制暂停”。
- 关键点：
render-blocking行为由 CSS 资源本身触发，和位置无关；但放在会让阻塞提前发生 - 真实场景：一个 200KB 的
main.css在弱网下耗时 800ms，期间 DOM 树完全停在开始前 - 错误优化：把
搬到前？不行 —— 此时 DOM 已构建完，但 CSS 尚未就绪，会先闪现无样式内容（FOUC），且部分 JS 可能因getComputedStyle等依赖样式而执行异常
media 属性如何让非关键 CSS “不阻塞”
给 加上 media 属性（如 media="print" 或 media="(min-width: 1024px)"），浏览器会**异步加载该 CSS，不阻塞渲染** —— 直到媒体查询匹配才应用样式。这是原生、零配置、兼容性极好的解耦手段。
- 适用场景：
print.css、暗色主题dark-theme.css、桌面端专属布局desktop.css - 注意：
media="all"或省略media属性等同于阻塞式加载；media="screen"仍会阻塞（因为默认匹配） - 实操建议：把首屏不需要的组件样式（如模态框、图表库、后台管理页模块）单独拆出，用
media="(min-width: 0px) and (max-width: 0px)"占位，再用 JS 动态切换为"all"（需谨慎，仅限必要时）
如何用 preload 提前拉取关键 CSS
对首屏必需的 CSS（
比如 reset.css、critical.css），用 提前发起请求，再配合 onload 注入，可绕过默认的阻塞时机，实现更早的资源调度。
-
as="style"必须写，否则浏览器不会按 CSS 类型预加载，可能降级为普通fetch -
onload回调里要立即改rel，否则样式不会生效；同时设this.onload=null防止重复执行 - 兼容性：Chrome 50+ / Firefox 64+ / Safari 11.1+ 支持；IE 完全不支持，需靠
回退 - 别滥用：
preload不解决 CSS 解析耗时，只解决“请求发起晚”的问题；若 CSS 文件本身过大或含大量@import，仍会拖慢解析
CSS 内联与外部文件的权衡边界在哪
内联关键 CSS（Critical CSS）确实能消除 HTTP 请求，但超过 ~14KB 就可能触发移动端 Chrome 的“延迟解析”机制 —— 浏览器会把大块内联 CSS 暂存，等主线程空闲才解析，反而增加首次绘制延迟。
- 安全阈值：建议控制在
4–8KB（gzip 后），足够覆盖首屏文字、按钮、导航栏等基础样式 - 风险点：内联 CSS 无法被缓存，每次 HTML 更新都会重传；服务端渲染（SSR）中若动态生成内联样式，还可能破坏 HTTP/2 多路复用优势
- 替代思路：对小项目，用
内联核心规则 +异步加载剩余样式；对大项目，优先考虑media拆分 +preload关键路径
真正影响 CSS 解析速度的，从来不是“怎么加载”，而是“加载了什么”——冗余选择器、未 purge 的框架样式、嵌套过深的 SCSS 输出，这些才是解析器真正要花时间处理的东西。优化顺序永远是：先删代码，再调加载策略。
