直接用 cssnano 的压缩率不等于真实体积收益，因其压缩的是整个 CSS 文件，而非首屏渲染实际使用的部分；应监控未 gzip 的原始 CSS 体积及关键 CSS 内联内容大小，并通过 size-limit 或 Webpack 插件在 CI 中做字节级断言。
为什么直接用 cssnano 的压缩率不等于真实体积收益
很多团队在 CI 中加一行 cssnano --dry-run 就以为能监控 CSS 体积，结果上线后发现 LCP 没改善，甚至变差。根本原因是：压缩率 ≠ 渲染关键路径体积。CSS 文件里可能包含大量未使用的媒体查询、冗余的嵌套规则、或被 JS 动态注入但未触发的样式块——这些都会被 cssnano 压缩，却对首屏渲染无实质帮助。
真正要测的是「首次渲染时实际解析/应用的 CSS 字节数」，这需要结合构建产物 + 页面加载上下文。CI 流水线里最可行的折中方案，是测量「生产构建后未 gzip 的 CSS 文件体积 + 关键 CSS 提取后的内联部分大小」。
- 只监控
dist/*.css文件大小（未压缩原始体积），比压缩后体积更稳定、可比性更强 - 若项目用了
critters或mini-css-extract-plugin提取关键 CSS，必须单独统计index.html中<style>标签内容长度 - 避免在 CI 中运行 Puppeteer 测量真实渲染体积——太慢、不稳定、易受网络/资源加载干扰
用 size-limit 在 CI 中做体积断言
size-limit 是少数专为 CI 场景设计的体积检测工具，它不依赖运行时环境，只读取构建产物文件并做字节级断言，适合放进 GitHub Actions 或 Jenkins Pipeline。
配置示例（size-limit.config.js）：
立即学习“前端免费学习笔记（深入）”；
module.exports = [
{
path: "dist/main.css",
limit: "120 KB",
gzip: false // 关键：关掉 gzip，避免 Node 版本差异导致校验失败
},
{
path: "dist/index.html",
limit: "8 KB",
include: ["<style>"]
}
];- 必须设
gzip: false：不同 CI runner 的 Node zlib 实现有微小差异，开启 gzip 容易误报 -
include支持正则或字符串，用于提取 HTML 中特定片段（如关键 CSS 内联内容）再测体积 - 它会在 CI 失败时明确输出「超出 limit X bytes」，而不是笼统报错，方便快速定位是哪个 CSS 文件膨胀了
Webpack 构建阶段直接暴露 CSS 体积信息
如果你用 Webpack，不需要额外工具也能拿到精确体积——在 webpack.config.js 的 stats 配置里启用 assets 和 children，再配合自定义插件把 CSS 资源大小写入 JSON 文件供 CI 读取。
简化的插件逻辑（放入 plugins 数组）：
class CssSizeReporterPlugin {
apply(compiler) {
compiler.hooks.done.tap('CssSizeReporter', (stats) => {
const cssAssets = stats.toJson().assets.filter(a =>
a.name.endsWith('.css') && !a.name.includes('map')
);
const sizes = cssAssets.map(a => ({ name: a.name, size: a.size }));
require('fs').writeFileSync('css-sizes.json', JSON.stringify(sizes, null, 2));
});
}
}- 这个 JSON 可被后续 CI 步骤用
jq或简单脚本解析，比如：jq '.[0].size' css-sizes.json - 注意过滤掉
.css.map文件，它们体积波动大且与渲染无关 - 如果使用
css-minimizer-webpack-plugin，确保它在插件执行前已运行完毕（即插件放在 plugins 数组末尾）
GitHub Actions 中如何设置体积增长告警而非硬性失败
突然卡死在某个体积阈值容易阻塞 PR，尤其当第三方 UI 库升级导致 CSS 增长时。更合理的方式是：只对「相比 main 分支同路径文件的增长率」做告警。
示例步骤（在 jobs.build.steps 中）：
- name: Compare CSS size with main
run: |
if [ "${{ github.head_ref }}" != "main" ]; then
git checkout main
npm run build
MAIN_SIZE=$(stat -c%s dist/main.css)
git checkout ${{ github.head_ref }}
npm run build
PR_SIZE=$(stat -c%s dist/main.css)
GROWTH=$(echo "scale=2; ($PR_SIZE - $MAIN_SIZE) / $MAIN_SIZE * 100" | bc)
if (( $(echo "$GROWTH > 5" | bc -l) )); then
echo "⚠️ CSS grew by ${GROWTH}% — please check new dependencies or unused rules"
echo "::warning::CSS size increased by ${GROWTH}%"
fi
fi- 这个逻辑绕开了“绝对阈值”，适应项目演进节奏；5% 是经验值，可根据团队接受度调整
- 用
stat -c%s而非ls -l，避免因 ls 输出格式差异导致解析失败 -
::warning::是 GitHub Actions 的日志指令，只标黄不中断流程，适合渐进式治理
体积监控最容易被忽略的一点：它必须和构建产物生成路径强绑定。如果 output.path 在不同环境（dev/staging/prod）里指向不同目录，或者用了动态 hash 导致文件名不可预测，所有体积断言都会失效。先统一产物结构，再谈监控。
