Prawie każde zestawienie „najlepszych open-source’owych scraperów” ma ten sam cichy problem: nikt nie uruchamia tych narzędzi na tych samych stronach. Scrapy testuje się na artykule newsowym, Playwrighta na jakimś demo e-commerce, Colly na czymś, co autor akurat miał pod ręką — a potem porównuje się je łeb w łeb, jakby te wyniki w ogóle znaczyły to samo. Taki ranking mówi więcej o stronach niż o narzędziach.
Dlatego zrobiłem rzecz oczywistą, którą większość list pomija. Zbudowałem jeden zestaw fixture’ów i przepuściłem przez niego wszystkie dziewięć narzędzi: statyczny katalog, katalog renderowany przez JavaScript, artykuł ukryty w nawigacji i śmieciach z footera, celowo uszkodzony HTTP 500, mały graf linków wewnętrznych oraz dwa publiczne serwisy ćwiczeniowe. Ta sama prawda referencyjna, te same pomiary, każdy pojedynczy przebieg. Skrypty i surowe wyniki są w publicznym repozytorium benchmarku, więc możesz samodzielnie uruchomić dowolny test. Z tego nie wyszła elegancka tabela liderów, którą obiecują podsumowania — nie ma jednego zwycięzcy. Są trzy różne zadania, a dziewięć narzędzi niemal samo układa się w te kategorie.
Wypróbuj Thunderbit do ekstrakcji danych z internetu
Jak działał test i jaki jeden limit warto powiedzieć głośno
Każde narzędzie dostało te same typy fixture’ów: 12 statycznych produktów rozłożonych na dwie strony, 8 produktów wstrzykiwanych przez JavaScript po opóźnieniu, artykuł otoczony nawigacją i stopką wokół trzech prawdziwych akapitów, celowy błąd serwera 500 oraz graf linków wewnętrznych. To właśnie taki układ sprawia, że wyniki da się porównać — „8/8 dynamicznych produktów” znaczy dokładnie to samo, niezależnie od tego, czy wynik wygenerował Puppeteer, czy Crawlee.
Oto granica, którą większość zestawień pomija. Zestaw fixture’ów dla każdego narzędzia odzwierciedla te same przykłady, więc bezwzględne liczby znaków nie są ściśle porównywalne między narzędziami — traktuj je jako sygnał wewnątrz danego narzędzia, nigdy jako wynik między narzędziami. Porównywalne są natomiast: recall, czyli trafność odczytu (traktuj ją jak wskaźnik), wynik JavaScript pass/fail oraz zachowanie strukturalne. Jedna uwaga w tym samym duchu: w przypadku Crawl4AI test na statycznym katalogu obejmował tylko pierwszą stronę, więc jego 6/6 to pełny recall na węższym wycinku, podczas gdy pozostałe narzędzia crawlowyły obie strony dla 12/12 — mniejszy zakres, a nie częściowe potknięcie. Pełne uzasadnienie, fixture po fixture, znajduje się w opisie metodologii.
Jeszcze jedno zastrzeżenie przed liczbami. Każdy pakiet zawiera też wstępny wynik badawczy, ale celowo nie pokazuję go jako tabeli rankingu. To były wewnętrzne pomocniki do sprawdzania każdego narzędzia względem własnych dowodów, a nie liga mistrzów — publikowanie ich w takiej formie odtworzyłoby dokładnie ten problem pozornej precyzji, którego cały ten eksperyment ma unikać. To synteza tego, co pokazał test, a nie tabela wyników.
Całe pole testowe na jednym polu
Spójrz w dół na dwie kolumny tej tabeli — „Renders JS?” i „Built-in crawl queue” — a trzy zadania praktycznie same się ujawnią.
| Narzędzie | Język | Renderuje JS? | Recall na statycznych stronach | Ustrukturyzowany wynik | Wbudowana kolejka crawl | Ciężar konfiguracji | Licencja |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Tak (browser) | 6/6 (strona 1) | Schemat CSS | BFS/DFS wbudowane | Duży (2 stosy przeglądarkowe) | Apache-2.0 |
| Firecrawl | Samodzielnie hostowane | Tak (playwright-service) | Pełny Markdown | Tak | /v1/crawl | Najcięższy (6 kontenerów) | AGPL-3.0 |
| trafilatura | Python | Nie | 3/3 artykuł | Nie (tylko tekst) | Nie | Lekki | Apache-2.0 |
| Crawlee | Node/TS | Opcjonalnie zależnie od silnika | 12/12 | Przez ekstrakcję | Tak (RequestQueue) | Średni (+~80 MiB) | Apache-2.0 |
| Playwright | Node / wieloplatformowy | Tak | 12/12 | Ręcznie | Nie (BFS pisany ręcznie) | Średni (browser) | Apache-2.0 |
| Puppeteer | Node | Tak (Chrome) | 12/12 | Ręcznie | Nie (BFS pisany ręcznie) | Średni (Chrome) | Apache-2.0 |
| Scrapy | Python | Nie | 12/12 | Eksport feedów (JSON/CSV/XML) | Tak (wbudowana) | Średni (zależności Twisted) | BSD-3 |
| Colly | Go | Nie | 12/12 | Przez callbacki | Kontrola głębokości | Lekki (1 binarka + Go) | Apache-2.0 |
| Scrapling | Python | Nie (fetcher HTTP) | 12/12 | Tak | Nie | Średni ([fetchers]) | BSD-3 |
Uwaga do metadanych w tej tabeli i wszędzie poniżej: liczby gwiazdek i wersje zostały zrzutowane na początku lipca 2026 i szybko się zmieniają. Zanim uznasz je za aktualne, sprawdź je ponownie na GitHubie i stronie pakietu każdego projektu.
Indeks recenzji pojedynczych narzędzi
Każdy projekt w tym zestawieniu ma swoją szczegółową recenzję:
- Recenzja Crawl4AI
- Recenzja Firecrawl
- Recenzja trafilatura
- Porównanie Playwright vs Puppeteer
- Recenzja Crawlee
- Recenzja Scrapy
- Recenzja Colly
- Recenzja Scrapling
Oto ich okładki — plus dwa prawdziwe zrzuty ekranu z testu renderowania JavaScript, żeby twierdzenie o „8/8 dynamicznych” nie było tylko liczbą na stronie.
Zadanie pierwsze: zamienić stronę w tekst gotowy dla LLM
Jeśli chcesz czysty Markdown do zasilenia pipeline’u RAG, walczą o to trzy narzędzia — i każde z nich jest zupełnie inaczej zbudowane.
Crawl4AI to pod marketingową otoczką generator Markdown oparty na przeglądarce. Warto od razu skorygować historię o „adaptive intelligence self-learning selector”, która przewija się w wynikach wyszukiwania: czegoś takiego nie ma — to trik innej biblioteki (wrócę do tego przy Scrapling). To, co faktycznie robi, robi dobrze. Na serwisie Books to Scrape wypluł 13 476 znaków Markdowna, obsługuje ekstrakcję przez schemat CSS dla danych strukturalnych, a jego wbudowany BFS deep crawl przeszedł 5 stron w fixture’ze grafu crawl, jednocześnie renderując stronę JavaScript i robiąc zrzut ekranu. Są jednak dwa istotne minusy. Surowy Markdown niesie ze sobą boilerplate strony, chyba że włączysz filtr treści, a celowy 500 wrócił jako success=false — nie dlatego, że Crawl4AI elegancko przechwycił błąd HTTP, tylko dlatego, że własna heurystyka treści uznała małe ciało błędu za minimal_text ... blocked. Do tego instalacja dokłada dwa stacki przeglądarkowe na dysk. Wersja 0.9.0, Apache-2.0, około 71 tys. gwiazdek na początku lipca.
Firecrawl jest ciężkim zawodnikiem i self-hosting naprawdę działa — mówię „naprawdę”, bo sześciokontenerowy stack (api, playwright-service, redis, rabbitmq, nuq-postgres i foundationdb) faktycznie wstał i wygenerował 9 222 znaki Markdowna gotowego dla LLM z tej samej strony Books to Scrape. Renderował stronę JavaScript przez dołączony playwright-service, a po skrypcie pojawił się cytat Einsteina, co potwierdziło, że render był rzeczywisty. Dwa problemy, na które trafiłem, były po stronie środowiska, nie Firecrawl, i chcę to doprecyzować, żeby nikt nie skopiował złej poprawki: build z kodu źródłowego potknął się o błąd snapshottera containerd pod colima (przeszedłem na prebuilt images), a zakres DNS 198.18.x.x w colima uruchomił zabezpieczenie SSRF w Firecrawl, które odblokowałem przez ALLOW_LOCAL_WEBHOOKS=true — obejście tylko na lokalny development, nie coś do wyłączania w produkcji. Wersja self-hosted core nie ma też Fire-engine, czyli chmurowej warstwy antyblokad, a API chmurowego nie testowałem. Najważniejszy znak ostrzegawczy to licencja: self-hosted core Firecrawl jest na AGPL-3.0, więc przed komercyjnym użyciem trzeba wykonać prawdziwą analizę prawną, a nie machnąć ręką jak na przypis. Około 148 tys. gwiazdek na początku lipca.
trafilatura to w tym gronie kontrarianin i zarazem narzędzie, o którym listy z AI-hype’em ciągle zapominają. Bez przeglądarki. Bez wierszy strukturalnych. Po prostu szybki, czysty tekst artykułu w czystym Pythonie. Na fixture artykułu pobrał tytuł plus wszystkie 3 z 3 prawdziwych akapitów, całkowicie usunął boilerplate — nie przeciekło nic w rodzaju „Login”, „Subscribe” ani „Copyright” — i dodatkowo odzyskał autora oraz datę. Na publicznej stronie produktowej zwrócił 1 324 znaki czystego tekstu. Jego ograniczenie jest dokładnie takie, jak sugeruje projekt: skieruj go na katalog, a odda 12 nazw produktów jako tekst, ale 0 struktur wierszy — tekst jest, struktury nie ma, a JavaScript nie jest renderowany. Wersja 2.1.0 (aktualne wydanie), Apache-2.0, około 6,2 tys. gwiazdek. Do czystej ekstrakcji artykułów to byłby mój pierwszy wybór.
Te dwie liczby znaków Markdowna — 13 476 z Crawl4AI i 9 222 z Firecrawl — pochodzą z tej samej publicznej strony, ale nie odczytuj ich jako różnicy jakości. Pokazują różne strategie Markdowna (ile chrome strony każde narzędzie zachowuje), a nie werdykt, które wyjście jest lepsze. To właśnie wcześniej wspomniana zasada sygnału wewnątrz narzędzia, pokazana tutaj w praktyce.
Zadanie drugie: niezawodnie renderować JavaScript
Część danych po prostu nie istnieje w HTML, dopóki nie uruchomią się skrypty, i wtedy prawdziwa przeglądarka przestaje być opcją, a staje się koniecznością. To zadanie obsługują trzy narzędzia — i dwa z nich okazały się niemal tym samym narzędziem.
Playwright i Puppeteer zremisowały we wszystkich testach, które im rzuciłem. Oba renderowały 8/8 dynamicznych produktów na lokalnym fixture i 10 na publicznej stronie Quotes JS, oba miały 12/12 recall na statycznych stronach i oba poradziły sobie z 500 w czysty sposób (Puppeteer zwraca obiekt odpowiedzi zamiast rzucać wyjątek). Żadne z nich nie ma własnej kolejki crawl, więc oba wymagały ręcznie napisanego BFS do przejścia po grafie 12 stron. Jedyna realna różnica to zasięg: Playwright obsługuje Chromium, Firefox i WebKit oraz mówi po Pythonie i .NET, a Puppeteer jest nastawiony na Chrome i działa tylko w Node. Dwa doprecyzowania, bo wersje zmieniają się tu szybko: testowałem Playwright 1.56.0 na tle aktualnego 1.61.1 i tylko w Chromium, a Puppeteer 24.16.0 na tle aktualnego 25.3.0 — interpretuj wyniki odpowiednio lub powtórz test. Oba Apache-2.0; około 92 tys. i 95 tys. gwiazdek.
Crawlee to narzędzie, które rozwiązuje problem kolejki, pozostawiony otwarty przez tamtą dwójkę. Łączy silnik Cheerio (HTTP) i silnik Playwright (browser) pod jednym API, a kontrast na jednej stronie świetnie pokazuje jego sens: silnik Cheerio zobaczył 0 elementów wstrzykniętych przez JavaScript, a silnik Playwright zobaczył wszystkie 8/8 lokalnie (i 10 na publicznym serwisie), a przełączanie między nimi to zmiana jednej linii. Daje też prawdziwy RequestQueue, dlatego trafia do tej, a nie do trzeciej kategorii. Zastrzeżenie, którego nikt nie pisze w nagłówku: silnik browser wymaga osobnego npx playwright install, czyli około 80 MiB, których npm install crawlee nie pobierze za Ciebie. Wersja 3.17.0, TypeScript, Apache-2.0, około 24,6 tys. gwiazdek.
Zadanie trzecie: szybki crawl bez przeglądarki
Brak JavaScriptu na stronie oznacza, że przeglądarka jest drogim naddatkiem. W tym obszarze rywalizują trzy narzędzia oparte na HTTP, po jednym z każdej filozofii językowej, i różnią się w ciekawy sposób.
Scrapy to najbardziej „inżynieryjny” framework w zestawieniu — spider’y, eksport feedów do JSON/CSV/XML, AutoThrottle i cała reszta. Osiągnął 12/12 recall na statycznych stronach, pobrał 3/3 akapity z artykułu, przeszedł 11 stron w głębokości 0–2 po grafie crawl i przechwycił 500 przez handle_httpstatus_list. Najciekawsze jest jego podejście: nie renderuje, tylko odtwarza żądanie. Wrzucony na stronę JavaScript zwrócił 0 węzłów — a potem API JSON ukryte za tą samą stroną dało mu 8/8. To właśnie filozofia Scrapy w jednym punkcie danych: znajdź request, który wykonuje strona, i go powtórz, zamiast prowadzić przeglądarkę. Kosztem jest spory stos zależności (Twisted, lxml, parsel), a testowałem go tylko na małych fixture’ach. Wersja 2.17.0, BSD-3-Clause, około 63 tys. gwiazdek.
Colly to odpowiedź świata Go i jest odświeżająco dosłowny w tym, czym jest: jedna statyczna binarka, sterowana callbackami OnHTML, OnResponse i OnError, z kontrolą głębokości. Trafił w 12/12 na statycznych stronach, pobrał 8/8 z API JSON przez OnResponse, przechwycił 500 przez OnError i dotarł do 17 stron przy crawl depth 2 — i celowo formułuję to właśnie tak, bo ta liczba stron pochodzi z licznika harnessu, a nie z gwarancji kompletności, którą składa Colly. Czego nie robi, to JavaScript: fixture dynamiczny i strona Quotes JS wróciły jako 0, zgodnie z założeniem. Do buildu potrzebujesz toolchainu Go, a wersja modułu (v2.3.0) jest dziś nowsza niż tagowane wydanie (v2.2.0). Apache-2.0, około 25 tys. gwiazdek.
Scrapling jest specjalistą i w pełni zasługuje na to określenie. Jego adaptacyjne selektory są zbudowane po to, by ponownie odnaleźć element po zmianie markup’u — więc gdy przemianowałem klasę HTML celu z product-name na product-title, zwykły selektor dopasował 0, a adaptacyjne ponowne dopasowanie i tak odzyskało śledzony element. W zwykłej ekstrakcji HTTP osiągnął 12/12 na statycznych stronach i 8/8 na API JSON. Jest jednak ważny niuans, którego nie ukrywa też dokumentacja: w syntetycznym teście z wieloma elementami odzyskał 1 z 3 — to odporne śledzenie elementów, a nie pełne odzyskiwanie, więc nie należy tego przeceniać. Bazowe pip install scrapling wymaga też dodatku [fetchers], żeby w ogóle ruszyć, a jego StealthyFetcher to raczej zastrzeżenie compliance niż funkcja, którą pokazywałbym na slajdzie. Wersja 0.4.10 (aktualne wydanie), BSD-3-Clause, około 68,7 tys. gwiazdek.
Wzorzec ukryty pod trzema zadaniami
Gdy ustawisz te dziewięć narzędzi obok siebie, wychodzi z tego bardzo czytelny obraz. Pełny recall na statycznych stronach — równe 12/12 — to absolutne minimum dla każdego narzędzia opartego na HTTP; żadne nie poległo na łatwym przypadku, więc to nie jest czynnik różnicujący. Narzędzia przeglądarkowe uzasadniają swoją dodatkową wagę tylko wtedy, gdy w grę naprawdę wchodzi JavaScript, a płacą za to każdy na swój sposób: dodatkowym stackiem przeglądarkowym, osobną instalacją albo całym zestawem kontenerów. A kolumna „wbudowana kolejka crawl” to w praktyce granica między frameworkiem a silnikiem — Scrapy i Crawlee dają orkiestrację, a Playwright i Puppeteer każą pisać BFS samemu. Taki jest kształt tego pola. Nikt nie wygrywa ogólnie, bo nikt nie gra w tę samą grę.
Więc które narzędzie naprawdę wybrać
Ten benchmark nie wyłania zwycięzcy, bo poprawna odpowiedź nie brzmi „narzędzie”, tylko „pytanie” — które z trzech zadań wykonujesz?
- Potrzebujesz Markdowna gotowego dla LLM? Sięgnij po trafilatura, jeśli zależy Ci na czystym tekście artykułów; po Crawl4AI, jeśli chcesz dodatkowo ekstrakcję CSS i renderowanie JavaScript w jednej bibliotece; oraz po Firecrawl, jeśli konkretnie potrzebujesz hostowanego samodzielnie serwisu i możesz pogodzić się zarówno z licencją AGPL-3.0, jak i ciężarem sześciu kontenerów.
- Potrzebujesz renderowania JavaScript? Playwright albo Puppeteer do samego renderu — wybierz według silnika i języka, bo poza tym remisują — a Crawlee wtedy, gdy chcesz jeszcze dostać orkiestrację crawl bez pisania jej ręcznie.
- Crawl statycznych stron albo odtwarzalnych API na dużą skalę? Scrapy jako pełny framework Pythona, Colly jako szybkie Go w jednej binarce, a Scrapling wtedy, gdy Twoim konkretnym, powtarzalnym bólem jest odporność na zmiany markup’u.
Dopasuj narzędzie do zadania, a każde z nich będzie rozsądnym wyborem. Weź narzędzie z niewłaściwej kategorii — browser tool do stron statycznych albo parser HTTP do aplikacji JavaScriptowej — i nawet najwyżej oceniana biblioteka w internecie Cię zawiedzie.
Gdzie zamiast tego pasuje zarządzane API AI
Każde narzędzie powyżej jest darmowe, open-source i możesz je uruchamiać u siebie. To jednocześnie wspólny kompromis, który ten benchmark cały czas ujawnia: sam odpowiadasz za środowisko przeglądarki, kod crawl, wyścig z antybotami i całą konserwację. Dla wielu zespołów właśnie o tę kontrolę chodzi, a mapa licencji ma znaczenie, kiedy się na to decydujesz — większość pola ma licencje permisywne (Apache-2.0 dla Crawl4AI, Crawlee, Playwright, Puppeteer i Colly; BSD-3 dla Scrapy i Scrapling), a jedynym elementem wymagającym prawdziwego sprawdzenia przed komercyjnym użyciem jest self-hosted core Firecrawl z AGPL-3.0.
Ale zwróć uwagę na coś jeszcze, co pokazał ten benchmark: czego te narzędzia nie robią. Renderowanie, crawl, strukturyzacja i obchodzenie blokad — rzadko wszystko naraz i nigdy bez Twojej opieki. Zarządzane API do scrapingu z AI zamyka ten stos w jednym wywołaniu. Nasz własny developer surface w Thunderbit to jedna z takich opcji, a dla odbiorców technicznych liczą się przede wszystkim API, serwer MCP i CLI, a nie rozszerzenie przeglądarkowe. POST /distill zwraca czysty Markdown, a POST /extract zwraca JSON według schematu, przy czym renderowanie JavaScript i antybot są obsługiwane po stronie serwera, a nie na Twojej maszynie. Jest też oficjalny serwer MCP dla agentów i asystentów programistycznych — thunderbit_suggest_fields działa za darmo i planuje ekstrakcję, potem thunderbit_distill (1 kredyt) oraz thunderbit_extract (20 kredytów) wykonują robotę — oraz CLI, które możesz uruchomić przez npx @thunderbit/thunderbit-cli do terminala i zadań cron. Dla osób nietechnicznych w zespole jest też no-code’owe rozszerzenie Chrome, a cennik obejmuje oba scenariusze.
Kompromis jest ten sam, wokół którego obraca się cały ten benchmark: samodzielnie uruchamiać i utrzymywać do dziewięciu bibliotek przy zerowym koszcie za wywołanie albo oddać warstwę infrastruktury i płacić za request. Żaden wybór nie jest zły. Wszystko sprowadza się do tego, ile tego stosu naprawdę chcesz posiadać. Jeśli wolisz zobaczyć, jak to wygląda w praktyce, kanał Thunderbit na YouTube pokazuje to krok po kroku.
{{INTERNAL_BLOG_LINKS}}
Werdykt
Nie istnieje jeden najlepszy open-source’owy scraper i każda lista, która z pełnym przekonaniem wskaże Ci jeden, po cichu ukrywa pytanie, które naprawdę decyduje o wyborze: które z trzech zadań wykonujesz? Zamiana strony w tekst, renderowanie JavaScriptu czy szybki crawl bez przeglądarki — rynek układa się właśnie w takie koszyki, a wewnątrz każdego z nich wybór sprowadza się do języka i ciężaru konfiguracji, a nie do jakiegoś uniwersalnego mistrza.
Jeśli masz zapamiętać tylko jeden nawyk, niech będzie to ten: testuj na własnych stronach, zanim na cokolwiek się zdecydujesz. Każda liczba tutaj jest odtwarzalna w repozytorium benchmarku właśnie z tego powodu — bo narzędzie, które wygrywa ogólne zestawienie, i narzędzie, które przeżyje Twoje realne cele, nie zawsze są tym samym.
Wypróbuj Thunderbit do ekstrakcji danych z internetu Get Started Free
FAQ
Jaki jest najlepszy open-source’owy web scraper? Nie ma jednego — wszystko zależy od zadania. Do tekstu gotowego dla LLM: trafilatura lub Crawl4AI; do renderowania JavaScriptu: Playwright, Puppeteer albo Crawlee; do szybkiego crawl po HTTP: Scrapy lub Colly. Na wspólnym polu testowym każde narzędzie było najmocniejsze we własnej kategorii i wyraźnie słabsze poza nią, dlatego rankingi „dla wszystkich” są mylące.
Które open-source’owe scrapery renderują JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer oraz silnik Playwright w Crawlee renderują JavaScript. Scrapy, Colly, trafilatura i domyślny HTTP fetcher w Scrapling tego nie robią — albo potrzebują odtwarzalnego API za stroną (tak jak Scrapy, które pobrało 8/8 z endpointu JSON), albo osobnego trybu przeglądarkowego.
Czy do scrapowania strony potrzebuję headless browsera? Tylko wtedy, gdy dane pojawiają się dopiero po uruchomieniu JavaScriptu. Jeśli zwykły request HTTP plus parser wystarcza do dotarcia do treści, przeglądarka jest drogim naddatkiem — w takim przypadku Scrapy, Colly albo Scrapling będą znacznie lżejsze i szybsze.
Które z tych narzędzi ma najprzyjaźniejszą licencję do zastosowań komercyjnych? Większość ma licencje permisywne: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) lub BSD-3-Clause (Scrapy, Scrapling). Wyjątkiem jest self-hosted core Firecrawl, który działa na AGPL-3.0 i wymaga poważnego sprawdzenia licencyjnego, zanim zbudujesz na nim produkt komercyjny.
Czy te wyniki benchmarku da się odtworzyć? Tak. Każdy runner, fixture i surowy wynik znajduje się w publicznym repozytorium na licencji MIT. Jedno zastrzeżenie, o którym trzeba pamiętać: recall i wyniki strukturalne można porównywać między narzędziami, ale bezwzględne liczby znaków są wyłącznie sygnałem wewnątrz narzędzia, bo każdy pakiet odzwierciedla fixture’y zamiast korzystać z jednej kanonicznej kopii — porównuj więc wskaźniki i pass/fail, a nie surową liczbę znaków.
