前端打包优化经验：包体积不是只靠压缩就能降下来的

提到前端打包优化，很多人的第一反应是：

• 开 gzip
• 开 brotli
• 做压缩
• 分包

这些都重要，但它们更多是结果优化，而不是根因优化。

项目包体积越来越大，并不是因为压缩没做好，而是因为依赖结构、代码组织和资源策略本身就不够克制。

先弄清楚体积到底是怎么长起来的

一个前端包变大，常见来源通常有：

• 引入了过大的第三方库
• 首屏加载了本不该首屏加载的代码
• 公共依赖拆分不合理
• 图片、图标、字体资源过重
• 工具函数或组件重复打进多个 chunk

如果不先定位来源，只盯着构建配置调参数，优化通常很快进入瓶颈。

不要把“功能能跑”当成依赖引入标准

很多包体积问题，都是从一行 import 开始的。

比如为了一个简单功能，引入一个很重的库；或者只需要某个小工具函数，却把整个工具库一起打进来。

这类问题最常见，也最容易被忽视，因为功能层面完全没问题。

但从长期看，依赖使用要有一个基本原则：

引入的不是“功能”，而是“长期成本”。

路由级拆分是最基本的一步

如果一个页面用户根本没访问，理论上它相关的代码就不应该在首屏里出现。

这也是代码分割最直接的价值。

对于多页面或后台系统来说，路由级拆分通常是最先该做的事情。它并不是锦上添花，而是把不必要的首屏负担拿掉。

组件级懒加载也要谨慎

有些团队在发现包大之后，会开始把很多组件都做成懒加载。

这不是不行，但要分场景。

如果组件本身很轻、用户几乎一定会看到，那为了“拆得更碎”而懒加载，收益未必大，反而会增加请求碎片和复杂度。

更适合懒加载的通常是：

• 富文本编辑器
• 图表模块
• 大型表格
• 低频弹窗
• 管理后台高级筛选面板

也就是说，真正重、真正低频的模块优先拆。

图片和图标常常是被低估的体积来源

不少人会盯着 JS 包，却忽略了静态资源。

实际项目里下面这些都很常见：

• 首页大图未压缩
• 多个页面重复加载大图资源
• 只需要几个图标，却引入整套图标包
• 字体文件过大

这些问题加起来，用户感知可能比 JS 包还明显。

公共代码不是越集中越好

做公共 chunk 拆分时，一个常见误区是：只要公共就全抽出来。

问题在于，如果一个公共 chunk 非常大，而其中大部分内容其实只服务少数页面，那它反而会成为新的负担。

所以公共代码拆分不是追求“集中”，而是追求“合理复用”。

分析工具一定要用

如果一个项目已经明显变重，最不应该做的事情就是靠猜优化。

这时最有效的办法通常是：

• 看 bundle 分析图
• 看每个 chunk 的组成
• 找出最大的第三方依赖
• 找出重复出现的模块

很多优化方向只要一可视化，就会非常明显。

真正长期有效的优化，往往是结构优化

例如：

• 避免滥引第三方库
• 限制公共模块膨胀
• 拆分高成本页面
• 减少重复资源
• 让低频功能延后加载

这些事情比单纯调构建参数更费脑子，但通常也更有长期价值。

写在最后

打包优化不是一场“把构建工具调到最极致”的比赛，而是一次对项目结构的体检。

压缩、分包、缓存当然重要，但真正决定包体积的，通常还是代码和依赖本身的组织方式。只要结构合理，很多优化会自然发生；如果结构混乱，再多构建技巧也只是延后问题爆发。