打包后各个模块的可视化工具
webpack-bundle-analyzer
// webpack.config.ts中配置(也就是你的webpack配置文件，可能各个项目的名称和后缀会不一样)
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
module.exports = {
plugins: [
new BundleAnalyzerPlugin();
]
}
打包过程中检测各个模块的打包时间工具
speed-measure-webpack-plugin
// webpack.config.ts中配置(也就是你的webpack配置文件，可能各个项目的名称和后缀会不一样)
// 这里面要注意一下，我们使用的时间检测插件并不是通过new运算符的方式引入到plugins里面，而是通过引入的方法将我们整个导出的webpack配置进行包裹
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();
const webpackConfig = smp.wrap({
plugins: [new MyPlugin(), new MyOtherPlugin()],
});
其实通过可视化工具以及打包模块的时间检测，我们基本可以看出来到底是哪一个模块在打包过程中花费的时间比较长，比如在我们的项目中，打包后的antd.css文件就占据了大头以及babel-loader在打包过程中花费的时间也比较久，那么对于项目本身的优化而言，我就可以优先从对于css文件的优化以及对于babel-loader的优化开始着手。
React组件懒加载
// 原先的路由组件模式
import Home from './Home';
<HashRoute bashname="/">
<Switch>
<Route path="/" component={Home}>
</Switch>
</HashRouter>
// 使用React懒加载方式的路由组件模式
import Home from './Home';
import React, { Suspense } from 'react';
<Suspense fallback={<p>Loading...</p>}>
<HashRoute bashname="/">
<Switch>
<Route path="/" component={async () => import('./Home')}>
</Switch>
</HashRouter>
</Suspense>
对比而言，我们可以看到懒加载方式下，我们在路由的最外层包裹了React提供的Susense组件来实现我们在路由组件切换的时候的过渡加载状态，并且将原先路由中直接引入组件的方式改为使用React.lazy的模式进行引入，懒加载模式最大的好处是可以帮我们优化首页的打开速度，并且在打包过程中我们也可以看到，不使用懒加载模式的情况下，我们的组件打包后其实是放到一个JS文件里面的，会导致单个文件的体积过大，而使用懒加载模式后，我们会发现打包后的JS文件从一个变为了多个，也就是分块的方式进行打包，只有当路由跳转到该页面后才会加载，而不会在项目运行初就全部进行加载
其实之所以会把懒加载放在优化的第一个，主要原因在于我当时在考虑优化的时候，优先考虑对于其他部分进行优化，引入了很多的webpack优化插件，但是效果不明显，有些甚至在引入之后出现了打包体积不减反增的情况，最后当我重新考虑优化方向并且将组件全部替换成了懒加载方式后，我的打包体积直接从13MB减少到了7MB，所以建议小伙伴们在尝试的时候最好先考虑一下自己项目中的模块引入等方面是否需要进行优化，然后再考虑对于webpack本身的优化。
实现按需引入
我们项目中使用的是antd的组件库，在原先的引入方式是在index.js文件中直接引入import 'antd/dist/antd.css';的方式来保证我们的组件样式，但是这样存在的一个问题在于我们使用的组件肯定是部分，但却引入了所有组件的样式，并且在打包后，由于并没有进行任何的优化，导致样式文件被作为一个整体打包，占据了很大的空间。
按需引入插件：babel-plugin-import
// 我们可以通过npm或yarn直接安装对应的依赖，然后再babel配置文件中添加相关配置即可
// .babelrc或babel.config.js
module.exports = {
plugins: [
[
'import',
{
libraryName: 'antd',
style: true, // 或者替换成style: css也可以
},
],
]
}
依赖和配置完成之后，我们就可以删除原先通过直接引入import 'antd/dist/antd.css';的方式，并且在打包后的可视化工具页面，我们可以看到原先作为一个整体被打包的antd.css现在被拆分成了一个个小的样式模块，实现按需引入。(PS：不过我们的项目在使用这个优化方式后，实际的体积并没有太多的减少，不知道大家的优化情况怎么样)
webpack内置的优化配置
除了引入一些优化插件以外，webpack本身也内置了优化相关的配置
module.exports = {
optimization: {
// 告知 webpack 使用 TerserPlugin 或其它在 optimization.minimizer定义的插件压缩 bundle。
// 我们可以引入诸如TerserWebpackPlugin或者OptimizeCSSAssetsPlugin等优化的插件
minimizer: [],
// 为每个入口添加一个只含有 runtime 的额外 chunk。此配置的别名如下：
// 在打包后会生成一个名字为runtime.b06ab0d37a82c9b06f15之类的js入口文件
runtimeChunk: {
name: 'runtime',
},
// 对于动态导入的模块，使用webpack v4+ 提供的全新的通用分块策略
splitChunks: {
}
}
}
对于webpack内置的优化配置，上面只列举了一些基本的配置项，感兴趣的小伙伴可以去webpack文档中查看更加全面的配置。
还有一个需要提及的点：
设置开始minimize之后，webpack就会使用minimizer中添加的相关插件进行打包过程中的优化，其中TerserPlugin插件可以帮助我们配置开启多进程并发运行打包，可以帮助我们提高构建速度，但是对于一些体积各方面都比较小的项目就不建议开启了，很有可能开启后反而增加了时间，起到反向优化的效果
webpack optimization配置
babel-loader的缓存优化
前面几个优化方向主要是针对于打包的体积优化，而这个优化方向主要是针对构建速度上的优化，其实开始通过时间检测工具我们可以发现，在打包过程中，babel-loader相关的打包花费还是比较久的，是因为在没有任何配置的情况下，babel-loader是默认关闭了缓存相关的配置，导致在每次打包的过程中其实都相当于是完全的重新打包，而其实在很多时候，我们并不一定会引入很多的新东西，所以，通过缓存来优化我们的打包速度效果是很明显的。
//可以使用cache-loader或者直接配置babel-loader来实现缓存优化
// cache-loader(配置很简单，安装完依赖之后，只需要在其他loader前引入即可)
module.exports = {
module: {
//我的项目中,babel-loader耗时比较长，所以我给它配置了`cache-loader`
rules: [
{
test: /\.jsx?$/,
use: ['cache-loader','babel-loader']
}
]
}
}
// babel-loader内配置缓存
// 我们只需要在options中添加 cacheDirectory: true即可，因为如果不添加默认为false
module.exports = {
module: {
//我的项目中,babel-loader耗时比较长，所以我给它配置了`cache-loader`
rules: [
{
test: /\.jsx?$/,
use: [
loader: 'babel-loader',
options: {
cacheDirectory: true
},]
}
]
}
}
关于babel-loader的缓存配置很简单，但是效果很明显，在新的依赖引入后的第一次打包时间不会改变，因为相当于重新打包而不会从缓存中读取，从第二次开始，如果没有新的依赖加入，可以发现打包速度非常的快，可以看到，时间从6168ms直接减少到了2010ms，并且如果你的项目打包的时间需要更久的话，第二次以后的打包效率会更加明显。
其实关于项目优化，还有很多需要考虑的方向，不过基于目前的项目并没有那么复杂且通过上面的优化之后，打包体积和构建速度有了明显的下降，所以更多的优化策略会等到后续慢慢学习以及项目不断庞大的过程中再一点一点补充。
结果：我们的项目在没有引入任何优化的情况下，打包后的dist文件大小是13.7MB，添加了包含webpack优化，组件懒加载以及样式按需加载，打包后的dist文件大小为3.8MB，效果非常显著，而其中添加了组件懒加载后，打包体积直接从13.7MB减小到了7.2MB。