webpack之bundle splitting

为什么需要进行代码拆分?

随着前端代码需要处理的业务越来越繁重，我们不得不面临的问题是前端的代码体积也变得越来越庞大。这造成无论是在调试还是在上线时候都需要
花长时间等待编译完成，并且用户也不得不花额外的时间和带宽下载更大体积的脚本文件。对于性能优化来说，需要减少http请求，用webpack
进行应用的构建打包，将我们应用以及应用所需的模块打包成一个大bundle。这样确实是减少了HTTP的请求，但这样做也产生了其他问题：

• 首屏加载时间过长，导致白屏，移动端网络不稳定最明显
• 当修改业务代码以后，整个大的bundle需要重新下载
• 在开发时候，如果是修改有一行代码，我们需要重新打包文件
• 用户只是粗略浏览页面也需要将整个站点的脚本全部先下载下来

所以就需要按需的，有策略性的将代码拆分和提供给用户。webpack就允许我们在打包时候讲脚本分块；利用浏览器缓存我们根据需要加载资源。

根据webpack术语表,存在两类文件的分离。这些名词听起来可以互换的，但是实际上不行

• 打包分离(Bundle splitting):为了更好的缓存创建更多、更小的文件(但仍然以每一个文件一个请求的方式进行加载)；
• 代码分离(Code splitting):动态加载代码，所以用户只需要下载当前他正在浏览站点这部分代码

Bundle VS Chunk VS Module

首先对于模块(module)的概念相信大家都没有异议，它指的是我们在编码过程中有意识的封装和组织起来的代码片段。狭义上我们首先先到的是碎片化的Vue组件，或者是CommonJS模块
又或者是ES6模块，但是对Webpack和loader而言，广义上的模块还包括样式和图片，甚至说是不同类型的文件。

而包(bundle)就是把相关代码都打包进入的耽搁文件。如果你不想把所有的代码都放入一个包中，你可以把它们划分为多个包，也就是块(chunk)中。从这个角度看，块(chunk)等于包(bundle)，
他们都是对代码再一层的组织和封装。如果必须要给一个区分的话，通常我们在讨论时，bundle指的是所有某块都打包进入的耽搁文件，而chunk指的是按照某种规则的模块集合，chunk的体积大于
单个模块，同时小于整个bundle

Bundle splitting打包分离

打包分离背后的思想非常简单。如果你有一个体积巨大的文件，并且只改了一行代码，用户仍然需要重新下载整个文件。但是如果你把它分为了两个文件，那么用户只需要下载那个被修改的文件，
而浏览器则可以从缓存中加载另一个文件。值得注意的是因为打包分离预缓存相关，所以对站点的首次访问者来说没有区别。当谈论到频繁访问者时，量化性能提升会稍有棘手，但是我们必须量化

这将需要一张表格，我们将每一种场景与每一种策略的组合结果都记录下来

我们假设一个场景

• Alice连续10周每周访问站点一次
• 我们每周更新站点一次
• 我们每周更新"产品列表"页面
• 我们也有一个"产品详情的页面"，但是目前不许需要对他进行更新
• 在第5周的时我们给站点新增了一个npm包
• 在第8周时我们更新了现有的一个npm包

性能基线

假设我们的Javascript打包后的总体积为400KB，将它命名为main.js,然后以单文件的形式加载它

const path = require('path');
const HtmlWebpackPlugin = require("html-webpack-plugin");
const {CleanWebpackPlugin} = require("clean-webpack-plugin");

module.exports = {
	entry:"./src/index.js",
	output:{
		filename:"[name].[contenthash].js",
		path:path.resolve(__dirnane,"dist")
	}
}

当只有单个入口，webpack会自动把结果命名为main.js。main.js实际上是在说类似于main.xxxx.js这种包含一堆带有文件内容哈希字符串的东西。这意味着当你应用代码发生改变时
新的文件名会生成，这样就能迫使浏览器下载新的文件

所以当每周我想沾点发布新的变更时，包的contenthash就会发生更改。以至于每周Alice访问我们沾点时不得不下载一个全新的400KB大小的文件

文件	week1	week2	week3	week4	week5	week6	week7	week8	week9	week10
main.js	400	400	400	400	420	420	420	420	420	420
连续十周就是4.12MB

哈希(hash)与性能

是否会产生疑问

• 为什么带哈希串的文件名会对浏览器缓存产生影响？
• 为什么文件名里的哈希后缀是contenthash?如果把contenthash换成hash或者chunkhash有什么影响？

为了每次访问时不让浏览器都重新下载同一个文件，我们通常会把这个文件返回的HTTP头中的Cache-Control设置为max-age = 31536000，也就是一年(描述时间)。这样一来，
在一年之内用户访问这个文件时候，都不会再次向服务器发送请求二十直接从缓存中读取，知道或者手动清除了缓存。

如果我中途修改了文件内容必须让用户重新下载怎么办？修改文件名就好了，不同的文件(名)对应不同的缓存策略。二一个哈希字符串就是根据文件内容产生的"签名"，每当文件内容发生更改时，
哈希串也就发生了更改，文件名也就随之更改。这样一来，旧版本文件的策略就会失效，浏览器就会重新加载新版本的改文件。当然这只是其中一种最基础的缓存策略。

所以在webpack中配置的filename:[name]:[contenthash].js就是为了每次发布时候自动生成的文件名。

对于webpack，它提供了另外两种哈希算法供开发者使用：hash和chunkhash。那么为什么不适用他们二十使用contenthash?这要从他们的区别说起。原则上来说，他们是为不同
目的服务的，但在实际操作中，也可以交替使用。

hash

hash针对的是每一次构建(build)而言，每一次构建之后生成的文件所带的哈希都是一致的。它关心的是整体项目的变化，只要有任一文件内容发生了更改，那么构建之后其他文件的哈希也会发生更改
很显然这不是我们需要的，如果module_a文件内容发生更改，module_a的打包文件的哈希应该发生变化，但是module_b不应该。这回导致用户不得不重新下载没有发生变化的module_b打包文件

chunkhash

chunkhash基于的是每一个chunk内容的改变，如果该chunk所属的内容发生了变化，那么只有该chunk的输出文件的哈希会发生变化，其他的不会。这听上去符合我们的需求。
在之前我们对chunk进行过定义，既是小单位的代码聚合形式。在下面面的例子中以entry入口体现，也就是说每一个入口对应的文件就是一个chunk。

contenthash

该哈希根据的是文件的内容。从这个角度上说，他和chunkhash是能够相互代替的。所以在"性能基线"代码中作者使用了contenthash，不过特殊之处是，或者说是关于它的使用说明中，都只是如果你
想在ExtractTextWebpackPlugin或者MiniCssExtractPlugin中使用到哈希标识，应该使用contenthash。

例子

webpack.bundleSplitting.js内容

const path = require("path");
const MiniCssExtractPlugin = require("mini-css-extract-plugin")
module.exports = {
	entry:{
		index:path.resolve(__dirname,'src/index.js'),
		module_a:path.resolve(__dirname,"src/module_a.js"),
		module_b:path.resolve(__dirname,"src/module_b.js")
	},
	output:{
		filename:"[name].[hash].js",
		path:path.resolve(__dirname,'dist')
	},
	module:{
		rules:[
			{
				test:/.css/,
				use:[
					MiniCssExtractPlugin.loader,
					"css-loader"
				]
			}
		]
	},
	plugins:[
		new MiniCssExtractPlugin({
			filename:"[name].[contenthash].css"
		})
	]
}

index.js内容

import mathFn from "./math.js";
import "./reset.css"

math.js

function add(a,b){
	return a + b;
}

function minus(a,b){
	return a - b
}

function multiple(a,b){
	return a*b
}

export default{
	add,
	minus,
	multiple
}

module_a.js

function moduleA(){
	console.log("this is moduleA")
}

moduleA()

module_b.js

function moduleB(){
	console.log("this is moduleB")
}
moduleB()

packge.json

{
  "name": "webpackDevServer",
  "sideEffects": [
    "*.css",
    ".scss"
  ],
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1",
    "dev": "webpack-dev-server --config demo/webpack-dev-server/webpack-dev-server.js",
    "server": "node demo/webpack-dev-middleware/server.js",
    "hmr": "webpack-dev-server  --config demo/HMR/webpack.hmr.js",
    "treeShaking:dev": "webpack-dev-server --config demo/tree-shaking/tree-shaking.js",
    "treeShaking:build": "webpack  --config demo/tree-shaking/tree-shaking.js",
    "buildProd:dev": "webpack-dev-server --config demo/buildProduction/webpack.dev.js",
    "buildProd:build": "webpack --config demo/buildProduction/webpack.prod.js",
    "bundleSplitting":"webpack --config demo/bundleSplitting/webpack.bundleSplitting.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@babel/core": "7.6.4",
    "@babel/plugin-transform-runtime": "^7.6.2",
    "@babel/preset-env": "^7.6.3",
    "autoprefixer": "^9.7.1",
    "babel-loader": "8.0.6",
    "clean-webpack-plugin": "3.0.0",
    "css-loader": "^3.2.0",
    "express": "4.17.1",
    "file-loader": "^4.2.0",
    "html-webpack-plugin": "3.2.0",
    "mini-css-extract-plugin": "^0.8.0",
    "node-sass": "^4.13.0",
    "postcss-import": "^12.0.1",
    "postcss-loader": "^3.0.0",
    "postcss-url": "^8.0.0",
    "sass-loader": "8.0.0",
    "style-loader": "^1.0.0",
    "url-loader": "^2.2.0",
    "webpack": "4.41.2",
    "webpack-cli": "3.3.9",
    "webpack-dev-middleware": "3.7.2",
    "webpack-dev-server": "3.8.2",
    "webpack-merge": "^4.2.2"
  }
}

执行 npm run bundleSplitting

结果如下

在没有对任何文件修改，在执行npm run bundleSplitting，结果如下

修改module_a.js内容

function moduleA(){
	console.log("我是修改了的moduleA")
}
moduleA()

执行npm run bundleSplitting

结果如下

在设置为hash的时候，文件命的hash都是相同的，而且当修改了module_a.js后执行打包，所有文件hash都一起改变

将webpack.bundleSplitting.js的hash改成chunkhash

执行npm run bundleSplitting

结果如下

在没有对任何文件修改，在执行npm run bundleSplitting，结果如下

修改module_a.js内容

function moduleA(){
	console.log("我是修改成chunkhash的moduleA")
}
moduleA()

执行npm run bundleSplitting

结果如下

在设置为contenthash的时候。文件的contenthash都是不一样的，当修改了module_a.js后执行打包，只有module_a.js的contenthash发生改变

分离第三方类库

让我们把打包文件划分为main.js和vendor.js
很简单，类似于

const path = require("path");
module.exports = {
	entry:path.resolve(__dirname,'src/index.js'),
	output:{
		path:path.resolve(__dirname,'dist'),
		filename:'[name].[contenthash].js'
	},
	optimization:{
		splitChunks:{
		chunks:"all"
	}
}

在webpack4使用了optimization.solitChunks替代了CommonsChunkPlugin
设置optimization.chunks为'all'就是默认打包node_module到venders.js中
设置optimization.chunks.runtimeChunk为true，是讲webpack运行时候生成代码打包到runtime.js中

在实现基本的打包分离条件后，Alice在每次访问时候仍需要下载200KB大小的main.js文件，但是只需要在第一周、第五周、第八周下载200KB vendors.js脚本

文件	week1	week2	week3	week4	week5	week6	week7	week8	week9	week10
main.js	200	200	200	200	200	200	200	200	200	200
vendors.js	200				220			220
totol	400	200	200	200	420	200	200	420	200	200

也就是2.64MB

分离每一个npm包

我们的vendors.js承受着和开始main.js文件同样的问题——部分的修改会意味着重新下载所有的文件，所以为什么不把每一个npm包都分割到单独的文件？做起来非常简单

让我们把react，lodash，redux，moment等分立为不同的文件

const path = require('path');
const webpack = require('webpack');

module.exports = {
  entry: path.resolve(__dirname, 'src/index.js'),
  plugins: [
    new webpack.HashedModuleIdsPlugin(), // so that file hashes don't change unexpectedly
  ],
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash].js',
  },
  optimization: {
    runtimeChunk: 'single',
    splitChunks: {
      chunks: 'all',
      maxInitialRequests: Infinity,
      minSize: 0,
      cacheGroups: {
        vendor: {
          test: /[\/]node_modules[\/]/,
          name(module) {
            // get the name. E.g. node_modules/packageName/not/this/part.js
            // or node_modules/packageName
            const packageName = module.context.match(/[\/]node_modules[\/](.*?)([\/]|$)/)[1];

            // npm package names are URL-safe, but some servers don't like @ symbols
            return `npm.${packageName.replace('@', '')}`;
          },
        },
      },
    },
  },
};

这份文档非常好的揭示了这里做的事情，但是我仍然需要解释一下其中精妙的部分

• webpack有一些不那么智能的默认"智能"配置，比如当分离打包输出文件时只允许最多3个文件，并且最小文件的尺寸是30KB(如果存在更小的文件就把它们拼接起来)。所以这里把这些都覆盖了
• cacheGroups使我们用来指定规则告诉webpack应该如何组织chunks到打包输出文件的地方。在这里对所有加载自node_modules里的module指定了一条名为"vendor"的规则。通常
  情况下，你只需要为你的输出文件的name定义一个字符串。但是这里把name定义为一个函数(当文件被解析时会被调用)。在函数中会根据module的路径返回包的名称、结果就是，对于每一个包，我
  都会得到一个单独的文件
• 为了能够正常发布npm包的名称必须是合法的URL，所以我们不需要encodeURI对包的名词进行转移处理
• 整个步骤的配置设置之后就不需要维护了——我们不需要使用名称引用任何的类库

Alice每周都要重新下载200KB的main.js文件，并且在她首次访问时，仍然需要下载200KB的npm包文件，但是她在也不用重复的下载同一个包两次。

参考资料

• What are module, chunk and bundle in webpack?
• 深入理解Webpack打包分块
• 提取公共代码与第三方代码