Eine überladene Baukasten-Seite lädt deshalb 40 oder mehr einzelne Skript-Dateien nach, weil jedes verwendete Widget – Slider, Pop-up, Icon-Satz, Animation, eingebettetes Video – sein eigenes, unabhängiges JavaScript-Paket mitbringt, statt sich eine gemeinsame Basis mit den anderen Elementen zu teilen. Jede dieser Dateien kostet eine eigene Serveranfrage und zusätzliche Zeit zum Herunterladen, Verarbeiten und Ausführen, bevor die Seite für Besucher tatsächlich nutzbar wird.
Wie aus einem einzigen Baukasten-Widget mehrere Skripte werden
Ein visueller Seiten-Baukasten ist so aufgebaut, dass jedes Element unabhängig von den anderen funktionieren muss – ein Bildkarussell lädt deshalb seine eigene Slider-Bibliothek, ein aufklappbares Pop-up sein eigenes Dialog-Skript, ein animiertes Icon-Set seine eigene Icon-Bibliothek, und ein eingebettetes Erklärvideo oft noch eine weitere, separate Player-Bibliothek. Ein Beispiel zur Einordnung: Eine einzelne Startseite mit Hero-Slider, Kundenstimmen-Karussell, einem Kontakt-Pop-up, animierten Symbolen für die Leistungsübersicht und einem eingebetteten Video kommt allein durch diese fünf Widgets leicht auf 15 bis 20 einzelne Skript-Dateien – addiert mit den Basis-Skripten des Baukastens selbst und einzelnen kleineren Helfer-Skripten pro Widget-Variante sind 40 Dateien auf einer einzigen Seite keine Seltenheit, sondern der Normalfall bei konsequenter Nutzung vorgefertigter Elemente.
Was das konkret kostet: Anfragen, Datenvolumen, Ladezeit
Laut der bereits an anderer Stelle zitierten Google-Studie zur mobilen Ladezeit lag die durchschnittliche mobile Seite bereits 2016 bei 214 einzelnen Serveranfragen und 1,49 MB Datenvolumen – auf einer stark mit Baukasten-Widgets beladenen Seite stammt ein erheblicher Teil dieser Anfragen allein aus den zusätzlichen Skript-Dateien der einzelnen Elemente. In unserer eigenen Stichprobe realer Handwerksbetrieb-Websites zeigte sich die Konsequenz direkt in der gemessenen Ladezeit: Zwei WordPress-Websites mit umfangreichem Seiten-Baukasten-Plugin erreichten 7,8 beziehungsweise 12,6 Sekunden Largest Contentful Paint, während eine schlanke, individuell entwickelte Website mit deutlich weniger Skripten bei 2,5 Sekunden blieb – dem von Google empfohlenen Zielwert. Wie diese und weitere Ursachen für einen zu langsamen LCP-Wert im Detail zusammenhängen, erklärt unser Ratgeber zu den häufigsten LCP-Ursachen.
Zur Einordnung, wie unterschiedlich sich dieselbe Grundfunktion technisch umsetzen lässt:
| Umsetzung | Typische Skript-Anzahl | Gemessener LCP in unserer Stichprobe |
|---|---|---|
| Schlankes, individuell entwickeltes Theme | 5-10 Dateien | 2,5 Sekunden |
| WordPress mit umfangreichem Seiten-Baukasten-Plugin | 30-40+ Dateien | 7,8-12,6 Sekunden |
Render-blockierendes JavaScript: Warum die reine Anzahl nicht das ganze Bild zeigt
Nicht jedes Skript kostet gleich viel Zeit – entscheidend ist zusätzlich, ob der Browser ein Skript herunterladen und ausführen muss, bevor er mit dem eigentlichen Seitenaufbau fortfahren kann. Laut der offiziellen Chrome-Dokumentation zur Lighthouse-Bewertung fließt genau dieser Effekt über die so genannte Total Blocking Time mit 30 Prozent Gewichtung in den bekannten 0-100-Score ein – mehr als jede andere Einzelmetrik, wie unser Ratgeber zu PageSpeed Insights im Detail beschreibt. Ein Beispiel zur Einordnung: Zwei Seiten laden dieselbe Gesamtzahl an Skript-Dateien, aber auf der einen blockieren mehrere davon den Hauptprozess des Browsers nacheinander, bevor überhaupt reagiert werden kann, während die andere dieselben Skripte verzögert und erst nach dem sichtbaren Seitenaufbau nachlädt – letztere wirkt für Besucher spürbar schneller, obwohl die reine Skriptzahl identisch ist.
Was sich dagegen tun lässt
Der wirksamste Hebel ist selten eine einzelne technische Einstellung, sondern die bewusste Reduktion der verwendeten Widgets selbst: Jedes zusätzliche Karussell, jede zusätzliche Animation und jedes zusätzliche Pop-up sollte gegen den tatsächlichen Nutzen abgewogen werden, statt standardmäßig aktiviert zu bleiben, nur weil der Baukasten es anbietet. Ein Beispiel zur Einordnung: Ein Betrieb entfernt ein rein dekoratives Kundenstimmen-Karussell von der Startseite und ersetzt es durch drei statisch nebeneinander angezeigte Bewertungen ohne eigene Skript-Bibliothek – allein dieser eine Schritt reduziert die Zahl nachgeladener Skripte spürbar, ohne dass für Besucher inhaltlich etwas verloren geht. Grundsätzlicher lässt sich das Problem nur lösen, indem von vornherein auf ein schlankes Theme ohne Page-Builder-Overhead gesetzt wird, statt es nachträglich zu entladen – die Abwägung zwischen einem visuellen Seiten-Baukasten und einer individuell entwickelten, schlanken Website zeigt unser Ratgeber zu Baukasten oder individueller Website. Bei Skripten, die tatsächlich gebraucht werden, aber nicht sofort beim Seitenaufbau relevant sind, etwa ein Kartenmodul weiter unten auf der Seite oder ein Chat-Widget in der Ecke, hilft zusätzlich ein verzögertes Nachladen erst nach dem sichtbaren Seitenaufbau – so blockiert das Skript nicht länger den für Besucher entscheidenden ersten Eindruck, bleibt aber vollständig nutzbar, sobald es tatsächlich gebraucht wird.
Interaktiv: Was zusätzliche Skripte ungefähr kosten
Stellen Sie die ungefähre Anzahl zusätzlicher Skript-Dateien auf Ihrer Seite ein:
Fazit: Jedes Widget hat einen Preis, der selten sichtbar ist
40 nachgeladene Skripte sind kein Zeichen eines technischen Defekts, sondern die logische Folge, wenn viele vorgefertigte Baukasten-Widgets gleichzeitig verwendet werden – jedes davon bringt seine eigene, unabhängige Skript-Datei mit. Die Kosten dafür zeigen sich selten im Baukasten selbst, sondern erst in der gemessenen Ladezeit und damit direkt in der Absprungrate lokaler Suchanfragen. Wer konsequent nur die Widgets nutzt, die tatsächlich gebraucht werden, oder von vornherein auf ein schlankes Theme setzt, vermeidet diesen versteckten Preis.