网站ip地址查询域名,从优化角度来建设网站,义乌建设局网站,wordpress 添加ico本文的目的在于简单的介绍webpack的优化功能配置#xff1a;splitChunks。 webpack5出于“开箱即用”的目的#xff0c;将大部分曾经要使用插件的功能集成到了config配置中#xff0c;因此用户只需要了解如何配置#xff0c;即可达到优化目的#xff0c;其中最常使用接触的…本文的目的在于简单的介绍webpack的优化功能配置splitChunks。 webpack5出于“开箱即用”的目的将大部分曾经要使用插件的功能集成到了config配置中因此用户只需要了解如何配置即可达到优化目的其中最常使用接触的配置是webpack.optimization.splitChunks。
一、拆分方法的比较
参考 Webpack常用知识点 说到拆分往往我们会有以下几个选择 动态引入import()、webpack.entry配置多个入口、 splitChunks拆分抽取公共代码 相比较而言
动态引入的拆分需要对一个个文件单独处理不能整体规划更适合写代码时考虑。配置多个入口大多时候没有此必要而且容易将公共模块重复打包拆分策略不一定好。splitChunks拆分1. 配置在打包时开发过程中可以不考虑。2. 可以整体考虑公共代码比如react / utils等公共包。3. 使用webpack-analyze有利于更具体看到打包后的效果。
二、如何使用
webpack官方文档 详解利用webpack的splitChunk拆分打包文件
splitChunks中提供了一些字段常用的有下列属性其他属性大多时候不需改动
chunks
分为all(推荐)async(默认)initial 区别在于打包时模块的合并策略。
all推荐不论是同步引入还是异步引入都会被合并打包。async和目前我们不设置任何配置的情况相同同步引入的模块会被一起打包而动态进入的模块是自动拆分到另一个包中。initial同步引入的模块会被合并抽取成新的包而异步引入的代码会被拆分成另一个包比如a.js和b.js一个动态引入react一个同步引入react这时候打包出来的就是vendors-react同步、react异步两个react包而不会合并这样就造成了浪费。
minSize
最小尺寸默认是30Kdevelopment 下是10k设置的越大满足该尺寸的chunk 数就会变少针对于提取公共 chunk 的时候不管再大也不会把动态加载的模块合并到初始化模块中当这个值很大的时候就不会做公共部分的抽取了。
minChunks
如果一个模块被多个chunk所引用的次数达到了minChunks指定的次数那么这个模块就会被打包成一个单独的chunk。但是因为我们的项目只有一个入口文件Webpack只会生成一个chunk这时minChunks就没有作用了因为打包结果只有一个chunk不需要进行代码分离。
maxInitialRequests
参考https://www.cnblogs.com/kwzm/p/10316217.html maxInitialRequests是splitChunks里面比较难以理解的点之一它表示允许【单个】入口并行加载的最大请求数之所以有这个配置也是为了对拆分数量进行限制不至于拆分出太多模块导致请求数量过多而得不偿失。 这里需要注意几点 入口文件本身算一个请求如果入口里面有动态加载得模块这个不算在内通过runtimeChunk拆分出的runtime不算在内只算js文件的请求css不算在内如果同时又两个模块满足cacheGroup的规则要进行拆分但是maxInitialRequests的值只能允许再拆分一个模块那尺寸更大的模块会被拆分出来 cacheGroups
cacheGroups缓存组是 webpack splitChunks 最核心的配置splitChunks的配置项都是作用于cacheGroup上的也就是cacheGroups缓存组可以继承和覆盖来自 splitChunks.* 的任何选项。 接下来我们也是主要使用这个配置去拆分合并代码。
priority
拆分优先级webpack首先会遍历依赖生成依赖树然后对单个模块打包最后再拆分合并。这个属性可以决定一个模块同时属于多个合并规则的时候将合并进哪个文件内。
reuseExistingChunk
如果该chunk包含的modules都已经另一个被分割的chunk中存在那么直接引用已存在的chunk不会再重新产生一个
test
当test为函数时返回true/false并且接收两个参数module和chunks module每个模块打包的时候都会执行test函数并且传入模块 module 对象module 对象包含了模块的基本信息例如类型、路径、文件 hash 等 chunks是当前模块被分到哪些chunks使用module 跟 chunks 关系可能是一对一或者多对一。
module.exports {//...optimization: {splitChunks: {cacheGroups: {vendors: {test(module, chunks) {//...return module.type javascript/auto;}}}}}
};三、具体实现
修改完配置之后我们可以通过webpack-analyze看到打包出来的具体效果衡量自己的优化程度。 在next中就是如下配置
const withBundleAnalyzer require(next/bundle-analyzer)({enabled: process.env.ANALYZE true,
});module.exports withTM(withBundleAnalyzer(withImages(withAntdLess(nextConfig))));npm run analyzer一般而言没有改动过的Next自带的配置如下从next.config中打印出来的数据
{emitOnErrors: true,checkWasmTypes: false,nodeEnv: false,splitChunks: {chunks: [Function: chunks],cacheGroups: { {framework: {chunks: all,name: framework,test: [Function: test],priority: 40,enforce: true},lib: {test: [Function: test],name: [Function: name],priority: 30,minChunks: 1,reuseExistingChunk: true} },maxInitialRequests: 25,minSize: 20000},runtimeChunk: { name: webpack },minimize: true,minimizer: [ [Function (anonymous)], [Function (anonymous)] ]
}想要增加分包策略只需要像如下代码在next暴露出的config中配置 webpack(config, { webpack, isServer }) {try {if (!isServer) {const cacheGroups config.optimization.splitChunks.cacheGroups;console.log(cacheGroups)}} catch (e) {console.error(webpack cacheGroups error: ,e);}return config;}我的主要目的在于优化项目的首包也就是app.js所以主要查看的也是这个包。 首先打印出项目的打包文件如图假装有图 分析也许是受限于maxInitialRequests或者其他的原因react / mobx等包都没有拆分出app的包须知这种固定依赖往往可以放在CDN中很久不变动要是每次都跟着app包重新下载不利于CDN利用和首屏渲染。 故第一份优化配置如下 拆分公共依赖库antd / mobx / react / moment / lodash等等当然后续还可以拆分其他的模块。 const cacheGroups config.optimization.splitChunks.cacheGroups;// 1.mobxcacheGroups.antd {name: antd,test: /[\\/]node_modules[\\/](antd|ant-design)[\\/]/,enforce: true,chunks: all,};// 2.工具类cacheGroups.vendors {name: vendors,test: /[\\/]node_modules[\\/](mobx|axios|lodash|moment)[\\/]/,enforce: true,chunks: all,priority: 20,};// 3.utilsconfigcacheGroups.utils {name: utils,test: /[\\/]src[\\/]utils[\\/]/,enforce: true,chunks: all,priority: 20,};拆分后可见打出来三个新的包antd 、vendors、utils项目的整体大小少了0.6M如果觉得antd的包过大也可以再使用maxSize限制或者细化test正则。
接下来再分析app的页面看到某个模块下引入的配置文件基本上占用了一半的大小这个配置文件是在一个大的activity文件夹下的多个小活动中的config.js。这是因为之前为了在服务器端渲染的时候能够获取到配置数据所以在_app.js引入造成的问题随着后续的需求展开这里的影响可能会越来越大因此必须得想个办法拆分出去。 想要把这一部分的包拆分出去一开始考虑了几个方法
import动态引入分割。cacheGroup中添加代码分割的规则。不能直接使用test是因为文件夹下有很多文件一旦使用test会把所有文件都打包进来不符合要求把这部分配置集中到另一个文件夹内这样可以使用test去识别分割。以上办法都不行的话就把配置代码从_app中移出来放到组件里面去动态处理生成。
方法一
一开始写了一个类似下方这样的动态引入代码但是在mobx数据初始化时才会进行下载无法获取到配置数据。
await ConfigRes.then((Config) {const ConfigResModule ConfigRes.default;
});方法二
经过尝试最后把test的名称正则改成只识别配置文件夹下的config.js文件。 优先级不能填太高优先级填的高的话activity下方所有活动的文件都会被打包进来有使用和没有使用的文件都放在了一起这样反而无法达到减负的目的。因此优先级填最低这样可以使“未被划分进其他包、最后只能留在app.js包”中的这一些activity数据抽取出来。 再做一层保险设置maxSize以免以后配置了太多活动导致这个包过大。
cacheGroups.activity {name: activity,test: /[\\/]src[\\/]activity[\\/].*[\\/]config.js/,enforce: true,chunks: all,priority: -30,maxSize:200000,
};方法三
方法二其实比较繁琐但是这样做可以使开发可以不去关注打包信息只关注自己要开发的代码而不用把代码挪过来挪过去。
方法四
方法二已实现后暂时没有考虑。
四、数据比对
需要做性能测试。
五、安全考虑
可能要经过压测和稳定性测试以及性能测试看看是不是真的有效。
