Sie aktivieren „JavaScript-Ausführung verzögern“, der PageSpeed-Bericht springt nach oben, und dann kommen die Nachrichten. Das mobile Menü reagiert nicht. Das Cookie-Banner lässt sich nicht schließen. Das Kontaktformular lädt endlos. Der Slider auf der Startseite ist leer. Die Chat-Blase ist verschwunden. Oder eine Woche später zeigt die Webanalyse einen Rückgang der Sitzungen, den niemand erklären kann.

Der übliche Rat ist eine Liste von Ausnahmen zum Einfügen oder das Abschalten der Option. Beides funktioniert, und beides verschenkt den Gewinn, ohne Ihnen zu sagen, was eigentlich kaputt war. Dieser Leitfaden gibt Ihnen stattdessen die Methode: warum die Verzögerung Dinge kaputt macht, wie Sie das Symptom lesen und wie Sie das eine Skript finden, das herausmuss.

Was die Verzögerung mit einer Seite macht

Normalerweise wird jedes Skript der Seite während des Ladens heruntergeladen und ausgeführt. Mit einer JavaScript-Verzögerung werden die Skripte geparkt: ihre Tags werden so umgeschrieben, dass der Browser sie ignoriert. Ein kleiner Loader wartet, bis der Besucher etwas tut (die Maus bewegen, scrollen, tippen, eine Taste drücken) oder bis ein Timer abläuft, und setzt die Skripte erst dann wieder ein, eines nach dem anderen.

Deshalb steigt der Laborwert: Während des Tests läuft fast kein JavaScript. Deshalb geht auch etwas kaputt: Jedes Skript läuft jetzt später, in einer Seite, die bereits fertig geladen ist, und nur dann, wenn der Loader so weit kommt.

Kurz gefasst

Verzögerte Skripte laufen nicht beim Laden. Sie laufen nach der ersten Interaktion oder nach einem Timer.
Sie laufen in einer bereits geladenen Seite, und dafür wurden sie nicht geschrieben.
Jeder der folgenden Fehler geht auf eine dieser beiden Tatsachen zurück.

Die fünf Arten, wie es kaputtgeht, und ihre Signatur

1. Eine Abhängigkeit fehlt. Ein Skript ist von der Verzögerung ausgenommen (es läuft also beim Laden), aber etwas, das es braucht, ist noch geparkt. Der klassische Fall: Ein Menüskript läuft, während jQuery noch nicht existiert. Signatur: ein roter Fehler in der Konsole, zum Beispiel jQuery is not defined, $ is not a function oder Cannot read properties of undefined.

2. Das Seitenereignis ist schon ausgelöst. Viele Skripte warten auf DOMContentLoaded oder window.onload, bevor sie starten. Wenn ein verzögertes Skript ankommt, sind diese Ereignisse längst vorbei, also wartet sein Initialisierungscode auf etwas, das nie passiert. Signatur: kein Fehler, die Funktion startet einfach nie. Slider, Galerien und Lightboxen sind häufige Opfer.

3. Der erste Klick wird verschluckt. Das erste Tippen des Besuchers ist die Interaktion, die den Loader weckt. Die Skripte sind noch nicht da, wenn dieses Tippen ankommt, also passiert nichts. Signatur: Beim zweiten Tippen funktioniert es immer. Diesen Fall haben wir ausführlich im Leitfaden zum Burger-Menü behandelt.

4. Die Kette hängt an einem Skript. Verzögerte Skripte werden meist der Reihe nach wieder eingesetzt, eines nach dem anderen, damit Abhängigkeiten weiter funktionieren. Wird eines davon festgehalten (ein Werbeblocker, ein DNS-Filter oder ein Firmenproxy, der weder antwortet noch ablehnt), wartet alles danach für immer. Signatur: sporadisch, nur bei manchen Besuchern, nie auf Ihrem Rechner. Oft sterben die Funktionen im Footer.

5. Der Besucher wird nie gezählt. Ist Ihr Analytics-Tag verzögert, lädt ein Besucher, der die Seite liest und ohne Interaktion (und vor dem Timer) wieder geht, es nie. Signatur: kein sichtbarer Fehler, nur weniger Sitzungen und ein höherer Anteil kurzer Besuche, der in den Berichten fehlt.

Kurz gefasst

Roter Konsolenfehler: Eine Abhängigkeit fehlt (Fall 1).
Kein Fehler, die Funktion startet nie: Ein erwartetes Seitenereignis ist schon vorbei (Fall 2).
Funktioniert beim zweiten Tippen: Die erste Interaktion hat den Loader geweckt (Fall 3).
Kaputt nur bei manchen Besuchern: Die Kette hängt an einem festgehaltenen Skript (Fall 4).
Nichts Sichtbares, weniger Sitzungen: Das Analytics-Tag ist verzögert (Fall 5).

Schritt 1: Bestätigen, dass die Verzögerung die Ursache ist

Schalten Sie die Verzögerung ab, leeren Sie jede Cache-Ebene (Seiten-Cache, Hoster-Cache, CDN) und testen Sie erneut in einem privaten Fenster. Funktioniert die Funktion, ist die Verzögerung die Ursache. Scheitert sie weiterhin, hören Sie hier auf: Das Problem liegt woanders, oft bei einer CSS-Optimierung, die die Styles eines versteckten Elements entfernt hat (siehe den Leitfaden zu Critical CSS).

Schalten Sie sie dann wieder ein und reproduzieren Sie den Fehler sauber:

Mobile Emulation in den DevTools, nicht Ihre Desktop-Ansicht. Viele Setups halten pro Gerät eine eigene optimierte Version vor.
Ein sauberes privates Fenster, ohne Erweiterungen, damit Sie sehen, was ein Erstbesucher sieht.
Tippen Sie zuerst auf das kaputte Element, ohne vorher die Maus zu bewegen oder zu scrollen. Nur so sehen Sie Fall 3.
Dann noch einmal mit aktivem Werbeblocker, um Fall 4 sichtbar zu machen.

Schritt 2: Das Skript hinter der kaputten Funktion finden

Öffnen Sie die DevTools, bevor Sie den Fehler reproduzieren, und lesen Sie dann drei Stellen.

Die Konsole. Jeder rote Fehler nach Ihrer Interaktion deutet auf Fall 1, und der Dateiname rechts neben dem Fehler ist Ihr erster Verdächtiger. Klicken Sie darauf: Die DevTools zeigen die genaue Zeile.

Die Event-Listener des Elements. Rechtsklick auf den kaputten Button, Untersuchen wählen, dann das Panel Event Listeners öffnen. Es listet jeden an das Element gebundenen Handler und die Datei, die ihn gebunden hat. Ist die Liste nach Ihrer Interaktion leer, ist das Skript, das den Handler binden sollte, nie gelaufen (Fall 2 oder 4).

Eine Suche über alle geladenen Dateien. Durchsuchen Sie im Sources-Panel alle Dateien (Strg+Umschalt+F, oder Cmd+Option+F auf dem Mac) nach der Klasse oder ID des kaputten Elements, zum Beispiel menu-toggle oder cky-btn-accept. Die Datei, die darauf verweist, ist die, die es steuert.

Konsolen-Snippet: die noch geparkten Skripte auflisten

// In die Konsole einfügen, sobald die Seite geladen ist, vor jeder Interaktion,
// dann erneut nach Ihrem ersten Klick. Passen Sie den Typ an das Markup Ihres Tools an.
[...document.querySelectorAll('script[type]')]
  .filter(s => !/^(text|application)\/(javascript|ld\+json|json)$|^module$/.test(s.type))
  .map(s => s.src || s.dataset.src || (s.textContent || '').slice(0, 60))

Ist das gefundene Skript nach Ihrer Interaktion noch in dieser Liste, hat die Kette es nie erreicht: Sehen Sie sich an, was direkt davor steht (Fall 4).

Schritt 3: Die ganze Kette ausnehmen, nicht nur die Datei

Ein Skript arbeitet selten allein. Bevor Sie es ausnehmen, listen Sie auf, was es braucht, in der Reihenfolge, in der der Seitenquelltext es zeigt:

Seine Bibliotheken: jQuery und manchmal jQuery Migrate oder das Kernskript des Themes.
Seine Konfiguration: WordPress gibt oft direkt vor der Datei ein kleines Inline-Skript aus, dessen ID auf -js-extra endet (zum Beispiel var wpcf7 = {...} für Contact Form 7). Ohne es kann die Datei nicht laufen.
Seine eigene Datei, zuletzt.

Nehmen Sie sie gemeinsam aus und zielen Sie auf jede über ein eindeutiges Stück ihrer URL (etwa /contact-form-7/ oder jquery.min.js) statt über ein allgemeines Wort. Ein Fragment wie slider kann auf weit mehr Dateien passen, als Sie denken, und jeder zusätzliche Treffer gibt einen Teil des Gewinns zurück.

Kurz gefasst

Bibliothek, Inline-Konfiguration und Datei gemeinsam ausnehmen.
Über ein eindeutiges URL-Fragment zielen, nie über ein allgemeines Wort.
Eine ausgenommene Datei, deren Abhängigkeit noch verzögert ist, scheitert genauso, diesmal mit einem Fehler.

Schritt 4: Wenn Sie es nicht finden, halbieren

Auf einer schweren Seite mit 60 verzögerten Skripten dauert es einen Nachmittag, jedes einzeln zu lesen. Halbieren braucht sechs Tests. Nehmen Sie die erste Hälfte der verzögerten Skripte aus und testen Sie. Funktioniert die Funktion, steckt der Schuldige in dieser Hälfte; sonst in der anderen. Wieder halbieren, und wieder: 60, 30, 15, 8, 4, 2, 1.

Zwei Regeln machen es zuverlässig: Leeren Sie zwischen zwei Tests jede Cache-Ebene, und halten Sie die Hälfte, die jQuery enthält, mit jQuery zusammen, sonst scheitert jeder Test aus dem falschen Grund.

Die üblichen Verdächtigen, Familie für Familie

Menüs, Akkordeons, Tabs. Nehmen Sie die Kette aus (jQuery plus das Theme-Skript) oder geben Sie dem Menü ein winziges eigenständiges Skript. Den Kompromiss erklärt der Leitfaden zum Burger-Menü, und warum sich das Menü manchmal eine Datei mit dem Rest des Themes teilt, der Leitfaden zu monolithischen Theme-Skripten.

Cookie-Banner und Consent-Tools. Verzögern Sie sie nicht. Das Banner muss sofort bedienbar sein, und die Einwilligung muss gespeichert sein, bevor ein Tag entscheidet, was geladen wird. Diese Skripte sind klein, sie auszunehmen kostet wenig. Nutzen Ihre Tags den Consent Mode, muss auch der Standardzustand gesetzt sein, bevor die Tags laufen. Speziell für Axeptio lesen Sie wie Axeptio schneller lädt.

Formulare und Captchas. Nehmen Sie die Kette des Formular-Plugins auf den Seiten mit Formular aus, nicht auf der ganzen Website. Ein Captcha, das erst lädt, wenn der Besucher zu tippen beginnt, ist ein guter Kompromiss.

Slider und alles im sichtbaren Bereich beim Laden. Ist es das Erste, was der Besucher sieht, führt das Verzögern zu einem leeren oder ungestylten Hero und oft zu einem schlechteren Largest Contentful Paint. Nichts, was beim Laden sichtbar ist, sollte verzögert werden, nur was weiter unten liegt.

Chat-Widgets und Pop-ups. Genau dafür ist die Verzögerung da. Lassen Sie sie verzögert. Muss der Launcher ohne Interaktion sichtbar sein, geben Sie diesem einen Skript einen kurzen Timer, statt es auszunehmen.

Analytics und Tags. Sie zu verzögern bringt bei einem gut konfigurierten Tag wenig und kostet Daten. Entscheiden Sie bewusst: Entweder lädt das Tag früh und jeder Besuch zählt, oder es wartet und Sie akzeptieren, nur die Besucher zu zählen, die interagieren.

Gezielte Ausnahme

Eine Kette, per URL identifiziert, auf den Templates, die sie nutzen. Der Rest der Seite bleibt verzögert und der Gewinn bleibt erhalten.

Breite Ausnahme

„jQuery überall ausnehmen“, ein allgemeines Stichwort oder ein Sicherheitsmodus, der alles früh lädt. Der Fehler ist weg, und der Großteil des Gewinns auch.

Nach der Korrektur: prüfen, was Sie nicht sehen

Testen Sie noch einmal mit Werbeblocker: Eine Korrektur, die nur in einem sauberen Browser funktioniert, bleibt für einen Teil Ihrer Besucher kaputt.
Vergleichen Sie eine Woche Sitzungen vor und nach dem Aktivieren der Verzögerung. Ein Rückgang ohne Traffic-Grund ist Fall 5.
Testen Sie nach jedem Theme- oder Plugin-Update erneut: Dateinamen ändern sich, und eine Ausnahme per URL kann aufhören zu greifen.
Und halten Sie die Reihenfolge ein, die eine Website sicher hält: zuerst die harmlosen Optimierungen, die riskanten einzeln, wie in unserer Methode für Optimierungen ohne Bruch.

Mit Mantys Core

Mantys Core kann Ihre gesamte Performance-Schicht übernehmen, Cache inklusive, oder neben Ihrem bestehenden Setup laufen. Seine JavaScript-Verzögerung ist um die oben beschriebenen Fehler herum gebaut:

Der Setup-Code gängiger Consent-Tools, der Tag Manager und das Analytics-Tag sind standardmäßig von der Verzögerung ausgenommen, sodass Einwilligungsstatus und Tags beim Laden starten. Lädt Ihr Banner eine eigene Datei über ein separates Skript, fügen Sie diese den Ausnahmen hinzu.
Verzögerte Skripte werden in der Reihenfolge der Seite wieder eingesetzt, sodass eine Bibliothek immer vor dem läuft, was von ihr abhängt.
Ein von einem Filter oder Proxy festgehaltenes Skript kann den Rest nicht einfrieren: Nach kurzer Wartezeit geht die Kette zum nächsten weiter.
Eine Interaktion, die kommt, während die Seite noch lädt, wartet auf die ganze Seite, sodass kein Skript weiter unten zurückbleibt.
Ausnahmen werden per URL-Fragment deklariert und können pro Template gesetzt werden: Das Slider-Skript ist nur auf der Startseite ausgenommen und bleibt überall sonst verzögert.
Unabhängige Drittanbieter können einen eigenen kurzen Timer statt einer vollständigen Ausnahme bekommen.

Sie entscheiden weiterhin, was auf jeder Seite zählt. Die Plattform sorgt dafür, dass eine Ausnahme eine Ausnahme bleibt.

Zusammenfassung

Eine JavaScript-Verzögerung führt jedes Skript später aus, in einer bereits geladenen Seite, und nur, wenn der Loader so weit kommt.
Fünf Fehlerarten, fünf Signaturen: ein Konsolenfehler, eine Funktion, die nie startet, ein zweites Tippen, ein Ausfall nur bei manchen Besuchern und weniger Sitzungen.
Bestätigen Sie mit abgeschalteter Verzögerung, dann finden Sie das Skript über die Konsole, die Event-Listener des Elements und eine Suche über alle Dateien.
Nehmen Sie die ganze Kette (Bibliothek, Inline-Konfiguration, Datei) per URL-Fragment aus, und nur dort, wo es nötig ist. Halbieren Sie, wenn Sie nicht weiterkommen.
Verzögern Sie nie das Consent-Tool oder etwas, das beim Laden sichtbar ist; lassen Sie Chat-Widgets und Pop-ups verzögert.

Kommentare

Hängen Sie an einem ähnlichen Problem? Beschreiben Sie Ihr Setup und was Sie beobachten. Wir lesen jeden Kommentar und antworten.

Noch keine Kommentare. Teilen Sie als Erste oder Erster Ihren Fall.