echarts组件打包体积分析

打包体积

在图片统计的菜单页面按需引入 14个js(7个无名)

组件中按需引入 图表

js 复制代码
require('echarts/theme/macarons'); // echarts theme
import * as echarts from 'echarts/core';
import { LineChart } from 'echarts/charts';
// 引入提示框,标题,直角坐标系,数据集,内置数据转换器组件,组件后缀都为 Component
import {
  TitleComponent,
  TooltipComponent,
  GridComponent,
  DatasetComponent,
  TransformComponent
} from 'echarts/components';
// 标签自动布局、全局过渡动画等特性
import { LabelLayout, UniversalTransition } from 'echarts/features';
// 引入 Canvas 渲染器,注意引入 CanvasRenderer 或者 SVGRenderer 是必须的一步
import { CanvasRenderer } from 'echarts/renderers';
// 注册必须的组件
echarts.use([
  TitleComponent,
  TooltipComponent,
  GridComponent,
  DatasetComponent,
  TransformComponent,
  LineChart,
  LabelLayout,
  UniversalTransition,
  CanvasRenderer
]);

打包体积最大的是images_statistics.js,为349kb

chunk-vendors.js 体积为290kb

images_statistics.j + chunk-vendors.js 的体积和为约640kb

入口main.js中全局引入,会导致chunk-vendors.js打包体积变大 14个js(7个无名)

可以看到,最大的是400kb

images_statistics.js + chunk-vendors.js 的体积和为约640kb

如果在入口文件中全局引入echarts 14个js(7个无名)

可以看到,chunk-vendor.js的体积会高达 619kb

同时,images_statistics.j的体积会减小到 3kb

二者之和为 620多kb

组件懒加载后 18个js(11个无名)

无名的971.js体积最大,为 347kb

chunk-vendor.js的体积会高达 289kb

对比图

对比可以看出,按需引入明显比全局引入要好,全局引入会导致入口js的体积变大,不如分开成两个js, 若在main.js中按需引入,会导致首屏加载变慢,考虑到本项目的图表集中展示在图片统计页面,可以将按需加载的位置放到图片统计页面。 至于是在图片统计页面懒加载引入三个业务图表组件,还是非懒加载引入,二者的体积相差不大,但懒加载的话,js会变多,请求次数会增加, 由于浏览器同一时间针对同一域名下的请求有一定数量限制,超过限制数目的请求会被阻塞。 综合考虑,图表统计页的三个图表组件使用非懒加载组件的方式,echarts图按需引入。 当然,如果使用图表的业务模块很分散,建议还是在入口文件中全局引入即可。

相关推荐
IT_陈寒44 分钟前
JavaScript的闭包把我坑惨了,说好的内存会自动回收呢?
前端·人工智能·后端
Jackson__2 小时前
分享一个横向滚动案例,带悬停暂停,通用性很强
前端
MariaH2 小时前
git rebase的使用
前端
_柳青杨2 小时前
深入理解 JavaScript 事件循环
前端·javascript
阡陌Jony2 小时前
关于前端性能优化的一些问题:
前端
用户600071819103 小时前
【翻译】简化 TSRX
前端
IT乐手4 小时前
佛德角逼平西班牙,国足还有啥借口?
前端
JustHappy5 小时前
我汇总了身边朋友的经历才发现,其实第一份实习是最难找的......
前端·后端·面试
星栈5 小时前
Dioxus 的响应式系统:`Signal`、`Memo`、`Effect` 和异步状态到底该怎么分工
前端·前端框架
yingyima5 小时前
Java 正则表达式:比你想象的更强大
前端