Significant increase in initial load time after migrating to Vite + @module-federation/vite in multi-remote setup

[aryavgopal]

Describe the bug

Hi team. We are running into significant initial load time and bundle size issues after migrating a large micro-frontend application from Webpack Module Federation to Vite using this plugin, and we would like to understand whether:

• This is expected behaviour for our architecture
• We might be misconfiguring something, or
• There are recommended optimizations we are missing

Our setup (simplified):

• Host application
• 9 remotes all using Vite (more expected in the future)
• One remote acts as a shared/common library used by host and most of the remotes
• All applications are React based
• All applications are using @module-federation/vite

Observed Issue

After migration,

• Initial page load increased significantly (~ half a min)
• Bundle size increased noticeably
• Network tab shows a large number of JS requests and many small chunks. Some of them are of the kind __loadShare__react__loadShare for every remote loaded. Also, the shared MFE has a similar loadRemote for every remote using it
• Giving singleton and required version to shared dependencies makes the application reload infinitely

What we have already tried

• Ensured react and react-dom are shared and on same versions in all the applications
• Lazy load remotes

Host config (simplified)

export default defineConfig(({ mode }) => {
    return {
        ...
        plugins: [
            react(),
            tsconfigPaths(),
            federation({
                name: env.REACT_APP_NAME,
                filename: 'remoteEntry.js',
                exposes: {},
                remotes: {
                    remote1: {
                        type: 'module',
                        name: 'remote1',
                        entry: <remote 1 entry url>
                    },
                    remote2: {
                        type: 'module',
                        name: 'remote2',
                        entry: <remote 2 entry url>
                    },
                    .....
                },
                shared: Object.keys(deps),
            }),
        ],
        build: {
            target: 'esnext',
            modulePreload: false,
        },
        optimizeDeps: {
            esbuildOptions: {
                target: 'esnext',
                loader: {
                    '.js': 'jsx',
                },
            },
            exclude: ['@module-federation/vite'],
        },
    };
});

Network tab screenshot with JS filtered

We would really appreciate guidance on:

• Whether this initial load cost is expected for a setup of this size
• Recommended performance best practices for large MF systems with Vite
• Whether there are known bundle size or runtime overhead limitations
• Any suggestions for reducing request count/chunk waterfalls

About reproduction

We understand that a minimal reproduction is usually preferred, however a truly representative reproduction would require multiple remotes with a shared remote as well. Please let us know what level of reproduction would be most useful.

Thanks in advance for your time and help. We really want to make this setup work well at scale.

Version

7.1.11

Reproduction

https://github.com/aryavgopal/vite-mfe-sample

Relevant log output

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[gioboa]

I'm sorry to hear that.
mfe/vite is a community repo hosted here, but it is going to be replaced by the official mfe support from rolldown/vite team.
My suggestion is to use Rspack federation.

[gioboa]

Anyway, can you try to load a React Hello World app in your architecture?
is it fast or is it slow?
We can start from that to investigate.

[aryavgopal]

Thanks for the suggestion @gioboa.
We have created a minimal reproduction following the same architecture as our setup:

• Host
• Shared MFE (common components)
• One feature remote
• One "Hello World" remote

Observations

• Initial load time: ~1.25s
• Transferred size: ~3.3MB

When inspecting the Network tab for the shared MFE, we notice multiple virtual prebuild chunks being loaded:

• mf__virtual_shared__prebuild. In this case for react, react-dom and classnames as these are the libraries used in shared MFE
• shared_widgets.js for every app consuming it

Could this suggest that the shared MFE and/or its deps are being initialized multiple times, rather than being shared across the apps? This behaviour appears to scale non-linearly as the number of remotes increases. Is there a recommended configuration to ensure that it is truly shared?

We had observed several loadShare__react__loadShare chunks(some have react-router-dom chunk as well) loaded for every remote in our original setup, however this is not observed in the minimal setup.

While 1.25s is reasonably fast for a simple setup, we see as remotes increase, the JS requests and prebuild chunks increase, contributing to load time.

We're happy to iterate on the reproduction or provide further data if needed.
Thank you for your time and support.

[aryavgopal]

Anyway, can you try to load a React Hello World app in your architecture? is it fast or is it slow? We can start from that to investigate.

Sharing the repo for the minimal setup: https://github.com/aryavgopal/vite-mfe-sample

[zhangHongEn]

Please use manifest — it is specifically designed to solve this problem.