CSS工具与框架可用于性能敏感项目，关键在于克制选型与配置：PostCSS轻量高效，Tailwind配合PurgeCSS可减小体积，Bootstrap需模块化导入，避免CSS-in-JS运行时开销，并重视样式计算复杂度与真实指标验证。
CSS工具与框架在性能敏感项目中并非不能用，关键在于选型、配置和使用方式是否克制。
轻量级工具更适配性能敏感场景
PostCSS 本身不增加运行时开销，仅在构建阶段工作，搭配 cssnano、autoprefixer 等插件可实现高效压缩与兼容性处理。相比 Sass/Less 的完整预处理器功能，它按需启用，体积可控。Tailwind CSS 虽然默认生成大量类，但通过 PurgeCSS（v3+ 已整合为 content 配置） 可精准剔除未使用的样式，最终产物往往比手写 CSS 更小、更集中。
- 启用
content配置扫描 HTML/JSX 文件，避免全量打包 - 禁用不必要的插件（如 @tailwind/forms 在纯静态页中可省略）
- 避免在
@layer utilities中无节制扩展自定义类
框架类方案需警惕“隐式膨胀”
Bootstrap、Foundation 等传统 CSS 框架自带完整组件体系与重置样式，即使只引入单个按钮，也可能连带加载栅格、表单、动画等无关代码。其 CSS 文件常超 100KB（未压缩），对首屏渲染构成明显压力。
- 改用模块化导入：如 Bootstrap 5 的 SCSS partials，只 @import 需要的组件
- 避免 CDN 全量引入，优先走构建流程做 tree-shaking
- 慎用依赖 JS 的交互组件（如 dropdown、modal），它们会额外增加 JS 包体积与执行开销
运行时 CSS-in-JS 方案通常不推荐
Styled-components、Emotion 等在客户端动态生成样式，虽支持主题与作用域隔离，但带来三重负担：JS 解析执行耗时、样式字符串拼接开销、服务端渲染（SSR）时需同步注入 style 标签。在 LCP、CLS 等核心指标敏感的项目中，这类成本往往得不偿失。
立即学习“前端免费学习笔记（深入）”；
- 若必须用，启用 Emotion 的
css+styled编译时提取（@emotion/babel-plugin） - 禁用开发环境外的 sourceMap 和 css 校验（如 emotion 的
enableSourceMaps） - 避免在组件内部频繁调用 css() 创建动态样式
性能验证不能只看文件大小
压缩后 CSS 文件小 ≠ 实际渲染快。需关注关键路径上的样式计算复杂度：过多嵌套选择器、通配符（*）、过度依赖 :nth-child 或 :has()，都会拖慢浏览器样式计算与重排。工具链再先进，也掩盖不了低效写法。
- 用 Chrome DevTools 的 “Rendering” 面板开启“Paint flashing”和“Layout Shift Regions”
- 检查 Elements 面板中 computed styles 是否存在大量 inherited 或 cascade-heavy 规则
- 用 web.dev/measure 实测 CLS、FCP、LCP，对比不同方案下的真实用户指标
基本上就这些。工具是手段，不是答案；框架是起点，不是终点。性能敏感项目的 CSS 策略，核心是“可知、可控、可测”，而非一味拒绝抽象。
