Defer vs. Async JavaScript und wie sich dies auf die Core Web Vitals auswirkt
Erfahren Sie, wann Sie JavaScript asynchron (async) und wann verzögert (defer) laden sollten, um die besten Core Web Vitals Ergebnisse zu erzielen
Defer vs. Async JavaScript und wie sich dies auf die Core Web Vitals auswirkt
Wann immer ich die Core Web Vitals eines Kunden überprüfe, stelle ich oft fest, dass auf einer Seite kaum zwischen Parser-blockierendem (sync), asynchronem oder verzögertem (defer) JavaScript unterschieden wird. Das ist schade, denn verschiedene Skripte haben unterschiedliche optimale Timings.
Zuletzt überprüft von Arjen Karel im März 2026
Table of Contents!
- Defer vs. Async JavaScript und wie sich dies auf die Core Web Vitals auswirkt
- Kurz gesagt
- 1. Synchrones JavaScript (sync)
- 2. Asynchrones JavaScript (async)
- 3. Verzögertes JavaScript (defer)
- 4. Modul-Skripte
- Vergleichstabelle
- Häufige Fragen
- Wie async und defer die Core Web Vitals beeinflussen
- Noch einen Schritt weiter gehen: Skripte nach Bedarf laden
Laut dem Web Almanac 2025 bestehen nur 15 % der mobilen Seiten das Audit für Render-blockierende Ressourcen. Die mittlere Seite lädt 22 Skripte mit insgesamt über 630 KB, wobei 251 KB dieses JavaScript komplett ungenutzt bleiben. Die meisten Websites laden viel zu viel JavaScript und das zur falschen Zeit.
Kurz gesagt
'Normales' JavaScript im head der Seite blockiert den Browser beim Parsen des HTML, bis es heruntergeladen und ausgeführt ist. Async-Skripte werden im Hintergrund heruntergeladen, aber ausgeführt, sobald sie bereit sind, was das Parsen immer noch unterbrechen kann. Defer-Skripte werden im Hintergrund heruntergeladen und warten mit der Ausführung, bis das Parsen abgeschlossen ist, und zwar in der Reihenfolge des Dokuments.
Verwenden Sie defer für alles, was das DOM berührt. Verwenden Sie async für Skripte, die völlig unabhängig sind (Analytics, Tracking-Pixel). Verwenden Sie keines von beiden (sync) nur dann, wenn das Skript ausgeführt werden muss, bevor die Seite gerendert wird. Im Zweifelsfall verwenden Sie defer.
1. Synchrones JavaScript (sync)
Standardmäßig sind Skripte im Head der Seite synchron. Wenn der Browser auf ein synchrones Skript stößt, stoppt er das Parsen des HTML, lädt das Skript herunter und führt es aus, bevor er fortfährt. Das bedeutet, dass keine Pixel gezeichnet werden, bis alle Sync-Skripte abgeschlossen sind. Bei großen oder langsamen Skripten entsteht dadurch eine sichtbare Verzögerung beim First Contentful Paint.
<!DOCTYPE html> <html> <head> <title>Sync JavaScript Beispiel</title> <script src="script1.js"></script> <script src="script2.js"></script> </head> <body> <!-- Seiteninhalt hier --> </body> </html>
Der Browser muss script1.js herunterladen und ausführen, bevor er überhaupt mit script2.js beginnt. Währenddessen wird nichts gerendert. Die mittlere mobile Seite hat im Jahr 2025 bereits eine Total Blocking Time von fast 2 Sekunden. Synchrone Skripte im Head machen dies noch schlimmer.
2. Asynchrones JavaScript (async)
Das Hinzufügen des async-Attributs weist den Browser an, das Skript im Hintergrund herunterzuladen, während er mit dem Parsen des HTML fortfährt. Das Skript wird ausgeführt, sobald der Download abgeschlossen ist, unabhängig davon, wo sich der Parser in diesem Moment befindet. Das Parsen pausiert nur während der Ausführung.
<!DOCTYPE html> <html> <head> <title>Async JavaScript Beispiel</title> <script src="script1.js" async></script> <script src="script2.js" async></script> </head> <body> <!-- Seiteninhalt hier --> </body> </html>
Async-Skripte garantieren keine Ausführungsreihenfolge. Das Skript, das zuerst heruntergeladen wurde, wird auch zuerst ausgeführt. Wenn script2.js von script1.js abhängt, wird async die Dinge unvorhersehbar beschädigen. Verwenden Sie async nur für Skripte, die völlig unabhängig voneinander und vom DOM sind.
Eine Sache, die Sie beachten sollten: In Chrome erhalten Async-Skripte standardmäßig eine niedrige Netzwerkpriorität (Low network priority). Das bedeutet, dass der Browser möglicherweise später als erwartet mit dem Herunterladen beginnt. Wenn Sie möchten, dass ein Async-Skript schnell geladen wird (ohne das Parsen zu blockieren), fügen Sie fetchpriority="high" hinzu.
3. Verzögertes JavaScript (defer)
Das defer-Attribut lädt das Skript ebenfalls im Hintergrund herunter, aber die Ausführung wird verschoben, bis das HTML-Dokument vollständig geparst ist. Defer-Skripte werden in der Reihenfolge des Dokuments ausgeführt, kurz bevor das DOMContentLoaded-Ereignis ausgelöst wird.
<!DOCTYPE html> <html> <head> <title>Defer JavaScript Beispiel</title> <script src="script1.js" defer></script> <script src="script2.js" defer></script> </head> <body> <!-- Seiteninhalt hier --> </body> </html>
Defer ist für die meisten Skripte die sicherere Wahl. Das DOM ist vollständig verfügbar, wenn das Skript ausgeführt wird, die Ausführungsreihenfolge bleibt erhalten und der erste Paint wird nicht blockiert. The Telegraph verzögerte alle seine Skripte und verbesserte die Ladezeit von Anzeigen um 4 Sekunden.
4. Modul-Skripte
Wenn Sie ES-Module verwenden (<script type="module">), erhalten Sie automatisch das defer-Verhalten. Modul-Skripte werden im Hintergrund heruntergeladen, nach dem Parsen ausgeführt und behalten die Reihenfolge bei. Das explizite Hinzufügen von defer hat keinen Effekt, da dies bereits der Standard ist.
Sie können einem Modul-Skript async hinzufügen, wenn Sie möchten, dass es ausgeführt wird, sobald der Abhängigkeitsgraph aufgelöst ist, anstatt auf den Abschluss des Parsens zu warten.
Vergleichstabelle
| Attribut | Downloads | Ausführung | Blockiert Parsing? | Reihenfolge bewahrt? |
|---|---|---|---|---|
keines (sync) |
Blockiert Parsing 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-Parsing, vor DOMContentLoaded | Nein | Ja |
type="module" |
Im Hintergrund | Nach dem HTML-Parsing (gleiches wie defer) | Nein | Ja |
Häufige Fragen
Was passiert, wenn ich sowohl async als auch defer auf demselben 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 mehr, beides zu verwenden.
Funktionieren async und defer bei Inline-Skripten? Nein. Beide Attribute werden bei klassischen Inline-Skripten (ohne src) ignoriert. Sie funktionieren nur bei externen Skripten. Die Ausnahme ist <script type="module">, welches standardmäßig verzögert wird, selbst wenn es inline ist.
Ist defer besser, als Skripte ans Ende des Body zu setzen? Ja. Ein Defer-Skript im <head> beginnt sofort mit dem Herunterladen (parallel zum HTML-Parsing). Ein Skript am Ende des Body kann nicht mit dem Herunterladen beginnen, bis der Parser es erreicht. Defer bietet Ihnen eine frühere Entdeckung und eine spätere Ausführung, was das Beste aus beiden Welten ist.
Wie async und defer die Core Web Vitals beeinflussen
Synchrone Skripte schaden direkt dem FCP, da nichts gezeichnet wird, bis sie abgeschlossen sind. Sie schaden auch dem LCP, wenn das LCP-Element erst gerendert werden kann, wenn die Skripte abgeschlossen sind.
Async-Skripte 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 Haupt-Thread blockieren.
Defer-Skripte liefern Ihnen die besten Paint-Metriken, da sie das anfängliche Rendern überhaupt nicht beeinträchtigen. Der Kompromiss: Wenn Ihre Seite zur Anzeige von Inhalten auf JavaScript angewiesen ist (Single-Page-Apps), kann defer den LCP tatsächlich verzögern, da der Inhalt erst erscheint, wenn das Skript nach dem Parsen ausgeführt wird.
In den Monitoring-Daten von CoreDash verbesserten Websites, die alle nicht kritischen Skripte von sync auf defer umstellten, ihren FCP im Durchschnitt um 340 ms.
Noch einen Schritt weiter gehen: Skripte nach Bedarf laden
Async und defer können eine Seite beschleunigen, indem sie den Parser nicht blockieren, aber es ist wichtig zu beachten, dass das Verzögern von Skripten nicht alle Ihre Probleme lösen wird. Beispielsweise ist das Largest Contentful Paint-Element anfällig für Netzwerk- und CPU-Wettbewerb, der durch Defer- und Async-Skripte verursacht wird. Die Interaction to Next Paint wird ebenfalls durch Skripte beeinflusst, die früh während des Seitenladevorgangs ausgeführt werden. Deshalb sollten Sie Skripte wann immer möglich nach Bedarf laden, um mehr Kontrolle über deren Auswirkungen auf die Seiten-Performance zu haben. Lesen Sie, wie wir Skripte nach Bedarf laden.
Einen vollständigen Überblick über alle JavaScript-Ladestrategien finden Sie unter 16 Methoden, um JavaScript zu verzögern. Wenn Sie mit der Lighthouse-Warnung bezüglich Render-blockierender Ressourcen zu tun haben, behandelt dieser Leitfaden die Lösung. Sie können das Laden auch mit JavaScript-Prioritätsstufen feinabstimmen und die optimale Skript-Platzierung im Head vs. Footer wählen.
Real time data. Not 28 day averages.
CoreDash segments every metric by route, device, browser, and connection type.
Explore CoreDash
