探寻webpack打包vue前端项目的过程和出现的问题

简介: 前端 vue2 项目中,多人开发,从一段时间开始发现打包变得特别慢,每次线上更新也至少要10几20分钟,正常项目线上更新一般也就1、2分钟,新需求开发拉新分支本地运行也要至少5、6分钟才能运行的起来

前端 vue2 项目中,多人开发,从一段时间开始发现打包变得特别慢,每次线上更新也至少要10几20分钟,正常项目线上更新一般也就1、2分钟,新需求开发拉新分支本地运行也要至少5、6分钟才能运行的起来。

查找问题

为了找出打包慢的原因,我们首先得找到到底是哪些文件太大还是耗时太久?这中间用到了两个插件:

  • webpack-bundle-analyzer:分析打包过后的包的大小
  • speed-measure-webpack-plugin:分析各个插件和loader打包用时

1、安装 webpack-bundle-analyzer

# NPM
npm install --save-dev webpack-bundle-analyzer

# Yarn
yarn add -D webpack-bundle-analyzer

2、安装 speed-measure-webpack-plugin

# NPM
npm install --save-dev speed-measure-webpack-plugin

# Yarn
yarn add -D speed-measure-webpack-plugin

3、配置 webpack 这两个插件

// vue.config.js
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin')

module.exports = {
   
   
  configureWebpack: config => {
   
   
    config.plugins.push(new BundleAnalyzerPlugin())
    config.plugins.push(new SpeedMeasurePlugin())
  }
}

插件分析结果

  • 打包总时间:5分30.61秒
  • 打包文件总大小:24.03 MB
  • 打包时间比较长的插件和loader:@vue/vue-loader-v15、mini-css-extract-plugin、css-loader、postcss-loader、stylus-loader、cache-loader
  • 打包最大的单个文件:依赖了 echarts 的页面,大小为3.79MB,还有 xlsx 和 html2canvas 也比较大
    1.png
    2.png
    3.png
    猜测大饱满可能是 echarts 造成的,项目里是直接全部导入的 echarts 库,其实项目中只用到了一个折线图,先改成按需导入

按需导入 echarts 打包分析结果

按需引入封装的 echarts.js,项目中只用到了一个折线图,所以只需引入 LineChart:

// 引入 echarts 核心模块 和 Canvas 渲染器
import * as echarts from 'echarts/core'
import {
   
    CanvasRenderer } from 'echarts/renderers'

// 引入折线图图表
import {
   
    LineChart } from 'echarts/charts'

// 引入图表里用到的组件
import {
   
   
  LegendComponent,
  GridComponent,
} from 'echarts/components'

// 注册必须的组件
echarts.use([
  LegendComponent,
  GridComponent,
  CanvasRenderer,
  LineChart
])

export default echarts
<template>
  <div>
    <div ref="canvas" />
  </div>
</template>
<script>
  import echarts from './echarts.js'
  let LineChart = null // 图表实例

  export default {
    methods: {
      chartInit() {
        if (!LineChart) LineChart = echarts.init(this.$refs.canvas)

        // 设置参数
        LineChart.setOption({
          // ...
        }
      }
    }
  }
</script>
  • 打包总时间:5分52.31秒
  • 打包文件总大小:22.07 MB
  • 打包后的 echarts 的只有1点多MB

打包的文件大小确实有变小,但是打包时间缺变得更长了。

4.png
5.png
6.png

注意上面的分析都是基于 npm run dev 打的开发包。

目录
相关文章
|
2月前
|
JavaScript 前端开发 Docker
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
在使用 Deno 构建项目时,生成的可执行文件体积较大,通常接近 100 MB,而 Node.js 构建的项目体积则要小得多。这是由于 Deno 包含了完整的 V8 引擎和运行时,使其能够在目标设备上独立运行,无需额外安装依赖。尽管体积较大,但 Deno 提供了更好的安全性和部署便利性。通过裁剪功能、使用压缩工具等方法,可以优化可执行文件的体积。
147 3
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
|
1月前
|
缓存 前端开发 JavaScript
前端性能优化:Webpack与Babel的进阶配置与优化策略
【10月更文挑战第28天】在现代Web开发中,Webpack和Babel是不可或缺的工具,分别负责模块打包和ES6+代码转换。本文探讨了它们的进阶配置与优化策略,包括Webpack的代码压缩、缓存优化和代码分割,以及Babel的按需引入polyfill和目标浏览器设置。通过这些优化,可以显著提升应用的加载速度和运行效率,从而改善用户体验。
57 6
|
1月前
|
缓存 监控 前端开发
前端工程化:Webpack与Gulp的构建工具选择与配置优化
【10月更文挑战第26天】前端工程化是现代Web开发的重要趋势,通过将前端代码视为工程来管理,提高了开发效率和质量。本文详细对比了Webpack和Gulp两大主流构建工具的选择与配置优化,并提供了具体示例代码。Webpack擅长模块化打包和资源管理,而Gulp则在任务编写和自动化构建方面更具灵活性。两者各有优势,需根据项目需求进行选择和优化。
75 7
|
1月前
|
缓存 前端开发 JavaScript
前端工程化:Webpack与Gulp的构建工具选择与配置优化
【10月更文挑战第27天】在现代前端开发中,构建工具的选择对项目的效率和可维护性至关重要。本文比较了Webpack和Gulp两个流行的构建工具,介绍了它们的特点和适用场景,并提供了配置优化的最佳实践。Webpack适合大型模块化项目,Gulp则适用于快速自动化构建流程。通过合理的配置优化,可以显著提升构建效率和性能。
49 2
|
1月前
|
前端开发 JavaScript
手敲Webpack 5:React + TypeScript项目脚手架搭建实践
手敲Webpack 5:React + TypeScript项目脚手架搭建实践
|
2月前
|
缓存 前端开发 JavaScript
深入了解Webpack:模块打包的革命
【10月更文挑战第11天】深入了解Webpack:模块打包的革命
|
2月前
|
JSON 前端开发 JavaScript
前端模块打包器的深度解析
【10月更文挑战第13天】前端模块打包器的深度解析
|
2月前
|
存储 前端开发 JavaScript
前端模块化打包工具的深度解析
【10月更文挑战第13天】前端模块化打包工具的深度解析
|
2月前
|
缓存 前端开发 JavaScript
Webpack技术深度解析:模块打包与性能优化
【10月更文挑战第13天】Webpack技术深度解析:模块打包与性能优化
|
2月前
|
前端开发 JavaScript 开发工具
从零开始:构建、打包并上传个人前端组件库至私有npm仓库的完整指南
从零开始:构建、打包并上传个人前端组件库至私有npm仓库的完整指南
393 0