JavaScript reduzieren: Blockierendes JS für besseren PageSpeed entfernen
JavaScript ist für die Interaktivität moderner Webseiten unverzichtbar. Allerdings ist JavaScript auch die „teuerste“ Ressource im Web. Im Gegensatz zu Bildern, die lediglich gerendert werden müssen, blockiert JavaScript während des Ladens, Parsens und Ausführens den Haupt-Thread des Browsers. Eine konsequente JavaScript-Reduzierung ist daher eine der wichtigsten Massnahmen zur Optimierung des PageSpeeds (insbesondere der Metrik INP).
Die Kosten von JavaScript (The JavaScript Tax)
Viele Entwickler glauben, eine 100 KB JavaScript-Datei sei genauso unbedenklich wie ein 100 KB Bild. Auf mobilen Endgeräten führt dies jedoch zu Problemen:
- Download: Die Datei muss übertragen werden.
- Parsing & Compilation: Der Browser-Kompilierer (z. B. V8 in Chrome) muss den Code einlesen und in Maschinencode übersetzen. Dies kann auf älteren Smartphones mehrere Sekunden dauern.
- Execution: Das Skript wird ausgeführt. Solange dies geschieht, reagiert die Seite nicht auf Klicks (hoher INP).
Die eigentliche Belastung liegt also nicht im Download, sondern in Parsing und Ausführung auf dem Haupt-Thread. Genau dieser Haupt-Thread bestimmt auch die INP-Werte und damit die gefühlte Reaktionsfähigkeit der Seite.
| Ressource (100 KB) | Download | Parsing/Compile | Ausführung | Haupt-Thread blockiert |
|---|---|---|---|---|
| Bild (JPEG/WebP) | ja | gering (Decode) | nein | nein |
| JavaScript | ja | hoch | ja | ja |
Ein 100-KB-Bild kostet den Browser also fast nichts ausser dem Download – 100 KB JavaScript hingegen blockieren die Seite über mehrere Phasen hinweg.
Best Practices zur Optimierung
1. Script-Loading anpassen (Async & Defer)
Binden Sie Skripte niemals klassisch im <head> ein, da sie das HTML-Parsing blockieren. Nutzen Sie stattdessen:
defer(Empfohlen für Haupt-Skripte):<script src="app.js" defer></script>Das Skript wird asynchron geladen und erst ausgeführt, wenn das Dokument komplett aufgebaut ist.async(Für Drittanbieter-Skripte, z. B. Analytics):<script src="analytics.js" async></script>Das Skript wird unabhängig geladen und sofort ausgeführt. Es eignet sich nur für Skripte, die das DOM nicht manipulieren müssen.
2. Minifizierung und Komprimierung
- Entfernen Sie Leerzeichen, Kommentare und ungenutzten Code (Minification) während des Build-Prozesses.
- Komprimieren Sie JS-Dateien auf Netzwerkebene mit Brotli oder Gzip. Wie diese Komprimierung über den Header Accept-Encoding ausgehandelt wird, beschreibt der zugehörige Beitrag.
3. Tree Shaking & Code Splitting
- Tree Shaking: Verwenden Sie moderne Bundler (wie Vite oder Rollup), die ungenutzten Code aus importierten Bibliotheken (z. B. ungenutzte Funktionen aus Lodash) automatisch entfernen.
- Code Splitting (Dynamic Imports): Laden Sie JavaScript-Module erst dann nach, wenn sie wirklich benötigt werden (z. B. das Skript für ein komplexes Kontaktformular erst dann laden, wenn der Nutzer auf „Kontakt“ klickt).
4. Zero-JS-Konzepte als Standard (Astro-Philosophie)
Der effektivste Weg, JavaScript zu reduzieren, ist, es gar nicht erst an den Browser zu senden.
- Das von uns genutzte Framework Astro 6 liefert standardmässig 0 KB JavaScript an den Client aus (static HTML).
- Dynamische Komponenten (Svelte 5) werden nur dort als interaktive Inseln geladen, wo sie wirklich benötigt werden (z. B. bei der Glossarsuche via
client:visible).
Die wichtigsten Massnahmen nach Wirkung geordnet
Nicht jede Optimierung lohnt sich gleichermassen. Die folgende Tabelle priorisiert die typischen Hebel:
| Massnahme | Aufwand | Wirkung auf INP/Ladezeit |
|---|---|---|
defer statt blockierendem <head>-Script | gering | hoch |
| Minifizierung + Brotli | gering | mittel |
| Drittanbieter-Skripte verzögern/entfernen | mittel | sehr hoch |
| Tree Shaking / unused Code entfernen | mittel | mittel |
| Code Splitting (Dynamic Imports) | hoch | hoch |
| Zero-JS-Architektur (Astro) | hoch (Migration) | sehr hoch |
Vorher/Nachher: Eine überladene Landingpage entschlacken
Eine Marketing-Seite lädt eine grosse jQuery-Bibliothek, ein Karussell-Plugin und drei Tracking-Skripte synchron im <head>.
- Vorher: 480 KB JavaScript blockierend, Total Blocking Time 720 ms, INP über 400 ms (schlecht).
- Nachher: jQuery durch wenige Zeilen Vanilla-JS ersetzt, Karussell per
client:visiblenachgeladen, Tracking nach der ersten Nutzerinteraktion gestartet – 95 KB JavaScript, Total Blocking Time 90 ms, INP unter 150 ms (gut).
Die Seite ist visuell identisch, reagiert aber spürbar schneller auf Eingaben. Solche Verbesserungen schlagen direkt auf die Core Web Vitals durch und lassen sich anschliessend mit einem Tool nachmessen.
[!TIP] Die Reduzierung blockierender Skripte verbessert die Reaktionsfähigkeit (INP) Ihrer Website spürbar. Messen Sie die JavaScript-Ausführungszeiten Ihrer Seite mit dem PageSpeed Check auf balou.tools.
Häufig gestellte Fragen (FAQ)
Was ist der Unterschied zwischen „async“ und „defer“?
Beide laden Skripte im Hintergrund herunter. `async` führt das Skript sofort nach dem Download aus und blockiert dabei das HTML-Parsing. `defer` wartet mit der Ausführung, bis das HTML vollständig eingelesen ist, und erhält die Reihenfolge der Skripte aufrecht.
Warum belastet JavaScript mobile Geräte stärker als Bilder?
Ein Bild muss vom Browser nur decodiert und gezeichnet werden. JavaScript-Dateien müssen geladen, geparst, in Maschinencode kompiliert und auf der CPU ausgeführt werden. Dies belastet schwächere Mobilgeräte-CPUs stark und führt zu Blockierungen (hoher INP).
Was bedeutet „unused JavaScript“ im Lighthouse-Report?
Lighthouse markiert JavaScript-Code, der beim initialen Laden übertragen, aber nicht ausgeführt wird – etwa Funktionen einer Bibliothek, die auf der aktuellen Seite gar nicht zum Einsatz kommen. Solcher Code lässt sich durch Tree Shaking entfernen oder per Code Splitting erst bei Bedarf nachladen, was Download- und Parse-Zeit spart.
Sind Drittanbieter-Skripte wie Analytics oder Chat-Widgets ein Performance-Problem?
Ja, häufig sogar das grösste. Drittanbieter-Skripte werden von fremden Servern geladen, sind nicht minifiziert kontrollierbar und blockieren teils den Haupt-Thread. Laden Sie sie mit `async`, verzögert nach der Nutzerinteraktion oder über einen Tag-Manager, und prüfen Sie regelmässig, ob jedes Skript noch benötigt wird.