Blockierende Skripte: Warum Ihre Website beim Laden einfriert
Test #07 analysiert <script>-Tags und prüft, ob sie das erste Rendering blockieren. Ein häufiges Problem, leicht zu beheben, das für den Nutzer alles verändert.
- Ein Skript ohne defer oder async blockiert das Seiten-Rendering: Der Besucher sieht während des Downloads einen weißen Bildschirm.
- Orilyt zählt externe Skripte und berechnet den nicht-blockierenden Prozentsatz. ≥ 50 % = Score 100, 0 % = Score 30.
- Die Korrektur ist einfach: Das Hinzufügen von defer (oder async) zu jedem <script src="...">-Tag reicht in den meisten Fällen aus.
Wenn ein Browser auf ein <script src="...">-Tag trifft, hält er an, lädt die Datei herunter, führt sie aus und setzt dann das Seiten-Rendering fort. Währenddessen sieht der Besucher nichts — oder schlimmer, eine halb aufgebaute Seite.
Das ist das Standard-HTML-Verhalten. Ohne explizite Anweisungen ist jedes externe Skript „blockierend". Je mehr Skripte im <head>, desto länger die Rendering-Verzögerung.
Der Orilyt-Test #07 erkennt dieses Problem und misst den Anteil nicht-blockierender Skripte. Sehen wir uns an, wie er funktioniert und wie Sie seine Ergebnisse nutzen können.
Warum sind blockierende Skripte ein Problem?
Eine typische WordPress-Website lädt zwischen 5 und 15 externe JavaScript-Dateien: Analytics, Cookie-Banner, Slider, Formulare, verschiedene Plugins. Wenn keines defer oder async verwendet, lädt der Browser sie nacheinander, bevor er irgendetwas anzeigt.
Die Auswirkung auf die Core Web Vitals ist direkt: LCP (Largest Contentful Paint) und FCP (First Contentful Paint) werden verzögert. Google bestraft langsame Websites im Ranking.
Für den Nutzer ist der Effekt sofort spürbar: Die Website erscheint 2 bis 5 Sekunden lang „eingefroren" bei einer Mobilverbindung. Im Jahr 2026 ist das inakzeptabel.
Wie funktioniert Test #07?
Orilyt analysiert den HTML-Code der Seite und extrahiert alle <script>-Tags mit einem src-Attribut (externe Skripte). Für jedes Skript werden drei Informationen erfasst:
- Vorhandensein des defer-Attributs — das Skript wird parallel heruntergeladen und nach dem HTML-Parsing ausgeführt.
- Vorhandensein des async-Attributs — das Skript wird parallel heruntergeladen und ausgeführt, sobald es bereit ist.
- Position im <head> — ein blockierendes Skript im <head> ist der schlimmste Fall.
Der Score wird basierend auf dem Prozentsatz nicht-blockierender Skripte (defer oder async) berechnet:
Wenn keine externen Skripte erkannt werden, ist der Score automatisch 100/100 — kein Blockierungsrisiko.
Der Bericht zeigt auch die „Head Offenders": blockierende Skripte im <head>, die den größten Einfluss auf das erste Rendering haben.
defer vs async: Was ist der Unterschied?
Beide Attribute ermöglichen dem Browser, das Skript herunterzuladen, ohne das Rendering zu blockieren. Der Unterschied liegt im Ausführungszeitpunkt:
defer: Das Skript wird ausgeführt, nachdem das HTML vollständig geparst ist, in der Reihenfolge des Auftretens. Ideal für die meisten Skripte (Analytics, UI, Plugins).
async: Das Skript wird ausgeführt, sobald es heruntergeladen ist, ohne auf HTML oder andere Skripte zu warten. Nützlich für unabhängige Skripte (Tracking, A/B-Tests).
Im Zweifelsfall verwenden Sie defer — es ist die sicherste Wahl, da es die Ausführungsreihenfolge beibehält.
Wie nutzen Sie diesen Test in Ihren Angeboten?
Blockierende Skripte sind ein besonders wirksames Vorverkaufsargument: Das Problem ist für den Website-Besitzer unsichtbar (er hat eine schnelle Verbindung), aber kritisch für seine mobilen Besucher.
So strukturieren Sie Ihre Empfehlung mit der FIA-Methode:
- Fakt: „Ihre Website lädt X JavaScript-Dateien ohne defer oder async. Sie blockieren das Rendering für Y Sekunden."
- Auswirkung: „Auf Mobilgeräten sehen Besucher während des Ladens einen weißen Bildschirm. Google bestraft langsame Websites in den Suchergebnissen."
- Aktion: „Das defer-Attribut zu jedem <script>-Tag hinzufügen. Geschätzte Zeit: 30 Minuten (Theme + Plugins)."
Der Orilyt-Bericht listet blockierende Skripte nach URL auf — Sie können dem Kunden genau zeigen, welche Dateien das Problem verursachen.
Diesen Test in Ihren Workflow integrieren
Test #07 ergänzt die anderen Performance-Tests für eine vollständige Diagnose:
- Starten Sie das Orilyt-Audit → der Score „Skriptladung" erscheint im Abschnitt Performance.
- Wenn der Score rot oder orange ist, öffnen Sie die Details: Sie sehen die Anzahl blockierender Skripte, die „Head Offenders" und den Gesamtprozentsatz.
- Nach der Korrektur (Hinzufügen von defer/async) starten Sie das Audit erneut und nutzen den Vorher/Nachher-Vergleich, um die Verbesserung zu zeigen.
In Kombination mit den Tests TTFB (#16), Komprimierung (#04) und Browser-Caching (#03) bildet dieser Test die Grundlage einer soliden Performance-Diagnose.
Fazit
Blockierende Skripte sind eine der häufigsten Ursachen für Langsamkeit auf WordPress-Websites. Das Problem ist mit bloßem Auge unsichtbar, aber messbar: genau die Art von Entdeckung, die ein professionelles Audit rechtfertigt.
Der Orilyt-Test #07 gibt Ihnen eine präzise Diagnose: Anzahl der Skripte, nicht-blockierender Prozentsatz, Liste der Verursacher. Ein konkretes, datengestütztes Argument, das direkt in Ihr Angebot einfließen kann.
Testen Sie jetzt eine Kunden-Website — Sie werden wahrscheinlich von der Anzahl blockierender Skripte überrascht sein.