Webpack 分包优化首屏加载

开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第1天

 背景：

由于项目中使用 monorepo来改变了项目结构，分出了两个包ui-components、common-lib，整体迁移完成后，跑单独项目的build发现，first-load-js bundle size比改造项目之前还要大

重构之前：

重构之后：

随后使用webpack-bundle-analyzer分析，发现了以下几个问题：

1. 分出来的这两个包，作为依赖被打入_app bundle，但未对这两个包进行tree-shaking导致很多未被使用的包被打进来。
2. 有些组件并未做懒加载处理

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%

结论

不推荐优化：

1. 优化幅度很小 5%
2. 代码中会用到一些链式调用，例如 _.chain()，因为链式会包含 lodash 中其他方法，所以该链式方法不支持使用按需引入，做替换成本较高。
3. 不清楚会不会有类似问题，但是成本较高，故去除该优化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问题排查指南