移动端CSS默认阻塞渲染，须异步化：内联首屏Critical CSS，非关键CSS用media="print"+onload或preload注入；工具链自动提取（如critters/vite-plugin-critical），配合PurgeCSS/UnoCSS减体积，合理设置缓存头。

移动端 CSS 加载阻塞渲染，必须异步化处理

移动端首屏白屏时间对用户留存影响极大，而 默认是**渲染阻塞资源**：浏览器会暂停构建 DOM 和绘制，直到 CSSOM 构建完成。这意味着哪怕只有一小段未优化的 CSS，也可能让首屏卡住几百毫秒。

• 关键路径上避免使用 @import —— 它会触发串行请求，且无法被预加载器识别
• 不要把所有样式打包进一个 main.css 再全量加载；拆分出「首屏关键 CSS」（Critical CSS）内联到 中
• 非关键 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 阶段模拟提取，避免上线才发现漏样式
• 提取后生成的内联 块需加 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 的无阻塞加载 */

移动端 CSS 加载最易被忽略的一点：**CSS 文件的 HTTP 缓存头设置是否合理**。很多团队设了 Cache-Control: public, max-age=31536000，却忘了更新 HTML 中的 版本号（比如没加 ?v=2.3.1 或用 contenthash），导致用户永远拿不到新样式。这比加载慢更隐蔽，也更难排查。