文章目录
目录导航
快速定位文章内容
正文
前端包体积开始失控后，我一般会先砍哪几类东西
很多前端页面首屏变慢，并不是因为逻辑复杂到算不动，而是资源在不知不觉里越堆越多。尤其项目做久了以后，图表库、富文本编辑器、图片、字体、埋点 SDK、监控脚本都会一点点长进来，最后打包体积和下载成本一起失控。
我一般不会一上来就盯业务代码
包体积变大时，我现在很少先去看组件里是不是多写了几行逻辑，因为真正占体积的大头，往往不是业务判断，而是这些东西：
- 很重但加载时机不合理的第三方库
- 本来可以按需加载，却被整包引入的模块
- 分辨率过高或数量过多的图片资源
- 没有裁剪的字体文件
- 很早就注入，但用户根本不一定会用到的 SDK
所以我更习惯先问一句：到底是谁把包撑大了。
第一刀，我通常会先看大依赖
很多项目体积突然上涨，最常见的原因就是引入了重量级依赖，比如图表库、地图、编辑器、日期库、代码高亮库。
这类库不一定不能用，但我会先判断两件事：
- 它是不是首屏必须
- 它有没有更轻的引入方式
如果不是首屏必需，我通常会优先拆成动态加载。
const Editor = dynamic(() => import('./Editor'), { ssr: false, loading: () => <div>编辑器加载中...</div>, })
这一步对编辑器、图表和预览器这类模块尤其有效，因为很多用户并不会一进页面就立刻用到它们。
第二刀，我会排查是不是“整包搬运”
有些体积问题不是库太大，而是引入方式太粗暴。比如明明只用了一个方法，却把整套工具都拉进来了。
我现在会特别留意：
- 组件库是否真的按需加载
- 工具函数是否从入口整包引入
- icon 是否一次性打进很多个
- 样式文件是否把不需要的内容一起带进来
很多时候，包不是优化不了，而是没人回头看过引入方式。
第三刀，我会盯资源文件而不是只盯 JS
前端首屏慢，JS 只是其中一部分。图片和字体同样很容易把页面拖重。
我现在通常会先做这些判断：
- 首屏图片有没有必要这么大
- 背景图能不能改成更轻的格式
- 字体是否只保留真正用到的字重
- 是否可以先用系统字体兜底，再延迟加载品牌字体
很多项目明明代码不重，但首屏依然慢，就是因为资源文件下载成本太高。
第四刀，我会审视第三方 SDK 的加载时机
埋点、客服、监控、可视化分析这些 SDK 很容易越接越多。问题不是它们不能接，而是很多站点会在页面一打开时全部注入。
我现在更倾向于按场景加载：
- 用户真正进入相关页面再加载
- 交互发生后再初始化
- 非核心脚本延后到首屏完成后再执行
这样做的核心不是省几 KB，而是把最关键的首屏时间先让出来。
第五刀，我会接受“不是所有东西都该首屏拥有”
性能优化做到后面，本质上是在做取舍。并不是每个功能都必须在页面打开那一刻就全部准备好。
我现在会更愿意把页面拆成几个层次：
- 首屏必须立即可用的部分
- 可以稍后出现的增强能力
- 只有少数用户会触发的重功能
一旦这样分层，很多优化思路就会自然清楚，哪些该预加载，哪些该懒加载，哪些该彻底挪走。
结语
前端包体积失控，很多时候不是单点问题，而是项目在迭代里不断累积的结果。比起一上来就改细枝末节，我现在更习惯先找大头依赖、看引入方式、查资源文件，再去判断加载时机。先砍最重的那几类东西，优化通常会更快见效。