关于umi项⽬打包之后体积⼤问题
概述
⼀个项⽬打包之后发现包⾮常的⼤，达到了惊⼈的10MB，别⼈打包都是⼏百K、2，3MB的体积，我的项⽬有问题毒瘤
查看每⼀个打包之后的⽂件，发现了俩毒瘤：js和async.js
它们俩竟然超过了7MB，为什么呢？
分析毒瘤
运⾏umi⾃带的包模块结构分析⼯具analyze，查看项⽬每个模块的⼤⼩
命令yarn analyze或npm run analyze
analyze介绍请查看umi
运⾏之后会看到如下⼀个界⾯，很直观：包越⼤⽐例越⼤
⽐如我这⾥就能看到有3个很⼤的包：BizCharts.js和xlsx.js和antd中的BizCharts.js
其他的相对来说还算是正常
左侧⾯板能够进⾏筛选你要查看的包
可以看到这俩兄弟在这⾥
简单介绍⼀下上⾯3中size：
Stat：压缩转换之前的⽂件⼤⼩
Parsed：最终输出的尺⼨⼤⼩（我们真正的就是看这个）
Gzip：经过gzip压缩之后的⼤⼩
解决⽅案
通过umi的webpack-chain的API修改webpack配置进⾏处理：chainWebpack
umi⽂件位置如图
我的代码配置如下
chainWebpack(config){
<({
optimization:{
minimize:true,
splitChunks:{
chunks:'async',
minSize:30000,
minChunks:2,
automaticNameDelimiter:'.',
cacheGroups:{
vendor:{
name:'vendors',
name:'vendors',
test:/^.*node_modules[\\/](?!ag-grid-|lodash|wangeditor|react-virtualized|rc-select|rc-drawer|rc-time-picker|rc-tree|rc-table|rc-calendar|antd) .*$/,
chunks:"all",
priority:10,
},
virtualized:{
name:"virtualized",
test:/[\\/]node_modules[\\/]react-virtualized/,
chunks:"all",
priority:10
},
rcselect:{
name:"rc-select",
test:/[\\/]node_modules[\\/]rc-select/,
chunks:"all",
priority:10
},
rcdrawer:{
name:"rcdrawer",
test:/[\\/]node_modules[\\/]rc-drawer/,
chunks:"all",
priority:10
},
rctimepicker:{
name:"rctimepicker",
test:/[\\/]node_modules[\\/]rc-time-picker/,
chunks:"all",
priority:10
},
ag:{
name:"ag",
test:/[\\/]node_modules[\\/]ag-grid-/,
chunks:"all",
priority:10
},
antd:{
name:"antd",
test:/[\\/]node_modules[\\/]antd[\\/]/,
chunks:"all",
priority:9
},nginx部署前端项目
rctree:{
name:"rctree",
test:/[\\/]node_modules[\\/]rc-tree/,
chunks:"all",
priority:-1
},
rccalendar:{
name:"rccalendar",
test:/[\\/]node_modules[\\/]rc-calendar[\\/]/,
chunks:"all",
priority:-1
},
rctable:{
name:"rctable",
test:/[\\/]node_modules[\\/]rc-table[\\/]es[\\/]/,
chunks:"all",
priority:-1
},
wang:{
name:"wang",
test:/[\\/]node_modules[\\/]wangeditor[\\/]/,
chunks:"all",
priority:-1
},
},
lodash:{
name:"lodash",
test:/[\\/]node_modules[\\/]lodash[\\/]/,
chunks:"all",
priority:-2
},
bizcharts:{
name:"bizcharts",
test:/[\\/]node_modules[\\/]bizcharts[\\/]/,
chunks:"all",
priority:10
},
xlsx:{
name:"xlsx",
test:/[\\/]node_modules[\\/]xlsx[\\/]/,
chunks:"async",
priority:10
}
}
}
}
});
//过滤掉momnet的那些不使⽤的国际化⽂件
config.plugin("replace").use(require("webpack").ContextReplacementPlugin).tap(()=>{ return[/moment[/\\]locale$/,/zh-cn/];
});
}
关于这些配置项的描述，可以参考这篇或者这篇
之前打包：5.7MB
现在打包：3.8MB
减少了近2MB，效果挺好的
服务端使⽤gzip进⾏压缩
1. 项⽬安装plugin依赖
yarn add compression-webpack-plugin -D
2. 在config/config.js⽬录下进⾏配置
const CompressionWebpackPlugin =require('compression-webpack-plugin');
const prodGzipList =['js','css'];
chainWebpack: config =>{
v.NODE_ENV==='production'){// ⽣产模式开启
config.plugin('compression-webpack-plugin').use(
new CompressionWebpackPlugin({
// filename: ⽂件名称，这⾥我们不设置，让它保持和未压缩的⽂件同⼀个名称
algorithm:'gzip',// 指定⽣成gzip格式
test:new RegExp('\\.('+ prodGzipList.join('|')+')$'),// 匹配哪些格式⽂件需要压缩
threshold:10240,//对超过10k的数据进⾏压缩
minRatio:0.6// 压缩⽐例，值为0 ~ 1
})
);
}
}
3. 进⾏打包
yarn build
打包之后可以发现dist⽬录下会出现压缩之后的⽂件
注意：不是将整个dist进⾏打包了，⽽是将每⼀个dist中的⽂件打包了，所以⽂件数量变成了原来的两倍
4. 部署
我们项⽬使⽤的服务器是nginx
这个时候如果去访问的话，会发现拿到的还是没有经过压缩的版本，需要先到nginx的配置⽂件下添加⼀⾏配置，配置完了后悔⾃动寻压缩过的资源。
gzip_static on;
5. 访问之后能够发现已经是压缩之后的版本了，成功。
关于使⽤宝塔进⾏部署项⽬的点击

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。