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.
