Nicht verwendetes JavaScript reduzieren

Wenn PageSpeed Insights oder Lighthouse „Nicht verwendetes JavaScript reduzieren" meldet (die genaue Formulierung kann je nach Lighthouse-Version abweichen), wurde Skript gefunden, das Ihre Seite lädt und verarbeitet, aber beim Laden nie ausführt. Der Browser zahlt trotzdem den vollen Preis: Er lädt die Datei über das Netzwerk, parst sie und hält sie im Speicher. Ungenutztes JavaScript zu entfernen ist einer der zuverlässigsten Wege, eine moderne Seite zu beschleunigen, weil JavaScript pro Byte die teuerste Ressource ist, die eine Seite ausliefern kann. Dieser Leitfaden erklärt, was die Warnung bedeutet und wie Sie sie beheben.

Was die Empfehlung bedeutet

Lighthouse lädt Ihre Seite in Chrome mit aktivierter Code-Abdeckung und zeichnet auf, welche Zeilen jeder Datei ausgeführt werden. Code, der ausgeliefert, aber beim Laden nicht ausgeführt wird, zählt als nicht verwendet, und die Prüfung meldet die geschätzte verschwendete Übertragungsgröße pro Datei. Die Meldung ist kein Fehlerbericht über kaputten Code. Sie bedeutet nur, dass diese Bytes für die gemessene Ansicht keine Arbeit geleistet haben.

In der Praxis stammt das ungenutzte JavaScript aus wenigen wiederkehrenden Quellen. Ein Bundle enthält oft Code für Seiten oder Komponenten, die diese Seite nie rendert. Eine ganze Bibliothek wird für eine einzige Hilfsfunktion eingebunden. Polyfills werden für Browser ausgeliefert, die niemand mehr unterstützt. Und Drittanbieter-Skripte wie Analyse, Chat oder A/B-Tests laden ihre volle Nutzlast, ob der Besucher sie auslöst oder nicht.

Warum es für Ladezeit und Core Web Vitals zählt

JavaScript ist besonders teuer, weil die Arbeit nicht beim Download endet. Jedes Kilobyte muss geparst und kompiliert werden, und die Ausführung konkurriert um den Haupt-Thread des Browsers. Solange der Haupt-Thread mit Skript beschäftigt ist, kann er nicht auf Tippen oder Klicks reagieren, und genau das messen Total Blocking Time und Interaction to Next Paint. Hängt Ihr Rendering von JavaScript ab, kann ungenutzter Code auch den Largest Contentful Paint nach hinten schieben. Am stärksten trifft es Mittelklasse-Smartphones. Weil die Core Web Vitals ein Ranking-Signal sind, verbessert weniger JavaScript zugleich die Nutzererfahrung und die Sichtbarkeit. Der Zusammenhang mit der Reaktionsschnelligkeit ist in der Seite zu Interaction to Next Paint vertieft.

Nicht verwendetes JavaScript entfernen

1. Zuerst finden mit dem Coverage-Werkzeug

Bevor Sie etwas ändern, messen Sie, wo die Verschwendung sitzt. DevTools öffnen, Strg+Umschalt+P (Cmd+Umschalt+P auf dem Mac) drücken, Show Coverage ausführen und die Seite neu laden. Das Coverage-Panel listet jede Datei mit einem rot-grünen Balken, rot ist der Anteil, der geladen, aber nie ausgeführt wurde. Das zeigt, welche Bundles zuerst anzugehen sind.

2. Code nach Route und Interaktion aufteilen

Code-Splitting zerlegt ein großes Bundle in kleinere Teile, die nur bei Bedarf laden. Code hinter einen dynamischen Import legen, damit der Browser ihn erst holt, wenn er gebraucht wird:

// lädt chart.js erst beim Klick
button.addEventListener('click', async () => {
  const { renderChart } = await import('./chart.js');
  renderChart(data);
});

In einem Framework auf Routenebene aufteilen, etwa mit dem verzögerten Laden von Komponenten. In React übernimmt das React.lazy zusammen mit Suspense, in Next.js next/dynamic, sodass der Code einer Route erst lädt, wenn sie aufgerufen wird.

3. Tree-Shaking aktivieren

Tree-Shaking lässt den Bundler toten Code entfernen, also Exporte, die Sie nie importieren. Es funktioniert nur mit ES-Modulen, deshalb die einzelne benötigte Funktion importieren statt einer ganzen Bibliothek:

// lädt die ganze Bibliothek
import _ from 'lodash';

// lädt nur die eine Funktion
import debounce from 'lodash/debounce';

Das Paket als frei von Seiteneffekten markieren, damit der Bundler ungenutzte Module sicher entfernt:

// package.json
{ "sideEffects": false }

4. Toten Code und ungenutzte Abhängigkeiten entfernen

Die Abhängigkeiten prüfen und Bibliotheken löschen, die nicht mehr referenziert werden. Ein schweres Paket für eine einzige Aufgabe durch wenige Zeilen nativen Code ersetzen und Polyfills für nicht mehr unterstützte Browser streichen. Kleinere Bundles sind der dauerhafteste Fix, weil sie die Kosten bei jedem künftigen Besuch senken.

5. Drittanbieter-Skripte verzögern

Ein Vendor-Skript lässt sich nicht umschreiben, aber Sie steuern, wann es lädt. Chat, Analyse und Marketing-Tags erst laden, wenn die Seite interaktiv ist, oder eine Fassade verwenden, die das echte Widget erst bei Interaktion einblendet. Jedes verzögerte Drittanbieter-Tag ist ungenutztes JavaScript, das aus dem kritischen Pfad verschwindet.

6. Den Rest minifizieren

Zuletzt sicherstellen, dass der Produktions-Build minifiziert. Das entfernt zwar keinen ungenutzten Code, verkleinert aber zusammen mit den Schritten oben die Bytes, die wirklich ausgeliefert werden müssen.

7. Nicht verwendetes JavaScript in WordPress reduzieren

In WordPress stammt der Großteil des ungenutzten JavaScripts von Plugins, die ihre Skripte auf jeder Seite laden. Plugins entfernen, die Sie nicht mehr nutzen, denn jedes kann sitewide Skript einbinden, und ein schlankes Theme wählen. Ein Caching-Plugin kann nicht kritische Skripte verzögern und ungenutzte Skripte pro Seite ausschließen. Nach jeder Änderung testen, weil zu aggressives Verzögern interaktive Elemente stören kann.

8. Rückfall verhindern

Bundles wachsen wieder, sobald niemand hinsieht. Sichern Sie den Gewinn mit einem Performance-Budget in der Build-Pipeline, sodass ein Pull Request, der das Bundle aufbläht, fehlschlägt, bevor er live geht. Lighthouse CI kann prüfen, dass die Kennzahl grün bleibt, und eine Größenprüfung deckelt jedes Bundle.

Den Fix prüfen

Neu bauen, dann Lighthouse oder PageSpeed Insights erneut ausführen und prüfen, ob die verschwendeten Bytes gesunken sind. Mit dem Coverage-Werkzeug bestätigen, dass der rote Anteil kleiner ist. Laborwerkzeuge reagieren sofort, die Felddaten im Chrome UX Report folgen über ein nachlaufendes 28-Tage-Fenster, reale Verbesserungen zeigen sich also nach und nach. Mehrere Seiten gemeinsam testen ergibt ein verlässlicheres Bild als eine einzelne URL, weil sich ungenutztes JavaScript je Vorlage unterscheidet.

Häufige Fragen

Was bedeutet „nicht verwendetes JavaScript reduzieren"?

Ihre Seite liefert Skript aus, das beim Laden geladen und geparst, aber nie ausgeführt wird. Der Browser zahlt trotzdem die vollen Netzwerk-, Parse- und Kompilierkosten, deshalb beschleunigt das Entfernen die Seite. Die Empfehlung heißt je nach Sprache auch „ungenutztes JavaScript".

Wie finde ich ungenutztes JavaScript auf meiner Seite?

Mit dem Coverage-Werkzeug der Chrome DevTools. Show Coverage über das Befehlsmenü ausführen, die Seite neu laden, und der rote Anteil jedes Datei-Balkens ist der ungenutzte Code.

Lighthouse meldet mein JavaScript als ungenutzt, es wird aber verwendet. Warum?

Die Prüfung misst nur die Ausführung während des ersten Ladens. Code, der nach einem Klick, auf einer anderen Route oder in einem verzögerten Drittanbieter-Skript läuft, wird als ungenutzt gemeldet, weil er während der Messung nicht lief. Das ist erwartbar und bedeutet nicht, dass der Code kaputt ist.

Wie reduziere ich ungenutztes JavaScript aus Drittanbieter-Skripten, die ich nicht kontrolliere?

Sie steuern den Zeitpunkt. Das Tag verzögern, bis die Seite interaktiv ist, es per Fassade erst bei Interaktion laden oder Tags entfernen, die ihren Aufwand nicht mehr rechtfertigen.

Wie reduziere ich ungenutztes JavaScript in WordPress ohne Programmierung?

Nicht genutzte Plugins entfernen, da jedes sitewide Skript einbinden kann, ein performance-orientiertes Theme wählen und mit einem seriösen Optimierungs-Plugin nicht kritische Skripte verzögern. Nach jeder Änderung testen, weil zu aggressives Verzögern interaktive Elemente stören kann.

Verbessert das Reduzieren von JavaScript die Core Web Vitals und das Ranking?

Ja. Weniger Skript bedeutet weniger Arbeit im Haupt-Thread, was Total Blocking Time und Interaction to Next Paint verbessert und den Largest Contentful Paint beschleunigen kann. Da die Core Web Vitals ein Ranking-Signal sind, nützt der Gewinn Nutzern und Sichtbarkeit zugleich.