前言
現在已經是vue-cli3.x webpack4.x 的時代了，但是網上很多拆包配置還是一些比較低版本的。
本文主要是分享自己的拆包踩坑經驗。
主要是用了webpack4 的 splitChunks 來進行拆包的配置以及在配置中的一些踩坑。
首屏加載的優化主要在於兩個方面，一個是減小包的總體積，二是由於把依賴打包進去太大而要進行拆包處理，提高首屏的加載速度。
一、減小包體積
主要在於壓縮和去掉無用的代碼
壓縮可以用webpack的一些插件，服務端gzip壓縮
去掉無用代碼有 生產環境去掉 console，去掉 .map 文件
適用插件：UglifyJsPlugin、TerserPlugin等
二、拆包
1、分離第三方依賴包
const Home= resolve =>{require(['./components/home/index.vue'],resolve)}
如果路由很多，都用這個的話，打包出來會有很多文件。
這時候，如果后端項目模板文件是寫死引入的js和css的話就不太好辦了，當然如果是前后端完全分離部署的環境或者是后端每次修改模板文件or動態引入所有js和css的話，是沒什么問題的。
然而，我本次遇到的是前者，所以是希望基本上打包出來的文件名很少有變化才好。
（3）所以本次用的是webpack4 的 splitChunks , 注意 webpack 4 把 CommonsChunk 廢棄，用splitChunks來取代。
默認配置： https://webpack.docschina.org/plugins/split-chunks-plugin/
- chunks: 表示哪些代碼需要優化，有三個可選值：initial(初始塊)、async(按需加載塊)、all(全部塊)，默認為async
- minSize: 表示在壓縮前的最小模塊大小，默認為30000
- minChunks: 表示被引用次數，默認為1
- maxAsyncRequests: 按需加載時候最大的並行請求數，默認為5
- maxInitialRequests: 一個入口最大的並行請求數，默認為3
- automaticNameDelimiter: 命名連接符
- name: 拆分出來塊的名字，默認由塊名和hash值自動生成
- cacheGroups: 緩存組。緩存組的屬性除上面所有屬性外，還有test, priority, reuseExistingChunk
- test: 用於控制哪些模塊被這個緩存組匹配到
- priority: 緩存組打包的先后優先級
- reuseExistingChunk: 如果當前代碼塊包含的模塊已經有了，就不在產生一個新的代碼塊
在用它的時候，也遇到了一些配置問題，沒有配置之前app.js 達2.3MB 之大，想要達到的效果是js拆成 4-5 個包，最好不要有超過1MB的包。
首先准備是把element-ui這個包拆出來，效果是拆出來了，但app.js還是有2MB，然后把echarts也拆出來之后，app.js還是有1.8MB，再增加配置，一直沒有成功，只拆出來兩個包。
最終的拆包配置，vue.config.js 中在 chainWebpack添加配置
// 拆包 config.optimization.splitChunks({ chunks: 'all', maxInitialRequests: Infinity, minSize: 300000, // 依賴包超過300000bit將被單獨打包 automaticNameDelimiter:'-', cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name(module) { const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1]; return `chunk.${packageName.replace('@', '')}`; }, priority:10 } } })
用這種就可以，設置minSize， 根據項目情況來，最終是大於它的依賴包就會被拆出來，這種的好處就在於，如果要自己去判斷拆那個出來，有可能並不是很清楚哪些包比較大，哪些比較小，這種就會幫你判斷，而且如果不是引入一些新的比較大的包，服務端的模板配置基本可以不怎么變。
參考：
https://juejin.im/post/5b99b9cd6fb9a05cff32007a
https://blog.csdn.net/weixin_34160277/article/details/86720033