本文记录了一个基于Vue的UI组件库在开发环境构建速度从40秒优化至17秒的全过程。通过尝试HappyPack多线程处理、DLLPlugin预编译依赖以及单组件按需加载等策略,最终发现性能瓶颈源于vue-loader v13.1.0引入的prettier代码格式化功能。通过锁定依赖版本,成功解决了构建缓慢问题,提供了实用的开发环境优化思路。
背景与问题概述
背景
在公司主要负责基于Vue的UI组件库(类似element-ui)的开发,工作已持续两个多月。期间一直感觉项目构建速度过慢,每次启动开发环境需要约40秒,体验极差。尽管尝试了多种优化手段,效果均不理想。直到今日找到根本原因,构建速度提升了50%以上,现在仅需17秒左右,开发体验大幅改善。在此记录整个优化过程,因仅针对开发环境,故重点考虑构建速度。
基础配置优化与HappyPack尝试
各种配置项的优化
主要尝试了对部分loader添加include和exclude等配置进行微调。实际上,这一措施带来的性能提升微乎其微,更多是心理安慰作用。
引入happypack
此前阅读过相关文章,介绍happypack采用多线程处理可显著提升构建速度。认为该方案可行,查阅GitHub文档后决定尝试。
修改webpack一些loader配置,使用happypack
// config.dev.js
{
// ...
module: {
rules: [{
test: /\.vue$/,
loader: 'vue-loader',
options: {
// 这里估计是都懒得写lang='scss'
css: 'style-loader!css-loader!sass-loader',
// vue文件中基本不存在css代码,所以只把js交给happypack处理
js: 'happypack/loader?id=babel'
}
}, {
test: /\.js$/,
use: 'happypack/loader?id=babel',
exclude: /node_modules/,
// components目录是组件,examples目录主要是markdown文档,test目录是单元测试
include: [utils.resolve('./components'), utils.resolve('./examples'), utils.resolve('./test')]
}, {
test: /\.scss$/,
use: 'happypack/loader?id=scss'
}]
},
plugins: [
new HappyPack({
id: 'babel',
threads: 4,
loaders: ['babel-loader']
}),
new HappyPack({
id: 'scss',
threads: 4,
loaders: [
'style-loader',
'css-loader',
{
loader: 'postcss-loader',
options: {
config: {
path: utils.resolve('./postcss.config.js')
}
}
},
'sass-loader'
]
})
]
// ...
}
主要将组件库中各类需处理的文件均交由happypack处理,除js、scss、vue外,还将md(通过vue-markdown-loader)等纳入处理范围。配置方式类似,此处不再赘述。
配置完成后运行测试,结果报错……查看官方文档发现不支持vue-markdown-loader。于是将md文件处理改回原状并重新运行。虽然成功启动,但耗时仅减少4-5秒,并未达到预期效果。
通过运行命令添加--progress参数观察,发现主要耗时集中在处理md文件上,进度条在遇到md文件时明显变慢。
由此确定,优化的主要目标应聚焦于md文件的处理。
查阅 build/util.js 中的相关处理方法,部分代码如下
function render(tokens, idx) {
// tokens是markdown-it parse后的结果
var m = tokens[idx].info.trim().match(/^demo\s*(.*)$/);
if (tokens[idx].nesting === 1) {
let index = idx + 1;
var html = '';
var style = '';
var script = '';
while (tokens[index].nesting === 0) {
const content = tokens[index].content;
const tag = tokens[index].info;
if (tag === 'html') {
html = convert(striptags.strip(content, ['script', 'style'])).replace(
/(<[^>]*)=""(?=.*>)/g,
'$1'
);
script = striptags.fetch(content, 'script');
style = striptags.fetch(content, 'style');
} else if (tag === 'js' && !script) {
script = striptags.fetch(content, 'script');
} else if (
['css', 'style', 'scss'].indexOf(tag) !== -1 &&
!style
) {
style = striptags.fetch(content, 'style');
}
index++;
}
var description = m && m.length > 1 ? m[1] : '';
var jsfiddle = { html: html, script: script, style: style };
var descriptionHTML = description ? md.render(description) : '';
jsfiddle = md.utils.escapeHtml(JSON.stringify(jsfiddle));
return `
<demo-block class="demo-box" :jsfiddle="${jsfiddle}">
<div class="source" slot="source">${html}</div>
${descriptionHTML}
<div class="hljs highlight" slot="highlight">
`;
}
return '</div></demo-block>\n';
}
主要逻辑是将tip放入指定container,提取tokens中标记为html、js、css代码的部分组成jsfiddle对象,传递给一个Vue组件以提供jsbin在线调试功能。利用markdown-it的render方法,将其他Markdown语法文档渲染为HTML代码放入指定div,并将HTML代码(即文档中的示例代码)作为slot分发给上述Vue组件。
此处实在未找到有效的优化手段。
DLLPlugin预编译依赖的局限性
引入dll
另一个尝试的手段是采用webpack的DllPlugin和DllReferencePlugin引入dll,将一些基本不会改动的代码预先打包成静态资源,让webpack减少处理量。
打包dll的配置
// config.dll.js
module.exports = merge(base, {
// ...
entry: {
vendor: ['vue', 'vue-router', 'vue-i18n', 'clipboard']
},
output: {
path: path.resolve(__dirname, './dll'),
filename: '[name].js',
library: '[name]_[hash]'
},
plugins: [
new webpack.DllPlugin({
name: '[name]_[hash]',
path: path.resolve(__dirname, './dll/vendor.manifest.json')
})
]
// ...
})
上述配置打包后会在build目录下生成dll目录,其中包含 vendor.dll.js 和 vendor.manifest.json。
然后在 config.dev.js 中,引入 DllReferencePlugin。
DllReferencePlugin配置
{
plugins: [
new webpack.DllReferencePlugin({
manifest: require('./dll/vendor.manifest.json')
})
]
}
接着记得将打包好的js文件引入,这里可以采用add-asset-html-webpack-plugin。
{
plugins: [
new AddAssetHtmlPlugin({
filepath: require.resolve('./dll/vendor.js'),
includeSourcemap: false
})
]
}
这样,在项目中webpack处理 vue vue-router vue-i18n clipboard时,就不会去node_modules中获取,而是直接使用vendor.js。
再次运行 npm run dev 发现时间仅减少了1秒(我认为这其实是时间的微小波动……实际上并没有减少)。毕竟大头不在这。
单组件开发模式的探索与局限
单组件的开发模式
后来突然想到,每次开发组件时不都是单个单个进行的吗?既然这样,我只处理指定组件的md文件,速度岂不是能提升?
这或许是个办法,尝试一下。
找到引入md文件的地方,即examples/route.js,部分代码如下
function loadDocs(path) {
return r => require.ensure([],
() => r(require(`./docs${path}.md`))
);
}
这是vue-router的动态加载,只要把path写成固定路径(这里其实就是'/' + 组件名),不就能实现了吗。
运行命令大致如下
// package.json
{
"scripts": {
"dev:component": "cross-env RUN_ENV=component node build/dev-server.js",
}
}
由于在命令行中使用webpack-dev-server无法传递参数给process.argv,因此这里采用webpack-hot-middleware。
// build/dev-server.js
const webpack = require('webpack');
const webpackConfig = require('./config.dev');
const express = require('express');
webpackConfig.plugins = webpackConfig.plugins || [];
// 全局开发模式采用webpack-dev-server 无需配置hmr,这里需要单独给上
webpackConfig.plugins.push(new webpack.HotModuleReplacementPlugin());
webpackConfig.entry.push('webpack-hot-middleware/client?path=/__webpack_hmr&timeout=20000');
const compiler = webpack(webpackConfig);
const hotMiddleware = require('webpack-hot-middleware')(compiler, {
log: false
});
const devMiddleware = require('webpack-dev-middleware')(compiler, {
publicPath: webpackConfig.output.publicPath,
quiet: true,
logLevel: 'silent'
});
const app = express();
app.use(hotMiddleware);
app.use(devMiddleware);
app.use('/build', express.static('./build'));
app.listen(webpackConfig.devServer.port || 8089, '127.0.0.1', () => {
console.log('Starting server on http://localhost:8089');
});
然后采用webpack的DefinePlugin动态写入一个组件名即可搞定,大致思路如下。部分实现如下:
const component = process.argv[2];
// 先判断一下是不是单组件开发模式,是的话,必须指定运行的组件
if (process.env.RUN_ENV === 'component' && !component) {
throw new Error('component is required, like: npm run dev:component slider');
}
// 然后通过DefinePlugin写入
// 对了这里有个要注意的点,path是个变量,不是字符串,所以不能是"'path'",真tm机智。
// config.dev.js
{
// ...
plugins: [
new webpack.DefinePlugin({
'process.env': {
NODE_ENV: "'development'",
RUN_ENV: process.env.RUN_ENV === 'component' ? "'component'" : "''",
component: process.env.RUN_ENV === 'component' ? JSON.stringify('/' + component) : 'path'
}
})
]
// ...
}
// 然后再把 `route.js` 的源码改下
function loadDocs(path) {
return r => require.ensure([],
() => r(require(`./docs${process.env.path}.md`))
);
}
万事俱备,赶紧运行测试。
> DONE Compiled successfully in 10792ms
效果不错,仅需10秒,打开浏览器查看,也没问题。确实不错。
关闭服务,尝试原来的dev命令是否也没问题。终端显示正常,但浏览器报错???(黑人问号脸)。

似乎是 webpack 无法正常处理,最后修改为以下形式才能正常工作。
function loadDocs(path) {
return r => require.ensure([],
() => {
if (process.env.RUN_ENV === 'component') {
r(require(`./docs${process.env.component}.md`));
} else {
r(require(`./docs${path}.md`));
}
}
);
}
另外,除了md文件只需处理一个组件外,组件源码中也有很多无需处理的部分,因此继续修改代码。
在应用的入口处将全局引入UI库的方式改为按需引入。
// 原来的代码
import Vue from 'vue'
import gsui from 'components'
// ...
Vue.use(gsui)
// 修改后的
import Vue from 'vue'
// ...
if (process.env.RUN_ENV === 'component') {
// 一些页面共用的组件
// 只能用require 不能import 因为是静态处理
Vue.use(require(`components/submenu`).default);
Vue.use(require(`components/menu`).default);
Vue.use(require(`components/layout`).default);
Vue.use(require(`components/menu-item`).default);
Vue.use(require(`components/header`).default);
Vue.use(require(`components/icon`).default);
Vue.use(require(`components/tooltip`).default);
Vue.use(require(`components/modal`).default);
Vue.use(require(`components/message`).default);
Vue.use(require(`components${process.env.component}`).default);
} else {
// 不是单组件开发模式引入全部
Vue.use(require('components').default);
}
优化后的单组件开发模式和全局开发模式的对比


但很快发现这并不实用,因为许多组件需要依赖其他组件,有时需要查看其他组件的文档,单组件模式无法做到这一点。
只能再寻找其他手段了。
vue-loader版本导致的性能瓶颈
意外发现,原来是vue-loader的版本原因带来的性能消耗
前日偶然浏览到一个名为at-ui的UI库,下意识查看其构建配置,发现与我们的非常相似(实际上webpack配置也大同小异),同样使用了vue-markdown-loader。出于好奇,clone其代码并在本地构建。结果出乎意料,他们的构建仅需16秒。为何差异如此之大?查阅其文档发现,他们同时提供中文和英文文档(我们的组件库暂时无英文文档)。虽然组件数量不如我们多,但文档数量多出几十个。既然耗时主要在md文件解析上,为何耗时差距如此悬殊?仔细查看其配置及md处理代码,虽然支持写法不同导致处理代码较少,但也不至于造成如此巨大的时间差异。
找不到原因,干脆尝试用他们的配置来构建我们的项目。将build目录完全复制过来,修改了entry、alias等少量配置,安装了一些我们项目中不存在的依赖,其他基本无需变动。运行看看效果。
经过几次报错修改后成功运行,但耗时仍为37秒左右,令人费解。再尝试另一种方式,用我们的配置去运行他们的项目。
将其项目的src和docs目录复制过来,同样修改entry、alias并添加一些loader,他们还需处理yml文件。运行结果更令人困惑,耗时40秒(再次疑惑)。最后,在我们的项目中用他们的配置运行他们的项目,旨在验证是否由某个依赖版本不同引起。结果证实确实如此……
接下来就是找出是哪个依赖导致的。这里需要注意一点,package.json中依赖的版本如^1.0.0,以^开头的依赖在安装时总会按照该大版本下的最新版本安装,即^1.0.0和^1.1.0都会安装1.x下的最新版本,而^1.0.0和^2.0.0则不同。主要尝试了几个不同版本的依赖,包括webpack(2.x和3.x)和vue-markdown-loader(1.x和2.x),但更换后依然缓慢。最后在同事提醒下,怀疑是vue-loader的问题,因为vue-markdown-loader依赖vue-loader,且无论是1.x还是2.x都使用vue-loader 12.x版本,而我们使用的是13.x。最终功夫不负有心人,发现从vue-loader的v13.1.0开始,构建速度会变慢。
变慢的原因
以下结果由公司一位技术专家发现
最终发现,v13.1.0以上的vue-loader采用prettier来格式化代码,替代了原来的js-beautify,正是这一改变导致了性能问题。
最后的配置
// config.base.js
module.exports = {
module: {
rules: [
{
test: /\.css$/,
use: [
'style-loader',
'css-loader',
{
loader: 'postcss-loader',
options: {
config: {
path: utils.resolve('./postcss.config.js')
}
}
}
]
},
{
test: /\.md$/,
loader: 'vue-markdown-loader',
options: {
use: [
utils.mdAnchor,
utils.demoContainer,
utils.tipContainer
],
preprocess: utils.mdPreprocess
}
},
{
test: /\.scss$/,
use: 'happypack/loader?id=scss'
},
{
test: /\.jsx?$/,
exclude: exclude: [/node_modules/, /^dll$/],
use: 'happypack/loader?id=babel',
include: [utils.resolve('./components'), utils.resolve('./examples'), utils.resolve('./test')]
},
{
test: /\.json$/,
loader: 'json-loader'
},
{
test: /\.(jpg|png|gif|eot|svg|ttf|woff|woff2)(\?.*)?(#.*)?$/,
loader: 'url-loader?name=[name].[hash].[ext]'
},
{
test: /\.vue$/,
// use: 'happypack/loader?id=vue'
loader: 'vue-loader',
options: {
loaders: {
css: 'style-loader!css-loader!sass-loader',
js: 'happypack/loader?id=babel'
}
}
}
]
},
resolve: {
extensions: ['.js', '.vue', '.json', '.scss', '.css'],
alias: {
'gs-ui': utils.resolve('./'),
components: utils.resolve('./components'),
examples: utils.resolve('./examples')
}
},
plugins: [
new HappyPack({
id: 'babel',
threads: 4,
loaders: ['babel-loader']
}),
new HappyPack({
id: 'scss',
threads: 4,
loaders: [
'style-loader',
'css-loader',
{
loader: 'postcss-loader',
options: {
config: {
path: utils.resolve('./postcss.config.js')
}
}
},
'sass-loader'
]
})
]
};
// config.dev.js
module.exports = merge(config, {
entry: entry,
output: {
path: '/',
publicPath: '',
filename: '[name].js'
},
plugins: [
new webpack.DefinePlugin({
'process.env': {
NODE_ENV: "'development'",
RUN_ENV: process.env.RUN_ENV === 'component' ? "'component'" : "''",
component: process.env.RUN_ENV === 'component' ? JSON.stringify('/' + component) : 'path'
}
}),
new HtmlWebpackPlugin({
template: utils.resolve('examples/index.html'),
filename: 'index.html',
inject: true
}),
new FriendlyErrorsPlugin(),
new OpenBrowserPlugin({
url: 'http://localhost:' + PORT
}),
new webpack.DllReferencePlugin({
manifest: require('./dll/vendor.manifest.json')
})
],
devServer: {
disableHostCheck: true,
host: '0.0.0.0',
port: PORT,
quiet: true,
hot: true,
historyApiFallback: true
},
devtool: 'cheap-eval-source-map'
});
最终优化后的构建速度为16-17秒,结果较为理想。

结语
最终发现是依赖版本带来的构建性能问题,严格来说不算webpack构建优化,只能算是一个踩坑经验。
其他在项目中可能用到的优化点主要是 happypack dll,能够有效提升构建速度,其他方面还需进一步尝试。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持本站。