开启成长之旅！这是我参与「日新计划 12 月更文应战」的第1天
布景：
因为项目中运用monorepo来改动了项目结构，分出了两个包ui-components、common-lib，全体搬迁完成后，跑独自项意图build发现，first-load-js bundle size比改造项目之前还要大
重构之前：
重构之后：
随后运用webpack-bundle-analyzer剖析，发现了以下几个问题：
- 分出来的这两个包，作为依靠被打入
_app bundle，但未对这两个包进行tree-shaking导致许多未被运用的包被打进来。
- 有些组件并未做懒加载处理
tree-shaking 公共包
运用sideEffects：false：
sideEffects：false的意义：设置在确认无副作用的包 packag.json 中，webpack 在剖析依靠时就会去辨认 package.json 中的副作用符号 (sideEffects)，以跳过那些未被运用且不包括副作用的导出模块。
-
ui-components都是展示组件，能够确认无副作用，故能够设置。 -
common-lib多为公共办法，且在 ESLint 等规矩的加持下，不会存在具有副作用的办法被tree-shaking的情况，故能够设置。
sideEffects: true
sideEffects: false
组件懒加载
因为运用 next.js 结构，该结构可运用next/dynamic做到动态引进然后到达组件懒加载的效果，所以主要对事务中Modal等popUp组件，这种不需要立即在页面上展示的组件进行处理。对一些能够做懒加载的进行优化：
对 app.tsx 引进改动
import { xxx } from '@helper/index'=>import { xxx } from '@helper/request'
lodash 是否需要做优化
lodash 全部引进
lodash 按需引进 ↓ 5%
结论
不推荐优化：
- 优化起伏很小 5%
- 代码中会用到一些链式调用，例如 _.chain()，因为链式会包括 lodash 中其他办法，所以该链式办法不支持运用按需引进，做替换本钱较高。
- 不清楚会不会有类似问题，但是本钱较高，故去除该优化zhuanlan.zhihu.com/p/349260482
Lighthouse测验
优化前
优化后
总结
本文意图是如何经过webpack-bundle-analyzer并结合事务剖分出优化点，经过分包把page、first-load-js bundle的包巨细减小，以减少加载时间。优化起伏不大，主要是总结出优化思路、验证概念。
参考资料
Next.js的Babel及拆包优化 –
分包王！优化项目体积减少20%！ –
干货！我是如安在一线大厂实践webpack优化的 –
【NextJS】一文了解 NextJS 并对功能优化做出最佳实践 –
Your Next.js Bundle Will Thank You
为什么 Webpack tree shaking 失效了？
你的Tree-Shaking并没什么卵用
tree shaking问题排查指南
