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

布景：

因为项目中运用monorepo来改动了项目结构，分出了两个包ui-components、common-lib，全体搬迁完成后，跑独自项意图build发现，first-load-js bundle size比改造项目之前还要大

重构之前：

Webpack 分包优化首屏加载

重构之后：

Webpack 分包优化首屏加载

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

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

tree-shaking 公共包

运用sideEffects：false：

sideEffects：false的意义：设置在确认无副作用的包 packag.json 中，webpack 在剖析依靠时就会去辨认 package.json 中的副作用符号 (sideEffects)，以跳过那些未被运用且不包括副作用的导出模块。

  • ui-components都是展示组件，能够确认无副作用，故能够设置。
  • common-lib多为公共办法，且在 ESLint 等规矩的加持下，不会存在具有副作用的办法被tree-shaking的情况，故能够设置。
sideEffects: true

Webpack 分包优化首屏加载
Webpack 分包优化首屏加载

sideEffects: false

Webpack 分包优化首屏加载

Webpack 分包优化首屏加载

组件懒加载

因为运用 next.js 结构，该结构可运用next/dynamic做到动态引进然后到达组件懒加载的效果，所以主要对事务中Modal等popUp组件，这种不需要立即在页面上展示的组件进行处理。对一些能够做懒加载的进行优化：

Webpack 分包优化首屏加载

对 app.tsx 引进改动

import { xxx } from '@helper/index'=>import { xxx } from '@helper/request'

Webpack 分包优化首屏加载

lodash 是否需要做优化

lodash 全部引进

Webpack 分包优化首屏加载
Webpack 分包优化首屏加载

lodash 按需引进 ↓ 5%

Webpack 分包优化首屏加载

结论

不推荐优化：

  1. 优化起伏很小 5%
  2. 代码中会用到一些链式调用，例如 _.chain()，因为链式会包括 lodash 中其他办法，所以该链式办法不支持运用按需引进，做替换本钱较高。
  3. 不清楚会不会有类似问题，但是本钱较高，故去除该优化zhuanlan.zhihu.com/p/349260482

Lighthouse测验

优化前

Webpack 分包优化首屏加载

优化后

Webpack 分包优化首屏加载

总结

本文意图是如何经过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问题排查指南