Websites herunterladen, die Modernizr nutzen

Über Modernizr

Gerade in der Versionsspalte wird der Eintrag zu Modernizr merkwürdig, und diese Merkwürdigkeit sollte man vor allem anderen erklären. Wir verzeichnen 439 verschiedene Versionswerte, weit mehr, als das Projekt je veröffentlicht hat, denn die Bibliothek wird normalerweise als individueller Build eingebunden. Ein Entwickler wählt die Feature-Tests aus, die ein Projekt tatsächlich braucht, der Builder versieht das Ergebnis mit einer Kennung für genau diese Kombination, und diese Kennung landet im Seitencode. Der erfasste Wert 2 ist der Fingerabdruck eines solchen Builds und keine Release-Nummer, was bedeutet, dass die Zahl verschiedener Werte misst, wie vielfältig die Builds sind, und nicht, wie viele Upgrades stattgefunden haben.

Die Bibliothek selbst beantwortet eine Frage, die heute weitgehend niemand mehr stellt. 2009 unter der Lizenz MIT veröffentlicht, prüft sie den Browser auf einzelne Fähigkeiten, damit sich eine Seite an das anpassen kann, was tatsächlich unterstützt wird, statt aus dem User-Agent-String zu raten. In einer Zeit, in der sich Browser in fast allem uneinig waren, war Feature-Erkennung die verantwortungsvolle Art zu entwickeln. Dann glichen sich die Browser an. Die Technik überlebt in engen Nischen, doch ein Frontend, das noch eine universelle Erkennungsbibliothek lädt, wurde meist zu einer Zeit zusammengebaut, als diese Technik gängige Praxis war.

Stand Oktober 2026 finden wir die Bibliothek aus der Kategorie JavaScript libraries noch auf 781.084 Websites. 260.516 davon verorten wir in den USA, und auf die Endung .com entfällt ein großer Teil des Volumens. Die Verbreitung folgt den Theme- und Template-Ökosystemen jener Zeit und nicht einer heutigen Vorliebe von Entwicklern, und aus demselben Grund verharren die Versionsstrings dort, wo ein Builder sie hinterlassen hat.

Ihr Vorhandensein taugt deshalb zur Datierung, und für solche Datierungshilfen gibt es Käufer. Agenturen, die Relaunches verkaufen, suchen Websites, deren Frontend älter ist als die aktuelle Framework-Generation, denn bei solchen Projekten lässt sich ein Relaunch leicht begründen. Sicherheits- und Compliance-Teams wollen denselben Bestand aus einem anderen Grund: Eine Seite, die seit Jahren niemand neu gebaut hat, bringt oft weitere ungepflegte Abhängigkeiten neben dieser einen mit, und eine Erkennungsbibliothek ist ein günstiger Weg, diese Kohorte zu finden, ohne jedes Skript auf jeder Seite zu prüfen. Anbieter neuerer Tools nutzen die Liste, um Kandidaten für eine Ablösung zu finden.

Keine dieser Überlegungen funktioniert Domain für Domain. Eine Einzelabfrage bestätigt, dass eine Website eine Erkennungsbibliothek lädt, und damit ist Schluss. Mit der herunterladbaren Liste können Sie die ganze Kohorte nach Land und Endung gruppieren, mit den anderen für dieselben Hosts erfassten Technologien verknüpfen und am Ende eine belastbare Aussage darüber treffen, welcher Teil eines Marktes noch Frontend-Code aus einer bestimmten Ära ausliefert. Auf die Verknüpfung kommt es an. Für sich genommen ist eine Technologiespalte eine Randnotiz. Dieselbe Spalte im Abgleich mit Geografie, Plattform und mitinstallierter Software ist ein Argument.

Die Vorbehalte sind wichtig, und beide verschieben die Zahl nach unten oder zur Seite. Individuelle Builds werden häufig in die Hauptskriptdatei einer Website gebündelt, wo der kennzeichnende Kommentar wegfällt und die Bibliothek für einen externen Crawler unsichtbar wird, sodass die tatsächliche Verbreitung größer ist als die Zahl, die wir veröffentlichen. Außerdem kann die Erkennung eine bewusste, moderne Nutzung nicht von einem geerbten Fragment unterscheiden, das niemand entfernt hat, und in der Praxis ist der zweite Fall häufig. Als Indikator für das Alter eines Frontends ist der Eintrag verlässlich. Als Maß dafür, wer heute aktiv auf Feature-Erkennung angewiesen ist, würde er die Absicht überschätzen, denn die meisten dieser Installationen sind Erbe und keine Entscheidung.