Funktioniert das JavaScript deiner Seite eigentlich?

Worum es geht

Auf einer WordPress-Seite laufen schnell ein Dutzend JavaScript-Bibliotheken: eine für den Slider, eine für das Lightbox-Fenster, eine für die Animationen beim Scrollen, eine für das Formular. Jede kommt von einem anderen Plugin, und keines weiß von den anderen.

Die interessante Frage ist nicht, ob sie geladen werden. Sondern ob sie tatsächlich arbeiten. Geladen ist nicht gleich funktionierend.

Dazu kommt eine zweite, ruhigere Frage: Aus wie vielen Elementen ist die Seite überhaupt gebaut, und wie tief sind sie ineinander verschachtelt?

Warum das zählt

Es gibt eine Klasse von Fehlern, die kaputt sind, ohne dass es jemandem auffällt. Ein Skript startet, bevor die Bibliothek existiert, von der es abhängt — dann läuft es ins Leere. Eine .js-Adresse liefert statt der Datei eine HTML-Fehlerseite zurück, was der Browser stillschweigend hinnimmt. Ein Slider ist im HTML vollständig vorbereitet, aber die Bibliothek, die ihn in Bewegung setzen müsste, wurde nie gestartet — dann stehen alle Folien untereinander oder gar nicht da.

Solche Fehler bemerkt man selten selbst, weil man die Seite meistens nur an einer Stelle anschaut und weil der eigene Browser die Dateien im Zwischenspeicher hat.

Der zweite Grund, warum das zählt, hängt an der Sichtbarkeit: KI-Systeme führen kein JavaScript aus. Retriever verarbeiten, was sie einlesen — nicht, was nach einer Interaktion erscheint. Ein Text, der erst nach dem Klick auf einen Reiter geladen wird, existiert für sie nicht.

Bei der Seitenkomplexität möchte ich ausdrücklich zurückhaltend sein, weil sie regelmäßig überinterpretiert wird. Weniger Elemente machen eine Seite nicht schneller. Die beiden Werte bewegen sich bei einem Neuaufbau oft gemeinsam, aber nur weil beide aus derselben Aufräumarbeit kommen. Ein Zusammenhang zwischen Elementzahl und Ladezeit lässt sich daraus nicht ableiten.

Es gibt auch keine belastbare allgemeine Zahl für „zu viele Elemente" oder „zu tief verschachtelt". Wenn ein Bericht Schwellenwerte nennt, sind es Googles eigene Warnpunkte — Hinweise, keine Vorschriften. Was solche Zahlen wirklich taugen, zeigt sich erst beim zweiten Mal: Eine Messung allein ergibt drei langweilige Zahlen. Zwei Messungen vor und nach einem Umbau ergeben ein Vorher und Nachher, das ein Kunde ohne Vokabelheft versteht.

Eine Sache noch, die bei der Bewertung wichtig ist: Ein Optimierungs-Plugin, das Skripte bis zur ersten Interaktion zurückhält, sieht bei einem reinen Seitenaufruf genauso aus wie ein kaputtes Skript. Das ist ein Fall für einen Menschen, nicht für ein Urteil.

Wie du das selbst prüfst

Öffne deine Seite in einem privaten Fenster und dann die Entwicklertools (F12), Reiter „Konsole". Lade neu.

Rote Zeilen sind Fehler. Die häufigsten Formulierungen: ... is not defined heißt, ein Skript hat etwas benutzt, das noch nicht da war. Uncaught SyntaxError bei einer .js-Datei heißt oft, dass die Datei gar keine JavaScript-Datei ist, sondern eine Fehlerseite. 404 in Kombination mit einer .js-Adresse heißt, die Datei fehlt.

Ein Hinweis dazu: Nicht jede rote Zeile gehört dir. Browser-Erweiterungen und Antivirensoftware schreiben ebenfalls in die Konsole. Prüfe im Zweifel in einem Browser ohne Erweiterungen.

Danach der praktische Teil: Klick die Seite einmal komplett durch. Slider, Akkordeons, Reiter, Lightbox, das Menü auf dem Handy, das Formular. Das dauert fünf Minuten und findet mehr als jedes Werkzeug.

Und für die Sichtbarkeitsfrage: JavaScript im Browser abschalten und neu laden. Was dann noch dasteht, ist das, was Suchmaschinen und KI-Systeme sicher bekommen.

Was zu tun ist, wenn es fehlt

Bei Konsolenfehlern ist die erste Frage immer: Welches Plugin gehört dazu? Der Dateipfad in der Fehlermeldung verrät es meistens. Häufig ist die Ursache banal — ein Plugin, das nicht mehr gepflegt wird, oder zwei Plugins, die dieselbe Bibliothek in unterschiedlichen Versionen mitbringen.

Wenn ein Optimierungs-Plugin im Spiel ist, schalte seine Zusammenfassung und Verzögerung von JavaScript testweise ab. Ein großer Teil der Skriptfehler auf WordPress-Seiten entsteht erst dort — durch das Zusammenlegen von Dateien, deren Reihenfolge dabei kippt.

Für die Sichtbarkeit gilt: Der Haupttext gehört ins ausgelieferte HTML. Wenn Inhalt in Reitern oder Akkordeons steckt, sollte er im HTML vorhanden und nur optisch eingeklappt sein — nicht per Skript nachgeladen.

Und zur Komplexität: Der Weg dahin führt nicht über eine Elementzahl, sondern über weniger Verschachtelung im Aufbau. Baukästen erzeugen für jede Zeile und jede Spalte zusätzliche Container. Ein Aufbau, der stattdessen mit modernem CSS-Layout arbeitet, kommt mit einem Bruchteil aus. Das ist eine Frage der Bauweise, kein nachträglicher Optimierungsschritt.

Quellen

• Skript läuft, bevor die Bibliothek existiert; .js-Adresse antwortet mit einer HTML-Fehlerseite; Elemente sind für eine Bibliothek vorbereitet, die nie gestartet wurde; geladen ist nicht funktionierend; Konsolenmeldungen von Antivirensoftware und Browser-Erweiterungen der prüfenden Maschine werden vor der Auswertung herausgefiltert; ein Optimierungs-Plugin, das Skripte bis zur ersten Interaktion zurückhält, ist von einem defekten Skript bei passivem Laden nicht unterscheidbar und wird als Prüffall für Menschen geführt; Elementzahl und Verschachtelungstiefe sind ein Komplexitätsmaß und kein Performancemaß, weil weniger Elemente eine Seite nicht schneller machen; es gibt keine belastbare allgemeine Zahl, die Schwellen sind Googles eigene Warnpunkte; der Wert entsteht beim zweiten Durchlauf als Vorher-Nachher-Vergleich -- @ctx:projects-tools-checky-workbench-docs-tech-specs-probe-catalog-experience@7
• RAG-Retriever verarbeiten, was sie parsen, nicht was nach einer Interaktion rendert; eine Hauptantwort hinter einem JavaScript-Reiter oder Akkordeon fehlt im First-Paint-HTML und damit für Retriever; Etch FSE liefert statisches HTML server-seitig aus -- @ctx:atlas-seo-practice-2026@3
• Risiko clientseitigen Renderings, weil Google die JavaScript-Verarbeitung häufig verzögert; server-seitiges Rendering oder Pre-Rendering bevorzugen; Rendering über die URL-Prüfung der Search Console testen; ungenutztes JavaScript und CSS über die Code-Coverage der Entwicklertools ermitteln -- @ctx:atlas-seo-technical-audit@1
• KI-Crawler führen kein JavaScript aus, weshalb eine Seite mit skriptabhängigem Inhalt für sie nahezu leer ist -- @ctx:atlas-seo-geo-scoring@1
• Keine überflüssigen JavaScript-Bibliotheken; sauberes semantisches HTML -- @ctx:projects-websites-dhs-cpt-checklisten-technisches-seo-content@2