打包体积太大，先看依赖再谈压缩
有人问我打包体积怎么降，我一般先反问一句：你确定体积是被压出来的吗。打包体积太大怎么优化，顺序是先找是谁贡献了体积，再谈压缩。压缩是最后一步，不是第一步。
我见过太多人一上来就开各种压缩选项，结果体积只降了一点点，因为大头根本不在那里。
前提：打包体积太大怎么优化，先分清属于哪种问题
一种是首次下载大，用户要等；另一种是体积极小但请求极碎，用户也要等。
判断方法是看请求列表：如果主文件很大，是第一种；如果一堆小文件，那其实是拆包问题，去调分块策略更对路。
第一步：找出体积排前几名的模块
构建工具都能输出一份体积构成，按大小排序看前几名。
只看前几名就够了。通常几个大依赖占掉了大部分体积，把一个换掉或者挪走，比优化几十个小模块加起来还多。
动作：导出一次体积构成，把那几个大块的名字记下来。
第二步：逐个问「这个依赖真的需要吗」
这是最有效的一步，而且和压缩无关。
很多体积是这么来的：为了一个小功能引入了一整个库；同一个功能的两个库同时存在；某个库只在很偏的一个页面用过，却被打进了主包。
动作：对着排前面的依赖问三个问题——用了几次、能不能自己写、能不能只在需要时才加载。三个问题里有一个答案是「能」，就值得动手。
第三步：检查有没有重复打包
同一个库出现在多个分块里，用户就要多下一份。
这类问题不会在体积构成里显眼地跳出来，得主动找。表现是总体积比各个分块单独看时感觉的要大。
动作：搜一下公共依赖是不是被固定到了单独分块，没有的话就固定一个。
第四步：把不急的东西挪出首屏，最后才动压缩
有些依赖体积不小，但只有少数路径才用得到。
把这些改成按需加载，首屏体积立刻下来。注意挪的时候别把首屏真正需要的东西也一起挪走了。
动作：从体积构成里挑一个大且使用频率低的，改成按需加载，然后测一次首屏。
前面几步做完，剩下的体积才轮到压缩与格式选项。这一步的收益取决于前面清理得干不干净，前面没清，压缩只是在压一堆本来就不该在里面的代码。
容易卡住的两个点
第一个是改完本地没变化。多半是看了缓存里的旧产物，重新构建一次再看。
第二个是体积降了但首屏没变快。这说明你压的是非首屏部分，方向没错但对用户没感觉，回头去看首屏那几个大块。
体积不会自己失控，是被一次次「先装上再说」堆起来的。
我现在的习惯是：装一个新依赖之前，先想一秒它有多大、用几次。这一秒不能阻止你装，但能阻止你装完就忘。等下次回头看列表的时候，至少记得哪些是临时用的。
体积治理是习惯问题，不是一次性任务。做完一轮清理，如果不改掉随手装的习惯，过一段时间还会回到原点。
配合的做法是定期看一眼体积构成，不用很频繁，但要看。看完有变化就处理，没变化就跳过，成本很低。
打包体积太大怎么优化，最后拼的不是压缩技巧，是你有没有养成看依赖的习惯。
常见问题
Q：打包体积太大怎么优化，第一步做什么？
A：先导出体积构成，看排前几名的模块。定位之后再决定是替换、移除还是改成按需加载，比直接开压缩有效得多。
Q：压缩选项开了为什么体积没降多少？
A：因为大头通常不是压缩率的问题，而是有不该打进来的依赖。先清理依赖，压缩才有效果。
Q：体积降了但页面没变快是什么原因？
A：很可能降的是首屏用不到的部分。用户只为首屏那部分等待，所以要优先处理首屏里的大依赖。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」