Websites herunterladen, die Slick nutzen

Über Slick

Ein Karussell, das jahrelang unverändert bleibt, ist meist ein Problem. Hier ist genau das der springende Punkt. Kopien des Codes wurden einmal in Templates eingefügt und dann in Ruhe gelassen. Auf Seiten, die vor langer Zeit entstanden sind, erfüllen sie noch immer die Aufgabe, für die sie geschrieben wurden. Das macht Slick für eine Roadmap uninteressant, für die Datierung einer Website aber sehr aufschlussreich.

Das Plugin erschien 2014 unter der Lizenz MIT und löste ein Problem, das damals jede Visitenkarten-Website hatte. Inhalte mussten rotieren, die Bedienung musste per Finger ebenso klappen wie per Maus, und das Ganze musste sich in eine Codebasis einfügen, die bereits von jQuery abhing. Slider dieser Generation wurden von Theme-Autoren übernommen, nicht von Website-Betreibern, und deshalb taucht die Bibliothek auf Websites auf, deren Betreiber den Namen nie gehört haben.

Stand Oktober 2026 erkennen wir die Bibliothek auf 1.006.949 Websites. 322.070 davon werden in den USA gehostet, und die gängigste Endung ist .com. Außerdem unterscheiden wir 87 verschiedene Versionsangaben, und am häufigsten erfassen wir Version 1.8.1. So sieht eine Bibliothek, die in Themes mitgeliefert wird, von außen aus: eine starke Konzentration auf ein einziges Release und eine dünne Streuung über viele andere. Die meisten Installationen bleiben dauerhaft bei der Version, mit der ihr Template ausgeliefert wurde, deshalb sagen Versionsnummern wenig darüber aus, wie sorgfältig eine Website gepflegt wird.

Das Signal für die Datierung muss stattdessen aus dem Kontext kommen, und genau diesen Kontext liefert ein vollständiges Technologieprofil. Eine Website, die diese Bibliothek neben einem alten jQuery-Build, einem Page-Builder aus derselben Zeit und einem Stylesheet-Framework ähnlichen Jahrgangs lädt, hat ein Frontend, das seit Langem nicht neu gebaut wurde. Steckt dieselbe Bibliothek dagegen in einem ansonsten modernen Stack, hat meist nur ein altes Template ein Redesign überlebt. Anhand einer einzelnen Erkennung lassen sich diese beiden Fälle unmöglich unterscheiden, anhand einer ganzen Datenzeile dagegen problemlos.

Wer braucht diese Unterscheidung? Agenturen, die Relaunches verkaufen und statt Kaltakquise eine belastbare Zielliste brauchen. Performance-Anbieter, deren ganzes Argument ungenutzter clientseitiger Code ist, der auf jeder Seite geladen wird. Fachleute für Barrierefreiheit, denn rotierende Inhalte und Tastaturnavigation haben sich nie vertragen, und Nachbesserungen müssen erst im Umfang abgeschätzt werden, bevor sich ein Angebot erstellen lässt. Sicherheitsteams, die alternde Frontend-Abhängigkeiten inventarisieren und dabei nicht fragen, ob eine bestimmte Website verwundbar ist, sondern wie viel der installierten Basis angefasst werden müsste. Jede dieser Fragen betrifft den gesamten Bestand.

Die Grenzen der Erkennung wirken nur in eine Richtung. Wir identifizieren die Bibliothek anhand von Dateisignaturen und charakteristischem Markup, daher kann uns jede Website entgehen, die ihre Skripte zu einem Bundle zusammenfasst, die Datei umbenennt, sie inline einbettet oder nur unter Bedingungen lädt. Die Zahl ist deshalb eine Untergrenze und keine Vollerhebung, und die Websites, die uns entgehen, sind eher solche mit einer Build-Pipeline. Besser gepflegte Websites sind also unterrepräsentiert. Die Verzerrung ist so gleichmäßig, dass Vergleiche zwischen Ländern, Endungen und benachbarten Technologien belastbar bleiben, auch wo die absolute Gesamtzahl es nicht ist.

Eine herunterladbare Liste ändert die Richtung der Abfrage. Die Prüfung einer Domain zeigt Ihnen, was diese Domain lädt, und das könnten Sie ohnehin im Seitenquelltext sehen. Ein Export zeigt, wie viele Websites die Bibliothek einbinden, in welchen Märkten und unter welchen Endungen, und was sonst noch daneben läuft. Nur in dieser Form lässt sich die Frage beantworten, bevor die Antwort keine Rolle mehr spielt. Sortiert nach den Content-Management-Systemen, die daneben erkannt werden, ist dieses Karussell kein Widget mehr, sondern ein Merkmal für einen ganzen Baujahrgang, und einem Jahrgang kann man etwas verkaufen, man kann ihn absichern oder migrieren.