Eine Webanwendung wächst selten geplant. Erst kommt der Shop, dann das Kundenkonto, später die Suche, das Ticketsystem und ein Bereich für Händler. Irgendwann arbeiten fünf oder zehn Teams am selben Frontend, und jedes Release wird zur Abstimmungsrunde. Genau an dieser Stelle setzen Micro Frontends an: Sie übertragen die Idee der Microservices vom Backend auf die Benutzeroberfläche.

Dieser Beitrag stammt vom März 2025 und beschreibt den Stand der Diskussion zu diesem Zeitpunkt. Eine aktuelle Entscheidungshilfe, wann sich die Architektur lohnt und welche Alternativen Sie zuerst prüfen sollten, finden Sie im Beitrag Micro Frontends: Wann sich die Architektur für Webanwendungen lohnt.

Die Grundidee: eine Oberfläche, viele kleine Anwendungen

Bei Micro Frontends wird eine Webanwendung in kleinere, voneinander unabhängige Frontend-Teile zerlegt. Statt eines großen Frontend-Monolithen – einer einzigen Codebasis für die gesamte Oberfläche – betrachtet man die Anwendung als Zusammenschluss von Fachbereichen. Jeden davon entwickelt und betreibt ein eigenes, fachlich ausgerichtetes Team.

Ein Micro Frontend ist im Kern eine kleine Anwendung mit eigenem Code, oft eigenem Repository und eigenem Build-Prozess. Ein übergeordneter Container, häufig „Shell“ genannt, bettet diese Teile ein und fügt sie zu einer Oberfläche zusammen. Wer die Seite nutzt, sieht davon nichts: Für ihn wirkt das Ergebnis wie eine einzige Anwendung.

Angenommen, ein Onlinehändler teilt seine Website so auf: Ein Team verantwortet Produktsuche und Listen, ein zweites den Warenkorb und den Bestellabschluss, ein drittes das Kundenkonto. Jedes Team kann seinen Teil ändern und veröffentlichen, ohne die anderen um Erlaubnis zu fragen.

Die Prinzipien, auf die sich die Community verständigt hatte

Der Gedanke dahinter ähnelt der Aufteilung eines Backend-Monolithen in Microservices: Ein großes, kaum noch überschaubares Frontend wird in handhabbare Stücke zerlegt. Jedes Stück gehört zu einem Geschäftsbereich und wird von einem cross-funktionalen Team verantwortet, also einem Team, das von der Gestaltung bis zum Betrieb alles selbst erledigt.

Für den Aufbau galten einige Prinzipien als Richtschnur:

1. Technologische Unabhängigkeit: Jedes Team wählt seinen Technologie-Stack selbst und aktualisiert ihn im eigenen Tempo.

2. Getrennte Codebasen: Die Teile laufen isoliert, ohne gemeinsamen globalen Zustand und ohne gemeinsame Laufzeitumgebung.

3. Klare Namensräume: Wo sich eine vollständige Trennung nicht erreichen lässt, verhindern vereinbarte Präfixe und Namenskonventionen Kollisionen, etwa bei CSS-Klassen, Events oder Einträgen im Local Storage.

4. Browserfunktionen statt eigener Schnittstellenschicht: Für Kommunikation und Einbindung nutzt man bevorzugt, was der Browser ohnehin mitbringt, etwa Custom Events oder die URL.

5. Robustheit und Progressive Enhancement: Jeder Teil soll der Seite etwas Nützliches liefern, auch wenn JavaScript langsam lädt oder ausfällt.

Diese Regeln dienen einem Zweck: Abhängigkeiten zwischen den Teams sollen sichtbar und klein bleiben, damit die Unabhängigkeit nicht nur auf dem Papier besteht.

Wie die Teile im Browser zusammenkommen

Die zentrale technische Frage lautet: Wie werden unabhängig gebaute Teilanwendungen zu einer Seite? Am Ende zeigt der Browser immer ein HTML-Dokument an. Es braucht also einen Mechanismus, der die einzelnen Teile dort einbettet, startet und wieder entfernt.

Einen einzigen richtigen Weg gab es dafür nicht. Etabliert hatten sich mehrere Ansätze mit jeweils eigenen Stärken und Schwächen.

Einbindung per iframe

Am einfachsten ist es, jedes Micro Frontend in ein iframe zu setzen, also ein eingebettetes Browserfenster innerhalb der Seite. Die Isolation ist stark: Jedes iframe läuft in einem eigenen Kontext, CSS und JavaScript kommen sich praktisch nicht in die Quere, und verschiedene Frameworks oder Versionen laufen problemlos nebeneinander.

Diese Isolation hat ihren Preis. Layouts lassen sich schwer über iframe-Grenzen hinweg gestalten, die Kommunikation zwischen Seite und iframe läuft über postMessage und erfordert zusätzlichen Code, und jedes iframe bringt Ladeaufwand mit. Viele Projekte nutzten iframes deshalb nur als Übergangslösung oder für Teile, die ohnehin klar abgegrenzt sind, etwa ein eingebundenes Fremdsystem.

Web Components als gemeinsame Schnittstelle

Immer häufiger setzten Teams auf Web Components, einen Satz von Browserstandards für eigene HTML-Elemente. Jedes Team liefert sein Micro Frontend als Custom Element aus, etwa mf-warenkorb, und der Container setzt es bei Bedarf ins Dokument. Das DOM wird damit zur Schnittstelle: Attribute dienen als Eingabe, Events als Ausgabe.

Der Vorteil liegt in der Unabhängigkeit vom Framework. Moderne Browser unterstützen Web Components ohne Zusatzbibliothek. Intern kann ein solches Element mit React, Vue oder ganz ohne Framework gebaut sein, nach außen zeigt es sich als gewöhnliches HTML-Tag. Mit dem Shadow DOM, einem gekapselten Teilbaum des Dokuments, lassen sich Styles abschirmen, sodass CSS-Regeln nicht in andere Teile durchsickern.

Komposition per JavaScript im Browser

Ein weiterer verbreiteter Weg ist das dynamische Nachladen per JavaScript. Ein Container-Skript entscheidet anhand der Route oder des Anwendungszustands, welches Micro-Frontend-Bundle es lädt, und hängt es an einer festgelegten Stelle in die Seite ein.

Für diese Integration zur Laufzeit gab es spezialisierte Bibliotheken:

• single-spa: eine verbreitete Open-Source-Bibliothek, die mehrere Single-Page-Anwendungen auf einer Seite koordiniert, auch wenn sie mit unterschiedlichen Frameworks gebaut sind.

• Webpack Module Federation: eine Funktion von Webpack 5, mit der unabhängig gebaute Anwendungen zur Laufzeit Code untereinander austauschen können, etwa gemeinsame Bibliotheken oder ganze Komponenten.

Komposition auf dem Server

Neben der Zusammensetzung im Browser gab es Ansätze, die Seite bereits auf dem Server zusammenzubauen. Der Server holt die HTML-Fragmente der einzelnen Teile ab, kombiniert sie und schickt dem Browser eine fertige Seite.

Das hilft bei der ersten Ladezeit und bei der Suchmaschinenoptimierung, weil der Browser sofort vollständiges HTML erhält. Die Komplexität wandert dafür in die Serverschicht: Jemand muss die Fragmente zuverlässig ausliefern, cachen und bei Ausfällen sinnvoll reagieren. Häufig stellt jedes Team dafür einen eigenen Dienst bereit, nicht selten im Sinne des Musters Backend for Frontend, bei dem ein Backend genau auf eine Oberfläche zugeschnitten ist.

Was Micro Frontends Teams bringen

Die Vorteile zeigen sich vor allem in großen Projekten mit mehreren Teams. Für ein kleines Team mit überschaubarer Anwendung sind sie kaum spürbar.

Unabhängige Entwicklung und Auslieferung

Jedes Team kann seinen Teil eigenständig entwickeln, testen und veröffentlichen. Niemand muss auf einen gemeinsamen Release-Termin warten: Eine Fehlerbehebung im Warenkorb geht live, sobald sie fertig ist, auch wenn das Team der Produktsuche gerade mitten in einem Umbau steckt. Das verringert Wartezeiten und erlaubt häufigere, kleinere Releases.

Wachsen, ohne dass die Abstimmung explodiert

Micro Frontends erlauben es, eine große Entwicklungsorganisation in kleinere Einheiten zu teilen, die jeweils an einem klar umrissenen Bereich arbeiten. Die Aufteilung nach fachlichen Bereichen statt nach technischen Schichten hält die Teams in sich geschlossen: Jedes verantwortet einen Teil des Nutzererlebnisses von der Oberfläche bis zur Schnittstelle.

Auch die Einarbeitung wird leichter. Neue Entwickler:innen beginnen in einer kleinen Codebasis statt in einem riesigen Monolithen. Kommt ein neuer Fachbereich hinzu, kann die Organisation ein weiteres Team aufbauen, ohne die bestehenden umzubauen.

Überschaubarer Code und begrenzte Fehler

Statt einer großen Codebasis, die mit den Jahren unübersichtlich wird, gibt es mehrere kleine. Wer an einem Teil arbeitet, muss nicht die gesamte Anwendung im Kopf haben und kann die Architektur des eigenen Bereichs konsistent halten.

Fehler bleiben eher dort, wo sie entstehen. Ein Problem in einem Teil legt nicht zwangsläufig die ganze Seite lahm, und im Ernstfall lässt sich ein einzelnes Micro Frontend zurückrollen, ohne alle anderen anzufassen.

Schrittweise Migration statt Komplettumbau

Theoretisch können Teams in einer Micro-Frontend-Architektur unterschiedliche Technologien nebeneinander einsetzen. Der eigentliche Nutzen liegt aber woanders: bei Migrationen. Ist ein Framework veraltet oder stößt eine bestehende Anwendung an ihre Grenzen, kann man Bereich für Bereich auf eine neue Technik umziehen, statt alles auf einmal neu zu schreiben. Als Migrationspfad ist dieser Parallelbetrieb von Technologien besonders wertvoll.

Klare fachliche Zuständigkeit

Schneidet man die Teile entlang fachlicher Bereiche, entstehen Module mit klarem Fokus. Ein Team kann sich auf die Bedürfnisse seines Bereichs konzentrieren, was oft zu einem besseren Ergebnis für genau diese Funktion führt. Abhängigkeiten zu fachfremden Teilen nehmen ab, und damit sinkt der Abstimmungsbedarf.

Wo Micro Frontends Aufwand verursachen

Wie jede Architektur hat auch diese ihre Schattenseiten. Wer sie einführt, tauscht organisatorische Freiheit gegen technische Komplexität.

Mehr Code im Browser

Einer der häufigsten Kritikpunkte betrifft die Performance. Kommen mehrere Micro Frontends auf einer Seite zusammen, lädt der Browser leicht dieselben Ressourcen mehrfach, etwa ein Framework oder eine Datumsbibliothek in verschiedenen Versionen.

Bringt jedes Team sein eigenes Framework mit, summiert sich der doppelte Code schnell zu einer spürbaren Menge. Zugleich steigt die Zahl der Netzwerkanfragen, was die Ladezeit zusätzlich verlängern kann. Gemeinsam genutzte Abhängigkeiten, wie Module Federation sie erlaubt, mildern das Problem, erfordern aber Absprachen über Versionen.

Erste Ladezeit und Suchmaschinen

Viele Micro-Frontend-Setups setzen stark auf das Laden im Browser. Die Seite liefert anfangs nur ein fast leeres HTML-Gerüst, und erst nachdem eine größere Menge JavaScript geladen ist, erscheinen Inhalte. Ohne Gegenmaßnahmen verzögert sich der Zeitpunkt, an dem die Seite bedienbar ist. Zudem erschwert rein clientseitiges Rendering die Suchmaschinenoptimierung, weil Crawler im ungünstigen Fall wenig Inhalt vorfinden.

Die Integration als zusätzliche Schicht

Was in einer einzelnen Single-Page-Anwendung das Framework regelt – Routing, Zustandsverwaltung, gemeinsamer Datenkontext –, muss bei Micro Frontends eigens koordiniert werden. Diese Integrationslogik ist eine weitere Schicht, die jemand bauen und pflegen muss.

Die Teams müssen sicherstellen, dass ihre Teile im Container zusammenspielen: beim Routing, bei gemeinsamen Elementen wie Kopfzeile und Navigation und bei der Kommunikation untereinander. Auch übergreifende Informationen, etwa die angemeldete Person oder die gewählte Sprache, müssen allen Teilen zur Verfügung stehen.

Testen über Teamgrenzen hinweg

Für den einzelnen Teil ändert sich beim Testen wenig: Unit- und Integrationstests sichern ihn wie gewohnt ab. Schwieriger wird es bei End-to-End-Tests, die das Zusammenspiel prüfen. Wer stellt sicher, dass die zusammengesetzte Anwendung als Ganzes funktioniert, wenn jedes Team zu einem anderen Zeitpunkt ausliefert?

Ein einheitliches Erscheinungsbild

Arbeiten mehrere Teams unabhängig an der Oberfläche, droht ein uneinheitliches Bild. Unterschiedlich ausgelegte Gestaltungsregeln, abweichende Bedienelemente oder kleine Unterschiede bei Abständen und Schriften fallen Nutzer:innen schnell auf.

Dagegen helfen verbindliche Gestaltungsrichtlinien und meist ein gemeinsames Design System, also eine Bibliothek mit Komponenten und Regeln, die alle Teams verwenden. Viele Organisationen führten mit Micro Frontends deshalb strenge Styleguides oder geteilte Komponenten ein.

Frameworks und Werkzeuge im März 2025

Micro Frontends sind grundsätzlich unabhängig vom Framework. Nahezu jedes gängige Frontend-Framework lässt sich in eine solche Architektur einbinden. Der folgende Überblick zeigt den Stand vom März 2025.

Wie die großen Frameworks damit umgingen

• React: Als meistgenutzte Frontend-Bibliothek war React oft Teil von Micro-Frontend-Projekten. Eine eingebaute Unterstützung dafür bringt React nicht mit, es lässt sich aber gut in modulare Architekturen einfügen.

• Angular: Offiziell unterstützt Angular Micro Frontends nicht. Mit dem Wechsel auf Webpack 5 stand Module Federation jedoch auch Angular-Projekten offen, und aus der Community kamen Schematics und Plugins, die die Einrichtung vereinfachen.

• Vue.js: Vue lässt sich ähnlich leicht einbinden wie React. Per Module Federation können Vue-Komponenten oder ganze Single-Page-Anwendungen dynamisch nachgeladen werden.

• Svelte: Svelte übersetzt Komponenten bereits beim Build in schlanken JavaScript-Code und bringt kaum Laufzeitbibliothek mit. Das kommt Seiten entgegen, auf denen mehrere Micro Frontends gleichzeitig laufen.

• Web Components: Quer zu allen Frameworks bilden Web Components den gemeinsamen Nenner. Ein Team kann seinen Teil als Custom Element exportieren, das sich in jede andere Umgebung einsetzen lässt.

Spezialisierte Bibliotheken und Plattformen

Neben den allgemeinen Frameworks war ein eigenes Ökosystem für Micro Frontends entstanden:

• Webpack Module Federation: Mit dieser Funktion von Webpack 5 tauschen unabhängige Anwendungen gebündelten Code zur Laufzeit aus. Damit lassen sich etwa gemeinsame Bibliotheken nur einmal laden.

• single-spa: ein Open-Source-Framework speziell für Micro Frontends, das mehrere Teilanwendungen auf einer Seite koordiniert, einschließlich Routing und Lebenszyklus (Laden, Einhängen, Entfernen).

• Piral: ein Framework mit Fokus auf die Arbeit der Entwickler:innen. Es stellt eine Plattform bereit, in die sich einzelne Module („Pilets“) einklinken, und bringt Werkzeuge für die lokale Entwicklung mit.

• OpenComponents: verfolgt den Ansatz auf Komponentenebene. UI-Komponenten werden wie Dienste veröffentlicht und von Frontends dynamisch abgerufen.

• Luigi: ein schlankes Micro-Frontend-Framework von SAP, ausgerichtet auf Geschäftsanwendungen im Unternehmen. Navigation, Berechtigungen und Kommunikation zwischen den Teilen bringt es bereits mit.

Wer Micro Frontends mit Next.js umsetzen wollte, fand zudem eigene Wege, etwa die Aufteilung in mehrere Zonen. Wie sich ein Next.js-Projekt vom Monolithen zu Micro Frontends entwickeln lässt, beschreibt der Beitrag Skalierbare Next.js-Architekturen: Von Monolith zu Micro-Frontends.

Wohin sich das Thema Anfang 2025 bewegte

Im Frühjahr 2025 hatten sich Micro Frontends vom Hype-Thema zu einer etablierten Architekturoption entwickelt. Mehrere große Unternehmen hatten eigene Micro-Frontend-Plattformen aufgebaut.

Zugleich hatte sich der Blick verändert. Anfangs führten viele Organisationen Micro Frontends in der Erwartung ein, Entwicklungsaufwand zu sparen – eine Hoffnung, die sich nicht von selbst erfüllte. Bis 2025 hatte die Branche dazugelernt: Micro Frontends wurden gezielter für komplexe Szenarien empfohlen und mit den nötigen Änderungen an Prozessen und Teamstruktur eingeführt.

Technisch konzentrierten sich die Entwicklungen darauf, die bekannten Schwachstellen zu entschärfen:

• Unabhängigkeit vom Framework sollte Teams Freiheit lassen, ohne den Zusammenhalt der Anwendung zu gefährden.

• Design Systems galten praktisch als Pflicht. Viele Organisationen bauten zentrale Komponentenbibliotheken auf, damit alle Teile gleich aussehen und sich gleich bedienen lassen.

• Server-Side Rendering, also das Erzeugen von HTML auf dem Server, kam häufiger zum Einsatz, um die erste Ladezeit und die Auffindbarkeit in Suchmaschinen zu verbessern.

• Bessere Werkzeuge für die Koordination entstanden: Router, gemeinsame Lösungen für die Zustandsverwaltung und Muster für die Kommunikation zwischen den Teilen.

• Performance blieb ein Schwerpunkt, vom gemeinsamen Caching von Ressourcen bis zu schnelleren Build-Werkzeugen wie esbuild oder Rspack.

Einordnung: Für wen sich Micro Frontends 2025 lohnten

Micro Frontends verbinden technische Vorteile – Modularität, Unabhängigkeit, begrenzte Fehlerwirkung – mit organisatorischen: Teams können eigenständig arbeiten und ausliefern. Bei umfangreichen Webanwendungen, an denen viele Entwickler:innen gleichzeitig arbeiten, zahlt sich das aus. Neue Funktionen kommen schneller live, und die Anwendung bleibt über Jahre wartbar.

Sinnvoll ist die Architektur aber vor allem dann, wenn Komplexität oder Teamgröße einen Monolithen unwirtschaftlich machen. Für eine kleine Anwendung mit einem einzigen Team bringt sie wenig und schafft vor allem zusätzliche Komplexität. Unsere Einschätzung damals wie heute: Erst die Teamstruktur klären, dann über die technische Aufteilung entscheiden.

Für Entwickler:innen und Architekt:innen waren Micro Frontends 2025 damit ein nützliches Werkzeug unter mehreren – kein Allheilmittel, aber bei passendem Einsatz ein Weg zu Frontends, die mit der Organisation wachsen. Die Community und die Hersteller der Werkzeuge arbeiteten daran, die Kinderkrankheiten zu beheben, und bewährte Vorgehensweisen festigten sich.

Wer eine solche Architektur plant oder eine bestehende überprüfen möchte, findet auf unserer Themenseite Micro Frontends: Beratung, Coaching und Seminare einen Überblick über Workshops und Schulungen.

Häufige Fragen zu Micro Frontends

Worin unterscheiden sich Micro Frontends von Komponentenbibliotheken?

Eine Komponentenbibliothek stellt wiederverwendbare Bedienelemente bereit, die verschiedene Anwendungen einbinden, etwa Schaltflächen, Formularfelder oder Dialoge. Micro Frontends sind dagegen eigenständige Anwendungsteile mit eigener Logik, eigenem Lebenszyklus und eigener Auslieferung. Bibliotheken fördern die Wiederverwendung in der Oberfläche, Micro Frontends die Entkopplung von Anwendungsteilen und Teams.

Muss man für Micro Frontends verschiedene Frameworks einsetzen?

Nein. Verschiedene Technologien sind möglich, aber viele Organisationen setzen bewusst auf ein einheitliches Framework für alle Teile. Das verkürzt die Ladezeit und erleichtert ein einheitliches Erscheinungsbild. Der Hauptnutzen liegt in der organisatorischen Skalierung und der unabhängigen Auslieferung, nicht in der Vielfalt der Technik.

Wie bleibt das Erscheinungsbild einheitlich?

Entscheidend ist ein unternehmensweites Design System, das als gemeinsame Bibliothek bereitsteht und von allen Teams genutzt wird. Ergänzend helfen regelmäßige Reviews der Oberfläche, klare Styleguides und gegebenenfalls ein zentrales UX-Team, das übergreifende Regeln festlegt und die Teams bei der Umsetzung unterstützt.