Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ant-design-vue takes a long time to cold start in the vite build tool #5822

Closed
1 task done
core-admin opened this issue Jul 18, 2022 · 9 comments
Closed
1 task done

Comments

@core-admin
Copy link

  • I have searched the issues of this repository and believe that this is not a duplicate.

Version

3.2.6

Environment

window10 node:v16.13.0 vue:^3.2.37

Reproduction link

https://github.com/core-admin/ant-design-vue-vite-app-load-test.git

Steps to reproduce

在使用vite搭建项目时,引入ant-design-vue作为UI,在vite冷启动时,发现页面打开缓慢,使用vite提供的--debug参数,看了下启动耗时,发现主要的耗时时间都花费在了@ant-design/icons-vue的构建身份,平均每一个icons js文件的耗时为3000ms ,有个疑问,vite冷启动时,把@ant-design/icons-vue包中的全局文件做了一个预构建,是ant-design-vue底层在使用这个包时,全量引入了吗,没有批构建。

处理@ant-design/icons-vue耗时:平均时长在60s-80s左右

db13803b44065149511fe6775ce0564
2cb42981fc81bf0bf339307b8c9075e

对比了一下市面上其他几个UI,均在git仓库中进行了依赖安装,平均耗时如下:

naive-ui:

90f520d31086e3dc54842ad954ba8c1

@arco-design/web-vue:

8351e2dae762723a8fe9e33ebe75203

element-plus:

image

What is expected?

冷启动的的耗时缩减(想请教下作者,耗时久的原因大概在哪,有什么优化或者解决方法吗)

What is actually happening?

冷启动耗时太久

@github-actions github-actions bot changed the title ant-design-vue 在vite构建工具中冷启动耗时较长 ant-design-vue takes a long time to cold start in the vite build tool Jul 18, 2022
@lihanspace
Copy link

lihanspace commented Jul 21, 2022

刚刚新建了一个nuxt3项目,使用了ant-design-vue,我只在app.vue里使用了Button组件,但是Network中显示所有的图标都被加载了

ant-design-vue: 3.2.10
nuxt3: 3.0.0-rc.6-27638947.92269dd

import { defineNuxtConfig } from 'nuxt'

export default defineNuxtConfig({
  build: {
    transpile: ['compute-scroll-into-view', 'ant-design-vue']
  }
})
<script lang="ts" setup>
import { Button } from 'ant-design-vue'
</script>

<template>
  <div>
    <Button>Button</Button>
  </div>
</template>

image

@van-chin
Copy link

这个时间确实太久了

@core-admin
Copy link
Author

core-admin commented Jul 23, 2022

今天偶然用StackBlitz这个在线开发者工具导入了一下项目,发现运行速度挺快,看了下启动的运行日志,发现在处理icon js 文件时耗比我本地测试时耗时减少很多,且没有在处理完上一个文件时等待下一个文件处理(可能太快看不出来是串行还是并行),StackBlitz使用的是npm进行的包管理工具安装的依赖。一开始我以为是厂商提供的服务器好,我自己本地再次尝试了一下,这次并未使用 pnpm 进行依赖安装,使用npm安装的依赖(使用pnpm安装依赖报错了,故转而使用npm),启动测试大概尝试了10几次(每次启动时我都把 node_modules/.vite 预构建的资源删除了)从命令执行到显示出页面资源完全下载完毕平均时长为 26秒

StackBlitz 在线项目启动日志处理文件耗时(基于npm安装):

image

npm 依赖运行启动耗时:

image

比pnpm快了非常多,使用pnpm安装的依赖在运行时,处理icons js文件 没处理一个文件都会停一下,全部处理完到浏览器正常显示资源大概1分钟多(经过反复多次运行的平均值)

后又对比了 yarn 管理工具,使用其安装依赖重新测试,平均加载时长与npm差别不大

yarn 依赖运行启动耗时:

image

目前,已知使用pnpm管理工具,在第一次运行时处理文件的耗时远超其他管理工具(npm yarn)

yarn与npm安装的依赖,在编译@ant-design/icons-vue/es/icons下的文件时的耗时:

image

对比我之前发过的pnpm的耗时,pnpm处理每个文件时平均慢了10倍!!!

tangjinzhou added a commit that referenced this issue Jul 24, 2022
tangjinzhou added a commit that referenced this issue Jul 24, 2022
@izhouteng
Copy link
Contributor

有关优化,看这里 #5803

@core-admin
Copy link
Author

有关优化,看这里 #5803

好的我看一下,启动阶段目前vite确实把所有的icons js文件都处理了,这种情况下只能作者在源码上优化优化了,有个不太理解的点是,不同的包管理工具安装的依赖在启动时耗时差异还挺大,就比如我上面提到的npm与pnpm的对比,不知道是不是pnpm的包的管理形式不同造成的差异,这块不是很了解

@github-actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

@BabyLy233
Copy link

所以用pnpm的话现在还是只能用非解构语法引入图标来解决首次冷启动过慢的问题吗

@rxliuli
Copy link

rxliuli commented Oct 26, 2022

老实说,吾辈在考虑使用 esbuild 将 ant-design-vue 及依赖的图标库 bundle 起来,这对 esbuild 而言很快,只是几百 ms,但如果需要 rollup 解析,这会很慢。。。在开发环境整个引入也不是太大的问题

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants