Suchst du nach „Colly“, taucht fast immer dasselbe Adjektiv auf: schnell. Schneller Go-Crawler, schnell, weil es kompiliert, schnell, weil kein Browser im Weg ist. Kaum jemand nennt dazu eine Zahl.
Also habe ich mich nicht länger auf das Schlagwort verlassen. Ich habe eine kleine Testumgebung aufgebaut, Colly dagegen laufen lassen und genau beobachtet, was die Bibliothek tatsächlich macht — wie sauber statische Seiten erfasst werden, wie ein fehlgeschlagener Request weitergereicht wird und wie weit ein Crawl mit Tiefenlimit wirklich kommt. Die Kurzfassung vorab: Bei statischen Inhalten gab es vollständige Trefferquote, ein 500er landete genau dort, wo er sollte, und ein Crawl mit Depth-Limit erreichte 17 Seiten aus einer einzigen statischen Binary ganz ohne Browser. Gleichzeitig lieferte die Library bei allem, was per JavaScript gerendert wurde, sauber eine Null — genau den Teil, den die „schnell“-Rufe gern auslassen.
Was Colly eigentlich ist — und was nicht
Colly beschreibt sich selbst als „elegant scraper and crawler framework for Golang“ — und dieser eine Satz wiegt mehr, als er zunächst klingt. Es handelt sich um eine Go-Bibliothek, mit rund ~25,4k Stars vom 2026-07-09 auf gocolly/colly, lizenziert unter Apache-2.0. Es ist kein Kommandozeilen-Tool, das man einfach herunterlädt und auf eine URL loslässt. Stattdessen schreibt man Go-Code, importiert das Paket, verbindet ein paar Callbacks und kompiliert das Ergebnis zu einer einzelnen ausführbaren Datei.
Das mentale Modell ist ereignisgesteuert — und genau das bringt viele aus dem Tritt, die eher mit „abrufen und parsen“ arbeiten. Man iteriert nicht einfach über eine Response und zieht Feld für Feld heraus. Stattdessen hängt man Handler an einen Collector, und die Library ruft sie auf, während sie Seiten abarbeitet. OnHTML führt den Extraktionscode immer dann aus, wenn ein passender CSS-Selektor auftaucht. OnResponse übergibt den rohen Response-Body, was wichtig ist, wenn die Nutzlast JSON statt HTML ist. OnError fängt Requests ab, die scheitern. Das Crawling funktioniert genauso: Im Handler für Links ruft man Visit() auf die gefundenen URLs auf, Colly legt sie in die Warteschlange, und MaxDepth entscheidet, wie weit der Crawl laufen darf. Callbacks, Visit-Queue, Tiefenlimit, statisch kompiliert. Kein Interpreter, keine Laufzeitumgebung, kein Headless Chrome im Speicher.
Das Callback-Modell — und warum dadurch Extraktion anders wirkt
Die Callbacks sind das ganze Wesen des Tools, deshalb lohnt es sich, hier einen Moment länger zu bleiben. Drei davon haben in meinen Tests alles getragen.
OnHTML(selector, handler) ist der Callback, den du am häufigsten verwenden wirst. Hängst du ihn an .product oder article p, ruft Colly deinen Handler für jedes passende Element auf, während es das DOM parst. Hier findet strukturierte Extraktion statt — und das liest sich angenehm: Du beschreibst, was du willst, nicht die Schleife, die es abholt.
OnResponse(handler) sitzt eine Ebene tiefer und gibt dir die rohen Bytes direkt vom Draht. Wenn ein Ziel JSON statt Markup zurückliefert, fasst du das DOM nie an — du wandelst den Body selbst um. Genau dieser eine Callback ist der Grund, warum Colly in meinem Lauf eine JSON-API ohne einen einzigen HTML-Parse sauber verarbeitet hat.
OnError(handler) ist der Callback, den alle vergessen, bis ein Scraper um 3 Uhr morgens abstürzt. Er wird ausgelöst, wenn ein Request fehlschlägt, und übergibt dir die Response, sodass du den Statuscode auswerten und entscheiden kannst, was als Nächstes passiert. Ein Crawler, der Fehler stillschweigend verschluckt, ist schlimmer als einer, der deutlich scheitert; Colly tut weder das eine noch das andere, und genau das ist im Dauerbetrieb wichtiger, als es auf den ersten Blick wirkt.
Zwei weitere Eigenschaften sitzen über diesen Callbacks und sind operativ relevant. MaxDepth begrenzt den Crawl, sodass ein Link-folgender Collector nach zwei Hops stoppt, statt das offene Web zu durchstreifen. Und das Build-Ergebnis ist eine einzige statische Go-Binary — einmal kompilieren, eine Datei ohne Laufzeitabhängigkeiten erhalten, auf einen Server oder in einen CI-Job legen und starten. Wenn du schon einmal einen Nachmittag mit einer Python-Virtualenv auf einer frischen Maschine verloren hast, liest sich dieses Deployment-Modell nicht wie eine Fußnote, sondern wie ein echtes Plus.
Einrichtung — der Go-Toolchain, über den niemand spricht
Die Abhängigkeitsgeschichte ist kurz, hat aber einen echten Haken, also nenne ich ihn direkt, bevor du irgendetwas installierst. Die Maschine, auf der ich getestet habe, hatte überhaupt kein Go installiert, und Colly ist nun einmal eine Go-Bibliothek. Schritt null war also, erst eine Toolchain auf das System zu bringen — ich habe Go 1.26.5 über Homebrew installiert. Wenn dein Team nicht ohnehin in Go arbeitet, ist genau das die echte Reibung. Nicht die Library. Sondern die Sprache bzw. Laufzeitumgebung, die benötigt wird, bevor überhaupt eine Zeile kompiliert werden kann.
Mit installiertem Go lief das Hinzufügen von Colly problemlos. go get github.com/gocolly/colly/v2 landete ohne Umstände bei v2.3.0 — kein Browser, kein Headless-Setup, nichts außer der kompilierten Binary am Ende. Verglichen mit Python-Scrapern, die erst einen Parser installieren und dann beim ersten Fetch an einer Kette fehlender Extras zerbrechen, war das angenehm unspektakulär. Und genau das ist hier ein Kompliment.
Ein wichtiger Präzisionshinweis, ganz ausdrücklich, weil er beim Nachforschen garantiert für Verwirrung sorgt: Das neueste Modul im Go Proxy ist v2.3.0 und wurde im Dezember 2025 veröffentlicht. Das neueste getaggte Release auf GitHub ist v2.2.0 aus März 2025. Der Code, den ich getestet habe — v2.3.0 — liegt also vor dem, was die Releases-Seite des Repos zeigt. Das ist eine Eigenheit davon, wie Go-Module und GitHub-Tags im Laufe der Zeit auseinanderlaufen, kein Zeichen dafür, dass etwas kaputt ist. Nur nicht wundern, wenn go get und die Releases-Seite unterschiedliche Zahlen nennen.
Praxis — die Zahlen hinter „schnell“
Ich habe Colly gegen einen vollständig selbstgebauten Testserver auf Basis von Go httptest laufen lassen, plus gegen zwei öffentliche Demo-Seiten, damit das Verhalten reproduzierbar ist und nicht nur eine Geschichte, die ich erzähle. Das kam dabei heraus.
| Test | Ziel | Ergebnis |
|---|---|---|
| Statischer Katalog + Pagination | lokaler Testaufbau | 12/12 Produkte, Trefferquote 1,0 |
| Artikel-Extraktion | lokaler Testaufbau | Titel + 3/3 Absätze |
| Dynamische JSON-API | lokaler Testaufbau | 8/8 Elemente via OnResponse, Trefferquote 1,0 |
| HTTP-500-Behandlung | lokaler Testaufbau | an OnError weitergeleitet, Status 500 |
Crawl-Graph (MaxDepth 2) | lokaler Testaufbau | 17 Seiten |
| Books to Scrape | öffentliche Demo | 20 Produkte |
| Dynamische Seite (ohne JS) | lokaler Testaufbau | 0 Karten (erwartet) |
| Quotes JS (ohne Rendering) | öffentliche Demo | 0 (erwartet) |
Von oben nach unten gelesen ergibt das ein stimmiges Bild. Die statische Extraktion war sauber — 12 von 12 Produkten aus dem Katalog, alle drei Absätze aus dem Artikel, alles gesteuert über OnHTML-Selektoren. Der JSON-API-Test hat nie einen HTML-Parser gesehen: OnResponse übergab den Body, ich wandelte ihn um, und 8 von 8 Elementen kamen zurück. Der 500er-Test ist der wichtigste für mich, weil hier der Unterschied liegt zwischen einem Crawler, den man über Nacht laufen lassen kann, und einem, bei dem man daneben sitzen muss — Colly leitete den Fehler an OnError weiter und zeigte den Status sauber an, ohne Absturz und ohne stilles Verschwinden. Auf der öffentlichen Books to Scrape-Demo zog es 20 Produkte ohne Sonderbehandlung.
Das Crawling-Ergebnis ist die eigentliche Schlagzeile, und ich formuliere es bewusst präzise. Ein Collector mit MaxDepth(2), der Links verfolgt und sie in absolute URLs auflöst, erreichte 17 Seiten innerhalb meines Test-Graphs. Das ist die Stelle, an der der Satz „schneller Go-Crawler“ endlich mit einer echten Seitenzahl belegt ist statt mit einem Bauchgefühl. Wichtig ist aber die Formulierung: 17 Seiten bei einem Crawl mit Depth 2. Die Tiefenzahl ist in diesem Fall mein eigener Test-Wrapper, also die Art und Weise, wie ich den Lauf konfiguriert habe; ich behaupte nicht, dass Colly intern als harte Garantie „exakt Tiefe 2, keinen Link weiter“ zusichert. Die ehrliche, überprüfbare Aussage lautet: Mit begrenzter Tiefe von 2 durchlief der Crawl den Graphen und erreichte 17 Seiten.
Und jetzt die Grenze — genau dort, wo die „ist so schnell“-Beiträge meist still werden. Colly führt kein JavaScript aus. Ich habe es auf einen JavaScript-gerenderten Testaufbau angesetzt und 0 Karten zurückbekommen; ich habe es auf die öffentliche Quotes to Scrape JS page angesetzt und wieder 0 erhalten. Das ist weder ein Bug noch ein Vorwurf. Colly ist ein HTTP-Crawler — er lädt HTML herunter und parst es, aber er startet niemals einen Browser, um clientseitige Skripte auszuführen. Wie Scrapy und andere HTTP-first-Crawler gilt: Wenn der Inhalt erst nach JavaScript-Ausführung existiert, liefert Colly jedes Mal ein leeres Ergebnis, und auch noch so viel rohe Geschwindigkeit ändert daran nichts. Du musst es mit einem Renderer kombinieren oder ein Tool wählen, das Rendering direkt mitbringt.
Ich sage genauso klar, was ich nicht getestet habe, damit niemand meine Ergebnisse über die Belege hinaus ausdehnt. Ich habe den Async-Collector, Rate-Limits und Politeness-Konfigurationen, Proxy-Rotation sowie die Queue- und Storage-Backends nicht durchgetestet. Diese Funktionen gibt es in Colly. Ich habe den Kern für Extraktion und Crawling geprüft, nicht die Skalierungs-Infrastruktur. Die README spricht von Durchsatz jenseits von tausend Requests pro Sekunde auf einem einzigen Kern, aber das ist die Zahl des Projekts selbst — ich habe Seitenzahlen und Recall gemessen, nicht Durchsatz. Wenn ich also „schnell“ sage, meine ich den kompilierte-Go-Extraktionspfad, den ich tatsächlich erfasst habe, nicht einen Scrapy-Vergleich, den ich nicht ausgeführt habe.
Vor- und Nachteile
Vorteile:
- Vollständige Trefferquote bei statischer Extraktion — 12/12 Katalogprodukte und 3/3 Artikelabsätze über
OnHTML. - Saubere JSON-Verarbeitung über
OnResponse, ohne DOM-Parsing — 8/8 API-Elemente. - Korrekte Fehlerweiterleitung — ein 500er landete in
OnError, inklusive sichtbarem Status, ohne Absturz. - Ein Crawl mit Tiefenlimit erreichte 17 Seiten mit einem einzigen Collector.
- Eine statische Go-Binary, keine Laufzeitabhängigkeiten — sehr gut für Deployment und Betrieb.
- Die liberale Apache-2.0-Lizenz.
Nachteile:
- Kein JavaScript-Rendering — clientseitig erzeugte Inhalte liefern schlicht 0.
- Eine Go-Toolchain ist Pflicht; Teams ohne Go zahlen den Setup-Aufwand, bevor sie überhaupt einen Scraper schreiben.
- Das neueste Modul (
v2.3.0) liegt vor dem neuesten getaggten Release (v2.2.0), was jeden verwirrt, der nur auf die Releases-Seite schaut. - Die Ausgabe ist dein eigener Code — Colly liefert Callbacks, aber keinen fertigen Datensatz oder Export wie etwa Scrapy.
- Async-, Rate-Limit-, Proxy- und Queue-Backends existieren, wurden hier aber nicht getestet; „schnell“ bezieht sich auf den Extraktionspfad, den ich gemessen habe, nicht auf einen direkten Durchsatzvergleich.
Für wen Colly geeignet ist — und wer lieber etwas anderes nimmt
Colly passt, wenn du bereits in Go entwickelst und HTML- oder JSON-basierte Seiten schnell crawlen willst. Wenn dein Verständnis von sauberem Deployment darin besteht, eine einzelne Binary auf eine Maschine zu kopieren und zu starten — ohne Interpreter, ohne Virtualenv, ohne Abhängigkeitslotterie —, dann ist dieses Tool genau dafür gebaut. Das Callback-Modell zahlt sich spätestens dann aus, wenn die Extraktion nicht mehr trivial ist: OnHTML für Strukturen, OnResponse für rohe Nutzdaten, OnError für Fehler, die du sonst nie sehen würdest. Für statische oder API-gestützte Ziele, die du per CI nach Zeitplan crawlen willst, ist das eine starke, unkomplizierte Wahl.
Lieber weglassen — oder zumindest ein zweites Werkzeug dazunehmen — solltest du es, wenn deine Ziele stark auf JavaScript setzen. Colly lieferte bei jeder clientseitig gerenderten Seite, die ich ihm gegeben habe, 0 zurück, und das ist Absicht, kein Schalter, den man aktivieren könnte. Verzichte auch darauf, wenn dein Team kein Go nutzt und du nicht extra eine Toolchain aufsetzen willst, nur um ein paar Websites zu scrapen — die Bindung an die Sprache ist real und muss von dir gepflegt werden. Und wenn du strukturierte Daten lieber direkt geliefert bekommen willst, statt sie selbst per Code aufzubereiten, dann liegt die Arbeit bei Colly vollständig auf deiner Seite.
Alternativen — wo eine verwaltete AI-Scraping-API Sinn ergibt
Colly ist eine kostenlose Open-Source-Bibliothek, die du selbst kompilierst und betreibst. Du besitzt den Go-Code, die Callbacks, die Crawl-Logik und die Maschine, auf der alles läuft — dafür zahlst du pro Request nichts und behältst die komplette Kontrolle im eigenen Haus. Für ein Go-Team ist das eine absolut vertretbare Lösung, und das Deployment als einzelne Binary ist tatsächlich angenehm.
Die zwei Stellen, an denen Colly aufhört, sind genau die zwei, die sich mit einer anderen Lösung vergleichen lassen. Erstens JavaScript — Colly rendert es nicht, also ist alles Clientseitige tabu, sofern du nicht noch einen Browser anschließt. Zweitens Struktur — Colly liefert Callbacks und überlässt die Formung sauberer Ausgaben deinem Code. Eine verwaltete AI-Scraping-API beantwortet beide Punkte anders. Der Entwickler-Stack von Thunderbit übernimmt JavaScript-Rendering und liefert strukturierte Daten serverseitig zurück. POST /distill verwandelt eine Seite in sauberes, LLM-taugliches Markdown, inklusive dynamischer Inhalte und Anti-Bot-Behandlung. POST /extract liefert strukturiertes JSON auf Basis eines von dir definierten JSON-Schemas, mit renderMode, den du bei Bedarf auf vollständiges Browser-Rendering hochdrehen kannst. Dazu gibt es einen Thunderbit-MCP-Server für AI-Agenten und Coding-Assistenten — thunderbit_suggest_fields ist kostenlos, damit du erst prüfen kannst, was eine Seite überhaupt hergibt, bevor du dich festlegst — sowie eine CLI, die du mit npx @thunderbit/thunderbit-cli für Terminal, CI und Cron nutzen kannst.
Thunderbit für Web-Datenextraktion testen
Der Unterschied ist nicht „besser“ gegen „schlechter“. Es geht darum, wo die Arbeit stattfindet. Mit Colly behältst du Rendering (also keines), Parsing und Wartung in deiner eigenen kompilierten Binary, ohne Kosten pro Aufruf, und du musst das System pflegen, wenn sich eine Website verändert. Mit einer verwalteten API gibst du JavaScript-Rendering, Anti-Bot und strukturierte Ausgabe ab und zahlst pro Aufruf für diesen Komfort. Kleine, Go-native, HTML- oder JSON-basierte Ziele, die du gern selbst betreibst und pflegst? Da gewinnen Collys Kontrolle und Geschwindigkeit klar. JavaScript-lastige Seiten, oder du möchtest einfach lieber schema-konformes JSON erhalten, statt noch einen Callback zu schreiben? Dann spricht vieles für den verwalteten Weg. Wenn du den breiteren Markt sehen willst, zeigen dir die Übersichten zu den besten Web-Scraping-Tools und den besten GitHub-Projekten für Web Scraping, wo eine Bibliothek wie Colly im Vergleich zu browserbasierten und verwalteten Lösungen steht.
Fazit
Solltest du Colly verwenden? Ja — wenn du Go schreibst und HTML- oder JSON-Seiten mit Tempo crawlen willst, erfüllt es genau das, was der Ruf als „schneller Crawler“ verspricht, und diesmal stehen auch Zahlen dahinter. Vollständige Trefferquote bei statischer Extraktion. Sauberes JSON über OnResponse. Ein 500er, der korrekt an OnError weitergeleitet wurde, statt einfach zu verschwinden. Ein Crawl mit Tiefe 2, der 17 Seiten erreichte. Alles kompiliert in eine einzige statische Binary ohne Laufzeitabhängigkeiten — das ist in dieser Kategorie beinahe das freundlichste Deployment-Modell überhaupt.
Nimm die Aussagen aber ehrlich in ihrer Größe wahr. JavaScript wird nicht gerendert — jede clientseitige Seite in meinem Lauf lieferte 0, und das ist dauerhaft so, nicht etwas, das man per Konfiguration übersehen hat. Eine Go-Toolchain ist Pflicht, also zahlen Nicht-Go-Teams den Setup-Aufwand im Voraus. Das installierte Modul (v2.3.0) liegt vor dem neuesten getaggten Release (v2.2.0), also nicht in Panik geraten, wenn sich die Seiten widersprechen. Und „schnell“ bedeutet hier den gemessenen Extraktionspfad, nicht einen Durchsatz-Benchmark, den ich nicht gefahren habe. Innerhalb dieser Grenzen ist Colly ein schneller, zuverlässiger und tatsächlich gut auslieferbarer Go-Crawler — und er wird seinem Ruf genau in dem Moment gerecht, in dem du aufhörst, von ihm JavaScript zu erwarten.
Thunderbit für Web-Datenextraktion testen Get Started Free
FAQs
Ist Colly wirklich schnell, und gibt es dafür eine Zahl? Schnell ist es in dem Sinn, der für den Kernpfad zählt, den ich gemessen habe: kompiliertes Go, vollständige Trefferquote bei statischer Extraktion (12/12 Katalogprodukte), saubere JSON-Verarbeitung und ein Crawl mit Tiefe 2, der 17 Seiten erreichte — alles aus einer einzigen statischen Binary. Was ich nicht ausgeführt habe, ist ein Durchsatz-Benchmark gegen Scrapy. Betrachte „schnell“ also als gemessenes Extraktionsverhalten, nicht als direkten Geschwindigkeitsvergleich.
Kann Colly JavaScript-gerenderte Seiten scrapen? Nein. Colly ist ein HTTP-Crawler — er lädt HTML herunter und parst es, führt aber nie einen Browser aus. Eine JavaScript-gerenderte Testseite lieferte 0 Karten, und die öffentliche Quotes-JS-Seite lieferte ebenfalls 0. Für clientseitige Inhalte musst du Colly mit einem Renderer kombinieren oder ein Tool nutzen, das Browser-Rendering bereits eingebaut hat.
Muss ich Go kennen, um Colly zu nutzen?
Ja. Colly ist eine Go-Bibliothek, keine eigenständige CLI — du importierst sie, registrierst Callbacks (OnHTML, OnResponse, OnError) und kompiliert den Code. Auf der Maschine, die ich getestet habe, war Go nicht installiert, also begann die Einrichtung mit der Installation einer Toolchain (1.26.5). Wenn dein Team nicht ohnehin in Go arbeitet, ist genau diese Umgebung der eigentliche Setup-Aufwand.
Warum stimmt die Version, die ich installiere, nicht mit dem neuesten GitHub-Release von Colly überein?
Weil Go-Modul und GitHub-Release-Tag auseinanderlaufen können. Das neueste Modul im Go Proxy ist v2.3.0 (Dezember 2025), während das neueste getaggte Release auf GitHub v2.2.0 (März 2025) ist. Ich habe v2.3.0 getestet. Das ist eine Eigenheit von Modulen versus Tags, kein fehlerhafter Installationsvorgang.
Ist Colly für die kommerzielle Nutzung kostenlos? Ja, es ist Apache-2.0 lizenziert — also permissiv und kommerziell gut nutzbar. Prüfe wie immer vor dem Einsatz die aktuelle Lizenz im Repo.
