17370845950

@import 是 CSS 体积优化的反面典型，会阻塞渲染、串行加载；应改用构建工具内联合并，关键样式内联 HTML，非关键样式用 media 属性或动态加载，并借助 purgecss 等工具

做 Tree-shaking。

用 @import 引入 CSS 是体积优化的反面典型

很多人误以为用 @import 可以“按需加载”或“拆分逻辑”，实际它会阻塞渲染，且无法并行下载。浏览器遇到 @import 时，必须先下载并解析完被引入的文件，才能继续处理后续样式，导致关键 CSS 加载延迟。更糟的是，多个嵌套 @import（比如 A.css → @import B.css → @import C.css）会形成串行请求链。

• 避免在主 style.css 中使用 @import 引入其他 CSS 文件
• 若需模块化管理，改用构建工具（如 PostCSS、Webpack）做 @import 内联 —— 即编译时展开合并，运行时只剩一个请求
• 开发期可保留 @import 提高可维护性，但构建后必须确保它不落地到 HTML 的 或最终 CSS 文件中

的加载行为直接影响首屏性能

默认情况下， 是渲染阻塞的，但可通过属性微调加载优先级和时机。重点不是“少引几个”，而是“什么时候引、怎么引”。

• 核心样式（如重置、布局、字体）必须内联进 HTML 的 标签，避免额外请求
• 非关键 CSS（如打印样式、主题切换样式、页面底部组件样式）加 media 属性，例如：
  ，浏览器不会立即下载
• 动态加载的 CSS（如某个弹窗打开后才需要的样式）不要写死在 HTML 中，改用 JS 动态创建 并插入 head，配合 onload 回调控制使用时机

构建阶段的 CSS 拆分与 Tree-shaking 很难靠手写实现

CSS 本身没有导出/导入语义，所谓“Tree-shaking”必须依赖工具链识别未使用的选择器。纯手工删代码不仅低效，还容易误删（比如 JS 动态添加的 class 对应的样式）。

• 启用 cssnano（PostCSS 插件）做压缩：去除空格、合并重复声明、转为简写等
• 用 purgecss 或 unocss 扫描 HTML/JS 模板，剔除未匹配的选择器；注意配置白名单（如 js-、is-active 等运行时 class 前缀）
• 避免全局污染式写法，例如 body * { ... } 或无限制的属性选择器，这类规则无法被工具安全删除
• 慎用 CSS-in-JS 库（如 styled-components）的“动态样式”功能，它可能生成大量散列类名，反而增大体积

字体、图标、背景图等资源常是隐藏的体积大户

很多人只盯着 .css 文件大小，却忽略 CSS 中引用的外部资源：WOFF2 字体动辄 100KB+，SVG 图标 inline 后可能比原文件还大，base64 编码的图片直接膨胀 33%。

• 字体只加载需要的字重和字符集，用 font-display: swap 避免 FOIT，但别把整套 Noto Sans 全引过来
• 图标优先用 SVG Sprite 或 内联，而非字体图标（Font Awesome 的 Web Font 方案已明显过时）
• 避免在 CSS 中用 url(data:...) 内联大图；小图标（
• 检查 background-image 是否指向了未压缩的 PNG / JPG，用 WebP 或 AVIF 替代，并配 @supports 回退

真正卡住首屏的往往不是 CSS 文件大小本身，而是它的加载方式和关联资源。很多项目把 CSS 压到 50KB 以下，却因一个 @import 或一张未优化的背景图，让关键渲染时间多等 800ms。优化得从网络请求链路出发，而不是盯着 gzip 后的数字。