整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

你拆分JS代码的方法可能是错的!

者|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

质文章,第一时间送达!

学习全文大概需要 12分钟,内容实战性较强。

1. 前言

本篇将基于Python 3.7+Django 3.0结合Vue.js前端框架,为大家介绍如何基于这三者的技术栈来实现一个前端后离的Web开发项目。为了简化,方便读者理解,本文将以开发一个单体页面应用作为实战演示。

2. 先搞清楚什么是前后端分离

在正式开始实战示例之前,我们有必要先弄清楚一个概念:什么是前后端分离?

前后端分离目前已成为互联网项目开发的业界标准使用方式,在聊前后端分离之前,相信也有很多读者,对如何区分前端还是后端,还搞不清楚(是不是让我戳中了你的痛处了)。本着“致良知”,先科谱一下知识。

通常情况下,我们说的前端,大多是指浏览器这一端,一般是用Html+CSS+JS来实现的,所以通常会引申为用Html+CSS+JS写的大部分程序都是前端,包括App,小程序,H5等。

PS: 在NodeJS出现之后,用NodeJS写的后端部分,也会被人归类为前端,为了区分之前的前端,就给他们起了一个名字,叫做“大前端”。

久而久之,人们习惯把Html+CSS+JS,运行在浏览器端执行的,称之为前端。

而Java,C,Python,PHP这些运行在服务器端的,统一称之为后端。

但,这种以语言为分界点去区分前后端,真的合理么?显然不合理!

前后端的定义,不应该是以语言来定义,而是应该以它的运行环境,如果是在服务器端,就应该被称之为后端,代表着你看不见,摸不着。而如果运行在用户端,就应该被称之为前端,代表你是可以看得到的。

在不分前后端的时候,无论是Java还是JS,全都是一个人来写。

为什么现在很多互联网公司在项目开发时,建议要进行前后端分离,或者说前后端分离能带来哪些优势?(好处多多,这里仅提两个点)

  • 第一个,并行开发、独立部署、实现前后端解,前后端的进度互不影响,在过去,前后端不分离的情况下,项目代码耦合严重相互影响,且前后端人员工作量分布不均。

  • 第二个,术业有专攻(开发人员分离),以前的JavaWeb项目大多数都是Java程序员又当爹又当妈,又搞前端,又搞后端。前后端分离之后,前端工程师只管前端的事情,后端工程师只管后端的事情。

我们先看看一个 Web 系统,在前后端不分离时架构设计是什么样的。

用户在浏览器上发送请求,服务器端接收到请求,根据 Header 中的 token 进行用户鉴权,从数据库取出数据,处理后将结果数据填入 HTML 模板,返回给浏览器,浏览器将 HTML 展现给用户。

而采用前后端分离之后,分离的是人员职责,人员职责分离了,因此架构也发生变化。

前后端分离后,前端人员和后端人员约定好接口,前端人员不用再关心业务处理是怎么回事,他只需要把界面做好就可以了,后端人员也不用再关系前端界面是什么样的,他只需要做好业务逻辑处理即可。

小结一下,前后端分离是什么?

前后端分离是一种架构模式,或者说是最佳实践,它主张将前端开发人员和后端开发人员的工作进行解耦,尽量减少他她们之间的交流成本,帮助他她们更能专注于自己擅长的工作。

PS: 本篇实战示例,使用Vue.js作为前端框架,代替Django本身自带的模板引擎,Django则作为服务端提供API接口,从而实现前后端分离。

3. 环境准备

本实战示例,基础环境对应安装版本如下:

  • Python 3.7.4

  • Mysql 5.7

  • Pycharm (建议专业版)

  • Node

PS: 其中Python、Mysql、Pycharm、Node安装过程皆较为简单,不是本文介绍重点,读者可直接参考官网安装方法。

4. 新建独立的虚拟开发环境

1、创建一个用于Django项目开发的独立虚拟环境,切换到本地开发目录,输入如下命令:

python3 -m venv venv

2、创建完成后,目录结构如下:

➜ venv tree -L 2.├── bin│ ├── activate│ ├── activate.csh│ ├── activate.fish│ ├── easy_install│ ├── easy_install-3.7│ ├── pip│ ├── pip3│ ├── pip3.7│ ├── python -> python3│ └── python3 -> /usr/local/bin/python3├── include├── lib│ └── python3.7└── pyvenv.cfg
4 directories, 11 files

3、进入到bin目录,输入命令source activate 命令,激活虚拟环境。

4、虚拟环境激活后,如上图所示。接下来,在虚拟环境安装Django库。

安装Django (最新版本为3.0)

(venv) ➜ pip install Django

Django 项目源码:

https://github.com/django/django

Django3.0 版本特性可查阅官网:

https://docs.djangoproject.com/en/3.0/releases/3.0/

5、安装完成后,可检查一下版本信息:

(venv) ➜ pythonPython 3.7.4 (default, Jul 9 2019, 18:15:00)[Clang 10.0.0 (clang-1000.11.45.5)] on darwinType "help", "copyright", "credits" or "license" for more information.>>> import django>>> print(django.get_version)3.0

可以发现,在虚拟环境中已经成功安装好了Django 3.0。

5. 创建Django后端项目

1、创建Django项目,采用Pycharm或者命令行创建皆可。此处,以命令行方式作为演示,项目名为django_vue。

(venv) ➜ django-admin startproject django_vue

2. Django项目创建完成后,目录结构如下所示。

├── django_vue│ ├── django_vue│ │ ├── __init__.py│ │ ├── asgi.py│ │ ├── settings.py│ │ ├── urls.py│ │ └── wsgi.py│ └── manage.py

3、执行同步数据库文件(Django默认数据库为db.sqlite3),执行同步过程如下:

(venv) ➜ python manage.py migrateOperations to perform: Apply all migrations: admin, auth, contenttypes, sessionsRunning migrations: Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying admin.0003_logentry_add_action_flag_choices... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying auth.0008_alter_user_username_max_length... OK Applying auth.0009_alter_user_last_name_max_length... OK Applying auth.0010_alter_group_name_max_length... OK Applying auth.0011_update_proxy_permissions... OK Applying sessions.0001_initial... OK

4、启动Django Server ,验证默认配置是否正常。

(venv) ➜ python manage.py runserver 0.0.0.0:8000Watching for file changes with StatReloaderPerforming system checks...
System check identified no issues (0 silenced).December 15, 2019 - 08:36:28Django version 3.0, using settings 'django_vue.settings'Starting development server at http://0.0.0.0:8000/Quit the server with CONTROL-C.

5、打开浏览器,访问http://localhost:8000,一切正常的话,可见到如下界面。

6. 将Django数据库更换为Mysql

1、假设在前面,我们已经安装配置好了Mysql,输入如下命令进入到Mysql。

mysql -u root -p

2、创建数据库,数据库取名为django_vue_db,并设置字符集为utf-8。

mysql> CREATE DATABASE django_vue_db CHARACTER SET utf8;Query OK, 1 row affected (0.01 sec)

3、安装myslqclient库

(venv) ➜ pip install mysqlclient

4、配置settings.py文件,配置Mysql数据库引擎。

```python
DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'django_vue_db', 'USER': 'root', 'PASSWORD': 'xxxxxxx', 'HOST': '127.0.0.1', }}```

5、执行同步操作,将数据迁移到Mysql。

python manage.py migrate

6、验证是否切库成功,进入到Mysql客户端,查看django初化表是否有生成。

mysql> use django_vue_db;Database changedmysql> show tables;+----------------------------+| Tables_in_django_vue_db |+----------------------------+| auth_group || auth_group_permissions || auth_permission || auth_user || auth_user_groups || auth_user_user_permissions || django_admin_log || django_content_type || django_migrations || django_session |+----------------------------+10 rows in set (0.00 sec)

7、运行Django Server,重新访问http://localhost:8000。

python manage.py runserver 0.0.0.0:8000

如果能正常访问,过程没有报错,说明切换数据库已经成功了。

7. 创建Django实战项目App

1、创建Django App,进入django_vue项目主目录,输入如下命令:

(venv) ➜ python manage.py startapp api_test

2、App创建完成后,目录结构如下所示:

├── api_test│ ├── __init__.py│ ├── admin.py│ ├── apps.py│ ├── migrations│ │ └── __init__.py│ ├── models.py│ ├── tests.py│ └── views.py

并把api_test加入到settings文件中的installed_apps列表里:

```pythonINSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'api_test',]```

3、 在api_test目录下的models.py里我们简单写一个model如下:

```python# -*- coding: utf-8 -*-from __future__ import unicode_literalsfrom django.db import modelsclass Book(models.Model): book_name = models.CharField(max_length=128) add_time = models.DateTimeField(auto_now_add=True)
def __unicode__(self): return self.book_name```

只有两个字段,书名book_name和添加时间add_time。如果没有指定主键的话Django会自动新增一个自增id作为主键。

4、在api_test目录下的views里我们新增两个接口,一个是show_books返回所有的书籍列表(通过JsonResponse返回能被前端识别的json格式数据),二是add_book接受一个get请求,往数据库里添加一条book数据。

```pythonfrom django.shortcuts import renderfrom django.views.decorators.http import require_http_methodsfrom django.core import serializersfrom django.http import JsonResponseimport json
from .models import Book
@require_http_methods(["GET"])def add_book(request): response = {} try: book = Book(book_name=request.GET.get('book_name')) book.save response['msg'] = 'success' response['error_num'] = 0 except Exception as e: response['msg'] = str(e) response['error_num'] = 1 return JsonResponse(response)
@require_http_methods(["GET"])def show_books(request): response = {} try: books = Book.objects.filter response['list'] = json.loads(serializers.serialize("json", books)) response['msg'] = 'success' response['error_num'] = 0 except Exception as e: response['msg'] = str(e) response['error_num'] = 1 return JsonResponse(response)```

可以看出,在ORM的帮忙下,我们的接口实际上不需要自己去组织SQL代码。

5、在api_test目录下,新增一个urls.py文件,把我们新增的两个接口添加到路由里:

from django.conf.urls import url, includefrom .views import *
urlpatterns = [ url(r"add_book$", add_book, ), url(r"show_books$", show_books, ),]```

6、我们还要把api_test下的urls添加到项目django_vue下的urls中,才能完成路由:

```pythonfrom django.contrib import adminfrom django.urls import pathfrom django.conf.urls import url, includefrom django.contrib import adminfrom django.views.generic import TemplateViewimport api_test.urls
urlpatterns = [ url(r"^admin/", admin.site.urls), url(r'^api/', include(api_test.urls)),]```

7、在项目的根目录,输入命令:

python manage.py makemigrations api_testpython manage.py migrate

8、查询数据库,看到book表已经自动创建了:

mysql> show tables;+----------------------------+| Tables_in_django_vue_db |+----------------------------+| api_test_book || auth_group || auth_group_permissions || auth_permission || auth_user || auth_user_groups || auth_user_user_permissions || django_admin_log || django_content_type || django_migrations || django_session |+----------------------------+11 rows in set (0.00 sec)mysql> desc api_test_book;+-----------+--------------+------+-----+---------+----------------+| Field | Type | | Key | Default | Extra |+-----------+--------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | | auto_increment || book_name | varchar(128) | NO | | | || add_time | datetime(6) | NO | | | |+-----------+--------------+------+-----+---------+----------------+3 rows in set (0.01 sec)mysql>```

Django生成的表名将以app名加上model中的类名组合而成。

9、在项目的根目录,输入命令:

python manage.py runserver 0.0.0.0:800

启动服务,通过httpie测试一下我们刚才写的两个接口。

10、通过调用接口向Django App中添加两条书名记录。

```shell➜ http http://127.0.0.1:8000/api/add_book\?book_name\=mikezhou_talkHTTP/1.1 200 OKContent-Length: 34Content-Type: application/jsonDate: Sun, 15 Dec 2019 09:11:12 GMTServer: WSGIServer/0.2 CPython/3.7.4X-Content-Type-Options: nosniffX-Frame-Options: DENY{ "error_num": 0, "msg": "success"}

➜ http http://127.0.0.1:8000/api/add_book\?book_name\=测试开发技术HTTP/1.1 200 OKContent-Length: 34Content-Type: application/jsonDate: Sun, 15 Dec 2019 09:11:44 GMTServer: WSGIServer/0.2 CPython/3.7.4X-Content-Type-Options: nosniffX-Frame-Options: DENY{ "error_num": 0, "msg": "success"}```

11、通过调用接口,显示Django App中所有书名列表:

```shell➜ http http://127.0.0.1:8000/api/show_booksHTTP/1.1 200 OKContent-Length: 305Content-Type: application/jsonDate: Sun, 15 Dec 2019 09:13:48 GMTServer: WSGIServer/0.2 CPython/3.7.4X-Content-Type-Options: nosniffX-Frame-Options: DENY{ "error_num": 0, "list": [ { "fields": { "add_time": "2019-12-15T09:11:12.673Z", "book_name": "mikezhou_talk" }, "model": "api_test.book", "pk": 1 }, { "fields": { "add_time": "2019-12-15T09:11:44.305Z", "book_name": "测试开发技术" }, "model": "api_test.book", "pk": 2 } ], "msg": "success"}```

8. 新建Vue.js前端项目

1、有关Vue的模块(包括vue)可以使用node自带的npm包管理器安装。推荐使用淘宝的 cnpm 命令行工具代替默认的 npm。

npm install -g cnpm --registry=https://registry.npm.taobao.org

2、先用cnpm安装vue-cli脚手架工具(vue-cli是官方脚手架工具,能迅速帮你搭建起vue项目的框架):

cnpm install -g vue-cli

3、安装好后,在django_vue项目根目录下,新建一个前端工程目录:

vue-init webpack frontend

在创建项目的过程中会弹出一些与项目相关的选项需要回答,按照真实情况进行输入即可。

4、安装 vue 依赖模块

cd frontendcnpm installcnpm install vue-resourcecnpm install element-ui

5、现在我们可以看到整个文件目录结构是这样的:

本文为了读者方便查看,是直接将vue前端工程放在django项目目录下,实际多人协作开发过程中,完全是可以放在不同代码仓库下面的。

6、在frontend目录src下包含入口文件main.js,入口组件App.vue等。后缀为vue的文件是Vue.js框架定义的单文件组件,其中标签中的内容可以理解为是类html的页面结构内容。

7、在src/component文件夹下新建一个名为Home.vue的组件,通过调用之前在Django上写好的api,实现添加书籍和展示书籍信息的功能。在样式组件上我们使用了饿了么团队推出的element-ui,这是一套专门匹配Vue.js框架的功能样式组件。由于组件的编码涉及到了很多js、html、css的知识,并不是本文的重点,因此在此只贴出部分代码:

Home.vue文件代码:

```vue
<template><div class="home"><el-row display="margin-top:10px"><el-input v-model="input" placeholder="请输入书名" style="display:inline-table; width: 30%; float:left"></el-input><el-button type="primary" @click="addBook" style="float:left; margin: 2px;">新增</el-button></el-row><el-row><el-table :data="bookList" style="width: 100%" border><el-table-column prop="id" label="编号" min-width="100"><template slot-scope="scope"> {{ scope.row.pk }} </template></el-table-column><el-table-column prop="book_name" label="书名" min-width="100"><template slot-scope="scope"> {{ scope.row.fields.book_name }} </template></el-table-column><el-table-column prop="add_time" label="添加时间" min-width="100"><template slot-scope="scope"> {{ scope.row.fields.add_time }} </template></el-table-column></el-table> </el-row> </div></template>
<script>export default { name: 'home', data { return { input: '', bookList: } }, mounted: function { this.showBooks }, methods: { addBook { this.$http.get('http://127.0.0.1:8000/api/add_book?book_name=' + this.input) .then((response) => { var res = JSON.parse(response.bodyText) if (res.error_num === 0) { this.showBooks } else { this.$message.error('新增书籍失败,请重试') console.log(res['msg']) } }) }, showBooks { this.$http.get('http://127.0.0.1:8000/api/show_books') .then((response) => { var res = JSON.parse(response.bodyText) console.log(res) if (res.error_num === 0) { this.bookList = res['list'] } else { this.$message.error('查询书籍失败') console.log(res['msg']) } }) } }}</script>
<!-- Add "scoped" attribute to limit CSS to this component only --><style scoped> h1, h2 { font-weight: normal; }
ul { list-style-type: none; padding: 0;}
li { display: inline-block; margin: 0 10px;}
a { color: #42b983;}</style>```

8、在src/router目录的index.js中,我们把新建的Home组件,配置到vue-router路由中:

```jsimport Vue from 'vue'import Router from 'vue-router'// import HelloWorld from '@/components/HelloWorld'import Home from '@/components/Home'Vue.use(Router)export default new Router({ routes: [ { path: '/', name: 'Home', component: Home } ]})```

9、在src/main.js文件中,导入element-ui、vue-resource库。

```jsimport Vue from 'vue'import App from './App'import router from './router'import ElementUI from 'element-ui'import VueResource from 'vue-resource'import 'element-ui/lib/theme-chalk/index.css'Vue.use(ElementUI)Vue.use(VueResource)Vue.config.productionTip = false
/* eslint-disable no-new */new Vue({ el: '#app', router, components: { App }, template: '<App/>'})```

10、如果出现跨域问题,需要在Django层注入header,用Django的第三方包django-cors-headers来解决跨域问题:

pip install django-cors-headers

settings.py 修改:

```pythonMIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'corsheaders.middleware.CorsMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware',]
CORS_ORIGIN_ALLOW_ALL = True```

PS: 注意中间件的添加顺序。

12、在前端工程frontend目录下,输入npm run dev启动node自带的服务器,浏览器会自动打开, 我们能看到页面:

13、尝试新增书籍,如填入:“自动化测试实战宝典”,新增的书籍信息会实时反映到页面的列表中,这得益于Vue.js的数据双向绑定特性。

14、在前端工程frontend目录下,输入npm run build,如果项目没有错误的话,就能够看到所有的组件、css、图片等都被webpack自动打包到dist目录下了:

9. 整合Django和Vue.js前端

目前我们已经分别完成了Django后端和Vue.js前端工程的创建和编写,但实际上它们是运行在各自的服务器上,和我们的要求是不一致的。因此我们须要把Django的TemplateView指向我们刚才生成的前端dist文件即可。

1、 找到project目录的urls.py,使用通用视图创建最简单的模板控制器,访问 『/』时直接返回 index.html:

```pythonurlpatterns = [ url(r"^admin/", admin.site.urls), url(r'^api/', include(api_test.urls)), url(r'^$', TemplateView.as_view(template_name="index.html")),]```

2、上一步使用了Django的模板系统,所以需要配置一下模板使Django知道从哪里找到index.html。在project目录的settings.py下:

```pythonTEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS':['frontend/dist'], 'APP_DIRS':True, 'OPTIONS': { 'context_processors': [ 'django.template.context_processors.debug', 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages', ], }, },]```

3、 我们还需要配置一下静态文件的搜索路径。同样是project目录的settings.py下:

```python# Add for vuejsSTATICFILES_DIRS = [ os.path.join(BASE_DIR, "frontend/dist/static"),]```

4、 配置完成,我们在project目录下输入命令python manage.py runserver,就能够看到我们的前端页面在浏览器上展现:

注意此时服务的端口已经是Django服务的8000而不是node服务的8080了,说明我们已经成功通过Django集成了Vue前端工程。

该实战示例为大家充分展示了现在主流的前后端分离方式,由前端框架,如Vue.js来构建实现前端界面,再通过后端框架,如Django来实现API数据提供,两者通过接口进行通讯、相辅相成、最终实现一个完整Web项目。

声明:前后端分离图片来源于网络,如有侵权,请联系删除。

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

根据 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) 中关于代码拆分的描述那样。

以上就是所有我想说的话,简单地说就是:

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