移动端CSS默认阻塞渲染，须异步化：内联首屏Critical CSS，非关键CSS用media="print"+onload或preload注入；工具链自动提取（如critters/vite-plugin-critical），配合PurgeCSS/UnoCSS减体积，合理设置缓存头。
移动端 CSS 加载阻塞渲染，必须异步化处理
移动端首屏白屏时间对用户留存影响极大，而 <link rel="stylesheet"> 默认是**渲染阻塞资源**：浏览器会暂停构建 DOM 和绘制，直到 CSSOM 构建完成。这意味着哪怕只有一小段未优化的 CSS，也可能让首屏卡住几百毫秒。
- 关键路径上避免使用
@import—— 它会触发串行请求，且无法被预加载器识别 - 不要把所有样式打包进一个
main.css再全量加载；拆分出「首屏关键 CSS」（Critical CSS）内联到<head>中 - 非关键 CSS（如页面底部、交互后才显示的模块、主题切换样式）用
rel="preload"+onload注入，或通过media="print"+ JS 切换media="all"
如何提取并内联 Critical CSS？别手写，用工具链自动化
人工判断哪些 CSS 属于首屏是不可靠的，尤其在组件化、SSR 或动态路由项目中。推荐在构建流程中集成提取逻辑，而非发布前手动拷贝。
- Webpack 项目可用
critical插件（配合puppeteer模拟 viewport 截取首屏样式）或critters（更轻量，纯 AST 分析，支持 SSR 输出） - Vite 用户优先选
vite-plugin-critical，它能在 dev 阶段模拟提取，避免上线才发现漏样式 - 提取后生成的内联
<style>块需加data-critical标记，方便后续 JS 清理或调试 - 注意：提取结果随 HTML 结构和 viewport width 变化，
mobile: 375px和tablet: 768px应分别提取，不能共用同一份
CSS 文件本身要压缩，但别盲目启用 Brotli 或 gzip 就以为万事大吉
压缩算法只是传输层优化，如果 CSS 文件体积过大、选择器冗余严重、或包含大量未使用的 UI 框架样式（比如只用了 Button 却引入了整套 Ant Design CSS），再好的压缩也救不了首屏速度。
- 用
purgecss或unocss（推荐后者）做按需生成 —— 尤其适合 Tailwind 或原子类项目，可将 200KB 的 CSS 压到 10KB 以内 - 禁用
@font-face的font-display: swap不解决 CSS 阻塞，但它能缓解 FOIT；真正要动的是字体文件本身的加载时机：用rel="preload"提前拉字体，但仅限关键文字（如 logo 字体），正文用系统字体兜底 - 慎用 CSS-in-JS 库（如 styled-components）的“服务端注入”模式：若未正确分离 critical styles，很容易把整页样式都塞进 HTML，反而增大 TTFB
/* 示例：用 media="print" 实现非关键 CSS 的无阻塞加载 */ <link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'"> <noscript><link rel="stylesheet" href="non-critical.css"></noscript>
移动端 CSS 加载最易被忽略的一点：**CSS 文件的 HTTP 缓存头设置是否合理**。很多团队设了 Cache-Control: public, max-age=31536000，却忘了更新 HTML 中的 <link> 版本号（比如没加 ?v=2.3.1 或用 contenthash），导致用户永远拿不到新样式。这比加载慢更隐蔽，也更难排查。
立即学习“前端免费学习笔记（深入）”；
