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

> Umfassender Leitfaden zu Angular @defer-Bloecken: Trigger-Typen, Prefetching, SSR-Verhalten, inkrementelle Hydration, Performance-Patterns und die wichtigsten Interview-Fragen fuer Angular-Positionen.

- Published: 2026-06-14
- Updated: 2026-06-14
- Author: SharpSkill
- Tags: angular, angular-defer, lazy-loading, performance, ssr, signals, deep-dive
- Reading time: 9 min

---

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.

> **Was @defer bewirkt**
>
> `@defer` weist den Angular-Compiler an, die umschlossenen Komponenten in separate JavaScript-Chunks auszulagern, die erst geladen werden, wenn eine definierte Trigger-Bedingung eintritt. Der Browser laedt weniger JavaScript beim initialen Seitenaufruf, was Largest Contentful Paint (LCP) und Time to First Byte (TTFB) verbessert — ohne manuelle Code-Splitting-Konfiguration.

## 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:

```typescript
// app.component.html
@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.

```typescript
// product-page.component.html

// 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](https://developer.mozilla.org/en-US/docs/Web/API/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:

```typescript
// dashboard.component.ts
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.

```typescript
// settings.component.html
@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.

```typescript
// analytics.component.html
@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:

```typescript
// blog-post.component.html
@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](https://angular.dev/guide/incremental-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.

```typescript
// product-page.component.html
@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

```typescript
// dashboard.component.html
<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

```typescript
// editor.component.ts
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:

```typescript
// 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](/technologies/angular/interview-questions/standalone-components) 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](/technologies/angular/interview-questions/change-detection) und [Angular Signals](/technologies/angular/interview-questions/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

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/de/blog/angular/angular-defer-loading-declarative-lazy-loading-guide