Angular @defer im Jahr 2026: Deklaratives Lazy Loading und Interview-Fragen

Angular @defer-Bloecke loesen ein Problem, das routerbasiertes Lazy Loading nie adressieren konnte: das bedarfsgesteuerte Laden einzelner Komponenten, Direktiven und Pipes, ohne die gesamte Anwendungsarchitektur in separate Routen umstrukturieren zu muessen. Eingefuehrt in Angular 17 und ueber die nachfolgenden Versionen bis Angular 22 stabilisiert, verwandelt @defer einen Prozess, der zuvor dynamische Imports, *ngIf-Flags und Webpack-Konfiguration erforderte, in einen einzigen deklarativen Template-Block.

Wie @defer unter der Haube funktioniert

Wenn der Angular-Compiler auf einen @defer-Block trifft, extrahiert er saemtliche Standalone-Komponenten, -Direktiven und -Pipes innerhalb des Blocks in einen separaten Chunk. Das Hauptbundle wird ohne diese Abhaengigkeiten ausgeliefert. Zur Laufzeit wertet Angular die Trigger-Bedingung aus und laedt den Chunk ueber einen dynamischen import()-Aufruf nach.

Der Block unterstuetzt vier Unterbloecke, die steuern, was der Benutzer waehrend des Ladezyklus sieht:

@defer (on viewport) {
  <analytics-dashboard />
} @placeholder {
  <div class="h-64 bg-muted animate-pulse"></div>
} @loading (minimum 200ms) {
  <loading-spinner />
} @error {
  <p>Failed to load the dashboard. Please refresh.</p>
}

@placeholder wird gerendert, bevor der Trigger ausloest. @loading erscheint, waehrend der Chunk heruntergeladen wird, mit einem optionalen minimum-Parameter zur Vermeidung von Flackern. @error faengt Netzwerkfehler oder Chunk-Ladefehler ab. Der minimum-Parameter bei @loading verhindert ein kurzes Aufblitzen des Spinners, wenn der Chunk schnell aus dem Cache geladen wird.

Eine wesentliche Einschraenkung: Jede Abhaengigkeit innerhalb von @defer muss standalone sein. Nicht-Standalone-Komponenten, die in einem NgModule deklariert sind, koennen nicht deferred werden und werden unabhaengig vom @defer-Wrapper eager geladen.

Trigger-Typen: Steuerung des Ladezeitpunkts

Angular stellt sieben integrierte Trigger bereit, die jeweils eine unterschiedliche Ladestrategie abdecken. Mehrere Trigger koennen mit Semikolons kombiniert werden und werden als ODER-Bedingungen ausgewertet.

// Loads when the browser goes idle (default)
@defer {
  <recommendation-engine />
}

// Loads when the element enters the viewport
@defer (on viewport) {
  <customer-reviews [productId]="product.id" />
}

// Loads on click or keydown
@defer (on interaction) {
  <product-configurator />
} @placeholder {
  <button>Configure this product</button>
}

// Loads on mouseenter or focusin
@defer (on hover) {
  <quick-preview />
}

// Loads after 3 seconds
@defer (on timer(3s)) {
  <chat-widget />
}

// Loads immediately after initial render
@defer (on immediate) {
  <notification-center />
}

Der on viewport-Trigger nutzt intern die Intersection Observer API. Der on idle-Trigger delegiert an requestIdleCallback und stellt damit den sichersten Standard fuer Inhalte unterhalb des sichtbaren Bereichs dar. Der on timer-Trigger akzeptiert Zeitangaben in Millisekunden (500ms) oder Sekunden (3s).

Der when-Trigger fuer reaktive Bedingungen

Ueber die ereignisbasierten Trigger hinaus akzeptiert when jeden beliebigen booleschen Ausdruck, einschliesslich Signal-Lesezugriffe:

export class DashboardComponent {
  showAdvanced = signal(false);
}

// dashboard.component.html
@defer (when showAdvanced()) {
  <advanced-analytics />
} @placeholder {
  <button (click)="showAdvanced.set(true)">Show advanced analytics</button>
}

Die Kombination von on und when ist zulaessig. Angular behandelt beide als ODER-Verknuepfung: Der Block wird geladen, sobald eine der Bedingungen erfuellt ist.

Prefetching: Trennung von Download und Anzeige

Prefetching entkoppelt den Zeitpunkt des Chunk-Downloads vom Zeitpunkt des Komponenten-Renderings. Dadurch wird die wahrgenommene Latenz eliminiert, indem das JavaScript geladen wird, bevor der Benutzer die Aktion ausloest.

@defer (on interaction; prefetch on idle) {
  <account-settings />
} @placeholder {
  <button>Open settings</button>
}

In diesem Pattern laedt der Browser den account-settings-Chunk waehrend der Leerlaufzeit herunter. Wenn der Benutzer klickt, rendert die Komponente sofort, da der Code bereits verfuegbar ist. Prefetching akzeptiert dieselben Trigger-Typen wie die Haupt-on-Klausel.

Ein gaengiges Pattern fuer Dashboards: ressourcenintensive Komponenten waehrend der Leerlaufzeit prefetchen und das Rendering auf den Viewport-Eintritt verschieben.

@defer (on viewport; prefetch on idle) {
  <chart-widget [data]="salesData()" />
} @placeholder (minimum 100ms) {
  <div class="h-48 bg-muted rounded-none"></div>
}

Der minimum-Parameter bei @placeholder verhindert ein Layout-Flackern, wenn der Benutzer schnell scrollt und die deferred Komponente nahezu sofort geladen wird.

@defer und serverseitiges Rendering

Auf dem Server rendert @defer standardmaessig den @placeholder-Inhalt. Die deferred Komponente wird serverseitig nicht gerendert. Dieses Verhalten ist beabsichtigt: Der Chunk-Download ergibt nur im Browser-Kontext Sinn.

Fuer SEO-kritische Inhalte bedeutet dies, dass @placeholder aussagekraeftiges HTML enthalten muss, nicht nur einen Spinner:

@defer (on viewport) {
  <comment-section [postId]="post.id" />
} @placeholder {
  <section aria-label="Comments">
    <h2>Comments</h2>
    <p>Loading comments...</p>
  </section>
}

Suchmaschinen indexieren den Placeholder-Inhalt waehrend des SSR. Ein beschreibender Placeholder stellt sicher, dass die Seite semantisch vollstaendig bleibt.

Inkrementelle Hydration mit @defer

Angular 19 fuehrte die inkrementelle Hydration als Developer Preview ein, und Angular 22 stabilisiert sie als produktionsreifes Feature. Die inkrementelle Hydration erweitert @defer um einen hydrate-Trigger, der steuert, wann eine serverseitig gerenderte Komponente auf dem Client interaktiv wird.

@defer (hydrate on viewport) {
  <product-gallery [images]="product.images" />
}

@defer (hydrate on interaction) {
  <product-reviews [productId]="product.id" />
}

Im Gegensatz zum Standard-@defer rendert die inkrementelle Hydration das vollstaendige Komponenten-HTML auf dem Server. Der Client empfaengt vollstaendiges Markup, ueberspringt jedoch die Hydration der Komponente, bis der Trigger ausloest. Das Ergebnis: Der Browser zeichnet die vollstaendige Seite sofort, aber die JavaScript-Ausfuehrung wird verzoegert.

Das Angular-Team berichtet von konsistenten Verbesserungen der LCP-Werte um 40-50%, wenn inkrementelle Hydration auf inhaltslastigen Seiten eingesetzt wird. Angular DevTools in Version 22 visualisiert Hydration-Zustaende (pending, hydrated, error) direkt im Komponenten-Inspektor.

Praxisnahe Patterns und Performance-Strategien

Pattern 1: Umfangreiches Dashboard mit mehreren deferred Panels

<div class="grid grid-cols-2 gap-4">
  @defer (on viewport; prefetch on idle) {
    <sales-chart />
  } @placeholder {
    <skeleton-card height="300px" />
  }

  @defer (on viewport; prefetch on idle) {
    <user-activity-feed />
  } @placeholder {
    <skeleton-card height="300px" />
  }

  @defer (on interaction) {
    <export-panel />
  } @placeholder {
    <button>Export data</button>
  }
</div>

Jedes Panel wird unabhaengig geladen. Das Export-Panel bleibt ungeladen, bis der Benutzer es explizit anfordert, wodurch ein vollstaendiger Chunk-Download fuer Benutzer eingespart wird, die die Export-Funktion nie verwenden.

Pattern 2: Bedingtes Feature-Loading mit Signals

export class EditorComponent {
  user = inject(UserService).currentUser;
  isPremium = computed(() => this.user()?.plan === 'premium');
}

// editor.component.html
@defer (when isPremium()) {
  <ai-assistant />
} @placeholder {
  <upgrade-banner />
}

Benutzer im kostenlosen Tarif laden den AI-Assistenten-Chunk niemals herunter. Das Upgrade-Banner dient gleichzeitig als Placeholder und als Konversionsimpuls.

Haeufige Fallstricke vermeiden

Das Verschachteln von @defer-Bloecken mit demselben Trigger fuehrt zu gleichzeitigen Chunk-Downloads. Die Trigger sollten ueber verschachtelte Bloecke hinweg gestaffelt werden:

// Avoid: both fire on idle simultaneously
@defer {
  @defer {
    <nested-heavy-component />
  }
}

// Better: outer on idle, inner on viewport
@defer (on idle) {
  <wrapper-component />
}
// Inside wrapper-component template:
@defer (on viewport) {
  <nested-heavy-component />
}

Ein weiterer Fallstrick: die Verwendung von @defer fuer Komponenten, die sich bereits im kritischen Rendering-Pfad befinden. Das Deferring von Above-the-Fold-Inhalten erhoeht den LCP-Wert, da der Browser den Chunk erst herunterladen und ausfuehren muss, bevor er den Inhalt zeichnen kann. @defer sollte fuer Below-the-Fold- oder benutzergesteuerte Inhalte reserviert werden.

@defer vs. routerbasiertes Lazy Loading

Routerbasiertes Lazy Loading und @defer ergaenzen sich gegenseitig. Router-Lazy-Loading spaltet auf Routenebene und deferred komplette Feature-Module. @defer spaltet innerhalb eines Templates und deferred einzelne Komponenten.

| Aspekt | Router Lazy Loading | @defer | |--------|-------------------|--------| | Granularitaet | Route-Ebene | Komponenten-Ebene | | Trigger | Navigationsereignis | viewport, idle, interaction, hover, timer, Bedingung | | SSR-Verhalten | Vollstaendiges Server-Rendering | Placeholder auf dem Server | | Standalone erforderlich | Nein (funktioniert mit NgModules) | Ja (nur Standalone) | | Prefetching | preloadingStrategy | prefetch on-Klausel | | Anwendungsfall | Feature-Module, Seiten | Widgets, Panels, bedingte UI |

Eine typische Anwendung nutzt beides: Router-Lazy-Loading fuer uebergeordnete Feature-Bereiche und @defer fuer ressourcenintensive Komponenten innerhalb dieser Bereiche.

Interview-Fragen zu Angular @defer

Technische Vorstellungsgespraeche behandeln @defer zunehmend, da es eine zentrale Rolle in der Angular-Performance-Strategie einnimmt. Die folgenden Fragen und Antworten decken die haeufigsten Themen ab, die in Angular-Interviewfragen auftreten.

Frage: Was passiert, wenn eine Nicht-Standalone-Komponente innerhalb von @defer platziert wird?

Die Komponente wird unabhaengig vom @defer-Block eager geladen. Der Angular-Compiler kann in einem NgModule deklarierte Komponenten nicht in separate Chunks extrahieren. Es wird kein Fehler ausgeloest, aber die Optimierung greift stillschweigend nicht. Dieses Verhalten macht es besonders wichtig, dass Teams ihre Komponentenarchitektur auf Standalone umstellen, bevor sie @defer flaechendeckend einsetzen.

Frage: Wie verhaelt sich @defer waehrend des serverseitigen Renderings?

Der Server rendert den @placeholder-Inhalt. Die deferred Komponente wird serverseitig niemals gerendert. Die Hydration erfolgt auf dem Client, wenn der Trigger ausloest — oder ueber hydrate on bei inkrementeller Hydration. Fuer SEO-relevante Inhalte muss der Placeholder daher semantisch aussagekraeftiges HTML enthalten, da Suchmaschinen ausschliesslich diesen Inhalt indexieren.

Frage: Kann @defer mit OnPush Change Detection verwendet werden?

Ja. @defer ist ein Feature auf Template-Ebene und funktioniert mit jeder Change-Detection-Strategie. Die deferred Komponente folgt nach dem Laden ihrer eigenen Change-Detection-Konfiguration. Die Kombination von @defer und OnPush stellt ein gaengiges Optimierungsmuster dar, da beide Mechanismen unabhaengig voneinander die Performance verbessern.

Frage: Was ist der Unterschied zwischen on idle und on immediate?

on idle wartet, bis der Browser alle anstehenden Aufgaben abgeschlossen hat, und nutzt dafuer requestIdleCallback. on immediate loest direkt nach Abschluss des initialen Render-Durchlaufs von Angular aus, ohne auf den Leerlaufzustand zu warten. on immediate eignet sich fuer Komponenten, die zeitnah geladen werden sollen, aber den First Paint nicht blockieren duerfen. In der Praxis bedeutet dies, dass on immediate den Chunk-Download frueher startet als on idle, dafuer aber die Idle-Phase des Browsers belastet.

Fuer eine vertiefte Vorbereitung auf Angular-Interviews empfehlen sich die Module zu Angular Change Detection und Angular Signals.

Fazit

• @defer lagert Standalone-Komponenten in separate Chunks aus, die bedarfsgesteuert geladen werden, und reduziert die initiale Bundlegroesse ohne Umstrukturierung der Routenarchitektur
• Sieben Trigger-Typen (idle, viewport, interaction, hover, timer, immediate, when) decken jede Ladestrategie von passiv bis benutzergesteuert ab
• prefetch on entkoppelt den Chunk-Download vom Komponenten-Rendering und eliminiert die wahrgenommene Latenz bei benutzergesteuerten Komponenten
• Inkrementelle Hydration (hydrate on) rendert vollstaendiges HTML auf dem Server und verzoegert die JavaScript-Ausfuehrung auf den Client, was zu LCP-Verbesserungen von 40-50% auf inhaltslastigen Seiten fuehrt
• @placeholder-Inhalte werden waehrend des SSR gerendert und muessen fuer SEO semantisch aussagekraeftig sein
• @defer ergaenzt routerbasiertes Lazy Loading: Routen fuer die Aufteilung auf Feature-Ebene, @defer fuer die Aufteilung auf Komponentenebene innerhalb von Templates
• Nicht-Standalone-Komponenten koennen nicht deferred werden und werden stillschweigend eager geladen