@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 后的数字。










