CSS加载慢不一定是网络问题，主因是渲染阻塞、HTTP/1.1串行请求、未压缩、缓存失效及合并不当；HTTP/2下仍建议合理合并并按需动态引入。
为什么 CSS 文件加载慢不一定是网络问题
浏览器解析 HTML 时遇到 会阻塞渲染，直到 CSSOM 构建完成。即使文件体积不大，若存在多个小 CSS 文件、HTTP/1.1 下的串行请求、或未启用压缩，都会显著拖慢首屏时间。
- HTTP/1.1 默认每域名最多 6 个并发连接，10 个
.css文件可能排队等待 - 未开启 Gzip/Brotli 压缩时，
main.css从 120KB 变成 320KB（原始大小），传输耗时翻倍 - CDN 未缓存或缓存头设置错误（如
Cache-Control: no-cache）会导致每次重新拉取
合并 CSS 文件时要注意哪些依赖顺序
CSS 合并不是简单 cat 拼接，顺序错乱会导致样式被覆盖或失效。关键原则是：通用重置 → 基础组件 → 布局 → 页面级特有样式 → 覆盖类（如 .theme-dark）。
- 把
normalize.css放最前，避免后续规则被用户代理样式干扰 -
button.css和form.css应早于dashboard.css，否则按钮在仪表盘里可能漏样式 - 慎合入
@import的文件——它会触发额外请求，且必须放在文件顶部，合并后容易位置错位 - 构建工具如 Webpack/Vite 默认不处理
@import内联，需配css-loader或启用importLoaders
压缩 CSS 不能只靠 minify，还要关掉 devtool 注释
很多构建配置启用了 sourceMap 或保留注释（如版权、调试说明），这些内容在生产环境毫无用处，却占体积 15%~30%。
- Webpack 中确保
optimization.minimizer使用CssMinimizerPlugin，并设removeComments: true - Vite 生产构建默认压缩，但若在
vite.config.ts中写了build.cssCodeSplit: true，会拆出多份 CSS，反而增加请求数 - 手动压缩可用
cleancss -o main.min.css main.css，但注意它默认不处理url()中的相对路径，需加--relative-to ./src - 检查压缩后是否误删了
/*# sourceMappingURL=...*/——如果没关 sourceMap，这个注释应被移除；如果开了，则要保留且路径正确
HTTP/2 或 HTTP/3 下还该合并 CSS 吗
HTTP/2 支持多路复用，单个大 CSS 不再比多个小 CSS 明显更快；但合并仍有价值，只是优先级下降。
立即学习“前端免费学习笔记（深入）”；
- 仍建议合并：减少解析开销（每个
都要走 DNS + TCP + TLS + HTTP 头解析） - 避免过度合并：把登录页专用样式（
auth.css）和后台管理样式（admin.css合并，会导致非登录用户也下载无用代码） - 更优解是「按路由拆分 + 预加载」：Vite 中用
import('/src/css/auth.css').then(...)动态导入，配合 - 确认服务器已启用 Brotli（比 Gzip 平均再省 15%），Nginx 配置中要有
brotli on;和brotli_types text/css;
实际项目中最常被忽略的是缓存策略和动态引入时机——CSS 文件即使只有 20KB，若 Cache-Control 设为 max-age=0，每次都是 200 请求；而一个本可异步加载的暗色主题 CSS，硬塞进主包，会让所有用户多下 8KB。
