2026 年 7 月一个客户说包体已经拆过了，从 2.1 兆降到 600K，首屏还是 2.8 秒。我打开 DevTools 一看，600K 里有 400K 是首屏根本用不到的东西，只是被放在了主包里。
拆包解决的是什么
它解决下载量，让首屏不用等全部 JS 下完。但首屏时间不只取决于下载，还取决于解析、执行、以及依赖的先后顺序。
一个 300K 的包，在 4 倍 CPU 降速下执行要一秒多。拆成三个 100K 的包并行下载，执行时间没变。
所以拆包只是第一步，关键是让主线程上只跑首屏需要的东西。
三种常见的拆错
第一种，把首屏依赖拆进了懒加载。按钮点击才加载的组件里，包含了首屏渲染要用的工具函数，结果首屏卡住等它。
第二种，拆得太碎。几十个小 chunk，每个都要一个请求，HTTP/2 下虽然能复用连接，但请求排队和依赖解析反而更慢。
第三种，vendor 全塞一个包。所有第三方库打成一个 1 兆的文件，首屏只用到其中一个，剩下全是白下。
加载顺序怎么排
首屏关键 chunk 用 modulepreload 提前拿，放在 head 里，让它和 HTML 并行。
非关键的用 defer，别用 async。async 的执行时机不确定，可能抢在关键脚本前面跑，造成页面空白。
runtime 和 manifest 内联到 HTML 里，省一个请求，也避免版本错配。
真正的大头往往不在业务代码
我们拆过十几个站，主包里最大的三样东西通常是：全量引入的工具库、图标库、polyfill。
工具库只用了两个函数，却把整个库打进来；图标库引了一千个图标，页面只用八个；polyfill 给现代浏览器也塞了一份。
这三样加起来能占主包的一半，砍掉比拆十次都有用。
怎么判断哪里该砍
用 bundle 分析工具看每个模块的体积占比，先砍排名前十的。
再用代码覆盖率看首屏执行了多少。我们见过首屏执行率 12% 的页面，意思是 88% 的 JS 白跑了。
最后在 4 倍 CPU 降速下测。桌面跑得欢的代码，在中端安卓机上可能是灾难。
一个可以立刻做的检查
打开 DevTools 的 Coverage 面板，录一次首屏加载，它会告诉你每个 JS 文件执行了多少、浪费了多少。
超过一半没执行的包，就是该拆或者该砍的。这个检查十分钟能做完，比看任何分析报告都直接。
一个判断
包体优化里，砍掉不用的代码比拆包收益大，排好加载顺序比压缩收益大，压缩只是最后一步。
很多团队把顺序做反了：先上压缩和 CDN，再研究拆包，最后才想起来问这些代码到底用不用。这个顺序应该倒过来。
元析智能
为软件公司做 SEO 和 GEO 优化