First, clarify the shared dependencies: set only common libraries across multiple micro front-ends (such as React) to share and enable singleton and eager to avoid version conflicts and delays; 2. Intelligent lazy loading of remote components: combine React.lazy and Suspense to achieve on-demand loading, and preload key remote portals through prefetch to optimize user experience; 3. Optimize the construction output: implement code segmentation, tree shaking and compression in each remote module, use webpack-bundle-analyzer to analyze volume, ensure that shared dependencies are not packaged repeatedly; 4. Coordinate version and deployment: Check version consistency through CI/CD, use requiredVersion to quickly fail mechanism, follow semantic versions and interface contracts to prevent incompatibility; 5. Monitor runtime performance: utilize Lighthouse and performance Tools such as API track time-consuming remote loading and rendering, and continuously optimize. The correct use of Module Federation requires collaborative optimization in five aspects: sharing, loading, building, versioning and monitoring to achieve a high-performance and scalable micro front-end architecture.

Building perform micro frontends with Module Federation isn't just about splitting code—it's about doing it smartly so your app stays fast, maintainable, and scalable. Webpack 5's Module Federation is a game-changer for micro frontends, but if used naively, it can hurt performance. Here's how to get it right.

1. Understand the Core: Hosts, Remotes, and Shared Dependencies

Module Federation works by letting one application (the host ) dynamically load code from another (the remote ) at runtime. To make this performant, you need to:

• Define clear ownership : Each micro frontend should own its routes, state, and UI components.
• Use shared wisely : Reuse common libraries like React, React DOM, or Lodash—but avoid over-sharing.

 // webpack.config.js (host or remote)
new ModuleFederationPlugin({
  name: 'host_app',
  remotes: {
    dashboard: 'dashboard@http://localhost:3001/remoteEntry.js',
  },
  shared: {
    react: { singleton: true, eager: true },
    'react-dom': { singleton: true, eager: true },
  },
})

Key points:

• singleton: true ensures only one version loads—critical for React.
• eager: true loads the lib upfront during initial bundle, avoiding async delays.
• Don't mark everything as shared—only libraries used across many remotes.

?? Pitfall: Over-sharing increases initial bundle size. Only share what's truly common.

2. Lazy Load Remote Components (But Not Too Late)

Loading remote components lazily improves initial load time, but you need to balance it with UX.

Use dynamic imports with React.lazy and Suspense :

 const RemoteDashboard = React.lazy(() =>
  import('dashboard/Dashboard').catch(() => {
    // Fallback on error
    return { default: () => <div>Failed to load dashboard</div> }
  })
)

function App() {
  Return (
    <Suspense fallback="Loading...">
      <RemoteDashboard />
    </Suspense>
  )
}

But don't wait until the last second. Consider prefetching remote entries:

 <!-- In index.html -->
<link rel="prefetch" href="http://localhost:3001/remoteEntry.js" />

Or do it in code:

 // Preload remote on hover or app idle
useEffect(() => {
  const script = document.createElement('script')
  script.src = 'http://localhost:3001/remoteEntry.js'
  document.head.appendChild(script)
}, [])

? Pro tip: Prefetch remotes when the user lands on a page where they'll likely navigate next (eg, after login).

3. Optimize Bundle Size and Build Output

Even with federation, each remote still bundles its own code. Poor optimization here kills performance.

Apply these:

• Code splitting : Use dynamic imports within remotes too.
• Tree-shaking : Avoid importing entire libraries ( import * from 'lodash' ). Use named imports.
• Minify and compress : Enable Terser, Gzip/Brotli in your build.
• Analyze bundles : Use webpack-bundle-analyzer .

Also, ensure remotes don't re-bundle shared dependencies:

 // In remote config
shared: {
  react: { singleton: true, eager: true, requiredVersion: '^18.0.0' },
}

This prevents duplication. If versions mismatch, the build warnings you—fix it early.

4. Handle Versioning and Deployment Strategically

One of the hidden performance killers is version drift.

• If the host expects React 18 but the remote uses 17, the fallback behavior can cause hydration issues or double-loading.
• Deploying remotes independently means you can't assume compatibility.

Solutions:

• Enforce version alignment via CI/CD checks.
• Use a shared dev toolkit or design system package that pins versions.
• Consider Module Federation's requiredVersion to fail fast on mismatches.

Also, avoid breaking changes in shared interfaces. Use semantic versioning and contracts (eg, TypeScript interfaces) between teams.

5. Monitor Runtime Performance

Even if it builds fast, runtime matters.

Track:

• Time to load remoteEntry.js
• Time to render remote component
• JavaScript execution and parse time

Use tools like:

• Lighthouse for audits
• Webpack Bundle Analyzer
• Custom performance markers :

   performance.mark('start:load-dashboard')
  import('dashboard/Dashboard').then(() => {
  performance.mark('end:load-dashboard')
  performance.measure('dashboard-load', 'start:load-dashboard', 'end:load-dashboard')
  })

  Log these in dev or send to analytics in production.

  ---

  Final Thoughts

  Module Federation enables powerful micro frontend architectures, but performance isn't automatic. You need:

  • Careful dependency sharing
  • Smart loading strategies
  • Solid build optimization
  • Cross-team version coordination
  • Real monitoring

  Used right, it gives you scalable, independently deployable UIs without sacrificing speed.

  Basically: federate thoughtfully, optimize relentlessly.

  The above is the detailed content of Building Performant Micro Frontends with Module Federation. For more information, please follow other related articles on the PHP Chinese website!