者｜David Gilbertson

译者｜无明

出处丨前端之巅

一个网站该如何以最佳的方式向用户发送资源文件？有很多不同的场景，不同的技术和不同的术语。在这篇文章里，我希望能够让你明白：哪种文件分割策略最适合你的网站和用户，以及如何实现。

根据 Webpack 术语表，有两种不同的文件分割类型。它们看起来似乎可以互换，但显然不行：

• 捆绑拆分：创建更多、更小的文件（但每个请求都需要加载它们）以获得更好的缓存效果。
• 代码拆分：动态加载代码，用户只下载他们正在查看的内容所需的代码。

第二种方法看起来更有吸引力，不是吗？事实上，有很多文章似乎都假设这是拆分 JavaScript 文件唯一有价值的方案。但我想要告诉你的是，对于很多网站来说，第一种方法更有价值，而且它应该是你首先要考虑的。

捆绑拆分

捆绑拆分背后的想法非常简单。如果你有一个巨大的文件，哪怕只是修改了一行代码，用户也必须再次下载整个文件。但是，如果你将它分成两个文件，那么用户只需要下载被修改的那个文件，浏览器会从缓存中获取另一个文件。

捆绑拆分与缓存有关，因此对于首次访问网站的用户来说，有没有拆分其实并没有什么不同。

对于频繁访问网站的用户来说，要衡量捆绑拆分所带来的性能提升可能也很棘手，但我们必须这样做！

我需要一个表格来记录性能数据。下面是上述提到的场景：

• Alice 每周访问我们的网站一次，为期 10 周；
• 我们每周更新一次网站；
• 我们每周都会更新“产品列表”页面；
• 我们还有一个“产品详细信息”页面，目前还未开发出来；
• 在第 5 周，我们添加了一个新的 npm 包；
• 在第 8 周，我们更新了一个现有的 npm 包。

基 线

假设我们的 JavaScript 包大小是 400 KB，只包含 main.js 单个文件。

我们的 Webpack 配置如下（我省略了不相关的配置）：

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

每个礼拜，当我们做出一些变更时，这个包的 contenthash 就会发生变化。因此，每周 Alice 访问我们的网站时必须下载新的 400 KB 文件。

我们把这些数字记录在表格中，它看起来就像这样。

下载量总共是 4.12 MB，为期 10 周。

但我们可以做得更好。

拆分 vendor 包

现在，我们将包拆分为 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',
 },
 },
};

Webpack 4 努力为你做最好的事情，甚至都不需要告诉它你想要如何拆分捆绑包。

有人说，“这样看起来很整洁，不错，Webpack！”

也有人说，“你都对我的包做了什么？”

设置 optimization.splitChunks.chunks='all'意味着“将 node_modules 所有内容都放入名为 vendors~main.js 的文件中”。

经过这个基本的捆绑拆分，Alice 每次访问网站时仍然需要下载 200 KB 的 main.js 新文件，然后分别在第 1 周，第 8 周和第 5 周下载 200 KB 的 vendor.js 文件。

现在的下载量总共是 2.64 MB。

减少了 36％。在配置中加了五行代码，效果还不错。

这样的性能提升似乎有点微不足道，因为它是 10 周加起来的总和，但不管怎样，向用户发送的字节数确确实实减少了 36％，我们应该为自己感到自豪。

但我们可以做得更好。

拆分每个 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 的文档（https://webpack.js.org/guides/caching/）对此做出了很好的解释，我会大致解释一下 groovy 的部分，因为我在这个上面花了很多时间：

• Webpack 提供了一些不是那么聪明的默认设置，比如分割输出文件最多为 3 个，最小文件的大小为 30 KB（更小的文件将被连接在一起），所以我覆盖了这些设置。
• 我们通过 cacheGroups 来定义 Webpack 应该如何将代码块分组到输出文件中。在这里我使用了“vendor”，用于处理从 node_modules 加载的模块。通常，你只需将输出文件的 name 定义为字符串，但我将 name 定义为一个函数（在解析每个文件时调用这个函数）。然后我基于模块的路径返回包的名称。因此，对于每个包，我们都会得到一个文件，例如 npm.react-dom.899sadfhj4.js。
• 出于发布的目的，NPM 包名称必须是 URL 安全的（https://docs.npmjs.com/files/package.json#name）， 因此我们不需要对 packageName 进行 encodeURI。但是，我遇到一个问题，即.NET 服务器不支持带有 @的文件名，所以我在这个代码片段中将它替换掉。
• 整个设置很棒，不需要额外的维护——我不需要引用任何包。

Alice 每周仍然会重新下载 200 KB 的 main.js 文件，并且在她第一次访问网站时仍然会下载 200 KB 的 npm 软件包，但她绝不会下载相同的软件包两次。

现在的下载总量是 2.24 MB，与基线相比减少了 44％。

我在想是否有可能减少 50％？

拆分应用程序代码

现在让我们回到可怜的 Alice 一次又一次下载的 main.js 文件。

我之前提到过，我们的网站上有两个截然不同的部分：产品列表页面和产品详细信息页面。每个部分不一样的代码为 25 KB（共享代码为 150 KB）。

“产品详细信息”页面现在并没有发生太大变化，因此，如果我们将其变为单独的文件，大多数时候可以从缓存中获取它。

另外，我们有一个巨大的内联 SVG 文件用于渲染图标，大小为 25 KB，而且很少会发生改动。

我们应该对此做些什么。

我们手动添加了一些条目，告诉 Webpack 为每一项创建一个文件。

module.exports={
 entry: {
 main: path.resolve(__dirname, 'src/index.js'),
 ProductList: path.resolve(__dirname, 'src/ProductList/ProductList.js'),
 ProductPage: path.resolve(__dirname, 'src/ProductPage/ProductPage.js'),
 Icon: path.resolve(__dirname, 'src/Icon/Icon.js'),
 },
 output: {
 path: path.resolve(__dirname, 'dist'),
 filename: '[name].[contenthash:8].js',
 },
 plugins: [
 new webpack.HashedModuleIdsPlugin(), // so that file hashes don't change unexpectedly
 ],
 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 还会为 ProductList 和 ProductPage 之间共享的内容创建文件，这样我们就不会得到重复的代码。

这样就可以为亲爱的 Alice 节省 50 KB 的下载量。

现在的总下载量只有 1.815 MB！

我们已经为 Alice 节省了高达 56％的下载量，在我们的理论场景中，这种情况可以一直持续下去。

截止到目前，我们只是通过修改 Webpack 配置来实现这一切——我们没有对应用程序代码进行任何更改。

我们的目标是将应用程序拆分为合理的小文件，让用户下载更少的代码。

因此，接下来我们要进入代码拆分，但首先我想要解决你现在想到的三个问题。问题 1：大量的网络请求不是更慢吗？

对于这个问题，答案是一个非常响亮的“不”。

在 HTTP/1.1 时代或许是这种情况，但对于 HTTP/2 来说并非如此。

尽管一些著名的文章得出“即使使用 HTTP/2，下载太多文件仍然较慢”的结论，但在这些文章中，他们所谓的“太多”文件是指“数百个”文件。所以请记住，如果你有数百个文件，可能会达到并发上限。

问题 2：每个 Webpack 捆绑包中不是有样板代码？

是的。

问题 3：如果有多个小文件，不就失去了压缩的优势了吗？

是的。

好吧，这就是说：

• 更多文件=更多的 Webpack 样板代码；
• 更多文件=更少的压缩。

接下来让我们做一下量化，这样就可以确切地知道性能被磨损了多少。

我做了一个测试，将 190KB 的文件拆分成 19 个小文件，这样发送给浏览器的总字节数大约增加了 2％。

在第一次访问时增加 2％，但在以后访问可以减少 60％，所以可以说完全没有磨损。

我针对 1 个文件和 19 个文件分别进行了测试，并基于不同的网络，包括 HTTP/1.1。

这是结果表格，我想这足以说明“更多文件会更好”：

在 3G 和 4G 网络上，当有 19 个文件时，总的加载时间缩短了 30％。

当然，这些数据带有一定的噪音。例如，第二次在 4G 网络上的加载时间为 646 毫秒，过了两次之后需要 1116 毫秒——多了 73％。因此，声称 HTTP/2“快 30％”似乎有点心虚的感觉。

我制作这张表来是想要量化 HTTP/2 的差异，但看来我唯一能说的是“它可能没有显著差异”。

真正的惊喜是最后两行，我原本认为旧的 Windows 和 HTTP/1.1 会很慢。

这就是我要说的有关捆绑拆分的一切。我认为这种方法的唯一缺点是要不断地说服人们，加载大量小文件是没有问题的。

现在，让我们谈谈另一种类型的文件拆分。

代码拆分（不加载不需要的代码）

这种方法可能只对某些网站有用。

我发明了 20/20 规则：如果你的网站的某些部分只有 20％的用户访问，而这部分超过了整个网站 20％的 JavaScript，那么你应该按需加载这些代码。

显然，因为存在更复杂的场景，所以这个数字显然需要做出调整。但关键在于，肯定存在一个平衡点，到了这个平衡点，代码拆分对于你的网站来说可能就没有意义了。

如何找到这个平衡点？

假设你有一个购物网站，你想知道是否应该对“结帐”代码进行拆分，因为只有 30％的用户会进行这个操作。

你需要弄清楚有多少代码是只与结账这个功能有关的。因为在进行“代码拆分”之前已经进行了“捆绑拆分”，因此你可能已经知道这部分究竟有多少代码。

只与结帐有关的代码是 7 KB，其余部分是 300 KB。看到这个我会说，我不会想去拆分这个代码，原因如下：

• 预先加载它并不慢，因为你是并行加载这些文件的。而且你可以试试是否有可能记录 300 KB 和 307 KB 加载时间的差异。
• 如果你稍后加载这段代码，用户在点击“Take My Money”后将不得不等待加载这个文件——这是你最不想遇到摩擦阻力的时候。
• 进行代码拆分需要更改应用程序代码。它会在以前只有同步逻辑的地方引入异步逻辑。这不是火箭科学，但它的复杂性，我认为应该通过对用户体验可感知的改进来证明。。

现在让我们来看看两个需要代码拆分的例子。

polyfill

我之所以从这里开始讲起，是因为它适用于大多数网站，而且介绍起来相对简单。

我在网站上使用了很多花哨的功能，有一个文件导入了所有需要的 polyfill。其中包括以下八行：

require('whatwg-fetch');
require('intl');
require('url-polyfill');
require('core-js/web/dom-collections');
require('core-js/es6/map');
require('core-js/es6/string');
require('core-js/es6/array');
require('core-js/es6/object');

我在 index.js 的顶部导入了这个文件。

import './polyfills';
import React from 'react';
import ReactDOM from 'react-dom';
import App from './App/App';
import './index.css';
const render=()=> {
 ReactDOM.render(<App />, document.getElementById('root'));
}
render(); // yes I am pointless, for now

根据之前的捆绑拆分的 Webpack 配置，polyfill 将自动被拆分为四个不同的文件，因为这里有四个 npm 包。它们总共约 25 KB，但 90％的浏览器都不需要它们，所以有必要进行动态加载。

使用 Webpack 4 和 import() 语法（不要与 import 语法混淆）可以很方便地实现 polyfill 的条件加载。

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App/App';
import './index.css';
const render=()=> {
 ReactDOM.render(<App />, document.getElementById('root'));
}
if (
 'fetch' in window &&
 'Intl' in window &&
 'URL' in window &&
 'Map' in window &&
 'forEach' in NodeList.prototype &&
 'startsWith' in String.prototype &&
 'endsWith' in String.prototype &&
 'includes' in String.prototype &&
 'includes' in Array.prototype &&
 'assign' in Object &&
 'entries' in Object &&
 'keys' in Object
) {
 render();
} else {
 import('./polyfills').then(render);
}

如果浏览器支持所有功能，那么就渲染页面，否则的话就导入 polyfill，然后渲染页面。在浏览器中运行这些代码时，Webpack 的运行时将负责加载这四个 npm 包，在下载和解析它们之后，将调用 render()……

顺便说一句，要使用 import()，需要 Babel 的 dynamic-import 插件 (https://babeljs.io/docs/en/babel-plugin-syntax-dynamic-import/)。 另外，正如 Webpack 文档解释的那样，import() 使用了 promise，所以你需要单独对其进行 polyfill。

这个很简单，对吗？下面来点稍微有难度的。

基于路由的动态加载（特定于 React）

回到 Alice 的例子，我们假设网站有一个“管理”功能，卖家可以登录并管理他们的商品。

这部分有很多精彩的功能，大量的图表，需要很多 npm 大图表库。因为已经在进行了捆绑拆分，所以它们都是 100 KB 左右的文件。

目前，我的路由设置是当用户访问 /admin 时，将会渲染<AdminPage>。当 Webpack 将所有内容捆绑在一起时，它会找到 import AdminPage from ./AdminPage.js，然后说，“我需要将它包含在初始化代码中”。

但我们不希望它这样。我们需要使用动态导入，例如 import(‘/AdminPage.js’)，这样 Webpack 就知道要进行动态加载了。

这很酷，不需要做任何配置。

因此，我可以创建另一个组件，当用户访问 /admin 时就会渲染这个组件，而不是直接引用 AdminPage。它看起来可能像这样：

import React from 'react';
class AdminPageLoader extends React.PureComponent {
 constructor(props) {
 super(props);
 this.state={
 AdminPage: null,
 }
 }
 componentDidMount() {
 import('./AdminPage').then(module=> {
 this.setState({ AdminPage: module.default });
 });
 }
 render() {
 const { AdminPage }=this.state;
 return AdminPage
 ? <AdminPage {...this.props} />
 : <div>Loading...</div>;
 }
}
export default AdminPageLoader;

这个概念很简单。在加载这个组件时（意味着用户在访问 /admin），我们将动态加载./AdminPage.js，然后在 state 中保存对该组件的引用。

在等待<AdminPage>加载时，我们只是在 render() 方法中渲染<div> Loading... </div>，或者在加载完成时渲染<AdminPage>，并保存在 state 中。

我自己这样做是为了好玩，但在现实世界中，你可以使用 react-loadable，正如 React 文档（https://reactjs.org/docs/code-splitting.html） 中关于代码拆分的描述那样。

以上就是所有我想说的话，简单地说就是：

如果用户会多次访问你的网站，请将你的代码拆分为很多小文件。如果你的网站有些部分是大部分用户不会访问到的，请动态加载这些代码。

英文原文

https://hackernoon.com/the-100-correct-way-to-split-your-chunks-with-webpack-f8a9df5b7758

日客户要求表内的数据依据某种分组生成HTML页面进行展示，一般处理这种需求直接上编程工具就好了，从数据库里读取数据，根据规则生成字符串，最后将字符串写出到文件。由于需求比较急，作为数据库编程系列文章，如果能用SQL实现首选还是SQL，这样处理既直接又快速，不过针对SQL要真的有耐心和信心写完，调试更是崩溃。由于要写出文件到硬盘，最后还是选择MySQL作为数据库工具，Navicat作为开发工具。

有两张表计划表、市县表，二者依靠市县编码（sxbm）进行等值连接，计划表内含有各个学校投放在各个市县的专业代号（zydh），专业名称（zymc）、招生备注(bz)、学制(xz)、要求的学历(xl)、计划数(jh)等字段组成的计划信息，院校编码(yxbm)为学校的两位数编码，院校代号(yxdh)为院校编码(yxbm)+市县编码(sxbm)组成的四位数编码，院校代号其实可以区分出学校在哪个市县的投档的专业计划。要求以学校为单位创建HTML页面，页面首先要以市县作为表格分割，然后根据专业代号排序。具体实现过程如下：

创建计划表：

CREATE TABLE `zzjh2019v` (
`YXDH` varchar(9) COMMENT '学校代号',
`YXMC` varchar(54) COMMENT '学校名称',
`ZYDH` varchar(2) COMMENT '专业代号',
`ZYMC` varchar(28) COMMENT '专业名称',
`XZ` varchar(3) COMMENT '学制',
`XL` varchar(4) COMMENT '学历',
`JH` varchar(6) COMMENT '招生计划数',
`BZ` varchar(200) COMMENT '备注',
`yxbm` char(2) COMMENT '学校编码',
`sxbm` char(2) COMMENT '市县编码'
) ENGINE=InnoDB CHARACTER SET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=Compact;

创建市县编码表：

CREATE TABLE `sx` (
`sxbm` char(2) COMMENT '市县编码',
`sxmc` varchar(20) COMMENT '市县名称'
) ENGINE=InnoDB CHARACTER SET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=Compact;

纠结了很久这个东西怎么写，最后采取游标、拼接字符串、字符串聚合，动态SQL，写文件等一些列操作完成需求，创建的存储过程如下：

CREATE DEFINER=`root`@`localhost` PROCEDURE `splitjh`()
BEGIN
declare done INT DEFAULT 0;
declare pyxbm char(2);
declare psxmc varchar(10);
declare pyxmc varchar(50);
declare pjhall int;
declare pjhrows TEXT;
declare yxjh cursor
for
select yxbm,yxmc,sum(jh) jhall from zzjh2019v a,sx b where a.sxbm=b.sxbm group by yxbm,yxmc order by yxbm;
declare CONTINUE HANDLER FOR SQLSTATE '02000' SET done=1;
open yxjh;
fetch yxjh into pyxbm,pyxmc,pjhall;
while done !=1 do
select group_concat(jhrow separator '') into pjhrows from
(select concat('<tr class="subtitle"><td>',yxdh,'</td><td>',yxmc,'在 <span><font color="red">',b.sxmc,'</font></span> 招生计划如下</td><td>',sum(jh),'</td><td></td><td></td></tr>',group_concat('<tr class="jhrow"><td>',zydh,'</td><td>',zymc,'(',bz,')</td><td>',jh,'</td><td>',xz,'</td><td>',xl,'</td></tr>' order by zydh separator '')) jhrow
from zzjh2019v a,sx b where yxbm=pyxbm and a.sxbm=b.sxbm group by yxdh order by yxdh,zydh) jhs;
set @pfilename=concat('''d:/32/1/1/jh11',pyxbm,'.html''');
set @sql=concat('select concat(''<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><link rel="stylesheet" type="text/css" href="zsjh.css" ><title>3+2计划</title></head><body><h3></h3><table><tr class="subtitle"><th>代号</th><th>专业及名称备注</th><th>人数</th><th>学制</th><th>学历</th></tr>'',''',pjhrows,''',''</body></html>'') from dual into outfile ',@pfilename);
prepare execsql from @sql;
execute execsql;
DEALLOCATE PREPARE execsql;
fetch yxjh into pyxbm,pyxmc,pjhall;
end while;
close yxjh;
END;

首先看效果，执行过程

call splitjh();

在磁盘形成的HTML文件效果如下图（数据有一定的敏感性，进行了遮挡处理）：

生成的文件列表如下图：

这里一共有87所学校，所以生成了87的文件，添加CSS样式文件，让表格呈现如前图所示。

技术点

1）MySQL的游标，以及循环读取游标的方法，涉及的语句如下：

declare yxjh cursor
for
select yxbm,yxmc,sum(jh) jhall from zzjh2019v a,sx b where a.sxbm=b.sxbm group by yxbm,yxmc order by yxbm;#游标定义
declare CONTINUE HANDLER FOR SQLSTATE '02000' SET done=1;#游标循环条件，注意此句一定要定义在游标之后，才起作用
open yxjh;#打开游标
fetch yxjh into pyxbm,pyxmc,pjhall;#将游标行内容赋值给变量。

2）执行动态SQL，由于MySQL into outfile 后接的文件名不能为变量，所以必须使用动态SQL的方法，涉及的语句如下：

prepare execsql from @sql;#从一个变量准备一个动态sql，注意execsql不用提前定义
execute execsql;#执行准备好的语句
DEALLOCATE PREPARE execsql;#销毁语句

综上就是使用MySQL数据库，并借用MySQL写文件的方式将数据从数据库内按照需求导出文件，为何不用navicat导出呢？因为无法达到要求，又是聚合、又是格式，所以只能自己编写过程通过SQL语句拼接字符串的方式来实现。没有太多的技术难度，主要是想法和调试难度。后续在此基础上又开发了以市县为单位创建HTML文件，各招生学校作为分割的过程。本案例是实际需求催生出来的做法，在遇到这样的需求前你是先想到SQL还是先想到开发工具呢？从实际效果看使用SQL这种方式更加灵活。这样的SQL实现的字符串拼接是不是有点极限呢？