背景
本文接上篇：
上文中， 咱们理解了 chunks 三个字段的含意， 以及每个字段对应的行为。
明天是实际篇。
批改短短几行配置， 就达到了数百毫秒的优化成果。
注释
我的这个我的项目， 迭代一年多了， 两头打包配置也没没怎么改过， 毕竟也没什么问题， 速度也还能够。
刚好最近老板要搞指标， 让每个项目组剖析性能数据， 给优化计划，做性能优化。
不剖析不晓得， 一剖析， 很快啊， 马上就看出了问题, 看包剖析后果：
脑海里霎时闪过一张图：
简直所有的三方依赖都打在了一起， 写好的页面按路由加载也都打到了一起, 几乎辣眼睛...
于是就去看了一下代码配置：
修改前
原始配置：
const OnBoard = React.lazy(() => import('@/pages/onboard'));const menuData = MenuItemTypes[] = [ { title: 'onboard', path: '/onboard', meta: { showInMenu: false }, children: [ { component: OnBoard, // ... }, // ... ] }, // ...];const AppRouter = () => { // ... const { el, routes } = getRoutes(menuData); // ... return ( <BasicLayout {...matchedRoute.meta}> <Suspense fallback={<Spin />}> <Route path="/" exact component={MyDashboard} /> {el} </Suspense> // ... </BasicLayout> );};const App: React.FC<> = () => { // ... return <AppRouter />;};const AppContainer = () => ( <Router history={history}> <Provider store={store}> <Locale> <App /> </Locale> </Provider> </Router>);看起来没什么问题。
看了一下 webpack 配置：
optimization: { splitChunks: { chunks: 'all', minSize: 30000, minChunks: 1, maxAsyncRequests: 5, maxInitialRequests: 3, cacheGroups: { vendor: { test: /[\\/]node_modules/, enforce: true, priority: 5, }, antd: { test: /[\\/]node_modules[\\/]antd[\\/]/, priority: 10, }, antdIcons: { test: /[\\/]node_modules[\\/]@ant-design[\\/]/, priority: 15, }, styles: { test: /\.(scss|css)$/, minChunks: 1, reuseExistingChunk: true, enforce: true, priority: 20, }, }, }, },看起来貌似也没什么问题。。。
build 之后 html 中的脚本， 乍一看如同也没故障...
<script type="text/javascript" src="/main.75a8d9f8.js"></script><script type="text/javascript" src="/chunk.styles~main.eaa8f358.js"></script><script type="text/javascript" src="/chunk.antdIcons~main.6ee35491.js"></script><script type="text/javascript" src="/chunk.vendor~main.aa82abbc.js"></script><script type="text/javascript" src="/chunk.main.db1b67a1.js"></script>这种状况下， 批改 chunks 配置的比照：
chunks: all
包剖析：
加载工夫以及入口文件初始加载的脚本文件：
chunks: async:
<script type="text/javascript" src="/main.64245819.js"></script> <script type="text/javascript" src="/chunk.main.d6a简直没有什么变动， 一时间， 开始狐疑是不是受了其余配置的影响，就去认真去找了一下， 果然：
速度批改了配置。
修改后:
chunks：all
optimization: { runtimeChunk: { name: 'manifest', }, splitChunks: { chunks: 'all', minSize: 30000, minChunks: 1, maxAsyncRequests: 5, maxInitialRequests: 3, cacheGroups: { vendor: { test: /[\\/]node_modules/, enforce: true, priority: 5, }, antd: { test: /[\\/]node_modules[\\/]antd[\\/]/, priority: 15, enforce: true, }, antdIcons: { test: /[\\/]node_modules[\\/]@ant-design[\\/]/, priority: 15, enforce: true, }, antdV: { test: /[\\/]node_modules[\\/]@antv[\\/]/, priority: 30, enforce: true, }, bizcharts: { test: /[\\/]node_modules[\\/]bizcharts[\\/]/, priority: 20, enforce: true, }, dplayer: { test: /[\\/]node_modules[\\/]dplayer[\\/]/, priority: 25, enforce: true, }, styles: { test: /\.(scss|css|less})$/, minChunks: 1, reuseExistingChunk: true, enforce: true, priority: 20, }, 'react-dom': { test: /[\\/]node_modules[\\/]react-dom[\\/]/, priority: 25, enforce: true, }, 'rc-components': { test: /([\\/]node_modules[\\/]rc-[a-zA-Z-]+[\\/])/, priority: 25, enforce: true, }, }, }, },很快啊， 马上就有了变动：
chunks: async
入口文件初始加载的脚本：
<script type="text/javascript" src="/main.572fc9fe.js"></script> <script type="text/javascript" src="/chunk.main.8c0dcc22.js"></script>除了入口脚本数量的变动， 总体积， 加载时长， 简直没有变动。
脚本数量的不同：
all: 8async: 4
区别就是， 大文件的体积不同， 对这个大文件的加载工夫有影响。
回头看， 这是一个 maxChunks 配置谬误引发的血案。
修改配置之后， 空谷传声。
依据不同场景正当的拆分
依据你的状况， 能够抉择更适宜的打包策略。
all 的劣势在于， 能共享代码。
Providing all can be particularly powerful, because it means that chunks can be shared even between async and non-async chunks.抉择这个模式， 如果你用的协定是h2, 并行下载，可能有比拟好的成果。
async 会帮你合并一些包，但产生的申请也会缩小。
须要依据理论状况做测试， 抉择最适宜的打包策略。
还有一种宰割策略：
基于路由的宰割 vs 基于组件的宰割
打包的状况也会不同， 比照如下两幅图：
和：
理论的场景中， 不会严格的辨别这两种， 能够一起用。
比方， 个别状况下， 一个页面就是一个模块， 它的子页面， 也是一个模块， 而这两者是离开的。
也就是更贴近这个模型：
当然一些非凡的场景下， 也能够对某些性能组件去宰割， 比方播放器组件， 代码块组件等。
这个时候的组件， 会独自成包， 应用的时候才去加载。
这是另一个话题了， 也有很多细节在外面， 本篇就不过多介绍。
总结
具体， 还是要依据不同的场景，抉择不同的打包策略， 来达到最有成果。
webpack 也提供了具体的文档：
https://webpack.docschina.org...
理论用到的时候能够去看看。
内容就这么多，心愿对大家有所启发。
谢谢。