Defer vs Async JavaScript und wie dies die Core Web Vitals beeinflusst

Erfahren Sie, wann Sie JavaScript async und wann defer laden sollten für die besten Core Web Vitals Ergebnisse

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-02

Defer vs Async JavaScript und wie dies die Core Web Vitals beeinflusst

Immer wenn ich die Core Web Vitals eines Kunden auditiere, stelle ich oft fest, dass auf einer Seite kaum zwischen parser-blockierendem (sync), asynchronem oder deferred JavaScript unterschieden wird. Das ist schade, denn verschiedene Scripts haben unterschiedliche optimale Zeitpunkte.

Zuletzt überprüft von Arjen Karel im März 2026

Laut dem 2025 Web Almanac bestehen nur 15% der mobilen Seiten das Render-Blocking-Resources-Audit. Die durchschnittliche Seite lädt 22 Scripts mit insgesamt über 630 KB, wobei 251 KB davon komplett ungenutzt bleiben. Die meisten Websites laden viel zu viel JavaScript und laden es zum falschen Zeitpunkt.

Kurz zusammengefasst

'Normales' JavaScript im head der Seite blockiert den Browser beim Parsen des HTML, bis es heruntergeladen und ausgeführt ist. Async Scripts werden im Hintergrund heruntergeladen, aber sofort ausgeführt wenn sie bereit sind, was das Parsen immer noch unterbrechen kann. Deferred Scripts werden im Hintergrund heruntergeladen und warten bis das Parsen abgeschlossen ist, bevor sie in Dokumentreihenfolge ausgeführt werden.

Verwenden Sie defer für alles, was mit dem DOM interagiert. Verwenden Sie async für Scripts, die vollständig unabhängig sind (Analytics, Tracking-Pixel). Verwenden Sie keines von beiden (sync) nur wenn das Script vor dem Rendern der Seite ausgeführt werden muss. Im Zweifelsfall verwenden Sie defer.

1. Synchrones JavaScript (sync)

Standardmäßig sind Scripts im Head der Seite synchron. Wenn der Browser auf ein synchrones Script trifft, stoppt er das Parsen des HTML, lädt das Script herunter und führt es aus, bevor er fortfährt. Das bedeutet, dass keine Pixel gezeichnet werden, bis alle sync Scripts fertig sind. Bei großen oder langsamen Scripts führt dies zu einer sichtbaren Verzögerung beim First Contentful Paint.

<!DOCTYPE html>
<html>
<head>
  <title>Sync JavaScript Example</title>
  <script src="script1.js"></script>
  <script src="script2.js"></script>
</head>
<body>
  <!-- Page content here -->
</body>
</html>

Der Browser muss script1.js herunterladen und ausführen, bevor er überhaupt mit script2.js beginnt. In der Zwischenzeit wird nichts gerendert. Die durchschnittliche mobile Seite hat bereits eine Total Blocking Time von fast 2 Sekunden im Jahr 2025. Synchrone Scripts im Head verschlimmern dies.

2. Asynchrones JavaScript (async)

Das Hinzufügen des async Attributs weist den Browser an, das Script im Hintergrund herunterzuladen, während er weiter das HTML parst. Das Script wird ausgeführt, sobald der Download abgeschlossen ist, egal wo sich der Parser zu diesem Zeitpunkt befindet. Das Parsen pausiert nur während der Ausführung.

<!DOCTYPE html>
<html>
<head>
  <title>Async JavaScript Example</title>
  <script src="script1.js" async></script>
  <script src="script2.js" async></script>
</head>
<body>
  <!-- Page content here -->
</body>
</html>

Async Scripts garantieren keine Ausführungsreihenfolge. Welches Script zuerst heruntergeladen wird, wird zuerst ausgeführt. Wenn script2.js von script1.js abhängt, wird async unvorhersehbare Probleme verursachen. Verwenden Sie async nur für Scripts, die vollständig unabhängig voneinander und vom DOM sind.

Ein wichtiger Hinweis: In Chrome erhalten async Scripts standardmäßig niedrige Netzwerkpriorität. Das bedeutet, der Browser beginnt möglicherweise später als erwartet mit dem Download. Wenn Sie ein async Script schnell laden müssen (ohne das Parsen zu blockieren), fügen Sie fetchpriority="high" hinzu.

3. Deferred JavaScript (defer)

Das defer Attribut lädt das Script ebenfalls im Hintergrund herunter, aber die Ausführung wird verschoben, bis das HTML-Dokument vollständig geparst ist. Deferred Scripts werden in Dokumentreihenfolge ausgeführt, kurz bevor das DOMContentLoaded Event ausgelöst wird.

<!DOCTYPE html>
<html>
<head>
  <title>Defer JavaScript Example</title>
  <script src="script1.js" defer></script>
  <script src="script2.js" defer></script>
</head>
<body>
  <!-- Page content here -->
</body>
</html>

Defer ist die sicherere Wahl für die meisten Scripts. Das DOM ist vollständig verfügbar wenn das Script ausgeführt wird, die Ausführungsreihenfolge bleibt erhalten und der erste Paint wird nicht blockiert. The Telegraph hat alle ihre Scripts deferred und die Ladezeit für Anzeigen um 4 Sekunden verbessert.

4. Modul-Scripts

Wenn Sie ES-Module verwenden (<script type="module">), erhalten Sie automatisch defer-Verhalten. Modul-Scripts werden im Hintergrund heruntergeladen, nach dem Parsen ausgeführt und behalten die Reihenfolge bei. Das explizite Hinzufügen von defer hat keine Wirkung, da es bereits der Standard ist.

Sie können async zu einem Modul-Script hinzufügen, wenn Sie möchten, dass es ausgeführt wird, sobald sein Abhängigkeitsgraph aufgelöst ist, anstatt auf den Abschluss des Parsens zu warten.

Vergleichstabelle

Attribut Download Ausführung Blockiert Parsen? Reihenfolge erhalten?
keines (sync) Blockiert Parsen während des Downloads Sofort nach dem Download Ja (Download + Ausführung) Ja
async Im Hintergrund Sobald der Download abgeschlossen ist Nur während der Ausführung Nein
defer Im Hintergrund Nach dem HTML-Parsen, vor DOMContentLoaded Nein Ja
type="module" Im Hintergrund Nach dem HTML-Parsen (wie defer) Nein Ja

Häufige Fragen

Was passiert, wenn ich async und defer am selben Tag verwende? Async gewinnt. Das defer Attribut wird vollständig ignoriert. Dieses Muster existierte früher als Fallback für IE9, aber im Jahr 2026 gibt es keinen Grund, beides zu verwenden.

Funktionieren async und defer bei Inline-Scripts? Nein. Beide Attribute werden bei klassischen Inline-Scripts (ohne src) ignoriert. Sie funktionieren nur bei externen Scripts. Die Ausnahme ist <script type="module">, das standardmäßig deferred ist, auch wenn es inline ist.

Ist defer besser als Scripts am Ende des Body zu platzieren? Ja. Ein deferred Script im <head> beginnt sofort mit dem Download (parallel zum HTML-Parsen). Ein Script am Ende des Body kann erst heruntergeladen werden, wenn der Parser es erreicht. Defer bietet frühere Erkennung und spätere Ausführung, was das Beste aus beiden Welten ist.

Wie async und defer die Core Web Vitals beeinflussen

Synchrone Scripts schaden direkt dem FCP, da nichts gezeichnet wird, bis sie fertig sind. Sie schaden auch dem LCP, wenn das LCP Element nicht gerendert werden kann, bis die Scripts abgeschlossen sind.

Async Scripts verbessern den FCP (der erste Paint wird nicht durch den Download blockiert), können aber immer noch INP Probleme verursachen, wenn sie während der Benutzerinteraktion ausgeführt werden und den Main Thread blockieren.

Defer Scripts liefern die besten Paint-Metriken, da sie das initiale Rendering überhaupt nicht beeinträchtigen. Der Kompromiss: Wenn Ihre Seite von JavaScript abhängt, um Inhalte anzuzeigen (Single-Page-Apps), kann defer den LCP tatsächlich verzögern, da der Inhalt erst erscheint, wenn das Script nach dem Parsen ausgeführt wird.

In den Monitoring-Daten von CoreDash sahen Websites, die alle nicht-kritischen Scripts von sync auf defer umstellten, eine durchschnittliche Verbesserung ihres FCP um [CD:placeholder]ms.

Einen Schritt weiter: Scripts bei Bedarf laden

Async und defer können eine Seite beschleunigen, indem sie den Parser nicht blockieren, aber es ist wichtig zu beachten, dass das Verschieben von Scripts nicht alle Probleme löst. Zum Beispiel ist das Largest Contentful Paint Element anfällig für Netzwerk- und CPU-Konkurrenz durch deferred und async Scripts. Das Interaction to Next Paint wird ebenfalls von Scripts beeinflusst, die früh während des Seitenladens ausgeführt werden. Deshalb sollten Sie Scripts, wann immer möglich, bei Bedarf laden, um mehr Kontrolle über deren Auswirkung auf die Seitenleistung zu haben. Lesen Sie, wie wir Scripts bei Bedarf laden.

Für einen vollständigen Überblick über alle JavaScript-Ladestrategien siehe 16 Methoden zum Verschieben von JavaScript. Wenn Sie mit der Lighthouse-Warnung zu Render-blockierenden Ressourcen zu tun haben, behandelt dieser Leitfaden die Lösung. Sie können das Laden auch mit JavaScript-Prioritätsstufen feinabstimmen und die optimale Script-Platzierung im Head vs Footer wählen.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Pinpoint the route, device, and connection that fails.

CoreDash segments every metric by route, device class, browser, and connection type. Real time data. Not the 28 day average Google gives you.

Explore Segmentation
Defer vs Async JavaScript und wie dies die Core Web Vitals beeinflusstCore Web Vitals Defer vs Async JavaScript und wie dies die Core Web Vitals beeinflusst