Websites herunterladen, die core-js nutzen

Über core-js

Kaum jemand entscheidet sich bewusst dafür, core-js zu installieren. Die modulare Polyfill-Bibliothek gelangt als Teil eines JavaScript-Bundles auf die Website, eingebunden als transitive Abhängigkeit eines Transpiler-Presets oder eines Framework-Starters, und die für die Website verantwortliche Person hat oft noch nie von ihr gehört. Wer das Web nach core-js durchsucht, misst daher keine Verbreitung im üblichen Sinn einer Vorliebe oder eines Kaufs. Gemessen werden die Spuren, die Build-Pipelines hinterlassen, und sobald man diese Sichtweise akzeptiert, werden die Daten nicht weniger, sondern mehr wert.

Ein Polyfill sorgt dafür, dass neuere Sprachfunktionen auch in älteren Engines funktionieren. Liefert eine Website core-js aus, wurde ihre Toolchain irgendwann so konfiguriert, dass sie Browser unterstützt, die ihre Besucher womöglich längst aufgegeben haben, und eine solche Konfiguration wird selten wieder angefasst. Das Gewicht des Frontends, Budgets für die Ladegeschwindigkeit und der langsame Verfall ungepflegter Websites folgen alle aus derselben Tatsache. Die Bibliothek wurde 2014 erstmals veröffentlicht, steht unter der Lizenz MIT und hat mehrere Generationen von Richtlinien zur Browser-Unterstützung überdauert, weshalb ein heute ausgeliefertes Bundle noch Kompatibilitäts-Shims für Engines enthalten kann, die kaum noch jemand nutzt.

Die Größenordnung prägt das Muster. Stand Oktober 2026 erkennen wir core-js auf 6.146.481 Websites. 2.890.140 davon verorten wir in den USA, und der Bestand hat einen deutlichen Schwerpunkt auf der Endung .com. Die Geografie sagt hier wenig darüber aus, wo die Bibliothek geschrieben wird, und viel darüber, wo sich kommerzielle, Framework-lastige Webentwicklung konzentriert, denn der Code wandert mit den Werkzeugen, auf die sich Agenturen und Produktteams als Standard festlegen.

Die Erkennung beruht auf Rückschlüssen und zählt zu wenig. Fingerprints überstehen die Minifizierung unterschiedlich gut, Bundler benennen um und entfernen per Tree Shaking ungenutzten Code, und ein Build, der nur eine Handvoll Polyfills einbettet, hinterlässt womöglich überhaupt nichts Erkennbares. Unser Eintrag enthält zudem keine verwertbare Aufschlüsselung nach Versionen. Der Datensatz zeigt also, wo die Bibliothek im Einsatz ist, aber nicht, welche Version ausgeliefert wird. Wer Arbeiten plant, die von einer bestimmten Version abhängen, muss die Liste als Kandidatenmenge behandeln und auf den relevanten Websites selbst nachprüfen.

Die Leute, die uns nach dieser Liste fragen, lassen sich in wenige Gruppen einteilen. Sicherheits- und Supply-Chain-Teams wollen die Reichweite eines Pakets kennen, dem sehr viele vertrauen, das aber nur von wenigen Maintainern betreut wird, denn gerade die Reichweite macht eine Abhängigkeit zu einem lohnenden Angriffsziel. Performance-Anbieter suchen Websites, die alten Kompatibilitätscode ausliefern, den sie nicht mehr brauchen. Maintainer von Frameworks und Browsern wollen Belege, bevor sie die Unterstützung für etwas Altes einstellen. Die Prüfung einer einzelnen Domain klärt keine dieser Fragen, und sie ist ohnehin einfach, denn die Entwicklertools eines Browsers erledigen das in wenigen Augenblicken.

Was eine herunterladbare Liste hinzufügt, ist die umgekehrte Abfrage. Statt zu fragen, was eine bekannte Website einsetzt, fragen Sie, welche Websites in einem Land, unter einer Endung, auf einer bestimmten E-Commerce-Plattform oder hinter einem bestimmten Content-Delivery-Netzwerk ebenfalls diese Abhängigkeit mitbringen, und Sie erhalten den gesamten Bestand als Zeilen zurück, die Sie mit Ihren eigenen Kundendaten verknüpfen können. Um das aus Abfragen pro Domain nachzubauen, müssten Sie den gesamten registrierten Namensraum selbst crawlen, und genau diese Arbeit haben wir bereits erledigt.