Verwendet noch jemand Polyfills im Jahr 2026?

Ja — aber fast keiner der Polyfills, die Ihr Bundler geerbt hat. Die pauschale Polyfill-Standardkonfiguration, die 2019 noch sinnvoll war — @babel/preset-env mit useBuiltIns: 'entry' gegen ein breites Browserslist-Target — schickt heute der überwältigenden Mehrheit der Nutzer toten Ballast, um einen Browsermarktanteil zu unterstützen, der gegen null geht. Ein Polyfill ist im Jahr 2026 nach wie vor das richtige Werkzeug für eine kurze, namentlich definierte Liste von Funktionen, die tatsächlich nicht unterstützt werden — und eine Haftung für alles andere.

Dieser Artikel beantwortet eine einzige Frage: ob die Polyfills in Ihrer aktuellen Build-Pipeline ihre Bytes noch rechtfertigen. Er benennt, welche APIs toter Ballast sind, welche legitim noch einen Polyfill benötigen, was der polyfill.io-Supply-Chain-Vorfall daran geändert hat, wie Sie diese laden, und die genauen Befehle, um zu prüfen, was Sie tatsächlich ausliefern.

Die native Support-Baseline 2026: Was Sie nicht mehr polyfillen müssen

Die meisten JavaScript-Funktionen, die Build-Konfigurationen noch routinemäßig polyfillen, werden jetzt von jedem Evergreen-Browser unterstützt — das bedeutet, dass das Polyfilling dieser Funktionen Bytes ausliefert, die fast kein echter Nutzer benötigt. Die Funktionen, die Polyfill-Tutorials ein Jahrzehnt lang geprägt haben — Math.trunc, Array.prototype.flat, Optional Chaining — werden jetzt weitgehend unterstützt und sind genau der tote Ballast, den ein Audit 2026 entfernen sollte.

Das genredefinierende Lehrbeispiel, javascript.infos Math.trunc-Polyfill, ist die deutlichste Illustration. Math.trunc hat seit 2015 universelle Browserunterstützung — laut MDNs Kompatibilitätsdaten wurde es in Chrome 38, Firefox 25 und Safari 8 eingeführt. Einen Math.trunc-Polyfill im Jahr 2026 zu schreiben oder zu bündeln bedeutet, eine Absicherung für einen Browser auszuliefern, den niemand mehr verwendet.

Dasselbe gilt für die gesamte API-Oberfläche, auf die veraltete Konfigurationen noch abzielen. Die Support-Prozentsätze unten stammen aus den globalen Nutzungsdaten von caniuse.com (StatCounter, Mai 2026); „globale Unterstützung” bezieht sich auf den gewichteten Browsermarktanteil von caniuse über alle erfassten Versionen.

Funktion	Globale Unterstützung (caniuse, 2026)	Noch sinnvoll zu polyfillen?
Array.prototype.flat	94,11 %	Nein
Object.entries	95,06 %	Nein
Promise.allSettled	94,04 %	Nein
structuredClone	93,84 %	Nein
Optional Chaining (?.)	93,99 %	Nein (Syntax — transpilieren, nicht polyfillen)
Nullish Coalescing (??)	93,99 %	Nein (Syntax — transpilieren, nicht polyfillen)
fetch	96,3 %	Nein
Temporal	65,16 %	Ja — übergangsweise
Decorators	0 % nativ	Ja

Array.flat, Object.entries, Promise.allSettled, structuredClone, Optional Chaining, Nullish Coalescing und fetch liegen alle bei etwa 94–96 % globaler Unterstützung — und wenn Ihre Babel-Konfiguration diese noch polyfillet, liefern Sie Bytes aus, die fast keinem Nutzer nützen.

Syntax vs. Funktionen: Optional Chaining und Nullish Coalescing sind Syntax, keine fehlenden Funktionen, daher werden sie von einem Transpiler und nicht von einem Polyfill behandelt. Wie javascript.info es formuliert: Verwenden Sie einen Transpiler für moderne Syntax oder Operatoren und Polyfills für fehlende Funktionen. Die Unterscheidung ist beim Audit wichtig — ein ??-„Polyfill” in Ihrer Konfiguration ist ein Zeichen dafür, dass die Konfiguration beides vermischt.

Welche Polyfills rechtfertigen ihren Platz im Jahr 2026 noch?

Polyfills bleiben das richtige Werkzeug für eine kleine, namentlich definierte Gruppe von Fällen: Funktionen ohne native Unterstützung irgendwo, Funktionen im Übergang zwischen Browsern und gesperrte Browser-Umgebungen, in denen die Evergreen-Annahme nicht gilt. Das sind die Ausnahmen, die es rechtfertigen, überhaupt einen Polyfill-Mechanismus in Ihrer Pipeline zu behalten.

Decorators. Der TC39-Decorators-Vorschlag befindet sich in Stage 3 ohne native Browser-Implementierung. Wenn Sie Decorators verwenden — direkt oder über ein Framework wie Angular oder eine Bibliothek, die davon abhängt — verlassen Sie sich auf einen Transpiler plus in einigen Fällen auf Runtime-Hilfsfunktionen. Es gibt hier noch keine Option „auf nativ warten”; die Funktion wird nicht in Browsern ausgeliefert.

Temporal, während seines browserübergreifenden Übergangs. Temporal ist ein abgeschlossener TC39-Vorschlag — er erscheint auf der TC39-Liste der abgeschlossenen Vorschläge — und hat begonnen, nativ ausgeliefert zu werden. Laut MDNs Temporal-Kompatibilitätsdaten ist es in Firefox 139+, Chrome 144+, Edge 144+ und Node.js 26+ verfügbar, während Safari noch keine aktivierte Unterstützung bietet. Diese ungleichmäßige Einführung macht einen Temporal-Polyfill zu einer vorübergehenden Notwendigkeit und nicht zu einer dauerhaften. Das proposal-temporal-Repository von TC39 listet @js-temporal/polyfill als Alpha-Release-Option neben Alternativen auf — es ist nicht die einzige kanonische Wahl.

Enterprise- und gesperrte Browser-Umgebungen. Regulierte Finanzsysteme, Behörden-Intranets und Kiosk- oder POS-Geräte fixieren manchmal eine Browser-Version für Jahre. Wenn Ihre echte Nutzerbasis Browser enthält, die nicht aktualisiert werden können, ist Ihr Browserslist-Target breiter als der Evergreen-Standard und einige Polyfills sind tragende Elemente. Das Schlüsselwort ist echt — dieser Fall wird weit häufiger behauptet als gemessen. Validieren Sie ihn anhand von Analytics, bevor Sie Polyfills seinetwegen behalten.

Eingeschränkt verfügbare CSS-Funktionen hinter JS-Polyfills. Einige CSS-Funktionen, wie Container Queries auf älterem Safari, wurden während ihrer Einführung mit JavaScript polyfillet. Wie web.dev anmerkt, verwendet der Container-Queries-Polyfill ResizeObserver und MutationObserver, um natives Verhalten nachzuahmen — und seine README markiert ihn als nicht mehr gepflegt. Diese Polyfills tragen Verhaltensvorbehalte, die unten behandelt werden.

Der informelle Konsens aus dem breiteren Kommentar — „Verwenden Sie gezielte Polyfills, treffen Sie Entscheidungen auf Basis von Daten” — ist nicht falsch, unterschätzt aber, wie viel sich geändert hat: Für die meisten Apps im Jahr 2026 ist „Polyfills spielen weiterhin eine wichtige Rolle” nicht mehr zutreffend. Die Rolle ist jetzt eng und klar definiert.

Der polyfill.io-Vorfall hat das Remote-Polyfill-Service-Muster beendet

Das Remote-Polyfill-Service-Muster — das Laden eines <script>-Tags von einem Drittanbieter-CDN, das browserspezifische Polyfills zurückgibt — ist nach dem polyfill.io-Supply-Chain-Angriff 2024 keine vertretbare Architektur mehr. Der Vorfall zwang Teams dazu, zu prüfen, was sie von Drittanbietern luden, und die meisten stellten fest, dass sie den Großteil davon nicht benötigten.

Die Chronologie:

• Anfang 2024 — Eigentümerwechsel. Die polyfill.io-Domain wechselte den Besitzer. Fastlys Community-Beitrag dokumentiert den Wechsel und Fastlys Reaktion für betroffene Nutzer.
• 25. Juni 2024 — Malware-Bericht. Das Sicherheitsunternehmen Sansec berichtete, dass der polyfill.io-Dienst Malware in das Skript injizierte, das er an Endnutzer auslieferte.
• Juni 2024 — Mirror- und Gegenmaßnahmen. Cloudflare kündigte an, polyfill.io-Links automatisch durch seinen eigenen Mirror zu ersetzen, und Fastly bot einen Ersatz-Endpunkt an.

Die Mirrors halten bestehende Sites am Laufen, rehabilitieren aber das Muster nicht. Ein typischer Produktionsfehler, den dies aufdeckte: Teams hatten ein cdn.polyfill.io-Script-Tag, das Bündel von Polyfills lud, die sie seit Jahren nicht mehr benötigten, und führten bei jedem Seitenaufruf JavaScript von Drittanbietern aus, um Browser zu unterstützen, die sich seitdem aktualisiert hatten. Behandeln Sie den Cloudflare- oder Fastly-Mirror nicht als „sicheren” Drop-in-Ersatz — behandeln Sie den Vorfall als Anlass, das Script-Tag vollständig zu entfernen und alle tatsächlich benötigten Polyfills in Ihr eigenes Bundle zu verschieben, wo Sie diese kontrollieren und überprüfen können.

Wie Sie prüfen, was Ihr Bundler tatsächlich ausliefert

Das Prüfen Ihres Polyfill-Footprints ist eine vierstufige Abfolge: Lesen Sie Ihr echtes Browserslist-Target, untersuchen Sie das Bundle auf core-js-Gewicht, korrigieren Sie die Babel-Konfiguration und validieren Sie gegen echte Nutzerdaten. Nichts davon erfordert Raten — jeder Schritt ist ein Befehl oder ein Konfigurations-Diff, den Sie heute ausführen können.

Schritt 1: Sehen Sie Ihre echte Zielliste

Browserslist-Abfragen entscheiden, welche Browser Ihre Konfiguration unterstützt, und der einzige zuverlässige Weg zu wissen, was Ihre auflöst, ist, direkt nachzufragen:

npx browserslist

Dies gibt die konkrete Browser-Versionsliste aus, auf die Ihre aktuelle Konfiguration abzielt. Die Browserslist-Standardwerte (> 0.5%, last 2 versions, Firefox ESR, not dead) schließen IE11 bereits über not dead aus. Das eigentliche Risiko ist eine geerbte benutzerdefinierte Abfrage — ein verstreutes > 0.2% oder eine jahrelang alte explizite Versionsuntergrenze — die still alte Targets einbezieht. Führen Sie den Befehl aus; wenn die Ausgabe Browser enthält, die kein echter Nutzer verwendet, ist das Ihr toter Ballast.

Schritt 2: Finden Sie das core-js-Gewicht in Ihrem Bundle

core-js ist die Polyfill-Bibliothek, aus der @babel/preset-env injiziert, und sie kann einen erheblichen Anteil eines Bundles ausmachen, das sie nicht benötigt. Untersuchen Sie einen Produktions-Build:

npx source-map-explorer dist/assets/*.js

source-map-explorer rendert eine Treemap dessen, was in jedem Bundle aus seinen Source Maps enthalten ist. Suchen Sie nach core-js-Modulen — es.array.flat, es.object.entries, es.promise.all-settled. Jedes davon entspricht einer Funktion in der obigen Tabelle mit totem Ballast. (Für Webpack-Projekte bietet webpack-bundle-analyzer dieselbe Ansicht.)

Schritt 3: Korrigieren Sie die Babel-Konfiguration

Die kanonische Konfiguration, die die meisten Teams geerbt haben, ist unvollständig. Ein häufiges Muster sieht so aus:

{
  "presets": [
    ["@babel/preset-env", {
      "useBuiltIns": "usage",
      "corejs": 3
    }]
  ]
}

Die obige Konfiguration hat zwei Probleme. Erstens gibt es kein targets-Feld, sodass die Konfiguration auf Ihre Browserslist-Datei zurückfällt — die möglicherweise die veraltete benutzerdefinierte Abfrage aus Schritt 1 ist. Zweitens ist corejs: 3 nicht fixiert; laut der core-js-Dokumentation sollte die Version eine Minor-Version angeben, damit preset-env Polyfills injiziert, die dem installierten Release entsprechen. Eine für 2026 geeignete Version:

{
  "presets": [
    ["@babel/preset-env", {
      "targets": "> 1%, last 2 versions, not dead",
      "useBuiltIns": "usage",
      "corejs": "3.40"
    }]
  ]
}

Fixieren Sie corejs auf die tatsächlich installierte Minor-Version anstatt eine beliebige Zahl zu kopieren — preset-env verwendet sie, um zu entscheiden, welche Polyfills injiziert werden sollen.

Der useBuiltIns-Wert ist die folgenreichste Einstellung. Laut der @babel/preset-env-Dokumentation:

• 'entry' ersetzt ein einzelnes import 'core-js' durch den vollständigen Satz von Polyfills, den Ihre targets erfordern — breit gefächert und die Quelle des meisten geerbten Aufblähens.
• 'usage' fügt Polyfills nur für die Funktionen hinzu, auf die Ihr Code tatsächlich verweist, pro Datei. Das ist fast immer das, was Sie wollen: Es begrenzt die Polyfill-Injektion auf echte Verwendung statt auf Ihre gesamte Zielmatrix.

Schritt 4: Validieren Sie gegen echte Nutzerdaten

Eine Konfiguration ist eine Hypothese über Ihre Nutzer; RUM-Daten bestätigen oder widerlegen sie. web.dev empfiehlt, die echte Funktionsunterstützung zu messen, bevor man sich für einen Polyfill entscheidet, und verweist auf RUM Insights als breite Datenquelle. Das Muster dort: Funktionen im Baseline-„Widely available”-Set werden von 98 % oder mehr der Nutzer unterstützt. Wenn Ihre Analytics zeigen, dass eine Funktion nahe diesem Schwellenwert liegt, bedient der Polyfill dafür eine Nutzerschicht, die gegen null geht.

Wann sollten Sie polyfillen? Das Enhancement-, Additive-, Critical-Framework

Wenn eine Funktion tatsächlich nicht über Ihre echte Nutzerbasis hinweg unterstützt wird, ist web.devs Enhancement/Additive/Critical-Klassifizierung die nützlichste Heuristik, um zu entscheiden, ob ein Polyfill sinnvoll ist: Wenn eine fehlende Funktion für Nutzer unsichtbar ist, polyfillen Sie nicht; wenn sie sich elegant abbaut, tendieren Sie dazu, nicht zu polyfillen; nur wenn das Fehlen das Erlebnis beeinträchtigt, rechtfertigt ein Polyfill seine Performance-Kosten.

Die drei Ebenen, wie web.dev sie definiert:

1. Enhancement — die Funktion verbessert das Erlebnis, aber ihr Fehlen erzeugt keine visuelle Änderung oder verlorene Funktionalität. Performance-Hinweise wie fetchpriority sind das Beispiel. Nutzer in nicht unterstützenden Browsern werden es nicht bemerken. Nicht polyfillen.
2. Additive — die Funktion kann beeinflussen, wie eine Seite aussieht oder funktioniert, aber nicht auf eine Weise, die ernsthafte Probleme verursacht; ein Nutzer könnte es nur durch den Vergleich von Browsern bemerken. Wenn ein Polyfill existiert, tendieren Sie dazu, ihn nicht zu verwenden, besonders wenn Sie bereits andere Dinge polyfillen. Farbfunktionen und Subgrid sind Beispiele.
3. Critical — das Fehlen verursacht ein defektes Erlebnis: Laufzeitfehler, kaputte Layouts, unbrauchbare Funktionalität. Hier ist ein Polyfill (oder ein völlig anderer Ansatz) gerechtfertigt.

web.devs Ankerregel passt gut zur obigen Support-Tabelle: Wenn eine Funktion „Widely available” ist, sollten Sie nicht nach einem Polyfill greifen — es sei denn, Sie haben Daten über Ihre Nutzer, die Ihnen explizit etwas anderes sagen.

Warum Polyfill-Bugs verborgen bleiben — und wie Session Replay sie aufdeckt

Polyfill-Bugs gehören zu einer Klasse, die Standard-Test-Suites völlig übersehen: Sie manifestieren sich nur in dem Browser-Segment, das den Polyfill ausgelöst hat, was nie der Evergreen-Browser ist, gegen den Ihr CI läuft. Session Replay ist eine der wenigen Observability-Techniken, die den tatsächlichen DOM-Zustand dieser Nutzer erfasst, da sie die echte Interaktions- und Mutationssequenz des Browsers aufzeichnet, der den Polyfill-Pfad ausgeführt hat.

Session Replay deckt drei konkrete Divergenzmuster zwischen polyfillten und nativen Code-Pfaden auf:

• Layout-Shift-Timing im Container-Queries-Polyfill. Wie web.dev anmerkt, steuert der Container-Queries-Polyfill das Layout über ResizeObserver-Callbacks, die kurz vor dem Rendern eines neuen Frames durch den Browser ausgelöst werden — was die Präsentationsverzögerung erhöht und Interaction to Next Paint beeinflusst. Verzögertes Repaint-Timing kann Layout-Shifts erzeugen, die nur in den Browsern beobachtbar sind, die den Polyfill benötigten.
• Temporal-Zeitzonendivergenz. Während des browserübergreifenden Übergangs von Temporal müssen Teams möglicherweise sowohl native als auch polyfillte Temporal-Implementierungen testen, um konsistentes Verhalten über Browser hinweg sicherzustellen. Ihre Test-Suite läuft möglicherweise nur gegen einen Implementierungspfad, während echte Nutzer einen anderen erleben; Replays von Browsern, in denen native und polyfillte Implementierungen koexistieren, können helfen, diese Unterschiede aufzudecken.
• Lücken im Fokus-Management. Auf Barrierefreiheit ausgerichtete Polyfills können subtile Tastaturnavigations- und Fokus-Management-Probleme in Browsern einführen, denen native Unterstützung fehlt — die Art von Fehlerfall, die web.dev allgemeiner hervorhebt. Ein Replay mit Tastatur-Event-Erfassung zeigt den Nutzer, der durch einen Modal-Backdrop tabbt, was ein bestandener automatisierter Test gegen den Polyfill nicht aufdecken wird.

In jedem Fall ist der gemeinsame Faktor derselbe: Der Bug lebt in dem Nutzersegment, das Ihre Entwicklungsumgebung nie reproduziert. Das ist der strukturelle Grund, weniger Polyfills auszuliefern — jeder Polyfill-Pfad, den Sie entfernen, ist ein Divergenzpfad, den Sie nicht mehr überwachen müssen.

Konkrete Maßnahmen für diese Woche

Die Reduzierung Ihres Polyfill-Footprints ist eine Abfolge kleiner, reversibler Änderungen, die jeweils gegen das Bundle und Ihre Nutzer validiert werden. Das Ziel ist, nativ auszuliefern, wo Sie können, bedingt für den echten Long Tail zu laden und alles andere zu entfernen.

1. Führen Sie npx browserslist aus und löschen Sie alle geerbten benutzerdefinierten Abfragen, die auf Browser abzielen, die kein echter Nutzer verwendet. Der Wechsel zu einem engeren, aktuellen Target ist die einzelne Änderung mit dem größten Hebel.
2. Setzen Sie useBuiltIns: 'usage' und ein explizites targets-Feld in Ihrer @babel/preset-env-Konfiguration, und fixieren Sie corejs auf Ihre installierte Minor-Version.
3. Vergleichen Sie das Bundle vor und nach mit source-map-explorer, um zu bestätigen, dass das core-js-Gewicht tatsächlich gesunken ist, und führen Sie dann Ihre Tests aus, um zu überprüfen, dass nichts Benötigtes verschwunden ist.
4. Entfernen Sie jedes cdn.polyfill.io-Script-Tag vollständig; verschieben Sie tatsächlich benötigte Polyfills in Ihr eigenes Bundle.
5. Laden Sie die echten Ausnahmen bedingt. Für Temporal während seines Übergangs laden Sie den Polyfill nur für Browser, die ihn benötigen, anstatt ihn an alle auszuliefern. Für Decorators verlassen Sie sich auf Transpilation und Runtime-Hilfsfunktionen, wo erforderlich. web.devs Hinweis, dass Polyfills für Funktionen mit eingeschränkter Verfügbarkeit bedingt geladen werden sollten, gilt hier direkt.
6. Validieren Sie mit RUM-Daten vor und nach, damit das Audit auf Ihren Nutzern basiert, nicht auf dem globalen Durchschnitt.

Fazit

Die ehrliche Antwort für 2026 auf die Frage, ob noch jemand Polyfills verwendet, lautet ja — aber die vertretbare Liste ist kurz und spezifisch: Decorators, Temporal während es die Browser-Lücke überbrückt, und gesperrte Browser-Umgebungen, die Sie tatsächlich gemessen haben. Alles andere, was Ihre Konfiguration geerbt hat, sind Bytes, die für einen Browsermarktanteil ausgegeben werden, der gegen null geht, und der polyfill.io-Vorfall ist die Erinnerung daran, dass das unvorsichtige Laden dieser Polyfills ein echtes Risiko birgt. Beginnen Sie noch heute mit npx browserslist; die Lücke zwischen dem, was es ausgibt, und den Browsern, die Ihre Nutzer tatsächlich verwenden, ist Ihr Polyfill-Budget — und für die meisten Teams ist es weit kleiner als die Konfiguration annimmt.

FAQs

Was ist der Unterschied zwischen einem Polyfill und einem Transpiler?

Ein Transpiler schreibt moderne Syntax zur Build-Zeit in ein älteres Äquivalent um, während ein Polyfill zur Laufzeit eine fehlende Funktion oder API-Implementierung hinzufügt. Syntax-Funktionen wie Optional Chaining und Nullish Coalescing werden von einem Transpiler behandelt, da sie Sprachoperatoren und keine aufrufbaren Funktionen sind. APIs wie Promise.allSettled oder structuredClone werden von Polyfills behandelt, da es sich um fehlende Methoden handelt, die Runtime-Code bereitstellen kann. Ein Nullish-Coalescing-'Polyfill' in Ihrer Konfiguration signalisiert, dass beides vermischt wurde.

Was ist der Unterschied zwischen useBuiltIns 'usage' und 'entry' in babel-preset-env?

Mit useBuiltIns auf 'entry' gesetzt, ersetzt Babel ein einzelnes core-js-Import durch den vollständigen Satz von Polyfills, den Ihre Targets erfordern — was die Quelle des meisten geerbten Bundle-Aufblähens ist. Mit 'usage' injiziert Babel Polyfills nur für die Funktionen, auf die Ihr Code tatsächlich verweist, pro Datei. Der 'usage'-Wert ist fast immer vorzuziehen, da er Polyfills für echte Verwendung ausliefert statt für Ihre gesamte Zielmatrix. Beide erfordern eine corejs-Version, die auf Ihre installierte Minor-Version fixiert ist.

Ist es sicher, polyfill.io weiterhin über den Cloudflare- oder Fastly-Mirror zu verwenden?

Die Cloudflare- und Fastly-Mirrors halten bestehende Sites am Laufen, rehabilitieren aber das Remote-Polyfill-Service-Muster nicht. Nachdem die polyfill.io-Domain Anfang 2024 den Besitzer wechselte und Sansec am 25. Juni 2024 berichtete, dass der Dienst Malware injizierte, ist das Laden browserspezifischer Polyfills von einem Drittanbieter-CDN für sicherheitsbewusste Teams nicht mehr vertretbar. Entfernen Sie das cdn.polyfill.io-Script-Tag vollständig und verschieben Sie tatsächlich benötigte Polyfills in Ihr eigenes Bundle, wo Sie diese kontrollieren und überprüfen können.

Benötige ich noch core-js, wenn meine App nur auf Evergreen-Browser abzielt?

Für die meisten Evergreen-zielenden Apps im Jahr 2026 liefert core-js nahe null nützliche Polyfills, da Funktionen wie Array.flat, Object.entries, Promise.allSettled, structuredClone und fetch bereits weitgehend unterstützt werden. Die genannten Ausnahmen sind Decorators, die keine native Browser-Implementierung haben, und Temporal während seiner ungleichmäßigen browserübergreifenden Einführung. Führen Sie source-map-explorer gegen einen Produktions-Build aus, um zu sehen, welche core-js-Module vorhanden sind, und engen Sie dann Ihr Browserslist-Target ein und wechseln Sie useBuiltIns zu 'usage', um den toten Ballast zu entfernen.