Where should micro frontends be composed? An empirical comparison of Module Federation, Single-SPA and React Server Components

Micro frontends let teams build and release parts of a web user interface independently, but the step that joins those parts into a page, the composition, can happen at very different places: in the browser through build-time module contracts, in the browser through a runtime router, or on the server. Practitioners choose between these options mostly on the basis of opinion. We report a controlled experiment in which one four-page e-commerce application was implemented three times, with Webpack Module Federation, Single-SPA and React Server Components in Next.js 15, sharing the same components, styles, data and React version. All three were deployed on the same platform and measured with an automated pipeline: 180 Lighthouse page loads per deployment target under Slow 3G, Fast 4G and broadband profiles, plus scripted ten-step shopping sessions for interaction latency. Server-side composition painted first content about twice as fast as the browser-side strategies on Fast 4G (0.47 s against 1.00 s and 1.40 s), showed the main content about half the time sooner and had no layout shift, at the cost of about 100 ms more main-thread work and the loss of independent deployment. The browser-side strategies kept team autonomy and were faster for in-page data operations. Image optimisation and layout reservation affected results more than the strategy in several cases. We also document a headless-browser measurement artefact that had inflated earlier results. We condense the evidence into a decision framework and release the testbed and data.