Replies: 11 comments 14 replies
-
|
Have also found this to be an issue using Purescript, as all Purescript dependencies are also built at the same time as app source code rather than being pre-built under Perhaps by providing a regex matching our module names, Vite could pre-bundle everything else under |
Beta Was this translation helpful? Give feedback.
-
|
Improving the experience for large apps is definitely on our radar. The performance work we did in Vite 4.3 was in part triggered by this. Our current thinking then was that the bottleneck isn't at the number of requests but in the time it takes to process them. Even with these improvements in place, there is a limit though. Loading 2500 modules is going to take a few seconds to load. The dev tools network freeze seems something that should be improved/reported on Chrome's side (@bmeurer are there issues you are aware tracking this problem?). It is also recommended to codesplit your app using dynamic imports, which would help a lot the experience. But we know this may not be possible for all apps. We also discussed how to pre-bundle parts of your apps. To add the mechanism needed to select what to prebundle and properly invalidate, we may end up replicating the tools that monorepos already offers. So maybe it is better to break down large apps into smaller packages so pre-bundling can take care of this. Anthony Fu created a vite plugin to explore this solution on user space: Note: the repo is using |
Beta Was this translation helpful? Give feedback.
-
|
Devtool network freeze is Chrome bug, It seems to be fixed in the latest version on Chrome 115. I think for large pages the bottleneck is the number of requests, because:
In my real project, I have used methods like dynamic imports to reduce the number of files loaded on first load, But for large projects, where the number of files is very high, these means have very little effect. vite-plugin-prebundle is a very good attempt. In the test repo, it reduced the reload time from 6~8s to less than 1s. but it still has some problems (can't be used with vue plugin) and can't be used in real projects. Very much looking forward to its future progress. A little personal thought, may be available in the future proposal-module-declarations simply merge the module files together directly, without code bundle, In this way, you don’t need to go through the bundling system, just work on the dev server module directly. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @patak-dev. Actually dev tools freezing was our main issue, the page itself actually loads fine. Code splitting is definitely something we would like to add, but for us this comes with its own Purescript-specific hurdles (unrelated to Vite). From our side actually I don't think we actually need Vite to decide what to prebundle outside of |
Beta Was this translation helpful? Give feedback.
-
|
As @yArna said, the Network panel slowness was a Chrome DevTools bug (https://crbug.com/1447912), which has been fixed. On the loading side, I'm not an expert, but I'd expect that with something like 2000+ requests, you are stretching the limits of what can be done fast in the browser. |
Beta Was this translation helpful? Give feedback.
-
|
Just tested the linked repo with latest Vite (5.0.4) and Results on my M2 Pro MBP:
Could just be that my machine is too fast... but then I tested with Parcel + 2500 components, and it took Parcel 3.16s to build before the page showed anything. In other words, Vite is actually faster than Parcel in your benchmark (at least on my machine). |
Beta Was this translation helpful? Give feedback.
-
|
Looks like my MacBook Pro 2019 is a bit outdated |
Beta Was this translation helpful? Give feedback.
-
|
More test results：https://github.com/yArna/vite-vs-x |
Beta Was this translation helpful? Give feedback.
-
|
Does anyone have some hack on Chrome that will allow it to load all the resources in parallel? I am using vite with 3000+ components and the actual issue is to load it when the DevTools is open... |
Beta Was this translation helpful? Give feedback.
-
|
I would like to backup the results of @yArna (great job 👍) : we are experiencing exactly the same symptoms on our large React app. We are moving away from CRA and we experienced the degradation of the dev experience, not the improvements. Most of the time is spent in stalls indeed (I attach a HAR file): the majority of the load time is taken by the dependency chunks loading (rather stalls). 
Here's the app stats: Half of the time nothing happens network-wise which suggests that actual loading time could be ~4-5 seconds, not 10-15 seconds: I hope this helps to further improve. We are now scratching our heads to understand if we should stick with ViteJS or move to other solution. |
Beta Was this translation helpful? Give feedback.
-
|
Could your provide a cpuprofile? (using --profile, then P+enter after loads end) About the stalled requests, you could try the new option in this PR (that I hope we could merge soon, and it will be in vite 5.1): Also a good idea to check extensions: https://twitter.com/patak_dev/status/1745427465617433005 |
Beta Was this translation helpful? Give feedback.
-
|
@patak-dev Thanks for the quick response! I did a clean test with no extensions, with cold load + Addition: after the first cold load, subsequent loads take ~10 seconds instead of 25 (with caching disabled in browser). |
Beta Was this translation helpful? Give feedback.
-
|
You can open the profile in https://www.speedscope.app/ to review it Some quick finds, 43% of the server time is spent on plugin-inject. It is better to find another way to do this. Maybe you could evaluate https://github.com/unplugin/unplugin-auto-import sass takes another 22% of processing time, it would be better to switch to postCSS, but preprocessors may get a speed up if we merge #13584 You should also enabled cached fs trees, see: https://twitter.com/patak_dev/status/1734509163978301594 |
Beta Was this translation helpful? Give feedback.
-
|
Is there any news on this we have the same issue and behaviour in the browser in our large app. |
Beta Was this translation helpful? Give feedback.
-
|
Check this comment #13697 (reply in thread), maybe you could share your cpuprofile and check it out with speedscope, and check the performance guide to see what can be applied to your app. |
Beta Was this translation helpful? Give feedback.
-
|
Has anyone solved this or have a way to improve initial page load? |
Beta Was this translation helpful? Give feedback.
-
|
The best solution at the moment is to switch to https://www.rspack.dev |
Beta Was this translation helpful? Give feedback.
-
thank a lot for the suggestion! |
Beta Was this translation helpful? Give feedback.
-
|
The slow initial page makes it very difficult to use Vite with Cypress E2E tests, because a typical Cypress test starts with |
Beta Was this translation helpful? Give feedback.
-
|
@mracette We had the same exact problem, and our solution was to replace Cypress with Playwright. It's better in pretty much every way and fixes this issue. I realize that's a huge undertaking, but it is possible to run e2e tests with the Vite dev server; you just have to use the right e2e framework. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
In theory you should not run your E2E from the development environment (unless you have a specific use case). You should rather build your app and run them via |
Beta Was this translation helpful? Give feedback.
-
|
☝️ We also do this in our CI, and the results are very reliable. The Vite dev server actually won't start in our CI because it's too resource intensive, but |
Beta Was this translation helpful? Give feedback.
-
|
We are certainly not running |
Beta Was this translation helpful? Give feedback.
-
|
have exactly the same problem. I am migrating Cypress to Playwright and we have 1000 components, which are loading slowly on each test. So my suggestion was to start testing with Vite preview and reuse the build folder we have with CI Github. |
Beta Was this translation helpful? Give feedback.
-
|
From my experience migrating to Vite and Rsbuild: I migrated my large CRA project to Vite for the first time. However, it had many barrel files and used ".js" instead of ".jsx", so I needed to spend a lot of time addressing these issues to complete the migration. After successfully migrating to Vite, I encountered issues with the initial load being too slow, which was very frustrating. Then I found Rsbuild, which saved me. Migrating to Rsbuild was easy and resolved my initial load issues. Vite is awesome, but migrating from CRA is not perfect. |
Beta Was this translation helpful? Give feedback.
-
When i use Vite on a real world large web app, we encounter a poor experience: page reloading is extremely slow, and using the network panel in Devtool may result in freezing for several minutes.
The reason is that Vite's current unbundle mechanism is not suitable for large web app development, as it reloads a large number of code files and generates numerous requests on every page refresh. While Vite has Dependency Pre-Bundling to solve third-party dependency issues, for large web app, our own codebase is also substantial. When a page has 500 source files simultaneously, the development experience becomes terrible, and this number is not uncommon for large web app. Our real projects have 1500 to 2500 source files.
If the page undergoes hot reload, the speed is very fast, but not every code modification can be hot reloaded. Furthermore, page reloading (including page navigation) is often required during development and testing.
Users initially have a good experience using Vite for faster development. However, as the project grows, they find that page reloading becomes slower and freezing may occur for several minutes when using the network panel in Devtool. At this point, users may discover that tools like Parcel, which bundle during development, provide a better experience. Although Parcel may have a slower startup, it becomes fast once it is up and running, and the network panel in Devtool does not freeze.
For large web app, the current unbundle mechanism is not suitable because there will always be a significant number of requests. Perhaps Vite can provide an option to bundle during development, where the majority of code files are bundled, or find other ways to reduce the number of requests.
I believe this is a pressing issue that Vite needs to address because over time, the projects of Vite users will continue to grow. When users realize that the development experience with Vite is deteriorating, they will face the dilemma of migrating to development bundling tools like Parcel. Vite has excellent development experience and ecosystem, and I hope it can solve this problem and retain users of large-scale web apps within the Vite ecosystem.
Numbers
100%2%100%1.3%Reproduction
Parcel vs Vite Reload Benchmark
Beta Was this translation helpful? Give feedback.
All reactions