CSS框架本身不拖慢网页，但不当使用会因冗余样式、阻塞渲染、运行时生成和@import瀑布链而显著降低性能；需通过按需引入、PurgeCSS、SSR内联关键CSS、预编译合并及现代构建优化来解决。
CSS工具与框架本身不直接拖慢网页，但不当使用会显著增加资源体积、阻塞渲染、延长首屏时间。
打包体积与冗余样式是主要瓶颈
像Bootstrap、Tailwind CSS这类框架默认包含大量未使用的CSS规则。未启用tree-shaking或按需引入时，可能加载数百KB的无用样式。例如完整引入Bootstrap CSS（约200KB），而实际只用到按钮和网格，90%以上为冗余代码。
- 使用PurgeCSS（Tailwind推荐）或UnCSS自动移除未使用的CSS
- Bootstrap建议改用@import按需导入组件，如只引入_buttons.scss和_grid.scss
- 避免在构建后手动删CSS——易出错且不可持续，应通过配置实现自动化精简
CSS-in-JS方案需警惕运行时开销
Styled-components、Emotion等会在客户端动态生成并注入样式表。首次渲染时触发CSS字符串拼接、哈希计算、DOM操作，对低端设备或复杂页面有可感知延迟。
- 服务端渲染（SSR）配合extractCritical可将关键CSS提前内联，避免FOUC
- 开启Emotion的speedy: true（生产环境默认启用）以跳过部分样式校验
- 避免在render函数中动态创建styled组件——会导致重复注册和样式表膨胀
@import与网络瀑布链加剧加载延迟
传统Sass/Less中多层@import会串行请求CSS文件（尤其跨域CDN时），形成网络瀑布。一个@import "theme.scss"可能隐式拉取10+子文件，阻塞主样式表解析。
立即学习“前端免费学习笔记（深入）”；
- 构建阶段全部预编译为单个CSS文件，禁用浏览器端@import
- 用PostCSS插件（如postcss-import）替代原生@import，在打包时完成合并
- 关键CSS（如首屏布局）内联至，非关键部分异步加载（loadCSS模式）
现代工具链已大幅收窄性能差距
Vite + Lightning CSS、Next.js内置CSS优化、Astro的Scoped CSS零运行时等新方案，让框架开销趋近于手写CSS。重点不在“该不该用”，而在“怎么配”。
- 启用CSS压缩（cssnano）、Brotli压缩、HTTP/2推送关键CSS资源
- 用Chrome DevTools的Coverage面板实时查看未执行CSS占比
- 对比Lighthouse报告中“Eliminate render-blocking resources”项，验证优化效果
基本上就这些。工具不是性能敌人，配置失当才是根源。合理裁剪、提前内联、规避运行时生成，CSS框架完全可兼顾开发效率与加载体验。
