Angular Performance optimieren: 8 Techniken für schnellere Apps

Angular-Performance lässt sich mit acht gezielten Techniken deutlich verbessern: Lazy Loading, OnPush Change Detection, Signals, SSR/SSG-Rendering, Bildoptimierung, Critical CSS, Font-Preloading und Chunk-Analyse. Die häufigsten Performance-Probleme in Angular-Apps entstehen durch zu große initiale Bundles, unkontrollierte Change-Detection-Zyklen und fehlende Rendering-Strategie. Mit diesen Maßnahmen erreichen KMU-Websites messbar bessere Ladezeit und PageSpeed -Werte, ohne die Architektur komplett umzubauen.

Bundle-Größe reduzieren: Lazy Loading und Code-Splitting

Das initiale JavaScript-Bundle ist der größte einzelne Performance-Hebel in Angular-Anwendungen. Standardmäßig lädt Angular alle registrierten Komponenten beim ersten Seitenaufruf – auch wenn Nutzer 80% davon nie sehen. Lazy Loading via Code-Splitting löst dieses Problem strukturell.

• loadComponent: Statt statischem Import wird loadComponent: () => import('./pages/contact/contact').then(m => m.ContactPage) verwendet. Angular splittet den Code automatisch in separate Chunks.
• Standalone Components: Jede Komponente trägt ihre eigenen Abhängigkeiten – kein SharedModule, das alles in den initialen Bundle zieht. Direkte Importe ermöglichen präzises Tree-Shaking.
• Chunk-Größen im Blick behalten: ng build --stats-json + webpack-bundle-analyzer zeigt, welche Chunks zu groß sind. Ziel: Initiales Bundle unter 200 KB gzipped.
• Preloading-Strategie: PreloadAllModules oder Custom-Strategie sorgt dafür, dass Lazy Chunks im Hintergrund geladen werden, bevor der Nutzer navigiert.

Change Detection und OnPush-Strategie

Angulars Standard-Change-Detection prüft bei jedem Event den gesamten Komponentenbaum auf Änderungen. Bei großen Apps mit vielen Komponenten führt das zu hunderten unnötiger DOM-Checks pro Sekunde. OnPush reduziert das auf das notwendige Minimum.

• ChangeDetectionStrategy.OnPush: Die Komponente wird nur neu gerendert, wenn sich eine Input-Referenz ändert, ein Signal-Wert aktualisiert oder ein async-Pipe einen neuen Wert emittiert.
• Angular Signals (ab Angular 16): signal(), computed() und effect() ersetzen RxJS-BehaviorSubjects für lokalen Zustand. Signals triggern Change Detection präzise – nur betroffene Komponenten werden aktualisiert.
• computed() für abgeleiteten Zustand: Statt eine Methode im Template aufzurufen, cached computed() das Ergebnis und aktualisiert nur bei Änderung der Quelldaten.
• effect() im Constructor: Seiteneffekte in effect() im Constructor registrieren – niemals in ngOnInit, da effect() intern inject() nutzt.
• Keine Funktionsaufrufe im Template: someMethod() im Template wird bei jeder Change Detection neu ausgeführt. Stattdessen computed() oder Getter mit Memoization verwenden.

SSR und SSG: Wann lohnt sich was für Angular-Apps?

Das Rendering -Modell entscheidet maßgeblich über Time to First Byte (TTFB), SEO-Indexierbarkeit und wahrgenommene Ladezeit. Angular Universal bietet drei Optionen, die sich je nach Anwendungsfall unterschiedlich eignen.

• SSG (Static Site Generation) via ng build --prerender: Seiten werden zur Build-Zeit als statisches HTML gerendert. TTFB unter 50ms möglich. Ideal für alle Inhaltsseiten (Blog, Glossar, Stadtseiten).
• SSR (Server-Side Rendering): Seiten werden per Request auf dem Server gerendert. Notwendig nur für wirklich dynamische Daten (eingeloggter Nutzerstatus, Echtzeit-Preise).
• CSR (Client-Side Rendering): Nur für rein interaktive App-Bereiche hinter Login geeignet. Für öffentlich zugängliche Seiten aus SEO-Sicht zu vermeiden.
• Hybrides Modell: app.routes.server.ts ermöglicht pro Route die Wahl zwischen prerender, server und client. Content-Seiten auf prerender, dynamische Dashboards auf server.
• Hydration: Angular 17+ Universal Hydration verhindert Flash of Unstyled Content beim Übergang von SSR zu CSR. withEventReplay() in app.config.ts aktivieren.

Der Build-Prozess mit ng build --prerender erzeugt für jede vorgerenderte Route eine separate index.html – Apache liefert diese direkt aus, ohne Angular-Serverlogik. Für KMU-Websites mit 50–100 Seiten ist das die optimale Kombination aus SEO-Performance und geringem Server-Overhead.

Bilder und Assets optimieren

Bilder sind in den meisten Websites der größte Bandwidth-Verbrauch und häufigste Ursache für schlechte Largest Contentful Paint (LCP)-Werte. Richtiges Caching und optimiertes Asset-Delivery gehören zu den Maßnahmen mit dem besten Aufwand-Nutzen-Verhältnis.

• WebP als Standard-Format: WebP ist 25-35% kleiner als JPEG bei gleicher visueller Qualität. Für alle nicht-transparenten Bilder WebP verwenden.
• NgOptimizedImage (Angular 15+): Erzwingt width/height-Attribute, setzt automatisch loading='lazy' für Below-Fold-Bilder und unterstützt srcset für Responsive Images.
• Above-Fold-Bilder vorausläden: Das Hero-Bild erhält priority-Attribut – Angular setzt fetchpriority='high' und ein <link rel='preload'>. Gilt nur für das tatsächlich sichtbare LCP-Element.
• Lazy Loading für Below-Fold-Assets: Bilder unterhalb des Viewports loading='lazy'. Video-Embeds preload='none' – spart mehrere MB Bandwidth beim initialen Load.
• {criticalCss} inlinen: Die für Above-Fold-Inhalte benötigten Styles direkt in den <head> inlinen. Verhindert render-blocking durch externe Stylesheet-Requests.
• Font-Subsetting und Preload: Google Fonts self-hosten und auf benötigte Character-Sets subsetten. <link rel='preload' as='font'> für die primäre Schriftart im index.html.
• HTTP-Caching-Header: Statische Assets (JS, CSS, Bilder) mit langen Cache-Zeiten und Content-Hash im Dateinamen ausliefern.
• Unused CSS entfernen: Component-scoped SCSS verhindert globale Stylesheet-Aufblähung.

Kurz zusammengefasst

• Bundle-Größe: loadComponent für alle Routen, Standalone Components, Ziel unter 200 KB gzipped initial.
• Change Detection: OnPush auf allen Komponenten, Signals statt RxJS für lokalen Zustand, keine Funktionsaufrufe im Template.
• Rendering-Strategie: SSG (ng build --prerender) für Inhaltsseiten, SSR nur für wirklich dynamische Daten.
• Bilder: WebP, NgOptimizedImage mit priority für LCP-Element, lazy loading für alle Below-Fold-Assets.
• Assets: Fonts self-hosten und preloaden, HTTP-Caching mit langen Laufzeiten, Critical CSS inlinen.
• Monitoring: Lighthouse CI in Build-Pipeline integrieren, Core Web Vitals nach jedem Deployment prüfen.