Colly-Test: Statisches HTML, direktes JSON und die Grenze zum Browser

Ich habe eine Fixture-Website gebaut, um genau den Teil von Colly zu prüfen, den weder Seitenanzahl noch Tempo-Reputation beantworten: Liefert Colly in seinen Callbacks die erwarteten Datensätze, behandelt es einen HTTP-Fehler korrekt, folgt es einem begrenzten Graphen und macht es Inhalte sichtbar, die außerhalb von gerendertem HTML ausgeliefert werden? Das war eine Prüfung von Korrektheit und Grenzen, kein Durchsatz-Benchmark.

In den kontrollierten Fixtures extrahierte Colly jeden erwarteten statischen Datensatz, leitete eine 500-Antwort an OnError weiter und besuchte 17 URLs im konfigurierten Graphen mit begrenzter Tiefe. Auf zwei Seiten, deren Elemente erst nach JavaScript-Ausführung auftauchten, wurden 0 Ziel-Elemente zurückgegeben. Ein direkt erreichbarer JSON-Endpunkt blieb auch ohne Browser nutzbar – ein wichtiger Unterschied zum Rendern der Client-Oberfläche.

Was Colly eigentlich ist

Colly bezeichnet sich selbst als „elegant scraper and crawler framework for Golang“ – und diese Beschreibung trifft mehr zu, als man auf den ersten Blick denkt. Es ist eine Go-Bibliothek mit rund 25.300 GitHub-Stars und 1.850 Forks, lizenziert unter Apache-2.0. Es ist kein CLI-Tool, das man einfach herunterlädt und auf eine URL loslässt. Du schreibst Go-Code, bindest Colly ein, registrierst ein paar Callbacks und baust daraus eine einzelne ausführbare Datei.

Das Denkmodell ist ereignisgesteuert. Du hängst Handler an einen Collector: OnHTML führt Extraktionslogik für passende CSS-Selektoren aus, OnResponse liefert den rohen Response-Body, und OnError verarbeitet Request-Fehler. Link-Handler rufen Visit() für gefundene URLs auf, während MaxDepth den Traversal-Radius begrenzt. Für diese HTTP-only-Pfade braucht die Zielumgebung weder eine separat installierte Go-Runtime noch einen Browser; ob die erzeugte Binärdatei vollständig statisch ist, hängt von Build-Flags und CGO-Einsatz ab – das wurde in diesem Test nicht protokolliert.

Kernfunktionen und wie sie intern ablaufen

Das Callback-Modell ist der wichtigste Punkt, weil Colly sich genau dadurch anders anfühlt als ein bloßes Request-und-Parse-Skript. Drei Callbacks haben jeden meiner Tests getragen.

OnHTML(selector, handler) ist das Arbeitstier. Wenn du es etwa auf .product oder article p registrierst, ruft Colly den Handler pro passendem Element auf, während das DOM geparst wird. Hier lebt strukturierte Extraktion – und das liest sich angenehm, weil du beschreibst, was du holen willst, statt eine Parse-Schleife zu schreiben.

OnResponse(handler) sitzt eine Ebene tiefer und gibt dir die rohen Bytes. Wenn ein Ziel JSON statt HTML liefert, überspringst du das DOM komplett und deserialisierst den Body selbst. Genau dieser einzelne Callback war der Grund, warum Colly in meinen Tests eine JSON-API sauber verarbeiten konnte, ganz ohne HTML-Parsing.

OnError(handler) behandelt Request-Fehler und kann dem aufrufenden Code den Response-Status bereitstellen. In diesem Test erreichte eine Fixture-Antwort mit Status 500 den registrierten Callback. Retries, Timeouts, DNS-Fehler, Verbindungsabbrüche, Callback-Panics, Persistenz und Alerting wurden nicht getestet.

Über den Callbacks liegen zwei operative Eigenschaften. MaxDepth begrenzt die Link-Traversierung gemäß Collys Tiefensemantik. Eine kompilierte Go-Binary vermeidet außerdem eine separat installierte Sprachumgebung auf dem Zielhost. Dieser Lauf erfasste weder Build-Flags noch den CGO-Status und behauptet daher nicht, dass jede daraus entstehende Binärdatei vollständig statisch ist.

Setup: das nötige Go-Toolchain

Die Abhängigkeit ist klein, aber real – deshalb kommt sie hier vor der Installation. Auf dem Testrechner war kein Go installiert, und Colly ist eine Go-Bibliothek; also bestand Schritt eins darin, eine Go-Toolchain auf das System zu bringen (ich installierte Go 1.26.5 via Homebrew). Wenn dein Team nicht ohnehin in Go arbeitet, liegt genau hier die Reibung: nicht in Colly selbst, sondern in der Sprachumgebung, die vor der ersten kompilierten Zeile vorhanden sein muss.

Sobald Go installiert war, löste go get github.com/gocolly/colly/v2 auf v2.3.0 auf. Für die getesteten Pfade waren weder Browser noch Headless Chrome erforderlich.

Eine Versionsoberfläche kann verwirrend sein. Das Go-Modul löste auf v2.3.0 auf (veröffentlicht im Dezember 2025), während im GitHub-Releases-UI zum Prüfzeitpunkt der neueste sichtbare Eintrag v2.2.0 (März 2025) war. Der Unterschied liegt zwischen Modul-/Repository-Version und GitHub-Release-Eintrag, nicht zwischen Modul und Git-Tag. Ich habe v2.3.0 getestet.

Praxis: Extraktion und operative Grenzen

Ich habe Colly gegen einen in sich geschlossenen Fixture-Server (Go httptest) sowie zwei öffentliche Demo-Seiten laufen lassen. Das aktuelle Benchmark-Verzeichnis und results/colly-test-summary.json enthalten Artefakte, aber beide Links zeigen auf einen beweglichen Branch. Der Artikel nennt weder den getesteten Commit noch den exakten Befehl, Build-Flags oder den Fixture-Seed – also noch kein unveränderliches Reproduktionsrezept.

Bei den kontrollierten statischen Fixtures lieferten die konfigurierten Selektoren 12 von 12 erwarteten Produktdatensätze und alle drei erwarteten Artikelabsätze. Die direkte JSON-Antwort berührte nie einen HTML-Parser: OnResponse lieferte den Body, und das Test-Setup dekodierte alle acht erwarteten Elemente. Das einzelne 500-Fixture erreichte OnError mit sichtbarem Status und ließ diesen Lauf nicht abstürzen; daraus folgt aber keine unbeaufsichtigte Zuverlässigkeit. Auf der öffentlichen Books to Scrape-Seite lieferte der Selektor 20 Produkte als Smoke-Test für eine öffentliche Website.

Für die Traversierung wurde der Collector mit MaxDepth(2) und der Seed-Tiefen-Konvention des Test-Setups konfiguriert und besuchte 17 URLs im Fixture-Graphen. Das Ergebnis ist Crawl-Abdeckung, nicht Geschwindigkeit. Der beobachtete Trace – kein allgemeiner Anspruch an beliebige Graphen – steht in results/local_crawl_graph.json.

Colly führt kein JavaScript aus. Das JavaScript-gerenderte Fixture lieferte 0 Zielkarten, und die öffentliche Quotes to Scrape JS-Seite lieferte 0 Zielzitate. Wenn Elemente erst nach Browserausführung existieren und kein zugänglicher Backend-Endpunkt sie bereitstellt, kann der HTTP-only-Pfad diese Elemente nicht als gerendertes DOM sehen. Entweder mit einem Renderer kombinieren oder direkt den Backend-Endpunkt aufrufen, wenn einer verfügbar ist – wie das JSON-Fixture zeigt.

Ich habe den Async-Collector, Rate-Limiting- oder Politeness-Konfiguration, Proxy-Rotation, Retries oder Queue- und Storage-Backends nicht belastet. Es wurden weder Laufzeit, Durchsatz, Parallelität, CPU, Speicher, Ziel-Latenz noch eine Vergleichsbasis gemessen. Dieser Artikel erhebt daher keinen Anspruch auf Geschwindigkeit oder unbeaufsichtigte Zuverlässigkeit.

Wie man die Fixture-Ergebnisse liest

Die drei erfolgreichen Content-Pfade prüfen unterschiedliche Verträge. Die Katalog- und Artikel-Fälle testen CSS-Selektion auf serverseitig ausgeliefertem HTML. Ihre Nenner sind die vor der Extraktion festgelegten Fixture-Erwartungen: zwölf Produktdatensätze und drei Artikelabsätze. Sie als „erwartete Datensätze extrahiert“ zu benennen, ist Absicht. Der Lauf definiert weder Fuzzy Matching noch Duplikatbehandlung, Toleranz für unvollständige Felder oder eine corpus-weite Recall-Metrik – deshalb sollte das Ergebnis nicht zu allgemeiner Extraktionsgenauigkeit aufgeblasen werden.

Der JSON-Fall umgeht die DOM-Selektion. Colly erhält die Response-Bytes über OnResponse, und das Test-Setup übernimmt das JSON-Decoding. Deshalb bedeutet „Colly rendert kein JavaScript“ nicht, dass jede clientseitig getriebene Website unerreichbar ist. Wenn die vom Client verwendete Datenquelle ein direkt aufrufbarer Endpunkt ist und die Anfrage außerhalb des Browsers reproduzierbar ist, kann der HTTP-Crawler trotzdem ausreichen. Authentifizierung, generierte Signaturen, Browser-only-State und Anti-Bot-Kontrollen können die Antwort ändern; davon wurde hier nichts getestet.

Die 500-Routing-Prüfung testet Dispatch, nicht Recovery. Sie zeigt, dass der registrierte OnError-Callback diese Fixture-Antwort samt Status erhalten hat. Ein produktiver Crawler braucht trotzdem eine explizite Policy für wiederholbare Statuscodes, Backoff, terminale Fehler, Persistenz und Alarmierung. Der Test liefert keinen Beleg für diese Entscheidungen, und „der Callback hat ausgelöst“ darf nicht als „der Job läuft unbeaufsichtigt sicher“ gelesen werden.

Der 17-URL-Graph ist ebenso eng begrenzt. Er bestätigt die besuchte Menge, die dieses Fixture, diese Seed-Konvention und MaxDepth(2) erzeugt haben. Er belegt weder Seiten pro Sekunde noch Fairness über Hosts hinweg, noch Speicherwachstum oder Verhalten bei Zyklen und doppelten URL-Formen. Dafür braucht es separate Workload- und Queue-Tests.

Eine praxisnahe Auswahl-Checkliste aus diesem Lauf

Starte damit, den Response zu betrachten, den Colly tatsächlich erhält. Wenn die benötigten Felder im serverseitig ausgelieferten HTML vorhanden sind, nutze OnHTML und prüfe Feldanzahl oder Pflichtschlüssel, bevor du einen Datensatz akzeptierst. Wenn die Antwort JSON ist, verarbeite den Body über OnResponse und validiere das Schema. Wenn das HTML nur eine Anwendungs-Hülle ist, prüfe, ob eine zugängliche Backend-Anfrage die Daten enthält, bevor du einen Browser hinzunimmst.

Wenn Browserausführung notwendig ist, behandle sie als eigene Komponente, statt darauf zu hoffen, dass ein Colly-Flag das Rendering aktiviert. Der Browser muss die Bereitschaft herstellen, den gerenderten Inhalt oder die Backend-Responses zugänglich machen und die Daten in den restlichen Ablauf einspeisen. Diese Review hat eine solche Integration nicht getestet.

Für den produktiven Einsatz sollten Go-Version, Modul-Version, Build-Flags, CGO-Status, exakter Befehl, Fixture-Seed und Repository-Commit dokumentiert werden. Diese Angaben fehlen in den aktuellen Veröffentlichungslinks und entscheiden darüber, ob Artefakte prüfbar oder reproduzierbar sind. Für den Betrieb solltest du außerdem eine Fehler-Matrix anlegen und die wirklich relevante Last messen, bevor du das System als schnell oder zuverlässig bezeichnest.

Vor- und Nachteile

Vorteile:

• 12/12 erwartete Katalogprodukte und 3/3 erwartete Artikelabsätze über OnHTML extrahiert.
• Saubere JSON-Verarbeitung über OnResponse, kein DOM-Parsing nötig – 8/8 API-Elemente.
• Die getestete 500-Antwort erreichte OnError mit sichtbarem Status.
• Ein depth-limited Crawl erreichte mit einem einzigen Collector 17 Seiten.
• Kompiliert zu einer Go-Binary; für die getesteten Pfade braucht das Ziel keine separat installierte Go-Runtime.
• Permissive Apache-2.0-Lizenz.

Nachteile:

• Keine JavaScript-Ausführung – client-gerenderte Inhalte liefern schlicht 0.
• Go-Toolchain erforderlich; Nicht-Go-Teams zahlen diese Einrichtungskosten, bevor sie überhaupt einen Scraper schreiben.
• Das getestete Modul (v2.3.0) liegt vor dem neuesten beobachteten GitHub-Release-Eintrag (v2.2.0).
• Der Output ist dein eigener Code – Colly liefert Callbacks, aber keinen eingebauten Dataset-/Feed-Exporter wie Scrapy.
• Async-, Rate-Limiting-, Proxy- und Queue-Backends existieren, wurden hier aber nicht getestet; Durchsatz und Skalierung bleiben ungemessen.

Für wen es passt – und wer es lieber lässt

Colly passt, wenn du bereits in Go arbeitest und serverseitig gerendertes HTML oder direkt erreichbares JSON ansteuerst. Das Callback-Modell trennt strukturierte Treffer, rohe Payloads und Request-Fehler. Eine kompilierte Binärdatei vermeidet außerdem eine separat installierte Sprachumgebung auf dem Zielsystem, auch wenn eine vollständig statische Verlinkung hier nicht verifiziert wurde.

Einen Renderer solltest du hinzufügen, wenn die benötigten Ziel-Elemente erst nach Browserausführung entstehen und kein brauchbarer Backend-Endpunkt existiert. Ein direktes JSON-Endpunkt kann trotzdem ohne Rendering abgefragt werden. Colly ist außerdem weniger geeignet für Teams, die keine Go-Toolchain wollen oder die von einem Extraktionsdienst erwarten, dass er Schema-Formung und Selektorpflege übernimmt.

Alternativen, inklusive der Rolle von Thunderbit

Colly ist Open-Source-Software, die du selbst betreibst. Es gibt keine Lizenz- oder Nutzungsgebühr an einen Anbieter, aber Rechenleistung, Bandbreite, Proxys, Storage, Observability und Engineering bleiben deine Kosten. Du verantwortest Request-Verhalten, Parsing-Callbacks, Crawl-Logik und Browser-Integration, falls ein Ziel Rendering braucht.

Ein verwalteter Extraktionsdienst verschiebt einen Teil dieser Verantwortung zu einem Anbieter. Wir bauen Thunderbit, haben es aber nicht gegen diese Fixtures getestet; deshalb trifft dieser Artikel keine Aussagen zu Rendering, Anti-Bot, Qualität, Latenz oder Kosten. Der Unterschied liegt im Ownership: Colly liefert HTTP-Responses und Callbacks in deinem Go-Prozess; ein Managed Service kann Beschaffung und Schema-Formung gegen eine Gebühr pro Aufruf übernehmen.

Verwandte Benchmark-Reviews: der vollständige Vergleich von Open-Source-Scrapern, die Python-Crawler-Review zu Scrapy und die Review zu Scraplings adaptiven Selektoren.

Thunderbit für die Web-Datenextraktion testen

Fazit

Colly ist eine starke Option für Go-Teams, die serverseitig gerendertes HTML oder direktes JSON anvisieren und bereit sind, ihre Extraktionslogik selbst zu verantworten. Die Fixtures belegen die Extraktion erwarteter Datensätze, einen begrenzten Crawl-Trace und einen beobachteten 500-Callback – aber weder Geschwindigkeit noch Skalierung oder unbeaufsichtigte Zuverlässigkeit. Für browser-gerendertes DOM braucht es einen anderen Weg, sofern der zugrunde liegende Datenendpunkt nicht direkt aufrufbar ist.

Thunderbit für die Web-Datenextraktion testen Get Started Free

FAQs

Hat dieser Review Collys Geschwindigkeit gemessen? Nein. Gemessen wurden die Extraktion erwarteter Datensätze, direktes JSON-Handling, ein Error-Callback und die Abdeckung eines Fixture-Crawl-Graphs. Nicht gemessen wurden Laufzeit, Durchsatz, Parallelität, CPU, Speicher oder eine Vergleichsbasis.

Kann Colly JavaScript-gerenderte Seiten scrapen? Colly führt das JavaScript der Seite nicht aus. Der getestete HTTP-Pfad fand deshalb keine Zielelemente, die nur im gerenderten DOM erschienen. Es kann jedoch einen zugänglichen JSON-Backend-Endpunkt direkt anfragen, wie das JSON-Fixture zeigt. Verwende einen Renderer, wenn Ausführung nötig ist und keine reproduzierbare Backend-Anfrage die Daten liefert.

Muss ich Go kennen, um Colly zu verwenden? Ja. Colly ist eine Go-Bibliothek, keine eigenständige CLI – du bindest sie ein, registrierst Callbacks (OnHTML, OnResponse, OnError) und kompilierst. Auf dem von mir getesteten Rechner war kein Go installiert, daher begann das Setup mit einer Go-Toolchain (1.26.5). Wenn dein Team nicht schon in Go arbeitet, ist genau diese Umgebung der eigentliche Einrichtungsaufwand.

Warum passt die installierte Version nicht zur neuesten GitHub-Release-Version von Colly? Das Go-Modul löste auf v2.3.0 auf (Dezember 2025), während der neueste beobachtete GitHub-Release-Eintrag v2.2.0 (März 2025) war. Ich habe v2.3.0 getestet; das ist ein Unterschied zwischen Versionsoberflächen, kein Beleg für eine fehlerhafte Installation.

Ist Colly für kommerzielle Nutzung kostenlos? Ja, unter Apache-2.0, also permissiv und kommerziell gut nutzbar. Wie immer solltest du die aktuelle Lizenz im Repo prüfen, bevor du darauf aufbaust.

Vor dem produktiven Einsatz solltest du Tests ergänzen, die das operative Risiko abbilden, statt das Fixture-Ergebnis nur analog zu verlängern. Miss wiederholte Crawls an repräsentativen Zielen, dokumentiere CPU und Peak-Memory, teste wiederholbare und terminale Fehler und prüfe Politeness unter Parallelität. Wenn Persistenz wichtig ist, stoppe und setze einen Crawl fort und beobachte Duplikatbehandlung sowie Queue-Status. Wenn einfache Bereitstellung zählt, dokumentiere die exakte Compiler- und Linker-Konfiguration und prüfe die Laufzeitabhängigkeiten der erzeugten Binärdatei. Keine dieser Prüfungen ändert, was das aktuelle Fixture gezeigt hat; sie entscheiden nur, ob dieselbe Bibliothekskonfiguration zu einem bestimmten Produktivjob passt.