事情是这样的，公司有个四年的 Vue2 老后台项目，打包出来的主包体积接近 2M。 每次打开都要白屏很久，弱网环境下用户经常直接放弃等待。产品提需求只说了一句：“页面打开有点慢，你抽空调一下”，没有给指标，也没预估工作量。
本来以为只是简单压缩图片、懒加载路由就能搞定。深入排查之后才发现一堆历史遗留问题：
- 大量第三方组件全量引入，没有做按需导入，很多组件全程没被页面使用；
- 全局一次性引入所有图标库，上千个图标全部打进主包；
- 接口请求没有做预加载和缓存策略，页面渲染同时并发十几个请求；
- 旧的静态资源没有 CDN，全部放在业务打包产物里面。
我利用下班碎片时间，分批改造：
- 图标库按需引入，剔除未使用图标；
- 路由组件做动态 import，拆分路由 chunk；
- 大图片压缩、转 webp，静态资源迁移到 CDN；
- 增加接口数据本地缓存，避免重复请求。
改造完之后，主包体积直接砍掉 62%，首屏加载时间从 3.2s 降到 0.9s。 产品测试完，只随口评价：嗯，页面打开快多了。完全不知道背后改了一整套资源加载逻辑。
直到后面迭代新需求，同事发现本地开发启动速度也变快，打包产物体积大幅缩小，才意识到这次优化的工作量。
核心优化要点
- 第三方 UI 库按需引入，避免全量打包
- 路由懒加载，按页面拆分代码块，减小首屏主包
- 图片资源压缩、格式转换，静态资源 CDN 托管
- 非强实时接口增加本地缓存，减少页面初始化请求
小提醒：这类包体积优化，上线前务必做多环境回归测试，防止按需引入之后出现组件丢失的隐藏 bug。
结尾
很多前端性能优化，最终给用户的感知只有 “页面变快”，改动是藏在底层的。业务侧很难感知背后的工作量。但这种沉淀，会长期降低项目迭代、上线的各种隐性成本。
