Veraltetes JavaScript

Das Lighthouse-13-Insight Veraltetes JavaScript, englisch „Legacy JavaScript“, meldet Skripte mit Polyfills und Syntax-Umwandlungen für Funktionen, die jeder aktuelle Browser längst beherrscht. Ein Build für alte Browser schreibt Klassen, Pfeilfunktionen, Optional Chaining und async-Funktionen in längeren ES5-Code um und ergänzt Polyfills für Methoden wie Array.prototype.includes oder Object.fromEntries. Moderne Browser laden, parsen und führen all das aus, ohne es zu brauchen. Das Insight folgt auf die Prüfung „Verhindern, dass in modernen Browsern veraltetes JavaScript bereitgestellt wird“, die in der Standardkonfiguration von Lighthouse 13 nicht mehr enthalten ist (Lighthouse-Quellcode, core/config/default-config.js, Version 13.5, abgerufen am 18.10.2026). Das verwandte Insight Dupliziertes JavaScript ersetzt „In JavaScript-Bundles doppelt vorhandene Module entfernen“ und steht weiter unten, weil die Lösung an derselben Stelle liegt: in der Build-Konfiguration.

Aus den Messungen von PerfDelta: Eine Startseite überträgt im mobilen Labortest im Median 1,5 MB JavaScript, bei einem Gesamtgewicht von 4,3 MB (5.509 Startseiten). Veraltetes und doppeltes JavaScript erfasst PerfDelta nicht getrennt; beides steckt in dieser Menge. Mehr dazu im Datenblock unten.

Was das Insight prüft

Lighthouse durchsucht jedes Skript nach bekannten Mustern von Polyfills und Umwandlungen und gleicht sie mit Baseline ab, der Menge an Webfunktionen, die in den großen Browsern einheitlich funktionieren. Seit Lighthouse 12.5 dient Baseline als Maßstab statt der früheren Regel über ES-Module. Laut Chrome-Dokumentation schlägt das Insight an, wenn mehr als 5 KiB Polyfills oder Umwandlungen für Funktionen gefunden werden, die nach Baseline breit unterstützt sind (Chrome for Developers, Legacy JavaScript).

Die Tabelle in PageSpeed Insights zeigt je Skript die URL und die geschätzten verschwendeten Bytes. Darunter nennen Unterzeilen das gefundene Merkmal, etwa Array.prototype.at, Object.hasOwn oder eine Babel-Umwandlung wie @babel/plugin-transform-classes, mit der Stelle im Code. Liefert die Website Source Maps aus, zeigt die Stelle auf das ursprüngliche Modul. So erkennen Sie schnell, ob der Code von Ihnen oder aus einer Abhängigkeit stammt.

Im Pagespeed-Score hat das Insight kein Gewicht. Die gefundenen Bytes erhöhen aber das Seitengewicht und die Zeit für Parsen und Ausführen, die als Total Blocking Time und in der JavaScript-Ausführungszeit sichtbar wird.

Veraltetes JavaScript beheben

Ein modernes Browserziel festlegen

Die meisten Build-Werkzeuge lesen ihr Ziel aus Browserslist. Ein Ziel, das den tatsächlich genutzten Browsern entspricht, entfernt die meisten Umwandlungen in einem Schritt. Browserslist versteht Baseline-Abfragen direkt:

// package.json
{
  "browserslist": ["baseline widely available"]
}

// oder ausführlicher
{
  "browserslist": ["> 0.5%", "last 2 versions", "not dead", "not op_mini all"]
}

Prüfen Sie vorher Ihre Webanalyse. Nutzt ein relevanter Teil der Besucher alte Browser, hat die Umwandlung ihren Grund.

Polyfills nach Bedarf statt pauschal

Mit Babel ergänzt @babel/preset-env zusammen mit core-js nur die Polyfills, die die Zielbrowser brauchen, und nur für Funktionen, die der Code tatsächlich verwendet:

// babel.config.json
{
  "presets": [["@babel/preset-env", {
    "useBuiltIns": "usage",
    "corejs": "3.38",
    "bugfixes": true
  }]]
}

Entfernen Sie globale Importe wie import 'core-js/stable' oder import '@babel/polyfill' aus der Einstiegsdatei. Sie laden jeden Polyfill unabhängig vom Ziel.

Ausgabeziel in TypeScript, esbuild und Vite

// tsconfig.json
{ "compilerOptions": { "target": "ES2020" } }

// vite.config.js
export default { build: { target: 'es2020' } };

// esbuild
esbuild app.ts --bundle --target=es2020 --outfile=app.js

Ein altes tsconfig.json mit dem Ziel ES5 ist eine der häufigsten Ursachen. Ein höheres Ziel entfernt die umgeschriebenen Klassen und async-Funktionen, ohne dass sich der Quellcode ändert.

Abhängigkeiten mit vorkompiliertem ES5

Zeigen die Unterzeilen in node_modules, wird das Paket selbst als umgewandelter Code veröffentlicht. Suchen Sie nach einem modernen Build desselben Pakets (ein Eintrag exports oder module, oder ein Paket mit der Endung -es), wechseln Sie auf eine neuere Version mit moderner Syntax oder ersetzen Sie eine Hilfsbibliothek durch die native Methode.

Plattformen und Drittanbieter

In WordPress stammt veraltetes JavaScript oft aus älteren Plugins und Themes, die eigene Polyfills mitbringen. Meist hilft nur ein Update oder ein schlankeres Plugin. In Shopify lohnt der Blick auf die Skripte der Apps. Stammt das Skript von einem Drittanbieter, liegt die Lösung beim Anbieter; wie Sie solche Skripte später laden, erklärt der Ratgeber Drittanbieter-Code.

Dupliziertes JavaScript: ein Modul, zweimal ausgeliefert

Das Insight Dupliziertes JavaScript findet Module, die in den Skripten einer Seite mehrfach vorkommen: zwei Versionen von lodash, eine Datumsbibliothek in zwei Chunks oder eine Framework-Laufzeit im Haupt-Bundle und noch einmal in einem Widget. Die Tabelle zeigt das Quellmodul und die doppelten Bytes je Skript. Lighthouse erkennt Module über Source Maps; ohne sie sieht das Insight nur einen Teil der Dopplungen.

So finden Sie die Dopplungen im Abhängigkeitsbaum und im fertigen Bundle:

# Welche Versionen eines Pakets sind installiert?
npm ls lodash
pnpm why lodash

# Verträgliche Versionen zusammenführen
npm dedupe

# Das gebaute Bundle untersuchen
npx source-map-explorer dist/assets/*.js
npx webpack-bundle-analyzer dist/stats.json

• Versionen angleichen. Legen Sie eine Version für alle abhängigen Pakete fest, mit overrides (npm), resolutions (Yarn) oder pnpm.overrides.
• Zwei Varianten derselben Bibliothek vermeiden. lodash und lodash-es landen als getrennte Module im Bundle.
• Gemeinsame Chunks bilden. In webpack verschiebt optimization.splitChunks Module, die mehrere Einstiegspunkte nutzen, in einen gemeinsamen Chunk, statt sie in jeden zu kopieren.
• Getrennte Builds auf einer Seite. Zwei unabhängig gebaute Anwendungen auf einer Seite, etwa Shop und Konfigurator, bringen je eine eigene Laufzeit mit. Module Federation oder ein gemeinsamer Build entfernt die zweite Kopie.

Ergebnis prüfen

1. Neu bauen und PageSpeed Insights erneut ausführen. Skripte unter der Schwelle verschwinden aus der Tabelle, die doppelten Bytes sinken.
2. Übertragene JavaScript-Menge und Hauptthread-Zeit im Netzwerk- und Performance-Panel der DevTools vorher und nachher vergleichen.
3. Die Website im ältesten noch unterstützten Browser testen, damit das neue Ziel nichts beschädigt.

Der kostenlose Website Speed Test von PerfDelta zeigt das JavaScript-Gewicht und die größten Skripte für mehrere Seiten Ihrer Website und im Vergleich mit Wettbewerbern. So sehen Sie, ob eine Build-Änderung auf der ganzen Website wirkt. Für Code, der ausgeliefert, aber nie ausgeführt wird, gilt der Ratgeber Nicht verwendetes JavaScript entfernen.

Häufige Fragen

Kann ich alle Polyfills weglassen?

Nur für Funktionen, die alle Browser Ihrer Besucher unterstützen. Baseline „widely available“ umfasst Funktionen, die seit mindestens 30 Monaten einheitlich funktionieren. Prüfen Sie Ihre Webanalyse, bevor Sie weitergehen.

Warum meldet das Insight Code, den ich nicht geschrieben habe?

Abhängigkeiten und Skripte von Drittanbietern gehören zur Seite. Die Stelle in der Unterzeile zeigt, aus welchem Paket oder welcher Datei der Polyfill stammt.

Verbessert die Korrektur den Score?

Indirekt. Weniger Code bedeutet weniger Zeit für Parsen und Ausführen, das senkt die Total Blocking Time. Kleinere Übertragungen helfen dem LCP, wenn Skripte mit der LCP-Ressource um Bandbreite konkurrieren.

Warum zeigt „Dupliziertes JavaScript“ bei mir nichts an?

Entweder gibt es keine großen Dopplungen, oder die Skripte haben keine erreichbaren Source Maps. Ohne sie kann Lighthouse nicht erkennen, welche Module ein Bundle enthält.