Websites herunterladen, die Webpack nutzen

Über Webpack

Fast alles andere auf einer Technologieseite beschreibt etwas, das im Browser oder auf einem Server läuft. Webpack läuft auf dem Rechner eines Entwicklers, ist mit der Arbeit fertig, lange bevor jemand die Website besucht, und ist danach überhaupt nicht mehr vorhanden. Was wir erkennen, sind Spuren.

Der Bundler nimmt die Quelldateien einer Anwendung samt ihren Abhängigkeiten und erzeugt daraus ein kompaktes Paket browsertauglicher Dateien. Dabei hinterlässt er erkennbare Muster: den Runtime-Helfer, der Code-Chunks bei Bedarf nachlädt, die Namenskonvention für diese Chunks und die Struktur der Modul-Registry, die um die kompilierte Ausgabe gelegt wird. Das Tool erschien 2012 unter der Lizenz MIT und hat diese Muster in weiten Teilen des Ökosystems vereinheitlicht, und genau deshalb lassen sie sich von außen ablesen. Eine Version veröffentlichen wir für Webpack nicht, denn ein kompiliertes Bundle nennt keine, und eine Release-Version aus der Struktur des Codes abzuleiten, wäre eine als Tatsache verkleidete Vermutung.

Stand Oktober 2026 sind die Spuren, die wir in der Kategorie Miscellaneous führen, auf 786.881 Websites sichtbar, wobei wir 455.444 davon in den USA verorten und die Endung .com einen großen Teil des Rests ausmacht. Die Verteilung folgt hier den Orten, an denen Frontends im Stil von Anwendungen gebaut werden, und nicht der Verteilung des Webs insgesamt, was eine grundlegend andere Karte ergibt als die, die ein Content-Management-System zeichnen würde.

Der Einsatz lässt einen Schluss zu, der kommerziell von Bedeutung ist. Eine Website mit Bundler-Spuren wurde kompiliert, und eine kompilierte Website hat ein Paketmanifest, einen Abhängigkeitsbaum, irgendwo in ihrer Geschichte eine Toolchain und eine Person oder ein Team, das dafür bezahlt wird, all das zu pflegen. Einfache Visitenkarten-Websites, die in einem Baukasten zusammengestellt wurden, sehen anders aus. Wer Entwicklerwerkzeuge, Fehler-Monitoring, Abhängigkeitsscans oder Recruiting von Entwicklern verkauft, sucht genau den Bestand, den ein Bundler-Fingerprint herausfiltert, und der Fingerprint erfasst ihn gleichbleibend, unabhängig davon, welches Framework in einem bestimmten Jahr gerade in Mode ist.

Die Sicherheitsforschung nutzt dasselbe Merkmal aus entgegengesetzter Richtung. Gebündelte Ausgaben werden häufig mit Source Maps ausgeliefert, die niemand entfernt hat, mit Abhängigkeitsversionen, die im kompilierten Code stecken, und mit internen Modulpfaden, die in den Chunk-Namen erhalten bleiben. Derselbe Bestand ist deshalb auch der, den man auf unbeabsichtigte Offenlegung prüfen sollte. Eine Liste kompilierter Websites ist eine sinnvolle Ausgangsbasis für Studien dieser Art, und realistisch betrachtet lässt sie sich nicht von Hand zusammenstellen.

Die Untererfassung ist gravierend, und daran ändert keine Formulierung etwas. Ein Build lässt sich so konfigurieren, dass er jedes Merkmal löscht, nach dem wir suchen, und Meta-Frameworks, die den Bundler einbetten, erzeugen oft eine Ausgabe mit ihrer eigenen Signatur statt der darunterliegenden. Eine Website kann mit dem Tool kompiliert sein und von außen so aussehen, als wäre sie es nie gewesen. Das Fehlen der Spuren sagt hier fast nichts, ihr Vorhandensein dagegen ist verlässlich, und diese Kombination passt gut zur Akquise und schlecht zur Berechnung von Marktanteilen. Wer aus dieser Spalte einen Prozentanteil für das Ökosystem zitiert, zitiert eine Untergrenze.

Zu alldem passt eine Abfrage pro Domain nicht. Eine einzelne Website auf Bundler-Spuren zu prüfen, erledigt jeder in einer Minute mit den Entwicklerwerkzeugen des Browsers, und die Antwort stützt keine Entscheidung. Die herunterladbare Liste liefert, was eine einzelne Prüfung nicht leisten kann: wie groß das kompilierte Web ist, wie es sich auf Länder und Endungen verteilt, welche Frameworks und Monitoring-Tools in denselben Einträgen mitlaufen und wo sich ein Segment technikgetriebener Websites finden und vermessen lässt, bevor jemand Geld ausgibt, um es zu erreichen.