Wpisz w wyszukiwarkę „Colly”, a pierwszy przymiotnik zawsze będzie ten sam: szybki. Szybki crawler w Go, szybki, bo się kompiluje, szybki, bo nie przeszkadza mu przeglądarka. Prawie nikt nie podaje przy tym żadnej liczby.
Postanowiłem więc nie wierzyć w to na słowo. Uruchomiłem niewielką stronę testową, skompilowałem pod nią Colly i sprawdziłem, co biblioteka faktycznie robi — jaki ma odzysk danych na prawdziwych stronach, jak obsługuje nieudane żądanie, jak daleko dociera crawl z limitem głębokości. Krótko, zanim przejdziemy do liczb: przy ekstrakcji statycznej odzyskałem wszystko, błąd 500 trafił dokładnie tam, gdzie powinien, a crawl z ograniczeniem głębokości dotarł do 17 stron z jednego statycznego binarium bez podpiętej przeglądarki. Biblioteka zwróciła też czyste zero dla wszystkiego, co renderuje JavaScript — a właśnie ten fragment entuzjaści „szybkości” zwykle pomijają.
Czym Colly naprawdę jest, a czym nie jest
Colly przedstawia się jako „elegancki framework do scrapowania i crawlowania dla Golanga” — i to jedno zdanie mówi więcej, niż się wydaje. To biblioteka w Go — około ~25,4 tys. gwiazdek na 2026-07-09 w gocolly/colly, na licencji Apache-2.0. To nie jest narzędzie z linii komend, które pobierasz i kierujesz na URL. Piszesz kod w Go, importujesz pakiet, podpinasz kilka callbacków i kompilujesz całość do jednego pliku wykonywalnego.
Model działania jest zdarzeniowy i to właśnie on zaskakuje osoby przyzwyczajone do schematu „wyślij żądanie i sparsuj odpowiedź”. Nie iterujesz po odpowiedzi i nie wyciągasz pól linia po linii. Rejestrujesz handlery na Collector i pozwalasz bibliotece wywoływać je podczas przechodzenia po stronach. OnHTML uruchamia kod ekstrakcji za każdym razem, gdy pojawi się pasujący selektor CSS. OnResponse przekazuje surową treść odpowiedzi, co ma znaczenie, gdy zamiast HTML dostajesz JSON. OnError łapie żądania, które się wysypią. Crawlowanie działa podobnie: w handlerze dla linków wywołujesz Visit() na znalezionych URL-ach, Colly dodaje je do kolejki, a MaxDepth decyduje, jak daleko wolno mu się zapuszczać. Callbacki, kolejka odwiedzin, limit głębokości, statycznie skompilowany binarny plik. Bez interpretera, bez runtime, bez headless Chrome siedzącego w pamięci.
Model callbacków i dlaczego zmienia sposób pracy z ekstrakcją
Callbacki to cała osobowość tego narzędzia, więc warto zatrzymać się przy nich na chwilę. Trzy z nich wystarczyły do wszystkich testów, które przeprowadziłem.
OnHTML(selector, handler) to ten, z którego będziesz korzystać najczęściej. Rejestrujesz go dla .product albo article p, a Colly wywołuje handler dla każdego dopasowanego elementu podczas parsowania DOM. To tutaj dzieje się uporządkowana ekstrakcja — opisujesz, czego chcesz, a nie pętlę, która to pobiera.
OnResponse(handler) działa poziom niżej i daje Ci surowe bajty prosto z odpowiedzi. Gdy cel zwraca JSON zamiast markup’u, nie dotykasz DOM-u — samodzielnie deserializujesz body. Ten jeden callback sprawił, że Colly obsłużył w moim teście API JSON bez parsowania choćby skrawka HTML.
OnError(handler) to callback, o którym wszyscy przypominają sobie dopiero wtedy, gdy scraper pada o 3 rano. Uruchamia się przy nieudanym żądaniu i przekazuje odpowiedź, dzięki czemu możesz odczytać status i zdecydować, co dalej. Crawler, który po cichu połyka błędy, jest gorszy od tego, który wyraźnie się wywraca; Colly nie robi ani jednego, ani drugiego, a to ma większe znaczenie, niż mogłoby się wydawać, gdy zadanie działa bez nadzoru.
Dwie kolejne funkcje nakładają się na te callbacki i mają znaczenie operacyjne. MaxDepth ogranicza crawl, więc collector podążający za linkami zatrzymuje się po dwóch skokach zamiast objeżdżać cały otwarty web. A wynik kompilacji to pojedynczy statyczny binarny plik Go — kompilujesz raz, dostajesz jeden plik bez zależności runtime, wrzucasz go na serwer albo do joba CI i uruchamiasz. Jeśli kiedykolwiek straciłeś popołudnie przez Python virtualenv na świeżej maszynie, taki model wdrożenia nie jest drobiazgiem — to konkretna zaleta.
Konfiguracja — łańcuch narzędzi Go, o którym nikt nie wspomina
Historia zależności jest krótka, ale ma jeden prawdziwy haczyk, więc powiem o nim zanim zainstalujesz cokolwiek. Maszyna, na której testowałem, nie miała w ogóle zainstalowanego Go, a Colly jest biblioteką w Go, więc krok zero to doinstalowanie toolchaina — zainstalowałem Go 1.26.5 przez Homebrew. Jeśli Twój zespół nie żyje już w świecie Go, to właśnie jest realny koszt wejścia. Nie sama biblioteka. Tylko środowisko, którego potrzebuje, zanim skompiluje się choćby jedna linijka.
Gdy Go było już na miejscu, pobranie Colly poszło gładko. go get github.com/gocolly/colly/v2 rozwiązało się do v2.3.0 bez żadnych komplikacji — bez przeglądarki, bez headless czegokolwiek, bez niczego poza skompilowanym binarium na końcu. Zestaw to z pythonowymi scraperami, które instalują parser, a potem rozsypują się przy pierwszym pobraniu przez łańcuch brakujących dodatków, a tutaj było zaskakująco nudno. A „nudne” w tym kontekście to komplement.
Jedna precyzyjna uwaga, bo jeśli zaczniesz sprawdzać szczegóły, na pewno Cię to pomyli. Najnowszy moduł w Go proxy to v2.3.0, opublikowany w grudniu 2025. Najnowszy tag wydania na GitHubie to v2.2.0 z marca 2025. Czyli testowany przeze mnie kod — v2.3.0 — jest nowszy niż to, co widać na stronie Releases w repozytorium. To tylko efekt tego, że moduły Go i tagi GitHuba czasem się rozjeżdżają, a nie znak, że coś jest nie tak. Po prostu nie zdziw się, gdy go get i strona Releases pokażą różne numery.
Praktyka — liczby stojące za „szybkością”
Uruchomiłem Colly na samowystarczalnym serwerze testowym zbudowanym na httptest z Go, a także na dwóch publicznych stronach demo, więc wynik da się odtworzyć, zamiast traktować go jako moją opowieść. Oto, co wyszło.
| Test | Cel | Wynik |
|---|---|---|
| Statyczny katalog + paginacja | lokalna strona testowa | 12/12 produktów, odzysk 1.0 |
| Ekstrakcja artykułu | lokalna strona testowa | tytuł + 3/3 akapity |
| Dynamiczne API JSON | lokalna strona testowa | 8/8 elementów przez OnResponse, odzysk 1.0 |
| Obsługa HTTP 500 | lokalna strona testowa | przekazane do OnError, status 500 |
Graf crawl (MaxDepth 2) | lokalna strona testowa | 17 stron |
| Books to Scrape | publiczne demo | 20 produktów |
| Dynamiczna strona (bez JS) | lokalna strona testowa | 0 kart (zgodnie z oczekiwaniem) |
| Quotes JS (bez renderowania) | publiczne demo | 0 (zgodnie z oczekiwaniem) |
Jeśli czytasz to od góry do dołu, obraz się składa. Ekstrakcja statyczna była czysta — 12 z 12 produktów z katalogu, wszystkie trzy akapity z artykułu, a wszystko sterowane selektorami OnHTML. Test z API JSON nawet nie otwierał parsera HTML: OnResponse przekazał body, zrobiłem deserializację i wróciło 8 z 8 elementów. Test z błędem 500 jest dla mnie najważniejszy, bo właśnie on oddziela crawlera, którego można puścić na noc, od takiego, którego nie da się zostawić bez opieki — Colly przekazał błąd do OnError i poprawnie ujawnił status, bez crasha i bez cichego porzucenia żądania. Na publicznym demo Books to Scrape pobrał 20 produktów bez żadnych specjalnych obejść.
Wynik crawl jest najważniejszy, więc sformułuję go ostrożnie. Collector z MaxDepth(2), podążający za linkami i zamieniający je na absolutne URL-e, dotarł do 17 stron w moim grafie testowym. To właśnie ten moment, w którym hasło „szybki crawler w Go” dostaje realną liczbę stron, a nie tylko dobry nastrój. Zwróć jednak uwagę na sformułowanie — 17 stron w crawl’u z głębokością 2. Ten numer głębokości to licznik z mojego harnessu testowego, opisujący sposób konfiguracji uruchomienia; nie twierdzę, że Colly wewnętrznie gwarantuje „dokładnie depth 2 i ani linka dalej” jako kontrakt. Uczciwe, weryfikowalne stwierdzenie brzmi tak: przy limicie głębokości ustawionym na 2 crawl przeszedł przez graf i dotarł do 17 stron.
Teraz ograniczenie, czyli miejsce, w którym wpisy o „niesamowitej szybkości” zwykle cichną. Colly nie uruchamia JavaScriptu. Wskazałem mu stronę testową renderowaną przez JS i dostałem 0 kart; wskazałem publiczną stronę Quotes to Scrape JS i znów dostałem 0. To nie jest bug ani wada. Colly to crawler HTTP — pobiera i parsuje HTML, ale nigdy nie uruchamia przeglądarki, żeby wykonać skrypty po stronie klienta. Tak jak Scrapy i inne crawlery HTTP-first, jeśli treść istnieje dopiero po wykonaniu JavaScriptu, Colly za każdym razem zwróci pusty wynik, a żadna „szybkość” tego nie zmieni. Trzeba go połączyć z rendererem albo wybrać narzędzie, które ma renderer wbudowany.
Będę też równie uczciwy w kwestii tego, czego nie testowałem, żeby nikt nie wyciągał z moich wyników wniosków ponad dowody. Nie sprawdzałem asynchronicznego collectora, konfiguracji rate limiting i politeness, rotacji proxy ani backendów kolejki i storage. Te funkcje w Colly istnieją. Testowałem rdzeń ekstrakcji i crawl, nie całą infrastrukturę do skalowania. README podaje przepustowość powyżej tysiąca requestów na sekundę na jednym rdzeniu, ale to wartość z samego projektu — ja mierzyłem liczbę stron i odzysk danych, nie throughput, więc gdy mówię „szybki”, mam na myśli skompilowaną w Go ścieżkę ekstrakcji, którą faktycznie sprawdziłem, a nie benchmark przeciwko Scrapy, którego nie uruchomiłem.
Plusy i minusy
Plusy:
- Pełny odzysk danych przy ekstrakcji statycznej — 12/12 produktów z katalogu i 3/3 akapity artykułu przez
OnHTML. - Czysta obsługa JSON przez
OnResponse, bez potrzeby parsowania DOM — 8/8 elementów API. - Poprawne kierowanie błędów — 500 trafił do
OnErrorze statusem, bez crasha. - Crawl z limitem głębokości dotarł do 17 stron z jednego collectora.
- Jeden statyczny binarny plik Go, zero zależności runtime — świetny profil wdrożeniowy i operacyjny.
- Przyjazna licencja Apache-2.0.
Minusy:
- Brak wykonywania JavaScriptu — treść renderowana po stronie klienta zwraca 0, bez wyjątku.
- Wymaga toolchaina Go; zespoły, które nie pracują w Go, płacą koszt konfiguracji zanim napiszą choćby jednego scrapera.
- Najnowszy moduł (
v2.3.0) wyprzedza najnowszy tag wydania (v2.2.0), co może zmylić każdego, kto patrzy na stronę Releases. - Wynik zależy od Twojego kodu — Colly daje callbacki, a nie gotowy dataset czy eksport feedu jak Scrapy.
- Async, rate limiting, proxy i backendy kolejki istnieją, ale nie były tu testowane; „szybkość” dotyczy ścieżki ekstrakcji, którą mierzyłem, a nie bezpośredniego benchmarku throughput.
Dla kogo jest Colly, a kto powinien go ominąć
Colly sprawdzi się, jeśli już piszesz w Go i crawlujesz strony oparte na HTML albo JSON, a zależy Ci na szybkości. Jeśli Twoja definicja prostego wdrożenia to skopiowanie jednego binarium na serwer i uruchomienie go — bez interpretera, bez virtualenv, bez losowego rozwiązywania zależności — to narzędzie zostało zbudowane dokładnie pod taki sposób pracy. Model callbacków pokazuje swoją wartość od momentu, gdy ekstrakcja przestaje być trywialna: OnHTML dla struktury, OnResponse dla surowych danych, OnError dla błędów, których inaczej byś nie zobaczył. Dla statycznych stron albo API, które crawlujesz cyklicznie z CI, to mocny i bezproblemowy wybór.
Omiń go, albo przynajmniej dołóż drugie narzędzie, gdy Twoje cele mocno opierają się na JavaScript. Colly zwrócił 0 na każdej stronie renderowanej po stronie klienta, którą mu podałem, i jest to zachowanie zaprojektowane, a nie opcja do przełączenia. Omiń go też, jeśli Twój zespół nie dotyka Go i nie chcesz stawiać toolchaina tylko po to, by scrape’ować kilka stron — to realne zobowiązanie technologiczne i Ty będziesz je utrzymywać. A jeśli wolisz dostać gotowe, ustrukturyzowane dane zamiast samemu pisać kod, który je wyciąga, to w Colly te obowiązki zostają po Twojej stronie.
Alternatywy — gdzie pasuje zarządzane API do scrapingu AI
Colly to darmowa, open-source’owa biblioteka, którą kompilujesz i uruchamiasz samodzielnie. To Ty odpowiadasz za kod w Go, callbacki, logikę crawl i maszynę, na której działa — w zamian nie płacisz za żaden request i trzymasz całą operację we własnej infrastrukturze. Dla zespołu pracującego w Go to sensowna odpowiedź, a wdrożenie w formie jednego binarium jest naprawdę wygodne.
Dwa miejsca, w których Colly się zatrzymuje, są dokładnie tymi, które warto porównać z czymś innym. Po pierwsze, JavaScript — Colly go nie renderuje, więc wszystko, co po stronie klienta, odpada, chyba że dołożysz przeglądarkę. Po drugie, struktura — Colly daje callbacki i zostawia formowanie czystego outputu Twojemu kodowi. Zarządzane API do scrapingu AI odpowiada na oba te problemy inaczej. Zestaw deweloperski Thunderbit obsługuje renderowanie JS i zwraca ustrukturyzowane dane po stronie serwera. POST /distill zamienia stronę w czysty Markdown gotowy dla LLM, a dynamiczna zawartość i anty-bot są obsługiwane za Ciebie. POST /extract zwraca ustrukturyzowany JSON zgodny z definicją JSON Schema, a renderMode możesz podkręcić do pełnego renderowania w przeglądarce, gdy strona tego wymaga. Dla agentów AI i asystentów programistycznych dostępny jest serwer Thunderbit MCP — thunderbit_suggest_fields jest darmowe, więc możesz sprawdzić, co strona udostępnia, zanim się zdecydujesz — a do terminala, CI i crona możesz użyć CLI przez npx @thunderbit/thunderbit-cli.
Wypróbuj Thunderbit do ekstrakcji danych z sieci
Różnica nie polega na tym, co jest lepsze, a co gorsze. Chodzi o to, gdzie leży praca. W Colly renderowanie (czyli jego brak), parsowanie i utrzymanie trzymasz we własnym skompilowanym binarium, bez kosztu za każde wywołanie, ale musisz opiekować się narzędziem, gdy strona zmieni układ. W zarządzanym API oddajesz renderowanie JS, anty-bot i ustrukturyzowany output, a w zamian płacisz za każde wywołanie. Małe cele, natywne dla Go, oparte na HTML albo JSON, które chcesz samemu utrzymywać? Wtedy kontrola i szybkość Colly wygrywają bez dyskusji. Strony mocno oparte na JavaScript albo sytuacje, w których po prostu wolisz dostać JSON zgodny ze schematem zamiast pisać kolejny callback? To argument za podejściem zarządzanym. Jeśli chcesz szerszy obraz rynku, zestawienia najlepszych narzędzi do web scrapingu i najlepszych projektów web scraping na GitHubie pokazują, gdzie biblioteka taka jak Colly stoi obok opcji browser-based i managed.
Werdykt
Czy warto używać Colly? Tak — jeśli piszesz w Go i crawlujesz HTML albo JSON z dużą szybkością, robi dokładnie to, co obiecuje reputacja „szybkiego crawlera”, a teraz za tą reputacją stoją już konkretne liczby. Pełny odzysk danych przy ekstrakcji statycznej. Czysty JSON przez OnResponse. Błąd 500 poprawnie przekierowany do OnError, zamiast zniknąć. Crawl z depth 2, który dotarł do 17 stron. Wszystko to skompilowane do jednego statycznego binarium bez zależności runtime — to chyba najbardziej przyjazny sposób wdrożenia w całej tej kategorii.
Trzeba jednak uczciwie opisać zakres tych twierdzeń. Nie renderuje JavaScriptu — każda strona renderowana po stronie klienta w moim teście zwróciła 0 i to jest stałe, a nie przeoczona opcja w konfiguracji. Wymaga toolchaina Go, więc zespoły spoza ekosystemu Go płacą koszt wejścia z góry. Moduł, który instalujesz (v2.3.0), jest nowszy niż najnowszy tag wydania (v2.2.0), więc nie panikuj, gdy strony pokazują różne numery. A „szybki” w tym przypadku oznacza ścieżkę ekstrakcji, którą zmierzyłem, nie benchmark throughput, którego nie uruchomiłem. W tych granicach Colly jest szybkim, niezawodnym i naprawdę wdrażalnym crawlerem w Go — i zasługuje na swoją reputację dokładnie wtedy, gdy przestajesz wymagać od niego uruchamiania JavaScriptu.
Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free
FAQ
Czy Colly jest naprawdę szybki i czy stoi za tym jakaś konkretna liczba? Jest szybki w tym sensie, który ma znaczenie dla rdzenia, jaki testowałem: kompilowany Go, pełny odzysk danych przy ekstrakcji statycznej (12/12 produktów z katalogu), czysta obsługa JSON i crawl z depth 2, który dotarł do 17 stron — wszystko z jednego statycznego binarium. Nie uruchamiałem natomiast benchmarku przepustowości przeciwko Scrapy, więc traktuj „szybki” jako zmierzone zachowanie ekstrakcji, a nie bezpośredni wynik porównawczy.
Czy Colly potrafi scrape’ować strony renderowane przez JavaScript? Nie. Colly to crawler HTTP — pobiera i parsuje HTML, ale nigdy nie uruchamia przeglądarki. Strona testowa renderowana przez JavaScript zwróciła 0 kart, a publiczna strona Quotes JS również 0. W przypadku treści po stronie klienta musisz połączyć Colly z rendererem albo użyć narzędzia, które ma renderowanie przeglądarkowe wbudowane.
Czy muszę znać Go, żeby używać Colly?
Tak. Colly to biblioteka w Go, a nie samodzielne CLI — importujesz ją, rejestrujesz callbacki (OnHTML, OnResponse, OnError) i kompilujesz. Maszyna, na której testowałem, nie miała zainstalowanego Go, więc konfigurację zaczynałem od doinstalowania toolchaina (1.26.5). Jeśli Twój zespół nie pracuje już w Go, to właśnie to środowisko jest realnym kosztem wejścia.
Dlaczego wersja, którą instaluję, nie zgadza się z najnowszym wydaniem Colly na GitHubie?
Bo moduł Go i tag wydania na GitHubie zdążyły się rozjechać. Najnowszy moduł w Go proxy to v2.3.0 (grudzień 2025), a najnowszy tag wydania na GitHubie to v2.2.0 (marzec 2025). Testowałem v2.3.0. To tylko różnica między modułami a tagami, a nie uszkodzona instalacja.
Czy Colly jest darmowy do użytku komercyjnego? Tak, ma licencję Apache-2.0, więc jest elastyczny i przyjazny komercyjnie. Jak zawsze, przed wdrożeniem sprawdź aktualną licencję w repozytorium.
