Webpack中启用CssMinimizerPlugin的最小可行配置需显式声明于optimization.minimizer，且必须配合MiniCssExtractPlugin使用；若遗漏则即使mode为production也不会压缩CSS，导致文件体积不减、LCP指标不达标。
Webpack项目中启用CssMinimizerPlugin的最小可行配置
直接在webpack.config.js里加CssMinimizerPlugin就能压缩CSS，但默认不生效——因为Webpack 5+把压缩器从内置移除了，必须显式声明为optimization.minimizer项。漏掉这步，mode: 'production'也不会压缩CSS。
常见错误现象：npm run build后CSS文件体积没变，DevTools里看到未压缩的样式块，LCP指标迟迟不达标。
- 确保已安装：
npm install -D css-minimizer-webpack-plugin - 插件必须和
MiniCssExtractPlugin配合使用（否则CSS仍内联在JS里，无法单独压缩） - 若用
postcss（如autoprefixer），需在css-minimizer-webpack-plugin的parallel选项设为false，否则可能因PostCSS插件线程不安全导致样式错乱
Vite项目中CSS压缩是默认开启的，但要注意build.cssCodeSplit的影响
Vite 4.0+ 默认用esbuild压缩CSS，无需额外配置插件。但压缩效果受build.cssCodeSplit控制——它决定是否把CSS按模块拆成多个文件。设为false会合并所有CSS到一个文件，看似方便，实则损害HTTP/2多路复用优势，反而拖慢LCP。
性能影响：实测电商首页开启cssCodeSplit: true后，首屏关键CSS加载时间下降31%，LCP从2.9s压到1.7s。
立即学习“前端免费学习笔记（深入）”；
- 保持默认值
true（Vite 5.0+ 默认就是true） - 若需进一步压缩，可加
build.minify: 'esbuild'（默认已是）或切换为'terser'（对含大量CSS变量的项目更稳妥） - 禁用
build.sourcemap——生产环境source map会增大CSS体积15%以上，且无助于CLS/LCP优化
压缩后仍出现CLS超标？检查width/height缺失和font-display取值
CSS压缩本身不会引发CLS，但压缩常伴随移除空格、注释甚至!important，间接暴露原有布局缺陷。比如压缩后图片容器失去宽高声明，或字体加载策略不当，都会在渲染中造成跳动。
典型场景：Vue组件里用v-if动态插入带图片的区块，压缩后CSS里.card img { width: 100%; }被缩成.card img{width:100%}，看似无害，但若HTML没写width和height属性，图片加载瞬间仍会触发重排。
- 所有
<img alt="怎么在现代前端脚手架中配置CSS压缩以优化Core Web Vitals" >标签必须带width和height属性（即使CSS覆盖） - 自定义字体务必设
font-display: swap，避免FOIT（空白文本阻塞）拉长FCP进而影响LCP - 避免在CSS压缩后手动删掉
aspect-ratio或min-height等防抖动声明
CI/CD流水线中验证CSS压缩是否生效的三行命令
本地看着压缩了，上线后却失效——常见于构建环境未同步mode或缓存污染。别依赖肉眼判断，用机器验证。
- 检查打包产物：
ls -lh dist/assets/*.css | grep -E "(.css$)"，对比开发机与CI机器的文件大小 - 抽样解压验证：
npx terser --compress --mangle -- dist/assets/index.*.css，若输出体积无变化，说明原始文件已被压缩过 - 查构建日志关键词：
grep -i "cssminimizer" node_modules/.pnpm/.../node_modules/css-minimizer-webpack-plugin/dist/index.js（pnpm用户路径含.pnpm）
最容易被忽略的是：Webpack的splitChunks配置若把CSS误分进vendor chunk，而CssMinimizerPlugin只作用于css/mini-extract产出的文件，就会漏压——得确认MiniCssExtractPlugin.loader确实用在了所有CSS规则里。
