Vue多页面配置打包性能优化方式(解决加载包太大加载慢问题)

目录
  • 一、问题描述及解决方案
    • 1. 多入口存在的问题
    • 2. 我的预期效果
    • 3. 可行方案
  • 二、方案一:打公共 chunks,单独分离各自的ui库
  • 三、方案二:删除默认splitChunk配置,抽离公共资源
  • 四、方案对比
  • 总结

通常我们使用vue-cli开发多页面的时候,不知道您是否注意一个问题没有?

默认情况:webpack 会将多入口通用的组件库等,打包一个 vendor 的 chunk js 中

现在假设有两个页面:

入口 admin 使用到了element-ui组件库和echarts图表库,入口 index 使用了iview的组件库

一、问题描述及解决方案

1. 多入口存在的问题

那么这样就会存在问题:

  • 打出来的chunk-vendor.xxxx.js会包含element-ui和echarts和iview组件库,所以 js 体积会非常大
  • chunk-vendor.xxxx.js默认是所有node_modules下面的库集合
  • index 入口只是使用了 iview,由于需要加载chunk-vendor.xxxx.js,所以造成了不必要的加载
  • admin 入口 同上 会额外引入 iview

2. 我的预期效果

那么针对以上的问题,我们预期应该是怎样的呢?

  • index 入口和 admin 各自单独打包,按需引入各自的库
  • index 和 admin 公用的库 只打包一次

3. 可行方案

针对以上的需求,我探索出了一下两种方案:

  • 删除默认 splitChunk 配置,打公共 chunks,单独分离各自的 ui 库(做减法)
  • 删除默认 splitChunk 配置,抽离公共资源(做加法)

二、方案一:打公共 chunks,单独分离各自的ui库

方案 1: 删除默认 splitChunk 配置,打公共 chunks,单独分离各自的 ui 库

删除默认 splitChunk 配置是了取消 webpack 的默认配置,因为 webpack 默认的配置是将node_modules下的所用到的库打包成一个chunk-vendor.xxxx.js。

主要分成三步:

  • 第一步: 删除默认 splitChunk 的配置
  • 第二步: 单独配出 splitChunk
  • 第三部: 为多入口,各自单独配置 chunks

详细配置如下:

let pages = {
  index: {
    entry: "src/main.js",
    template: "public/index.html",
    // 特别注意:由于各个入口单独分离了chunk之后,需要将对于的chunk名显示的列出
    chunks: [
      "index", //注意:这个是页面名称的chunk,下面的chunk名称需要对呀splitChunk对应的名称
      "chunk-vendors", //这是node_modules下的chunk
      "chunk-common", //这是admin和Index入口公用的chunk
      "chunk-iview" //index的单独chunk
    ]
  },
  admin: {
    entry: "src/admin.js",
    template: "public/admin.html",
    // 特别注意:由于各个入口单独分离了chunk之后,需要将对于的chunk名显示的列出
    chunks: [
      "admin", //注意:这个是页面名称的chunk,下面的chunk名称需要对呀splitChunk对应的名称
      "chunk-vendors", //这是node_modules下的chunk
      "chunk-common", //这是admin和Index入口公用的chunk
      "chunk-element-ui", //admin的单独chunk
      "chunk-echarts", //admin的单独chunk
      "zrender" //echarts用到了zrender
    ]
  }
};
module.exports = {
  pages,
  publicPath: process.env.BASE_URL,
  outputDir: "dist",
  assetsDir: "assets",
  runtimeCompiler: true,
  productionSourceMap: false,
  parallel: true,
  css: {
    // 是否提取css 生产环境可以配置为 true
    extract: true
  },
  chainWebpack: config => {
    if (process.env.NODE_ENV === "production") {
      // 删除系统默认的splitChunk
      config.optimization.delete("splitChunks");
    }
  },
  configureWebpack: config => {
    // 给输出的js名称添加hash
    config.output.filename = "[name].[hash].js";
    config.output.chunkFilename = "[name].[hash].js";
 
    config.optimization = {
      splitChunks: {
        cacheGroups: {
          // 抽离所有入口的公用资源为一个chunk
          common: {
            name: "chunk-common",
            chunks: "initial",
            minChunks: 2,
            maxInitialRequests: 5,
            minSize: 0,
            priority: 1,
            reuseExistingChunk: true,
            enforce: true
          },
          // 抽离node_modules下的库为一个chunk
          vendors: {
            name: "chunk-vendors",
            test: /[\\/]node_modules[\\/]/,
            chunks: "initial",
            priority: 2,
            reuseExistingChunk: true,
            enforce: true
          },
          // 由于Index入口使用了iview,所以讲iview单独处理出来,这样admin入口就不会使用此js
          iview: {
            name: "chunk-iview",
            test: /[\\/]node_modules[\\/]iview[\\/]/,
            chunks: "all",
            priority: 3,
            reuseExistingChunk: true,
            enforce: true
          },
          // 由于admin入口使用了element-ui,所以讲element-ui单独处理出来,这样index入口就不会使用此js
          element: {
            name: "chunk-element-ui",
            test: /[\\/]node_modules[\\/]element-ui[\\/]/,
                  //根据你实际的目录情况来决定 /[\\/]node_modules[\\/]_?element-ui(.*)/,
            chunks: "all",
            priority: 3,
            reuseExistingChunk: true,
            enforce: true
          },
          // 由于admin入口使用了echarts,所以讲echarts单独处理出来,这样index入口就不会使用此js
          echarts: {
            name: "chunk-echarts",
            test: /[\\/]node_modules[\\/](vue-)?echarts[\\/]/,
            chunks: "all",
            priority: 4,
            reuseExistingChunk: true,
            enforce: true
          },
          // 由于echarts使用了zrender库,那么需要将其抽离出来,这样就不会放在公共的chunk中
          zrender: {
            name: "zrender",
            test: /[\\/]node_modules[\\/]zrender[\\/]/,
            chunks: "all",
            priority: 3,
            reuseExistingChunk: true,
            enforce: true
          }
        }
      }
    };
  }
};

三、方案二:删除默认splitChunk配置,抽离公共资源

其实告诉你,webpack如果是多入口的话,删除默认的 splitChunk 配置,多入口会单独各自打包,但是公共资源不会抽取。

针对以上的情况我们可以通过以下三步达到优化目的:

  • 第一步:删除默认的 splitChunk
  • 第二步:抽离公共的入口资源
  • 第三部:为各自入口单独配置 chunks

详细配置如下

const BundleAnalyzerPlugin = require("webpack-bundle-analyzer")
  .BundleAnalyzerPlugin;
let pages = {
  index: {
    entry: "src/main.js",
    template: "public/index.html",
    chunks: ["index", "chunk-common"] //分别是入口的名称,也就是前面的key值,和公共chunk的名称
  },
  admin: {
    entry: "src/admin.js",
    template: "public/admin.html",
    chunks: ["admin", "chunk-common"] //分别是入口的名称,也就是前面的key值,和公共chunk的名称
  }
};
module.exports = {
  pages,
  publicPath: process.env.BASE_URL,
  outputDir: "dist",
  assetsDir: "assets",
  runtimeCompiler: true,
  productionSourceMap: false,
  parallel: true,
  css: {
    // 是否提取css 生产环境可以配置为 true
    extract: true
  },
 
  chainWebpack: config => {
    // 删除默认的splitChunk
    config.optimization.delete("splitChunks");
  },
  configureWebpack: config => {
    // js output config
    config.output.filename = "[name].[hash].js";
    config.output.chunkFilename = "[name].[hash].js";
 
    config.optimization = {
      splitChunks: {
        cacheGroups: {
          common: {
            //抽取所有入口页面都需要的公共chunk
            name: "chunk-common",
            chunks: "initial",
            minChunks: 2,
            maxInitialRequests: 5,
            minSize: 0,
            priority: 1,
            reuseExistingChunk: true,
            enforce: true
          }
        }
      }
    };
  }
};

四、方案对比

方案一: 删除默认 splitChunk 配置,打公共 chunks,单独分离各自的 ui 库(做减法)

优点:不需要处理公共 chunk,单独分离各自的 chunk 缺点:如果多入口使用的库比较多,需要各自单独的抽离

适用场景

适用于:多个入口页面耦合性比较强的(也就是多入口使用的公共资源比较多的),只有少量组件库不同

删除默认 splitChunk 配置,抽离公共资源(做加法)

优点:不需要单独分离各自的 chunk,只需要处理公共 chunk 即可 缺点:如果多入口公共库使用的比较多,抽离需要更加细致化

适用场景

适用于:多个入口页面耦合性比较低的(也就是多入口使用的公共资源比较少,通常是多个入口没有任何关系的)

总结

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。

(0)

相关推荐

  • 浅谈vue项目打包优化策略

    使用vue-cli部署生产包时,发现资源包很大,打包后的vendor.js达到了1.4M,这已经很大了,而且会影响到首屏加载.那么,怎么优化呢? 1.组件按需加载 这是首先可以优化的点.如果频繁使用了第三方组件/UI库,如我的项目中经常同时使用了 element-ui, mint-ui,echarts等组件库,如果全部引入,项目体积非常大,这时可以按需引入组件. 示例如下: 1.1 element-ui 首先,安装 babel-plugin-component: npm install babe

  • vue终极性能优化方案(解决首页加载慢问题)

    目录 前言 1.路由懒加载 2.打包文件中去掉map文件 3.CDN引入第三方库 4.gzip打包 1.npmi-Dcompression-webpack-plugin 2.在vue.config.js中配置 3.在NGINX中配置 5.终极大招,预渲染 1.cnpminstallprerender-spa-plugin--save-dev 2.vue.config.js 3.router.js 4.main.js 总结 前言 用vue开发项目上线以后,发现首页加载速度非常慢,如果项目比较大,甚

  • Vue 打包体积优化方案小结

    Vue-cli3 打包体积优化方案 前言: 公司项目完成后 ,打包完成后有1.18MB,其实感觉还行了,但是还可以有优化的地方,对于咱们有精益求精(有没有还是有点*数的)的精神下再去优化,可以先在项目中安装webpack-bundle-analyzer可以看到各个文件的大小 npm install webpack-bundle-analyzer -save-dev 在vue.config.js中进行配置 module.exports = { chainWebpack: config => { c

  • Vue多页面配置打包性能优化方式(解决加载包太大加载慢问题)

    目录 一.问题描述及解决方案 1. 多入口存在的问题 2. 我的预期效果 3. 可行方案 二.方案一:打公共 chunks,单独分离各自的ui库 三.方案二:删除默认splitChunk配置,抽离公共资源 四.方案对比 总结 通常我们使用vue-cli开发多页面的时候,不知道您是否注意一个问题没有? 默认情况:webpack 会将多入口通用的组件库等,打包一个 vendor 的 chunk js 中 现在假设有两个页面: 入口 admin 使用到了element-ui组件库和echarts图表库

  • vue2.x 从vue.config.js配置到项目优化

    vue.config.js 是一个可选的配置文件,如果项目的 (和 package.json 同级的) 根目录中存在这个文件,那么它会被 @vue/cli-service 自动加载.你也可以使用 package.json 中的 vue 字段,但是注意这种写法需要你严格遵照 JSON 的格式来写. 前言 在实际项目中优化也是经常需要做的事情,特别在中大型项目中降低打包体积大小,提高首屏加载时间是必不可少的,同时在面试中也是一个高频问题.本片文章我将从vue.config.js配置到项目优化前后效果

  • vue前端性能优化之预加载和懒加载示例详解

    目录 预加载 图片预加载 JS预加载 js的加载方式 preload prefetch Preload & Prefetch 的区别 不同资源加载的优先级规则 懒加载 图片懒加载 路由懒加载 组件懒加载 最后 预加载 预加载简单来说就是将所有所需的资源提前请求加载到本地,这样后面在需要用到时就直接从缓存取资源:我们使用该技术预先告知浏览器,等下某些资源可能要被使用,先把资源下载下来,不要等使用的时候再下载,可以看出这样的加载技术会增加服务器的压力,但是用户的体验会比较好,因为可以较快的看到后面的

  • 基于Tomcat安全配置与性能优化详解

    Tomcat 是 Apache软件基金会下的一个免费.开源的WEB应用服务器,它可以运行在 Linux 和 Windows 等多个平台上,由于其性能稳定.扩展性好.免费等特点深受广大用户喜爱.目前,很多互联网应用和企业应用都部署在 Tomcat 服务器上,比如我们公司,哈. 之前我们 tomcat 都采用的是默认的配置,因此在安全方面还是有所隐患的.上周对测试环境的所有服务器的tomcat都做了安全优化,其间也粗略做了一些性能优化,这里就简单记录分享下! 一.版本安全 升级当前的tomcat版本

  • vue多页面配置详情

    目录 1.多页面的区别 2.SPA 与 MPA 3.Vue Cli 脚手架配置 1.多页面的区别 单页应用这个概念,是随着前几年 AngularJS.React.Ember 等这些框架的出现而出现的.在前面的前言内容里,我们在页面渲染中讲了页面的局部刷新,而单页应用则是使用了页面的局部刷新的能力,在切换页面的时候刷新页面内容,从而获取更好的体验. 2.SPA 与 MPA 单页应用(SinglePage Web Application,简称 SPA)和多页应用(MultiPage Applicat

  • 解决vue单页面应用打包后相对路径、绝对路径相关问题

    在项目开发过程中,在部署过程中,用到了反向代理,这就要求前端代码中不能使用绝对路径.但是我们知道,一般情况下,通过webpack+vuecli默认打包后的HTML.css.js等文件,使用的都是绝对路径.下面可以举几个例子来看一下: 1.打包后的index.html文件 2.打包后的css文件 所以,如果在项目中需要使用相对路径来获取静态的资源文件,需要怎么做呢? 1.修改webpack配置文件中的assetsPublicPath,修改为如下图所示. 修改配置后,进行打包发现,打包后的index

  • Vue在外部配置打包文件夹名称和url地址前缀

    在public中添加以下两个js文件 config_build.js: module.exports = { //打包文件夹名 OUTPUT_DIR: 'test', //浏览器url地址前缀.需要同步更改config_settings.js中的ROUTE_PREFIX ROUTE_PREFIX: '/test/' } vue.config.js: const config_build = require('./public/config_build') module.exports = { p

  • Vite打包性能优化之开启Gzip压缩实践过程

    目录 前言 Gzip 开启 Gzip 插件的其他配置 总结 前言 在使用 vite 进行项目打包时,默认已经帮我们做了一些优化工作,比如代码的压缩,分包等等.除此之外,我们还有一些可选的优化策略,比如使用 CDN ,开启 Gzip 压缩等.本文会介绍在 vite 中使用插件来开启 Gzip 压缩. Gzip Gzip 是一种压缩算法,在网络传输中使用非常普遍.随便打开一个网页,都使用了 gzip 压缩: 需要注意的是,Gzip 压缩仅对于文本类型的资源有明显提示,压缩后的体积大约是压缩前的 1/

  • JavaScript性能优化总结之加载与执行

    前言 无论当前 JavaScript 代码是内嵌还是在外链文件中,页面的下载和渲染都必须停下来等待脚本执行完成.JavaScript 执行过程耗时越久,浏览器等待响应用户输入的时间就越长.浏览器在下载和执行脚本时出现阻塞的原因在于,脚本可能会改变页面或 JavaScript 的命名空间,它们对后面页面内容造成影响.一个典型的例子就是在页面中使用document.write(),例如清单 1 清单 1 JavaScript 代码内嵌示例 <html> <head> <title

随机推荐