Sieben von zehn Websites, die bei PageSpeed Insights durchfallen, werden durch fremdes JavaScript ausgebremst. Externe Skripte, Analyse-Tools, Werbenetzwerke, Chats, Schriften und Cookie-Banner blockieren das Rendering und schieben den First Contentful Paint um Sekunden nach hinten. Und Sie können sie nicht einfach abschalten: Analyse-Tools versorgen das Marketing mit Daten, der Chat bringt Leads, und ohne Cookie-Banner besteht die Website kein Audit.

Es gibt eine Lösung: Lazy Loading. Das Skript wird erst geladen, wenn der Hauptinhalt dem Nutzer bereits angezeigt wurde. Der Browser wartet nicht, die Core-Web-Vitals-Kennzahlen springen in den grünen Bereich, und die Funktionalität der Website leidet nicht.

Wir haben alle funktionierenden Methoden zusammengetragen, von nativen HTML-Attributen über programmatische Techniken bis hin zu WordPress-Plugins. Mit Codebeispielen, die Sie direkt übernehmen und einsetzen können.

💡 Kurzüberblick:

• Verstehen Sie defer und async: Die Tabelle zeigt den Unterschied zwischen den Attributen klar auf
• Beherrschen Sie das programmatische Laden beim load-Event: eine moderne Version der Methode von Patrick Sexton
• Richten Sie den Intersection Observer für Skripte unterhalb des sichtbaren Bereichs ein: Chats, Karten, Kommentare
• Optimieren Sie WordPress ohne Codeeingriffe: die Plugins Flying Scripts und Asset CleanUp

Wie fremde Skripte den Ladevorgang ausbremsen

Der Browser parst HTML von oben nach unten. Stößt er auf <script src="..."> ohne Attribute, stoppt das Parsing: Der Browser lädt das Skript, führt es aus und setzt erst danach das Parsen der Seite fort. Das ist Render-Blocking.

Für den Nutzer bedeutet das einen weißen Bildschirm. Die Kennzahl First Contentful Paint (FCP), also die Zeit bis zur ersten sichtbaren Darstellung, hängt direkt davon ab, wie schnell der Browser alle blockierenden Skripte abgearbeitet hat. FCP ist Teil der Core Web Vitals und wirkt sich unmittelbar auf das Suchranking aus.

Fremde Skripte bremsen stärker als eigene: Sie liegen auf externen Servern, und Sie haben keine Kontrolle über deren Auslieferungsgeschwindigkeit oder Verfügbarkeit. DNS-Abfrage, TCP-Handshake, TLS-Handshake, Download, jede Stufe addiert Dutzende oder Hunderte Millisekunden. Laut HTTP-Archive-Daten für 2024 lädt die mediane Website auf Mobilgeräten 21 externe Skripte, drei davon blockierend.

Die Lösung besteht darin, dem Browser eine klare Anweisung zu geben: „Lade das Skript im Hintergrund und führe es später aus." Genau dafür sind die Attribute defer und async gedacht.

Defer und async: zwei eingebaute Mechanismen

Beide Attribute werden im <script>-Tag notiert und verändern das Ladeverhalten. Und zwar grundlegend unterschiedlich.

Defer: verzögerte Ausführung mit Reihenfolge-Garantie

Das Attribut defer weist den Browser an: „Lade das Skript im Hintergrund, führe es nach dem vollständigen HTML-Parsing aus." Die Ausführungsreihenfolge bleibt erhalten, Skripte werden exakt in der im Markup vorgegebenen Sequenz ausgeführt.

1
<script src="https://example.com/analytics.js" defer></script>
2
<script src="https://example.com/chat-widget.js" defer></script>

Die ideale Wahl für Skripte, die in einer bestimmten Reihenfolge ausgeführt werden müssen: Bibliothek, dann ihr Plugin, dann die Initialisierung. defer garantiert, dass das DOM zum Ausführungszeitpunkt bereit ist. Das DOMContentLoaded-Event feuert nach allen defer-Skripten.

Async: vollständige Unabhängigkeit

async lädt das Skript parallel zum Parsing und führt es sofort nach dem Laden aus, ohne auf andere zu warten. Die Reihenfolge ist nicht garantiert: Welches Skript zuerst vom Server geladen wurde, wird zuerst ausgeführt.

1
<script src="https://example.com/independent-widget.js" async></script>

Geeignet für völlig unabhängige Skripte: Besucherzähler, Social-Media-Buttons, Werbebanner. Wenn das Skript weder vom DOM noch von anderen Skripten abhängt, verwenden Sie async.

Wichtige Nuance: Ein async-Skript kann ausgeführt werden, bevor das DOM aufgebaut ist. Greift es auf Seitenelemente zu, die noch nicht existieren, erhalten Sie null und einen Fehler in der Konsole. Prüfen Sie das immer.

Programmatisches Laden beim load-Event: die Methode von Patrick Sexton

Was tun, wenn das Skript defer/async nicht unterstützt oder Sie das Markup nicht kontrollieren? Zum Beispiel, wenn das Skript über den Google Tag Manager eingebunden oder in einem fremden Plugin fest verdrahtet ist. Dann hilft der programmatische Ansatz.

Die Idee ist einfach: Erzeugen Sie ein <script>-Element per JavaScript und fügen Sie es erst dann ins DOM ein, wenn die Seite vollständig geladen ist. Der Urheber des Ansatzes, Patrick Sexton, beschrieb die Technik erstmals auf varvy.com.

Die moderne Version dieses Codes:

1
function loadScriptOnPageLoad(src) {
2
  const script = document.createElement('script');
3
  script.src = src;
4
  script.async = false;
5
  document.body.appendChild(script);
6
}
7
 
8
window.addEventListener('load', () => {
9
  loadScriptOnPageLoad('/wp-content/plugins/chat/chat.js');
10
  loadScriptOnPageLoad('/wp-content/plugins/analytics/tracker.js');
11
});

Zwei wesentliche Unterschiede zum jahrzehntealten Code. Erstens: Wir horchen auf load, nicht auf DOMContentLoaded. Das load-Event tritt später ein, wenn alle Bilder, Styles und Schriften geladen sind. Ein verzögertes Skript kann FCP oder LCP garantiert nicht beeinflussen. Zweitens: kein window.attachEvent. Diese Methode wurde nur für Internet Explorer 8 und älter benötigt, die es nicht mehr gibt. Modernes addEventListener funktioniert in allen aktuellen Browsern.

Drei Situationen, in denen der programmatische Ansatz unersetzlich ist

defer und async funktionieren nur bei <script>-Tags, die direkt im HTML stehen. Die programmatische Methode rettet Sie, wenn:

• Das Skript wird über Google Tag Manager oder einen anderen Tag-Manager eingefügt, Sie sehen das Markup nicht.
• Sie können die Vorlage nicht bearbeiten: Es handelt sich um ein Plugin oder Theme eines Drittanbieters mit einer starren Struktur.
• Sie benötigen bedingtes Laden: zum Beispiel ein Kontaktformular-Skript nur auf Seiten mit einem Formular.

Intersection Observer: bedarfsgesteuertes Laden

Für manche Skripte ist selbst defer zu früh. Ein Chat-Widget wird erst benötigt, wenn der Nutzer zum Footer scrollt. Eine Karte, bis er den Adressblock erreicht. Kommentare, bis er zum Diskussionsbereich liest.

Die Intersection Observer API löst genau diese Aufgabe: Das Skript lädt erst, wenn das Zielelement im Viewport erscheint.

1
const chatTarget = document.getElementById('chat-container');
2
 
3
if (chatTarget) {
4
  const observer = new IntersectionObserver((entries) => {
5
    entries.forEach((entry) => {
6
      if (entry.isIntersecting) {
7
        const script = document.createElement('script');
8
        script.src = '/wp-content/plugins/chat/chat.js';
9
        document.body.appendChild(script);
10
        observer.unobserve(entry.target);
11
      }
12
    });
13
  }, { rootMargin: '200px' });
14
 
15
  observer.observe(chatTarget);
16
}

Der Parameter rootMargin: '200px' lädt das Skript 200 Pixel, bevor das Element auf dem Bildschirm erscheint, der Nutzer bemerkt keine Verzögerung. Früher nutzten Entwickler jahrelang scroll-Listener mit getBoundingClientRect(), aber diese feuerten bei jedem Pixel des Scrollvorgangs und überlasteten den Haupt-Thread.

Intersection Observer arbeitet asynchron und belastet den Browser kaum. Die Unterstützung ist in allen modernen Browsern gegeben, einschließlich Safari ab Version 12.1. IE11 wird nicht unterstützt, aber sein Anteil nähert sich im Juni 2026 dem statistischen Fehler.

WordPress: Lazy Loading ohne Code-Änderungen

Wenn die Seite auf WordPress läuft, können Sie Lazy Loading auf drei Arten umsetzen, von der einfachsten bis zur flexibelsten.

Plugins für Lazy Loading von Skripten

Zwei funktionierende Optionen, getestet auf Tausenden von Seiten.

Flying Scripts, ein kostenloses Plugin von Gijo Varghese, über 30.000 aktive Installationen, Version 1.2.4 (aktualisiert im Mai 2026). Kann JavaScript bis zur ersten Nutzerinteraktion verzögern: Mausbewegung, Klick, Scrollen, Touch auf Mobilgeräten. Sie geben Schlüsselwörter aus der Skript-URL an, und das Plugin verzögert dessen Ausführung. Es gibt einen Timeout: Wenn der Nutzer nicht mit der Seite interagiert, werden die Skripte nach einer festgelegten Zeit ausgeführt. Maximaler Metrik-Gewinn, aber Chat- oder Rückrufformulare sollten von der Verzögerung ausgeschlossen werden, sie werden sofort benötigt.

WP Rocket, ein Premium-Caching-Plugin mit integrierter Funktion zur Verzögerung des JavaScript-Ladens. Fügt ausgewählten Skripten über die Admin-Oberfläche defer oder async hinzu. Sie geben die URL an, das Plugin ändert das Attribut beim Rendern der Seite. Geeignet für diejenigen, die WP Rocket bereits zum Caching nutzen und die Anzahl der Plugins nicht erhöhen möchten.

Script_loader_tag-Hook in der functions.php

Wenn Sie kein separates Plugin installieren möchten, erlaubt WordPress das Filtern der <script>-Tag-Ausgabe über den script_loader_tag-Hook. Der folgende Code fügt allen Skripten außer jQuery und dem Admin-Panel defer hinzu:

1
add_filter('script_loader_tag', function($tag, $handle) {
2
    if (is_admin()) {
3
        return $tag;
4
    }
5
    $skip = ['jquery', 'jquery-core', 'jquery-migrate'];
6
    if (in_array($handle, $skip, true)) {
7
        return $tag;
8
    }
9
    return str_replace(' src', ' defer src', $tag);
10
}, 10, 2);

Platzieren Sie den Code in der functions.php des Child-Themes oder über das Code Snippets-Plugin. Erstellen Sie vor der Anwendung ein Backup. defer bei jQuery zerstört jeden Code, der $() oder jQuery() vor DOMContentLoaded aufruft. Beginnen Sie mit einzelnen Skripten und prüfen Sie die Konsole nach jeder Änderung auf Fehler.

Volle Kontrolle: Asset CleanUp

Asset CleanUp, ein kostenloses Plugin (Version 1.4.0.4, aktualisiert im Mai 2026), das ALLE auf einer Seite geladenen Skripte und Styles anzeigt. Mit Angabe von Größe und Quelle. Sie können ein bestimmtes Skript auf einer bestimmten Seite deaktivieren, das Ladeattribut auf defer/async ändern oder ein unnötiges Asset komplett entladen.

Der Hauptvorteil gegenüber Flying Scripts: Asset CleanUp liefert ein vollständiges Bild für jede Seite. Sie sehen genau, was geladen wird, und treffen Entscheidungen präzise. Die Pro-Version bietet bedingtes Laden nach Bildschirmtyp und das Verschieben von Skripten zwischen HEAD und BODY. Funktioniert mit jedem Caching-Plugin zusammen, WP Rocket, W3 Total Cache, WP Fastest Cache.

Ein tieferer Einblick in die WordPress-Beschleunigung findet sich in einem separaten Artikel: 21 Tipps zur Verbesserung der PageSpeed Insights-Bewertung. Wenn das Problem nicht nur Skripte, sondern die allgemeine Hosting-Geschwindigkeit ist, sehen Sie sich Wege zur Reduzierung der WordPress-Seitenladezeit an. Und Tools zur Überprüfung der WordPress-Performance helfen, den tatsächlichen Effekt der Optimierung zu messen.

Video: async und defer in der Praxis

Eine fünfminütige Aufschlüsselung vom Kanal xplodivity, mit visuellen Ladediagrammen und Live-Code-Beispielen:

⁉️🤔 Häufig gestellte Fragen

defer** oder async, was sollte man für Google Analytics wählen?**

async. Analytics.js und gtag.js sind vollständig unabhängig vom DOM, sie benötigen keine bestimmte Ausführungsreihenfolge. GA4 empfiehlt offiziell async, die Bibliothek kümmert sich selbst um die verzögerte Initialisierung.

Wie unterscheidet sich das load-Ereignis von DOMContentLoaded?

DOMContentLoaded wird ausgelöst, wenn das HTML vollständig geparst und der DOM-Baum aufgebaut ist, Stylesheets und Bilder können noch laden. load tritt später ein: wenn wirklich alles geladen ist, inklusive Bilder, Schriften und Stylesheets. Für verzögertes Laden von Skripten ist load sicherer: Zu diesem Zeitpunkt wurde die Seite dem Nutzer definitiv bereits angezeigt.

Kann man defer zu einem Inline-Skript hinzufügen?

Nein. Das defer-Attribut funktioniert nur bei externen Skripten mit einem src-Attribut. Ein Inline-Skript (<script>code</script>) mit defer wird ignoriert, der Browser führt es als normales, blockierendes Skript aus. Um Inline-Code zu verzögern, betten Sie ihn in einen DOMContentLoaded- oder load-Listener ein.

Ist es sicher, defer bei allen Skripten einer WordPress-Seite zu setzen?

jQuery mit defer wird jeden Code zerstören, der $() oder jQuery() vor DOMContentLoaded aufruft. Genau deshalb wird jQuery im obigen Snippet von der Verarbeitung ausgeschlossen. Beginnen Sie mit nicht kritischen Skripten: Chat, soziale Medien, Werbung. Erweitern Sie die Liste schrittweise und prüfen Sie nach jeder Änderung die Konsole auf Fehler.

Intersection Observer oder defer, was ist besser?

Sie lösen unterschiedliche Aufgaben. defer ist für Skripte, die auf der Seite immer benötigt werden, aber für das erste Rendering nicht kritisch sind: Analytics, A/B-Tests. Intersection Observer ist für Skripte, die an einen bestimmten Block gebunden sind: Karte, Chat im Footer, Kommentar-Widget. Einfache Regel: Skript im oberen Seitenbereich, defer; Skript unterhalb des sichtbaren Bereichs, Intersection Observer.

Was tun, wenn Flying Scripts eine Funktion zerstört hat?

Schließen Sie das problematische Skript in den Plugin-Einstellungen von der Verzögerungsliste aus. Flying Scripts erlaubt die Angabe von Schlüsselwörtern für den Einschluss, entfernen Sie das Schlüsselwort des problematischen Skripts, und es wird normal geladen. Für kritische Elemente wie Formulare und Chats ist dies ein obligatorischer Schritt, bevor Sie die Verzögerung aktivieren.

Was Sie auf Ihrer Seite einsetzen sollten: Entscheidungsmatrix

Die Wahl läuft auf eine einfache Entscheidungstabelle hinaus:

• Skript ist im HTML geschrieben, Sie kontrollieren die Tags, defer, wenn es von der Reihenfolge abhängt, async, wenn es vollständig unabhängig ist.
• Skript wird über GTM oder ein fremdes Plugin eingebunden, Tags sind nicht zugänglich, programmatisches Laden beim load-Ereignis.
• Skript ist an einen Block unterhalb des sichtbaren Bereichs gebunden, Intersection Observer mit rootMargin: '200px'.
• WordPress, Sie benötigen es ohne Code, Flying Scripts (kostenlos, über 30.000 Installationen) oder Asset CleanUp für vollständige Asset-Kontrolle.

Beginnen Sie mit dem Einfachsten: Öffnen Sie PageSpeed Insights, finden Sie blockierende externe Skripte und fügen Sie defer hinzu. Ein Attribut, und der FCP kann von Rot auf Grün springen. Und wenn Sie die Attribute gemeistert haben, werfen Sie einen Blick auf unseren Test von Tools zur Überprüfung der WordPress-Performance, er hilft Ihnen, den tatsächlichen Effekt zu messen.