What Are Micro Frontends? Scalable Architecture for Large Enterprise Websites

When five teams ship code into the same frontend, every release starts to feel like a negotiation. Micro frontend architecture is one answer to that bottleneck. I have worked on enterprise websites and SEO since 2012. In this guide, I therefore look at micro frontends the way a decision maker should: real benefits, real costs and the SEO traps in between.

What is a micro frontend?

A micro frontend is an independently developed, tested and deployed slice of a website's user interface, usually owned by one team and one business domain. The page then combines several micro frontends, so the visitor sees one coherent site while each team ships on its own schedule.

One of the clearest references is Cam Jackson's article on martinfowler.com. It describes micro frontends as an architectural style that composes independently deliverable frontend applications into a greater whole. In other words, this is not a library or a product you buy. It is a decision about how teams split code and how the page comes back together.

For example, on a large retail site, search, product detail, basket and account could each be a separate application. A shopper on a product page might therefore see code from three teams on one screen. So the hard part is not writing the pieces. The hard part is joining them quickly and consistently.

Which problem were micro frontends designed to solve?

Once microservices became common on the backend, many companies noticed an odd mismatch. Their services were independent, yet the frontend was still one large block. As a result, the checkout team often waited for the catalog team's test suite before it could release a one line fix.

Micro frontends target exactly that bottleneck. The promise is simple: each team decides within its own domain, releases at its own pace and stops worrying about breaking another team's code. Put simply, the problem they solve is organisational more than technical.

• Dozens of developers colliding in one repository and long merge queues.
• A single bug blocking the release of the entire site.
• Having to rewrite the whole site at once to escape an old framework.
• Ownership boundaries that nobody can see in the codebase.

Conway's law, a well known idea in software, points the same way: organisations tend to design systems that mirror their own communication structure. So if your teams follow business domains but your code is one block, friction is unavoidable. That said, if your teams are not yet clearly separated, splitting the code first will not help. It only moves the waiting to a new place.

If none of the problems above sound familiar, this architecture will most likely add a problem rather than remove one. I come back to that point later in the article.

How does a micro frontend differ from a monolithic frontend?

In a monolithic frontend, every page lives inside one application: one repository, one build, one deployment pipeline. With a split frontend, each part can have its own repository, build process and release calendar. However, there is a wide grey zone between the two.

A modular monolith, for instance, organises code into packages by business domain but still ships in one release. For many companies, this middle path delivers a large share of the benefits at a much lower cost. Also, the table below summarises the trade offs in plain business terms.

These ratings reflect my own field experience. Read them as a directional summary, not as a measured benchmark.

Why should you keep information architecture and code architecture apart?

I often hear this in meetings: "Our site has grown huge, let's move to micro frontends." Yet size has two separate axes. The first is what visitors and Google see: categories, URLs and menus. The second is what developers see: repositories, packages and pipelines.

I cover the visitor side in my guide to category structure for large websites. This article deals only with code. The two connect, but neither replaces the other, because they answer different questions. If your category structure is messy, a new code architecture will not fix it. Instead, it will simply spread the mess across more repositories.

Therefore my first question is always the same. Is your problem that visitors cannot find their way, or that teams keep waiting for each other? The first is an information architecture job. The second is a code architecture job. A wrong diagnosis leads to a wrong budget.

How do micro frontends come together on a page?

The heart of this architecture is composition, the moment when separate parts become one page. That can happen in three places: at build time, on the server or CDN edge, and in the browser. The place you choose shapes team autonomy, and it also shapes SEO and performance.

1. Build time integration: each team publishes a package, and the main app compiles everything together.
2. Runtime integration via JavaScript: a shell application loads each part in the browser on demand.
3. Module Federation: separate builds exchange code at runtime and share common libraries.
4. Iframes: each part runs as its own document inside the page.
5. Server side and edge composition: the server or CDN edge stitches HTML fragments and sends a ready page.

No single option wins everywhere. In practice, large sites often run a hybrid: SEO critical pages come together on the server, while logged in dashboards come together in the browser. Let us look at each option in turn.

What is build time integration, and why does it often fall short?

With build time integration, every team publishes its part as a package. The main application adds those packages as dependencies and produces one output. In addition, setup is easy, performance is predictable and server side rendering works without friction.

The catch is significant. Jackson's article warns that this approach creates a lockstep release process. A change in one part means you rebuild and redeploy the whole application. So the main promise of the architecture, independent releases, largely disappears.

Still, I would not dismiss it. If you have few teams and your real need is tidy code, build time integration is really a polite name for a modular monolith. For many companies, that is also the right starting point.

How does runtime integration via JavaScript work?

Here a shell application, often called the container, sets up the page skeleton. Then it decides which part each route needs and downloads that part's JavaScript at runtime. Each team can update its own bundle whenever it wants, and the shell does not need a rebuild.

For independent releases, this is one of the most flexible options. In the open source world, orchestration tools such as single-spa helped popularise the model. Web Components also offer a standard way to package parts as custom HTML elements that do not depend on one framework.

On the other hand, the browser pays the bill. If the page waits for the shell, then the part, then the part's data, the first load slows down noticeably. Moreover, when content only exists after JavaScript runs, search engines depend on the rendering step to understand the page. I return to both risks in the SEO section below.

What is Module Federation, and what does it add to micro frontends?

Module Federation is a feature that arrived with webpack 5. According to the webpack documentation on Module Federation, its goal is to let multiple separate builds form a single application. In practice, each build acts as a container. It can expose code to others and consume code from them.

• Host: the main application that consumes modules from other builds.
• Remote: a separate build that exposes modules, usually through an entry file.
• Shared: a setting that lets common libraries such as React load once instead of once per part.
• Singleton: a rule that forces a library to run as a single copy on the page, which matters for state libraries.

From a decision maker's point of view, the real value is sharing. Set up well, the browser downloads a common library once rather than five times. However, version compatibility now becomes your responsibility. When one team upgrades a major version of a shared library, you need a plan for how the other teams will follow.

Do iframes still make sense for micro frontends?

Iframes are the oldest and strongest way to isolate parts. Each part runs in its own document, so CSS rules and JavaScript errors cannot leak into the others. That is why iframes still work for third party payment forms or admin screens that you carry over from a legacy system.

For public pages that target search traffic, however, I rarely recommend them. Responsive height, deep linking, the back button and accessibility all create extra work. SEO also adds uncertainty. Google's announcement of the indexifembedded tag explains that Google tries to associate iframe content with the parent page, but that this is not guaranteed.

In short, consider iframes for logged in areas that you do not want indexed anyway. For product, category and content pages, choose another integration path.

How do edge and server side composition work?

In this approach, composition happens before anything reaches the browser. The server or CDN edge calls HTML fragments from different teams and assembles them into one page. As a result, the browser receives complete HTML from the start. Server Side Includes and Edge Side Includes were early versions of this idea. Today you can do similar stitching with edge functions on modern CDNs.

For SEO and first load, this model is usually the healthiest option, because search engines and users see content before any JavaScript runs. Interactive parts then come alive in the browser through hydration.

The cost sits in operations. For instance, if one fragment server slows down, the whole page can slow down with it. So you need a timeout, a cache rule and a fallback for every fragment. For example, if the recommendations fragment does not answer within a few hundred milliseconds, the page should simply open without it.

Which micro frontend integration fits which situation?

You can map the options above to the list below. That said, it is not a recipe. It is the framework I use as a starting point in architecture meetings with client teams.

• Few teams, need for order: build time integration or a modular monolith.
• SEO critical storefront pages: server side or edge composition, then selective hydration.
• Logged in dashboards and apps: runtime JavaScript integration or Module Federation.
• Third party or legacy parts that need isolation: iframes.
• Framework migration: a shell app with route based runtime integration, so old and new code live side by side for a while.

Notice that one company can use several lines of this list at once. So instead of asking which method is best overall, ask which method fits each page type.

When are micro frontends unnecessary complexity?

To be honest, most enterprise sites I review do not need micro frontends. For a site of a few hundred pages run by one team, the architecture multiplies pipelines, monitoring tools and version debates. In return, however, it delivers almost nothing.

Jackson's article lists the downsides plainly. First, payload size grows because of duplicated dependencies. Second, local development environments can drift from production. Finally, operational complexity rises, since you now manage more repositories, pipelines and servers. These are not theoretical risks. They show up on the maintenance invoice every month.

• Only one team or two or three developers work on the frontend.
• You release a few times a month and nobody waits for anybody.
• The real complaint is speed, design or content.
• You have no platform team to own shared infrastructure.

If even two of these apply, first try splitting the code into modules and speeding up the pipeline. More often than not, the fix is right there.

Which signs show that you really need micro frontends?

Looking from the other side makes the picture clearer. I put this architecture on the table mostly for large ecommerce, banking, insurance, media and multi brand corporate sites. What they share, above all, is a high number of teams working on the frontend.

1. Several independent product teams change the same frontend many times a week.
2. Teams follow clear business domains, and every domain has a known owner.
3. You need to move from an old framework to a new one without freezing the site.
4. After a merger or acquisition, you must bring sites built on different stacks under one roof.
5. You have a platform team that can own shared infrastructure, the design system and the performance budget.

The fifth point is the one people forget. Without a platform team, a split frontend soon becomes a patchwork where every team sets its own rules. So include the cost of that team when you plan the budget.

How do micro frontends affect SEO?

In itself, the architecture is neither good nor bad for SEO. Instead, the effect comes from the integration path. Google Search Central's JavaScript SEO basics explains that Google processes JavaScript apps in three phases: crawling, rendering and indexing. If content only appears in the browser, it has to wait for rendering before it can reach the index.

The same page also states that server side rendering or pre-rendering is still a great idea, because it makes sites faster for users and crawlers, and not all bots can run JavaScript. That warning matters even more once you consider AI crawlers. I discuss this in my article on technical SEO after AI.

• Links should be real <a> elements with an href. Google says it can only discover links in that form.
• Manage title, meta description, canonical and structured data in one place, and never let two parts write the same tag.
• Route changes should create real URLs through the History API. Avoid hash based routing.
• Every part should return meaningful fallback content on error, not an empty box.

Why is server side rendering critical in a micro frontend setup?

Server side rendering, or SSR, means the server generates the page HTML and sends it complete. In a split frontend, SSR matters for two reasons. First, search engines and AI bots can read the content without relying on JavaScript. Second, the largest content element paints early, so visitors do not stare at a blank screen.

The problem is that not every integration path supports SSR equally. Build time integration and server side composition fit naturally. With runtime integration, however, each part must also run on the server. That also means extra code paths and extra testing.

So I suggest one simple question for your technical team: "When we view the source of our category and product pages, is the main content there?" If the answer is no, solve the rendering strategy before any architecture debate. I check this by viewing the page source and by using the URL Inspection tool in Google Search Console.

What Core Web Vitals risks do micro frontends carry?

Core Web Vitals are the three metrics Google uses to measure user experience. the Web Vitals guide on web.dev sets these good thresholds: LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less. Google looks at the 75th percentile of page loads, separately for mobile and desktop. INP replaced FID as a Core Web Vital in 2024.

I explain how these metrics affect rankings in how site speed affects SEO, and lab testing in my Lighthouse performance test guide. My rule for split frontends is simple. Give every part a JavaScript budget, and let the pipeline check that budget automatically.

How should you manage a shared design system across micro frontends?

Visitors do not know how many teams built a page, and they should not have to, because the page should feel like one product. If buttons, forms and typography look different in every part, the site feels messy and less trustworthy. Therefore a design system is not optional here. It is a requirement.

• Design tokens: colour, spacing and type scales come from one source.
• Component library: every team uses the same buttons, form fields and modals.
• CSS isolation: CSS modules, naming conventions or shadow DOM stop styles from leaking.
• Versioning policy: breaking changes ship on a schedule and with notice.

Jackson's article supports shared component libraries but draws an important line. Specifically, domain specific components should stay with the team that owns the domain. Otherwise, the shared library turns into a new monolith that ties everyone together. I apply the same logic when I build digital brand identity systems for clients.

How should you split teams and ownership in a micro frontend structure?

Most of the success comes from drawing boundaries in the right place. So draw them by business domain, not by technical layer. A split like "header team" and "footer team" still pulls everyone into the same meeting for every change.

A healthier split follows the customer journey: discovery and search, product detail, basket and checkout, account management. Each team owns the frontend of its domain, and often the backend too. As a result, a team can make end to end decisions in its own area.

Also name a clear owner for shared areas. If nobody owns the header, navigation, analytics tags and SEO metadata, everybody will touch them sooner or later. When analytics and conversion tags drift, reports lose their reliability. That creates blind spots for SEO consulting and ad optimisation alike.

How should you plan the move from a monolith to micro frontends?

As a rule, I do not recommend rewriting the site in one go. Instead, I use the gradual approach known as the strangler fig pattern. New parts grow around the old site, and you retire old code route by route. That way you measure every step, and if something breaks, you roll back a small area.

1. List every route and note its traffic, conversions and SEO value.
2. Start with an area that carries low risk but gains the most from team autonomy.
3. Set up the shell, the shared design system and the performance budget in the first step.
4. Compare Core Web Vitals, indexing and conversion data before and after each move.
5. If URLs change, prepare a 301 redirect map and test it before launch.

Every move that changes URLs is really a site migration. My website migration SEO checklist covers that side. To verify redirects one by one on the live site, you can use the redirect checker.

What should you ask before approving a micro frontend project?

When your technical team proposes this architecture, ask the questions below. After that, notice how clearly they answer, because it tells you a lot about the maturity of the plan.

1. Which concrete bottleneck delays releases today, and how will the new architecture remove it?
2. Which integration path did you choose, and will SEO critical pages render on the server?
3. What JavaScript budget will each part get, and who will track it?
4. Who will manage version compatibility for shared libraries?
5. Who owns the design system and the shared areas?
6. What happens to the page when one part fails or slows down?
7. What will extra infrastructure, monitoring and a platform team cost per year?

If you cannot get clear answers to at least three of these, postponing or starting with a small pilot is usually wiser. Moreover, the delay buys valuable time to modularise the existing code.

How do you measure success in a micro frontend project?

Judging an architecture change only by developer satisfaction is misleading. I suggest tracking three groups of indicators. The first is delivery speed: release frequency, the time from commit to production and the rollback rate.

Next, track user experience: Core Web Vitals field data, JavaScript weight per page and error rate. The third is business results: organic traffic, the number of indexed pages and conversion rate. Especially during a migration, seeing all three groups on one dashboard is the most reliable way to catch problems early.

Above all, write the targets down before the project starts. Otherwise, six months later everyone will answer "did we get faster?" with a gut feeling. My list of technical SEO tips also works as a baseline checklist for that measurement framework.

To keep measurement manageable, choose a pilot area that is small but meaningful. For example, move only the account pages or one product group, then compare it with the old setup for four to eight weeks. That window is a starting range from my field experience, not a guarantee. With low traffic, then, you will need longer. This way you decide with real data before you spread the budget across the whole site.

How should you make the micro frontend decision?

In short, micro frontends solve a team coordination problem, not a size problem. For organisations with many teams, many domains and frequent releases, they can bring real speed. In single team or mid sized sites, however, they usually increase maintenance load and put performance at risk.

When you decide, first check three things. Is the problem truly organisational? Will SEO critical pages render on the server? Do you have a team that can own shared infrastructure? If all three answers are clear, start with a small pilot and grow by measuring.

If you want the architecture, SEO and performance of a large corporate site reviewed together, we can work on it through my web design and technical SEO services. You can describe your situation on the contact page.