Splitting a large front end into separately built and deployed pieces, whether you call them micro frontends or something plainer, is a decision teams tend to make for the wrong reason. The reason is usually that the build is slow and the repository feels crowded. Those are real, but they are build problems, and splitting the application is an organizational change dressed as a technical one.
I think the decision goes better when a team asks a few questions first.
Do the pieces have different owners?
This is the one that matters most. A split pays off when each piece has a team that owns it end to end and rarely needs to change another piece to ship. If the same people will work across all of them, the split adds a seam without removing any coordination, and the seam has a cost every day.
What will be shared, and who owns that?
Every split front end still has a shell, a design system, routing, sign-in, and some way to pass state between pieces. Those become a platform, and a platform needs an owner. I think a lot of the pain stories come from a team that split the product and left the shared parts to whoever touched them last.
How will a user notice?
Two pieces loading two copies of a framework, or two versions of the component library, show up as a slower page and a flicker at the seam. A good answer is specific, such as one shared runtime, one version of the library, and a budget for what each piece may add to the page.
Could a build change get you most of this?
Build caching, a monorepo with task graphs, and clear module boundaries inside one application remove most of the slowness that starts these conversations. If the honest answer is that the build is the problem, I would fix the build first and keep the option to split for later. It is far easier to split a well-bounded single application than to merge three that drifted.
What is the way back?
Some splits do not work out, and the teams that recover are the ones that kept a path to recombine. Shared conventions, one component library, and no piece that depends on another's internals keep that path open.
Which question matters most
Ownership. In my experience a front end split along team lines, with a clear owner for the shared shell, usually goes well, and one split along technical lines with shared ownership usually does not. Where I am less sure is the very large product with dozens of teams, where some split is unavoidable and the real question becomes how few seams you can live with.
Photo source: https://photos.robertstowe.com/venice