Vue组件库Webpack构建速度优化实战：从40s到17s

作者：雾松时间：2026-10-22 15:36:30浏览：586

本文记录了一个基于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，能够有效提升构建速度，其他方面还需进一步尝试。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持本站。

作者最新文章

Vue项目中怎么集成JS颜色选择器组件

2026-11-05 13:28:32

Nuxt 3 快速上手：项目初始化与目录结构详解

2026-11-03 19:16:51

怎么在 Vue 或 React 项目中正确集成 viewer.js

2026-11-02 09:17:48

Vue3+Vue-Router+Vite实现动态路由的完整流程与代码示例

2026-11-01 03:30:58

el-tree限制选中个数的实例

2026-11-01 03:09:07