Oversharing modules can lead to perf degradation since a shared module cannot be tree shaken since its "used in unknown ways"

Also MF apps tend to have more chunks since shared/exposed modules are chunked out so its selectively loaded.

A good trick is to check if its cheaper not to share a vendor module (since tree shaking)

Another one is to make custom cacheGroups under splitChunks.
So i can test a regex for anything containing "react" and force it back into a single js file, so less requests needed for things that generally will always be needed. To make it work, you'd need to put enforce:true on the cacheGroup to override webpack default chunking of MFP.

Remember, everything is a tradeoff. A single monolithic build will have slightly better optimization since webpack can analyze everything - but at the cost of organizational agility, deploy couplings, and far less flexibility.

Old School MFES (like externals, or multi app mount points) have terrible performance but are flexible and provide deploy independence.

Module Federation is a combination of the two - more optimized than multi apps or externals, less optimized than single build. But usually not by much.

I mostly work with SSR based apps - so ive not really seen any perf impacts compared to a single build, this is because i can track and flush all script tags needed upfront so i dont have to wait for webpack to kick in, then load more js, creating a bit of a waterfall.

On the flip side - looking at your load times - the monolith took over a second, whereas the federated app took 800ms.

That said, look at the number of network requests in comparison. One single file to load, vs several.

A more fair tests would be to have your monolith use react.lazy and dynamic imports throughout.

If you use import from for your federated modules, this also slows things down as webpack has to load everything you imported BEFORE the app can even start.

So i always have a few import() in place or react lazy, so im only loading what's required upfront and if something is not rendered, im not delaying app start in order to download a bunch of sync imported modules that im not actually using.

Also consider the real world situation... 30kb or so more is not a bad price to pay for the gains, especially if you lazy load the extra things os needed.

To compare, ive got at least 2mb of third party code which adds 300 additional network requests to one of my applications.
So at scale, as long as you keep an eye on bundle size and check if sharing a module is worth the size bump or not - you should be good. So definitely keep an eye on perf and build perf - and id be happy to chat over twitter as i do quite a lot in the web perf space to mitigate the massive third party bloat i cannot control. See if we can optimize it a little more.

But always keep a holistic view...
A tag manager like adobe launch or GTM can easily add about 2-3 seconds to your site load time. Comparatively, theres much worst perf hits with higher rewards than my app loading an extra 100kb - tho thats no excuse not to care by any means.

In this case, the build size increase aside (since thats likely due to sharing modules that then need to opt out of tree shaking) - it might be the network requests that and using too much import from now forcing a waterfall just to start the app