背景本文接上一篇：在上文中，我们了解了chunks的三个字段的含义以及每个字段对应的行为。今天是练习。只需修改几行配置，即可达到数百毫秒的优化效果。正文我的项目迭代了一年多，中间的打包配置一直没怎么改。毕竟没有问题，速度也不错。正好老板最近要搞指标，要求各个项目组分析性能数据，提供优化方案，做性能优化。不分析就不知道了。一旦我分析它，我很快就会看到问题所在。看包分析结果：脑海中闪过一个画面：几乎所有的三方依赖都链接在一起，写的页面根据路由进行路由。loading也都放在一起了，真是养眼啊。。。于是去看代码配置：改正前的原配置：constOnBoard=React.lazy(()=>import('@/页面/板载'));constmenuData=MenuItemTypes[]=[{title:'onboard',path:'/onboard',meta:{showInMenu:false},children:[{component:OnBoard,//...},//...]},//...];constAppRouter=()=>{//...const{el,routes}=getRoutes(menuData);//...return(}>{el}//...);};constApp:React.FC<>=()=>{//...return;};constAppContainer=()=>();好像没什么问题。我看了一下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:{测试:/[\\/]node_modules[\\/]@ant-design[\\/]/,priority:15,},styles:{test:/\.(scss|css)$/,minChunks:1,reuseExistingChunk:true,enforce:true,priority:20,},},},}，好像没什么问题。..构建后html中的脚本乍一看似乎没问题...此时，修改chunks配置的比较：chunks:all包分析：加载时间和入口文件最初加载的脚本文件：chunks:async:除了入口脚本数量、总体积和加载时间发生变化外，脚本数量几乎没有变化：all:8async:4。区别在于大文件的体积不同。因为这个大文件对加载时间有影响。回过头来看，这是一场由maxChunks错误配置引起的大屠杀。更正配置后，结果立竿见影。根据不同场景合理拆分根据自己的情况，选择更合适的打包策略。all的优点是可以共享代码。提供all可能特别强大，因为这意味着即使在异步和非异步块之间也可以共享块。如果选择这种模式，如果使用h2协议，并行下载，可能会有更好的效果。async会帮助你合并一些包，但它也会产生更少的请求。需要根据实际情况进行测试，选择最合适的打包策略。还有一种切分策略：基于路由的切分和基于组件的切分打包的情况会有所不同。对比下面两张图：和：在实际场景中，这两种类型并没有严格区分，可以一起使用。比如一般情况下，一个页面是一个模块，它的子页面也是一个模块，两者是分开的。即更接近于这种模型：当然在一些特殊的场景下，也可以拆分一些功能组件，比如播放器组件，代码块组件等，此时的组件会单独打包，只有当用过的。这是另外一个话题，里面有很多细节，本文就不过多介绍了。综上所述，还是需要根据不同的场景选择不同的打包策略，才能达到最有效的效果。webpack还提供了详细的文档：https://webpack.docschina.org...实际使用的时候可以去看看。就这些了，希望对大家有所启发。谢谢。
