Page reload on dev server is very slow in large codebase

[michalzubkowicz]

Describe the bug

In issue
#3208

You've asked to code example, so I've created one:
https://github.com/michalzubkowicz/slow-vite-demo

Problem is that when are many components involved, compilation and reload times are very slow, much more than same app built with Webpack. Example app starts up on my computer more than 10 second (I mean app startup in browser, not a HTTP server startup). Reload times are quite long in comparison to even bigger apps built with Webpack

There is also Firefox bug I've found that make whole thing worse:
https://bugzilla.mozilla.org/show_bug.cgi?id=1125322
It causes that Vite is quite unusable.

In Chrome (or other webkit browser) situation looks better, but still, loading many components (for example 2000) it
I think this problem can be leveraged with proper use of in React, but it needs some work.

Hope this time this report will be helpful

Reproduction

https://github.com/michalzubkowicz/slow-vite-demo

System Info

System:
    OS: Linux 5.16 Ubuntu 21.10 21.10 (Impish Indri)
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 4.93 GB / 15.32 GB
    Container: Yes
    Shell: 5.1.8 - /bin/bash
  Binaries:
    Node: 14.19.1 - /run/user/1000/fnm_multishells/153575_1649063119273/bin/node
    npm: 8.6.0 - /run/user/1000/fnm_multishells/153575_1649063119273/bin/npm
  Browsers:
    Chrome: 99.0.4844.84
    Firefox: 98.0.2
  npmPackages:
    @vitejs/plugin-react: ^1.3.0 => 1.3.0 
    vite: 2.9.1 => 2.9.1

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[jjbell150]

+1 I'm having the exact same issue with Vite 2.9.1 on a large React project, startup is instant but loading the page takes 60 seconds to fully load with constant timeouts and refreshes, would be great to have this fixed

[patak-dev]

@jjbell150 if you have a good reproduction, please also share it.

It would be good that both check with 2.8.6, 2.7.10, and 2.6.13. There were some users reporting regressions in 2.7 for example: #6030
Lets first see if this is a regression from 2.8 to 2.9

[michalzubkowicz]

2.6.13 -
first render: 2.0s
reload in edge 0.8s
reload in firefox: 2.2s,

2.9
first render: 2s
reload in firefox: 2.2s,
reload in edge 0.8s

So there is no regression between the versions

Same app built with webpack (CRA)
first render: 0.2s
reload in firefox: 0.2s
reload in edge: 0.2s

Difference in first render is quite obvious because of different approach, but reload times are Vite drawbacks
Also I've found that Vite doesn't show all errors in TypeScript code on build.
There is a random big difference in first render. Sometimes render time is 1second, sometimes is 10 seconds. I don't know what is the reason of this

[ProTip]

I'm seeing something very similar porting over a large React codebase. ~40s initial load time(I suspect largely due to tons of SASS) and then ~4.5 page reloads.

Perhaps I don't understand how the 304 responses are supposed to work, but there doesn't seem to be any speedup benefit for me between them not working(ssl with untrusted cert) and working(ssl with trusted cert). Each network request still returns the data, and the imports listed in those files are also requested. Seems like there is a tremendous amount of unnecessary loading occurring?

[patak-dev]

How many modules does your app have? The Vite model doesn't work well when you need to load 1K modules. You can check discussions at #4120.
Most apps that experienced these issues were able to refactor the code so it doesn't load the full project for each route, and instead lazy load as much as possible. This helps Vite a lot and is actually good practice for your users.

Once the App is loaded, another issue is circular dependencies. They will kill HMR and will trigger a full page reload. It is important to review and avoid them so you hit HMR as much as possible.

I think there is space for improvement though, it would be great to somehow get good warnings of circular dependencies and push people in the right direction. And also explore some ways to maybe pre-bundle parts of the App if you don't care about HMR for it at the moment (and lazy loading isn't possible for it).

[michalzubkowicz]

@patak-dev , even if you use lazy loading you'll endup with 40-50 components on page, which in my tests will load very slowly especially in Firefox. HMR can be very hard to maintain if there are some more complicates state setups so full reloads are very important. Warnings can be helpful, but conventions should be very clearly documented. At this point none of any apps I've seen are compatible with Vite without hard rewrite. It's not a accusation ;). Wish you all the best and good luck!

[carl-jin]

1014 requests in 400+ ms , it's not bad for me.
you can try to open the https and change browser to Chrome dev

check this article for more details ( in Chinese) https://carljin.com/vite-resolve-request-files-a-ton.html

[liam-jones-lucout]

I've noticed this in our storybook project once we switched to vite.

[OmarWebDev]

Still the same issue in Vite v3.1.8 is there any workaround?

[BigBallard]

We also are moving from CRA scripts to Vite and our project is not small by any means. 47 seconds on a refresh is simply not going to work at all. Are there any tips or tricks for quicker reloads or any plans to improve this performance?

Using:

• Vite v3.2.3
• @vitejs/plugin-react v2.2.0

[michalzubkowicz]

I don't think any workaround is possible. It's design flaw. You should probably split application into smaller parts.

[gooftroop]

We have this same problem and are unable to lazy load at this moment. Is there any effort being put towards resolving this design flaw?

[michalzubkowicz]

I apologize for the wrong wording here. It's not a flaw, but more a design decision. In Vite every component is treated as a separate file. This approach needs to build applications in such a way, that everything is lazy loaded to not load ALL components on every reload. You cannot just switch from CRA (Create React App) or even plain Webpack to Vite in a large project and expect that everything will work better out of the box.

It's wise to choose the right tool for the job, if you cannot do lazy loading probably Vite can be not the best choice, maybe you need some adjustments.

[mreduar]

I have a similar problem, maybe it is the same, maybe not. The truth is that my development compile now takes about 30 minutes to compile, this is something that only happens to me in the team, the rest of my colleagues compile in 2 seconds having the same code base, only they are in Linux with Docker and I am in Windows without docker, and no, it is not because of computer resources, and if it were I do not think the difference would be so brutal. We are working on a somewhat medium-sized project, about 400 components and counting.

We are using Tailwind, and I have read that it can cause slow startup, but why only me if we have the same configuration?

This is how long it takes me.

This is how long it takes my teammates.

Does anyone have any suggestions, or at least where to start?

[jjbell150]

@mreduar That looks like a WSL2 shell, so I'm going to take a wild guess that your code is stored on your C: drive?

If that's the case, then you need to move your code to the WSL2 filesystem, or if that isn't possible downgrade to WSL1: https://stackoverflow.com/a/68974497/2941601

[mreduar]

@mreduar That looks like a WSL2 shell, so I'm going to take a wild guess that your code is stored on your C: drive?

If that's the case, you need to move your code to the WSL2 filesystem or downgrade to WSL1: https://stackoverflow.com/a/68974497/2941601

No, I don't use WSL2, it's Windows Terminal but with Git Bash.

[lessquo]

@mreduar I've had a similar issue and it turned out there was a big dist (build output) folder inside a source folder. So I think it's worth checking out if there is any unnecessary git-ignored files in your project or simply reclone it, just in case.

[mreduar]

@mreduar I've had a similar issue and it turned out there was a big dist (build output) folder inside a source folder. So I think it's worth checking out if there is any unnecessary git-ignored files in your project or simply reclone it, just in case.

Thank you very much @lessquo!
That wasn't exactly the problem since I don't have a build folder inside a src folder, but it gave me a very good idea of what the problem could be and indeed the problem was a storage folder that was filling up with images/files every time I ran the seeder (I use Laravel with Vue) and as soon as I deleted that folder now the compilation only takes about 20 seconds, it's much longer than my peers, but it's still A HUGE change.
For some reason vite seems to search those files outside the src folder. There were 40Gb in files 😅

Thank you! Cheers

[semmywong]

The application took 1461ms to start, which is acceptable, buttttt.... in the browser, the components load took 4.5min, which is totally unacceptable.

My app have 2000+ components

[kylesloper]

This is pretty much rendering a workflow with vite + windows useless. Any plans ahead?

sveltekit, vite, windows

[orizens]

In my case i found out a to crossing plugin was the cause for that.
I suggest to comment out all the plugins and start adding until you see the issue.

[bluwy]

We have been improving Vite's performance lately and I believe this has been fixed. Closing this as the work has been completed, but if there's more to work on, we'll track it at #12363 instead. Appreciate if anyone following would give Vite 4.3 beta a spin too.