Hi Silvan

sorry, you are absolutely right, I didn't answer directly and I’m glad you raised this topic again, hopefully, the following lines could amend what I missed.
As explained in the post, there are multiple flavors of micro-frontends, mapping a micro-frontend to a part of the view written in different frameworks will increase the bundle size, that’s true, that’s one of the reasons why Spotify moved away from using iframes for serving multiple views on the web:

Having iframes for every feature and having that feature load their own JS and CSS might have worked well for the desktop application, which the user downloads bundled with all the resources that it needs.
The web player, on the other hand, had to download many resources every time the user navigated between views, which resulted in long load times, which impacted user experience.

However, with the other flavor of micro-frontends, splitting up the application in multiple SPAs, single pages or SSR apps you will have the same control you have right now in the bundle size.
I can add also that a user can risk downloading less code even because if he remains inside only a micro-frontend during his session, he won’t need to download anything else more than what he is using, for instance in our application the authenticated part corresponds to a micro-frontend so the authenticated user won’t download anything related to the non-authenticated part.
Otherwise, he will need to download an additional bundle when he loads a new micro-frontends but there are strategies for sharing dependencies if needed.

If you want to know more about the approach we took feel free to read this and this post.
I hope this clarifies the point, sometimes I forget to highlight some key points but thanks again for raising the point again, for any additional concern or question feel free to reach me out, more than happy to discuss.