Według raportu 2025 State of Open Source aż 96% organizacji zwiększyło albo utrzymało poziom korzystania z open source w ubiegłym roku — a główny powód nadal pozostaje ten sam: „brak kosztów licencji”. Jest jednak jedna rzecz, o której prawie nikt nie mówi, gdy pobierasz scraper z GitHuba: „open source” i „bezpieczne do użycia w produkcie komercyjnym” to nie to samo.
W tym roku poświęciłem sporo czasu na porządkowanie najpopularniejszych rozwiązań — Scrapy, Playwright, Puppeteer oraz nowszych, natywnie AI projektów jak Crawl4AI i ScrapeGraphAI — i wyszło na jaw, że najważniejsza kwestia z perspektywy biznesu niemal nigdy nie pojawia się w typowych rankingach „najlepszych scraperów”: typ licencji. Większość zestawień układa narzędzia według liczby gwiazdek na GitHubie. Ja oceniam je według tego, co dzieje się wtedy, gdy dział prawny pyta: „chwila, a to jest AGPL?”. Ta lista porządkuje 12 narzędzi najpierw według dopasowania do kategorii (parsery, automatyzacja przeglądarki, AI-native scrapery, frameworki crawlingowe, rozszerzenia no-code), a dopiero potem według licencji, bo właśnie tak wyglądają realne decyzje.
Dlaczego typ licencji to pierwszy filtr przy wyborze open source web scrapera
„Open source” nie znaczy „możesz robić z tym, co chcesz”. Definicja Open Source wprost zakazuje dyskryminacji wobec zastosowań komercyjnych — dlatego każde narzędzie na tej liście wolno wykorzystywać biznesowo. Ale jak możesz z niego korzystać i jakie obowiązki uruchamiają się w momencie wdrożenia, zależy już wyłącznie od konkretnej licencji.
Licencje permisywne — MIT, BSD-3-Clause, Apache-2.0 — pozwalają praktycznie na wszystko, o ile zachowasz informację o prawach autorskich. Apache-2.0 idzie krok dalej, bo zawiera wyraźną zgodę patentową, którą prawnicy zwykle cenią najbardziej. Żadna z tych trzech nie wymaga publikowania własnego kodu źródłowego.
Licencje copyleft to zupełnie inna historia. AGPL-3.0 to ta, która najczęściej wywołuje zamieszanie, i właśnie na niej działa self-hosted core Firecrawl (SDK są MIT, ale sam silnik scrapujący jest AGPL). Zgodnie z sekcją 13 AGPL-3.0, jeśli zmodyfikujesz objęty program i pozwolisz użytkownikom korzystać z tej zmienionej wersji przez sieć, musisz udostępnić im odpowiadający kod źródłowy. To nie jest mechanizm typu „całe SaaS automatycznie staje się open source”, jak czasem opisują to internetowe fora — obowiązek dotyczy konkretnie zmodyfikowanego programu udostępnianego do zdalnej interakcji. Mimo to jest to realna kwestia prawna, która wymaga porady specjalisty, a nie wątku na Stack Overflow, zanim zbudujesz na tym zamknięty produkt.
Jest też bardziej niejednoznaczna kategoria „open-core”. Web Scraper, czyli rozszerzenie do Chrome, ma historyczne repozytorium LGPL-3.0 na GitHubie — ale ostatni commit w tym repo pochodzi z 2017 roku i nie ma zweryfikowanego powiązania między tamtym źródłem a obecnym rozszerzeniem w Chrome Web Store (wersja 1.111.13 w momencie pisania). Uczciwy wniosek jest taki: lokalne rozszerzenie jest darmowe, warstwa Cloud z harmonogramami i rotacją proxy to osobny, zamknięty produkt, a określanie całości jako „open source” zaciera tę różnicę.
Jak porównywałem te 12 najlepszych open source web scraperów
Oceniłem każde narzędzie według siedmiu kryteriów: typ licencji i tarcie przy użyciu komercyjnym, język/runtime, natywna obsługa renderowania JavaScript (w porównaniu z koniecznością dołączania wtyczki), próg wejścia, ukryty koszt obliczeniowy lub koszt proxy, sygnały zdrowia społeczności (otwarte issue, tempo wydań, ostatni commit) oraz najlepszy scenariusz użycia.
Lista jest pogrupowana według kategorii — statyczne parsery, frameworki automatyzacji przeglądarki, AI-native scrapery, frameworki crawlingowe, a na końcu jedyne rozszerzenie no-code — zamiast być ułożona wyłącznie według liczby gwiazdek. To świadoma decyzja. Beautiful Soup i Scrapy rozwiązują zupełnie różne problemy, mimo że oba są bardzo popularne; ocenianie ich według jednego kryterium tak naprawdę nikomu nie pomaga wybrać narzędzia.
| Kryterium | Co sprawdzałem |
|---|---|
| Licencja i dopasowanie do zastosowań komercyjnych | Dokładna licencja repozytorium, wymagania dotyczące atrybucji, klauzule copyleft i network |
| Runtime i dopasowanie do zespołu | Python, Node/TypeScript, Java albo obsługa wielojęzyczna |
| Renderowanie JS | Natywna obsługa przeglądarki vs. dołączana wtyczka vs. brak |
| Zakres frameworka | Tylko parser, sterownik przeglądarki, pełny pipeline crawl, czy produkt zarządzany |
| Kondycja społeczności | Gwiazdki na GitHubie, data ostatniego wydania, otwarte issue, ostatni push |
| Ukryty koszt | Zużycie pamięci przeglądarki, potrzeba proxy, zależność od API modelu, koszty utrzymania |
| Najlepsze dopasowanie | Konkretne dopasowanie do zespołu lub zadania, poparte dokumentacją albo issue |
Jedna uczciwa uwaga dotycząca metryk kondycji społeczności: oficjalny rozwój Beautiful Soup odbywa się na Launchpadzie, a nie na GitHubie, więc liczba gwiazdek na GitHubie (nieoficjalne lustrzane repo z 223 gwiazdkami i ostatnią aktywnością w 2022 roku) nie jest porównywalna z pozostałymi 10 narzędziami. Zaznaczam to wprost niżej zamiast udawać, że mieści się to w tej samej tabeli.
Najlepsza biblioteka open source do parsowania statycznych stron: BeautifulSoup
BeautifulSoup to biblioteka Pythona do przeglądania i przeszukiwania drzew HTML/XML. Nie pobiera stron, nie uruchamia JavaScriptu i nie zarządza kolejkami crawl — po prostu bierze markup, który już masz, i pozwala wygodnie wydobywać z niego dane. To wąskie zastosowanie jest właśnie jej siłą: sięgasz po nią wtedy, gdy HTML już masz, a potrzebujesz tylko wyciągnąć z niego informacje.
- Licencja: MIT — permisywna, bez obowiązków poza zachowaniem informacji o prawach
- Próg wejścia: naprawdę przyjazny dla początkujących; model obiektowy jest wyrozumiały
- Renderowanie JS: brak, natywnie — trzeba sparować z narzędziem, które najpierw pobierze wyrenderowany HTML
- Znane ograniczenie: oficjalna dokumentacja przyznaje, że „nigdy nie będzie tak szybki jak parsery, na których bazuje”, a różne backendy parsera (lxml, html5lib, html.parser) mogą dawać zauważalnie różne drzewa dla wadliwego HTML
Najlepsze zastosowanie: szybkie wewnętrzne skrypty i jednorazowe wyciąganie danych ze statycznego albo już pobranego HTML — nie do skali i nie do stron mocno opartych na JS.
Najlepszy open source framework automatyzacji przeglądarki do starszych testów cross-browser: Selenium
Selenium to najstarsza nazwa na tej liście, pierwotnie stworzona do testów przeglądarek, a później przejęta przez sporą część świata scrapingu. Jego najmocniejszą stroną nie jest szybkość, lecz zasięg. Oficjalne bindingi Selenium 4 obejmują Java, Python, C#, Ruby i JavaScript, a narzędzie steruje Chrome, Edge, Firefox i Safari poprzez standard W3C WebDriver.
- Licencja: Apache-2.0
- Kondycja GitHuba: 34 366 gwiazdek, 98 otwartych issue, 12 stabilnych wydań w ostatnim roku (najnowsze: 4.47.0)
- Renderowanie JS: natywne, przez prawdziwą przeglądarkę
- Udokumentowane tarcie: dokumentacja Selenium wskazuje synchronizację jako „jedno z najczęstszych wyzwań” — gotowość dokumentu nie oznacza, że elementy dodawane przez JS są już gotowe, a dynamiczne odświeżenie DOM wywoła
StaleElementReferenceException
Najlepsze zastosowanie: zespoły potrzebujące obsługi wielu przeglądarek lub wielu języków albo takie, które i tak używają Selenium do QA i chcą wykorzystać te same kompetencje do scrapingu.
Najlepszy open source framework automatyzacji przeglądarki dla nowoczesnych stron intensywnie korzystających z JS: Playwright
Playwright, rozwijany przez Microsoft, to nowoczesna odpowiedź na „Selenium jest wolne i toporne”. Natywnie automatyzuje Chromium, Firefox i WebKit, a dzięki sprawdzaniu actionability czeka automatycznie, aż elementy rzeczywiście będą gotowe — widoczne, stabilne i aktywne — zanim zacznie z nimi pracować. Samo to zachowanie eliminuje mnóstwo ręcznie pisanych przez użytkowników Selenium konstrukcji WebDriverWait.
Jest tu jednak ważny niuans, który ginie w każdym wątku „Scrapy vs. Playwright vs. Selenium”: Scrapy samo z siebie w ogóle nie renderuje JavaScriptu. Potrzebuje osobnej wtyczki — scrapy-playwright — żeby dołożyć renderowanie przeglądarkowe. Playwright i Puppeteer renderują natywnie, bo renderowanie jest ich podstawową funkcją.
- Licencja: Apache-2.0
- Kondycja GitHuba: 94 443 gwiazdki, 15 stabilnych wydań w ostatnim roku (najnowsze: 1.62.1)
- Ukryty koszt: same binaria przeglądarek zajmują około 281 MB dla Chromium, 187 MB dla Firefox i 180 MB dla WebKit — a zmiana w 1.38 zatrzymała automatyczne pobieranie przeglądarek, więc wersjonowanie obrazu Docker ma znaczenie
Najlepsze zastosowanie: zespoły scrapujące aplikacje SPA w React/Vue, które potrzebują niezawodnego działania cross-browser bez ręcznego budowania logiki oczekiwania.
Najlepsze open source narzędzie automatyzacji przeglądarki do projektów skupionych na Chrome: Puppeteer
Puppeteer, własna biblioteka automatyzacji Google, jest zaprojektowana przede wszystkim pod Chrome — głęboka integracja z Chrome DevTools Protocol, wbudowane generowanie screenshotów i PDF-ów, i tak dalej. Warto tu poprawić przestarzałe założenie: obecna wersja Puppeteer oficjalnie wspiera też stabilnego Firefox, więc „tylko Chrome” nie jest już do końca prawdą, choć Chrome nadal pozostaje głównym use case.
- Licencja: Apache-2.0
- Kondycja GitHuba: 95 458 gwiazdek, 249 otwartych issue — zauważalnie więcej niż w przypadku Playwrighta, co warto uwzględnić, jeśli patrzysz na responsywność projektu
- Realność anty-bot: issue #7006 w Puppeteer dokumentuje całkowicie normalną nawigację trafiającą na challenge Cloudflare — samo renderowanie strony nie czyni cię niewidzialnym dla systemów anty-bot
Najlepsze zastosowanie: zespoły Node.js oparte na Chrome, szczególnie jeśli poza scrapingiem potrzebują też generowania PDF-ów i zrzutów ekranu.
Najlepszy open source scraper AI-native do pipeline’ów LLM i RAG: Crawl4AI
Crawl4AI działa pod spodem na Playwright i został stworzony z myślą o czystym Markdown dla pipeline’ów LLM i RAG, zamiast surowego HTML. Obsługuje tryb „clean Markdown” oraz tryb „Fit Markdown” zoptymalizowany pod okna kontekstu, a opcjonalnie także ekstrakcję z użyciem LLM — przy czym filtrowanie CSS/XPath i BM25 działa bez potrzeby odwoływania się do API modelu.
Warto tu precyzyjnie zaznaczyć jedną rzecz: GitHub oznacza repo jako Apache-2.0, ale rzeczywisty plik licencji dodaje obowiązkową atrybucję przy publicznym użyciu i dystrybucji. To nie jest standardowe Apache-2.0 — to Apache-2.0 plus warunek specyficzny dla projektu, dlatego trzeba czytać sam plik licencji, a nie tylko plakietkę w panelu GitHuba.
- Kondycja GitHuba: 77 959 gwiazdek, najnowsze wydanie v0.9.2 (lipiec 2026)
- Wymagania zasobowe: instrukcja self-hostingu zaleca co najmniej 4 GB RAM dostępnych dla kontenera
- Udokumentowana niestabilność: changelog v0.9.0 odnotował breaking changes w domyślnych ustawieniach uwierzytelniania serwera Docker i przeniesienie modułów — to narzędzie szybko się zmienia, wersje trzeba przypinać
Najlepsze zastosowanie: zespoły Python zasilające świeżymi danymi webowymi agentów LLM lub pipeline’y RAG, które mogą samodzielnie utrzymywać infrastrukturę przeglądarkową.
Najlepszy open source scraper AI-native do wdrożeń self-hosted z haczykiem licencyjnym: Firecrawl
Self-hosted core Firecrawl to miejsce, w którym rozmowa o AGPL staje się bardzo konkretna. To crawler API-first, który zwraca Markdown, HTML, zrzuty ekranu i dane strukturalne — naprawdę potężny zestaw możliwości, oparty na Fetch i Playwright. Jednak dopracowanie, z którym wielu osobom kojarzy się „Firecrawl” — zarządzane obchodzenie zabezpieczeń anty-bot, rotacja proxy, warstwa stealth Fire-engine — należy do Firecrawl Cloud, a nie do self-hosted repo. Dokumentacja self-hostingowa Firecrawl mówi wprost, że Fire-engine i zaawansowane zachowania anty-bot nie są włączone w domyślnym self-hosted stacku, a screenshoty i działania na stronie tego wymagają.
- Licencja: głównie AGPL-3.0-or-later dla core, MIT dla SDK
- Kondycja GitHuba: 166 527 gwiazdek — naprawdę ogromna liczba w tej kategorii
- Rzeczywistość wdrożeniowa: self-hosting oznacza postawienie Redis, RabbitMQ, PostgreSQL i opcjonalnie FoundationDB — to operacja wieloserwisowa, a nie jeden kontener
Najlepsze zastosowanie: narzędzia wewnętrzne lub projekty open source, które akceptują obowiązek udostępniania źródeł wynikający z AGPL. Dwa razy zastanów się, zanim zbudujesz na tym zamknięty produkt komercyjny bez konsultacji prawnej.
Najlepszy open source scraper AI-native do ekstrakcji w języku naturalnym: ScrapeGraphAI
ScrapeGraphAI pozwala opisać, czego potrzebujesz, zwykłym językiem zamiast pisać selektory — to pipeline oparty na grafie, w którym to wywołania LLM wykonują mapowanie pól. Biblioteka na licencji MIT korzysta z twojej własnej infrastruktury: twojego klucza API do LLM (albo lokalnego modelu Ollama, jeśli wolisz ominąć koszt tokenów) oraz skonfigurowanej instancji Playwright.
I tu trzeba nazwać rzecz po imieniu: „open source” nie oznacza tu „brak kosztów w czasie”. Każda ekstrakcja zużywa tokeny w modelu, który podłączysz. A ekstrakcja oparta na promptach ma też specyficzny tryb awarii, którego nie mają narzędzia selector-based: jeden z otwartych problemów opisuje pipeline, który przechodzi wszystkie etapy, ale zwraca puste wartości albo NA dla danych widocznych na stronie — czyli cichy błąd, którego deterministyczne CSS/XPath po prostu nie generują.
- Licencja: MIT
- Kondycja GitHuba: 29 447 gwiazdek, najnowsza stabilna wersja v2.1.6
Najlepsze zastosowanie: nieregularne, jednorazowe zadania ekstrakcji, w których elastyczność promptów jest ważniejsza niż koszt modelu i walidacja wyników.
Najlepszy lekki open source scraper AI-native bez modelu: AutoScraper
AutoScraper całkowicie pomija LLM. Podajesz URL i przykładową wartość, którą chcesz wyciągnąć; narzędzie wnioskuje reguły strukturalne ze strony i ponownie stosuje je do podobnych stron. Bez klucza API do modelu, bez kosztów tokenów — pod spodem działa po prostu requests i BeautifulSoup.
Uważaj na etykietkę „porzucony projekt”, którą niektóre wątki na forach przypinają temu narzędziu. To nie jest trafne: w połowie 2025 roku pojawiały się realne commity, a ostatni push do repo był w lipcu 2026. Natomiast paczkowana wersja, którą użytkownicy faktycznie instalują przez pip, nadal ma numer v1.1.14 z 2022 roku. Uczciwy opis brzmi więc: „wolne tempo wydawania paczek”, a nie „martwy projekt”.
- Licencja: MIT
- Kondycja GitHuba: 7 844 gwiazdki
- Twarde ograniczenie: brak natywnego renderowania JS — narzędzie wywołuje
requests.get()i parsuje to, co wróci w HTML, bez żadnych wyjątków
Najlepsze zastosowanie: małe, powtarzalne zadania ekstrakcji na stabilnych statycznych stronach, gdzie można co jakiś czas ponownie nauczyć reguły po redesignie.
Najlepszy open source framework crawl do dużych projektów w Pythonie: Scrapy
Scrapy to produkcyjny framework crawl dla Pythona — silnik, scheduler, downloader, item pipeline i cała reszta. Jeśli Beautiful Soup jest skalpelem, to Scrapy jest całą salą operacyjną: asynchroniczna sieć, kontrola współbieżności per domena, AutoThrottle i eksporty prosto do CSV, JSON, JSON Lines, XML albo do storage w chmurze.
Niuans, o którym wspomniałem wcześniej, warto powtórzyć, bo to największe źródło nieporozumień wokół Scrapy: Scrapy nie ma natywnego renderowania JavaScriptu. Dokumentacja Scrapy zaleca najpierw znaleźć i odtworzyć źródłowe żądanie z danymi — bo zwykle jest to szybsze i pełniejsze niż renderowanie całej przeglądarki — a scrapy-playwright zostawić na sytuacje, gdy przeglądarka jest naprawdę nieunikniona.
- Licencja: BSD-3-Clause
- Kondycja GitHuba: 63 830 gwiazdek, 304 otwarte issue, 9 stabilnych wydań w ostatnim roku (najnowsze: 2.17.0)
- Luka w obsłudze rate limitów: otwarty request o ulepszenie wskazuje, że AutoThrottle dostraja się do opóźnienia, a nie do kodu HTTP 429 — backoff uwzględniający odpowiedzi musisz zbudować sam
Najlepsze zastosowanie: duże crawle statycznych stron, gdzie ważniejsze są strukturalne pipeline’y i elastyczny eksport niż renderowanie JS.
Najlepszy open source framework crawl do produkcyjnych wdrożeń w Node.js: Crawlee
Crawlee od zespołu Apify to najbliższy odpowiednik Scrapy w świecie Node/TypeScript — z tą różnicą, że renderowanie JavaScriptu nie jest doczepiane później, tylko wbudowane od początku poprzez klasy crawlerów oparte na Playwright i Puppeteer, działające pod wspólną warstwą kolejki, storage i rotacji proxy.
- Licencja: Apache-2.0
- Kondycja GitHuba: 25 364 gwiazdki, 8 stabilnych wydań w ostatnim roku (najnowsze: 3.18.1)
- Sprytny detal:
AutoscaledPooldynamicznie dostosowuje współbieżność na podstawie bieżącego obciążenia CPU, pamięci i event loop — a dokumentacja wyraźnie ostrzega, że zbyt wysoka minimalna współbieżność może wysadzić cały crawl
Najlepsze zastosowanie: zespoły Node.js/TypeScript, które chcą produkcyjnego zarządzania kolejką i renderowania JS bez samodzielnego składania odpowiednika Scrapy z osobnych komponentów.
Najlepszy open source framework crawl do indeksowania w Javie na poziomie enterprise: Apache Nutch
Apache Nutch jest odstępstwem od reguły na tej liście — to crawler w Javie zbudowany do indeksowania internetu na dużą skalę, zwykle zasilający Solr, Elasticsearch albo OpenSearch. To nie jest narzędzie do wyciągania cen produktów z konkurencyjnego sklepu; to narzędzie, po które sięgają zespoły search, gdy budują warstwę crawl pod wyszukiwarkę.
- Licencja: Apache-2.0
- Kondycja GitHuba: tylko 3 276 gwiazdek, ale ostatni push był jeszcze w sierpniu 2026 — niski wynik gwiazdek odzwierciedla niszowość, a nie zaniedbanie
- Obsługa JS: wymaga osobnej wtyczki
protocol-selenium; ticket JIRA dokumentuje awarię HTTPS proxy właśnie w tej ścieżce
Najlepsze zastosowanie: zespoły już działające na infrastrukturze Java/Hadoop, które potrzebują indeksowania webowego na skalę enterprise, a nie doraźnego wyciągania danych.
Najlepsze no-code open source rozszerzenie do przeglądarki: Web Scraper
Web Scraper to opcja typu point-and-click — generator sitemap i drzewa selektorów działający w Chrome DevTools. Obsługuje paginację, klika przyciski, przewija strony z nieskończonym ładowaniem i eksportuje lokalnie do CSV/XLSX, wszystko bez jednej linijki kodu.
W tym przypadku podział open-core ma większe znaczenie niż prawie wszędzie indziej na tej liście. Lokalne wyciąganie danych jest naprawdę darmowe. Ale planowanie, uruchamianie w chmurze, dostęp do API i zarządzanie proxy są w Web Scraper Cloud, czyli osobnym, płatnym produkcie. A jak wspomniano wcześniej, publicznie dostępne repo źródłowe LGPL-3.0 nie miało commita od 2017 roku — więc „open source” traktuj tu jako historyczne pochodzenie lokalnego rozszerzenia, a nie gwarancję tego, co działa w dzisiejszej wersji z Chrome Web Store.
Najlepsze zastosowanie: pojedyncze osoby lub małe zespoły wykonujące okazjonalne, lokalne ekstrakcje, które nie chcą pisać kodu i nie potrzebują skali.
Statyczne parsery vs. headless browsers: jak wybrać właściwe narzędzie dla stron ciężkich od JS
Warto oprzeć to na jednym konkretnym danych: 98,9% stron używa JavaScriptu jako języka po stronie klienta. Ten wynik jest jednak często błędnie interpretowany jako „98,9% stron wymaga headless browsera do scrapingu” — a to nie jest to samo. Mierzy on obecność JavaScriptu, a nie to, czy interesujące cię dane są już w początkowym HTML, czy pojawiają się dopiero po wykonaniu skryptów.
To właśnie jest prawdziwy punkt decyzyjny. Jeśli podzielisz 12 narzędzi na dwie uczciwe grupy:
Statyczne parsery — BeautifulSoup, AutoScraper — są szybkie, tanie i całkowicie ślepe na wszystko, co renderuje się po stronie klienta. Jeśli dane, których potrzebujesz, są w początkowej odpowiedzi HTML albo w endpointcie JSON, do którego możesz się odwołać bezpośrednio, te narzędzia wygrywają zawsze pod względem szybkości i prostoty.
Frameworki oparte na headless browserze — Playwright, Puppeteer, Selenium, przeglądarkowe crawlery Crawlee — rzeczywiście wykonują JavaScript, co oznacza realny koszt obliczeniowy. Dane HTTP Archive z 2024 roku pokazują medianę payloadu JavaScript na poziomie 558 KB na mobile i 22 osobne requesty JS — to właśnie ta praca, którą headless browser musi przetrawić przy każdym pojedynczym załadowaniu strony, podczas gdy statyczny parser po prostu pobiera surowy HTML.
A Scrapy pozostaje w dziwnym środku, o którym warto jeszcze raz wspomnieć: nie jest ani jednym, ani drugim. To pełny framework crawl bez natywnego renderowania, który wymaga dołożenia scrapy-playwright, jeśli w ogóle potrzebujesz JS.
Ukryty koszt „darmowego”: proxy, compute i godziny utrzymania
Cena licencji równa zero to tylko jeden składnik całkowitego kosztu, a nie cała historia. Rzeczywisty model kosztów podzieliłbym na kilka konkretnych obszarów:
Compute. Uruchamianie headless browserów na dużą skalę oznacza płacenie za sekundy pracy przeglądarki, a nie tylko za czas serwera. AWS Fargate nalicza około 0,000011244 USD za vCPU-second i 0,000001235 USD za GB-second dla Linux/x86 — pomnóż to przez liczbę równoległych instancji Playwrighta, a koszty rosną szybciej, niż większość osób się spodziewa.
Proxy. Oficjalne stawki Bright Data pokazywały proxy residential od około 5 USD/GB, a datacenter od 0,9 USD/IP — a „bandwidth” w takich modelach obejmuje zarówno ruch wychodzący, jak i odpowiedzi, a nie tylko to, co pobierasz. To właśnie ta pozycja potrafi zaskoczyć zespoły: omijanie limitów i blokad nie jest darmowe, tylko regularnie pojawia się w budżecie infrastruktury.
Utrzymanie. Każdy statyczny parser i każdy tool oparty na regułach strukturalnych na tej liście jest podatny na redesign strony, który psuje selektory. Samo README AutoScraper wymagało aktualizacji ceny po zmianach na stronie docelowej. To właśnie ta kategoria „ukrytego kosztu compute/proxy”, o której żaden znacznik licencji $0 nie wspomina — godziny inżynierów spędzone na naprawianiu broken extraction po tym, jak zespół po stronie docelowej wypuści redesign.
Dla zespołów, które ciągle wpadają na tę samą ścianę — selektory pękają, zarządzanie kontami proxy jest uciążliwe, a overhead DevOps zdaje się nie kończyć — self-hosted open source stack nie zawsze jest tańszą opcją, kiedy policzysz godziny inżynierskie. Rozszerzenie Chrome od Thunderbit podchodzi do tego inaczej dla osób nietechnicznych: wskazujesz autoryzowaną stronę, klikasz One Click Extract, a narzędzie analizuje stronę i samo ustala, co wyciągnąć — bez selektorów, bez skryptu do utrzymania, gdy zmienia się układ. To nie zastąpi Scrapy na poziomie frameworka crawl, ale jest rozsądnym kolejnym krokiem dla użytkownika biznesowego, który ręcznie utrzymuje kruchy zestaw reguł AutoScraper.
Ramy decyzyjne: jak dopasować narzędzie do ograniczeń twojego zespołu
Większość porównań kończy się na „najlepsze do X”. To tylko jedna zmienna. W praktyce zespoły żonglują co najmniej czterema naraz: potrzeba renderowania JS × język zespołu × wymagany format wyjścia × ograniczenie licencyjne.
| Sytuacja zespołu | Najlepsze narzędzie / narzędzia | Dlaczego |
|---|---|---|
| Python, statyczny HTML, szybki skrypt | BeautifulSoup, AutoScraper | Bez JS, licencja MIT, minimalna konfiguracja |
| Python, duży strukturalny crawl | Scrapy | BSD-3-Clause, wbudowane pipeline’y, scrapy-playwright tylko gdy JS jest naprawdę potrzebny |
| Node/TypeScript, produkcyjny crawl z JS | Crawlee | Apache-2.0, natywna obsługa przeglądarki wbudowana w system kolejek |
| Wielojęzyczność, szeroka macierz przeglądarek | Selenium | Apache-2.0, najszersze pokrycie języków i przeglądarek |
| Nowoczesna automatyzacja SPA, cross-browser | Playwright | Apache-2.0, natywne renderowanie, auto-wait wbudowany |
| Automatyzacja w Chrome z screenshotami/PDF | Puppeteer | Apache-2.0, głęboka integracja z CDP |
| Pipeline Markdown dla LLM/RAG | Crawl4AI | Apache-2.0 + klauzula atrybucji; sprawdź zgodność z tolerancją działu prawnego na dodatkowy warunek |
| Ekstrakcja prompt-driven, nieregularna | ScrapeGraphAI | MIT, ale uwzględnij koszt tokenów LLM |
| Self-hosted crawler dopasowany do API, tolerujący AGPL | Firecrawl | AGPL-3.0-or-later; uzyskaj zgodę prawną przed budową zamkniętego SaaS na tej podstawie |
| Indeksowanie enterprise w Javie/Hadoop | Apache Nutch | Apache-2.0, stworzony z myślą o infrastrukturze wyszukiwarki |
| No-code, okazjonalne użycie przez osoby nietechniczne | rozszerzenie Web Scraper | Lokalnie darmowe; zrozum podział open-core, zanim założysz pełną transparentność |
Porównanie wszystkich 12 open source web scraperów obok siebie
| Narzędzie | Język | Licencja | Bezpieczne do użycia komercyjnego? | Renderowanie JS | Próg wejścia | Najlepsze do |
|---|---|---|---|---|---|---|
| BeautifulSoup | Python | MIT | ✅ Tak | Brak (wymaga sparowania) | Niski | Parsowanie statycznego HTML |
| Selenium | Wielojęzyczne | Apache-2.0 | ✅ Tak | Natywne | Średni | Testy i scraping w wielu przeglądarkach/językach |
| Playwright | JS/TS/Python/Java/.NET | Apache-2.0 | ✅ Tak | Natywne | Średni | Nowoczesne strony ciężkie od JS |
| Puppeteer | Node.js/TS | Apache-2.0 | ✅ Tak | Natywne | Średni | Automatyzacja skupiona na Chrome |
| Crawl4AI | Python | Apache-2.0 + klauzula atrybucji | ⚠️ Sprawdź klauzulę | Natywne (przez Playwright) | Średni | Pipeline Markdown dla LLM/RAG |
| Firecrawl (self-hosted) | TypeScript | AGPL-3.0-or-later (core) | ⚠️ Warunkowo | Natywne (przez Playwright) | Wysoki (wiele serwisów) | Self-hosted AI crawling, tolerujący AGPL |
| ScrapeGraphAI | Python | MIT | ✅ Tak | Natywne (przez Playwright) | Średni | Ekstrakcja w języku naturalnym |
| AutoScraper | Python | MIT | ✅ Tak | Brak | Niski | Lekkie, powtarzalne zadania na statycznych stronach |
| Scrapy | Python | BSD-3-Clause | ✅ Tak | Wymaga sparowania | Wysoki | Duże crawle statycznych stron |
| Crawlee | Node.js/TS | Apache-2.0 | ✅ Tak | Natywne | Średni | Produkcyjne crawlery Node.js |
| Apache Nutch | Java | Apache-2.0 | ✅ Tak | Wymaga wtyczki | Wysoki | Indeksowanie dla enterprise search |
| Web Scraper (rozszerzenie) | N/D (no-code) | open-core | ⚠️ Zależnie od planu | Natywne (żywa przeglądarka) | Niski | Okazjonalne użycie przez osoby nietechniczne |
Podsumowanie: którego open source web scrapera powinieneś użyć?
Nie ma jednego „najlepszego” narzędzia — właściwa odpowiedź zależy od ograniczeń licencyjnych, języka twojego zespołu i tego, czy dane docelowe siedzą w statycznym HTML, czy za ścianą JavaScriptu. Scrapy wygrywa przy dużych crawlach statycznych w Pythonie. Playwright albo Crawlee wygrywają, gdy renderowanie JS jest nie do negocjacji. Crawl4AI pasuje, jeśli zasilasz pipeline LLM, z zastrzeżeniem, że w pliku licencji ma dodatkową klauzulę atrybucji, którą warto szybko przeczytać. Self-hosted core Firecrawl jest potężny, ale wiąże się z rozmową o AGPL, w której dział prawny powinien uczestniczyć, a nie być pomijany.
A jeśli utrzymanie selektorów i zarządzanie proxy zjada więcej godzin inżynierskich niż sam scraping, to zwykle znak, że czas przyjrzeć się alternatywie no-code, takiej jak Thunderbit, zamiast dokładać kolejną warstwę do self-hosted stacka OSS.
FAQ o open source web scraperach
Czy używanie open source web scraperów do zbierania danych biznesowych jest legalne?
Zwykle pobieranie publicznie dostępnych danych wiąże się z mniejszym ryzykiem niż scraping za logowaniem lub paywallem, ale nie oznacza to automatycznie legalności w każdym przypadku. Zawsze sprawdzaj regulamin strony docelowej i plik robots.txt — choć pamiętaj, że robots.txt jest protokołem prośby, a nie mechanizmem autoryzacji, więc przestrzeganie go to dobra praktyka, ale samo w sobie nie stanowi zgody prawnej. Przepisy o ochronie danych, takie jak GDPR, również obowiązują niezależnie od tego, czy dane są publicznie widoczne. To nie jest porada prawna — przy czymkolwiek więcej niż okazjonalne, niskonakładowe użycie skonsultuj się z prawnikiem.
Czy „open source” oznacza, że narzędzie można bezpłatnie wykorzystywać komercyjnie?
Tak, w tym sensie, że Definicja Open Source zabrania licencjom dyskryminacji zastosowań komercyjnych. Ale „można używać komercyjnie” i „bez żadnych obowiązków” to dwie różne rzeczy — AGPL-3.0 (używana przez self-hosted core Firecrawl) pozwala na użycie komercyjne, ale nadal wymaga udostępnienia odpowiadającego źródła dla zmodyfikowanych wersji udostępnianych przez sieć. MIT, BSD i Apache-2.0 takiego obowiązku nie mają.
Jaka jest różnica między open source scraperem a no-code narzędziem do scrapingu?
Open source scrapery, takie jak Scrapy, Playwright czy BeautifulSoup, wymagają napisania kodu, zarządzania infrastrukturą i samodzielnego ogarnięcia logiki crawl, proxy i eksportów. Narzędzia no-code, takie jak rozszerzenie Web Scraper do Chrome albo rozszerzenie Thunderbit, obsługują wykrywanie pól i ekstrakcję przez interfejs wizualny albo analizę strony wspieraną przez AI, zamieniając część elastyczności na znacznie niższy próg wejścia.
Który open source web scraper jest najlepszy dla osób nietechnicznych?
Prawie każde narzędzie z tej listy — Scrapy, Playwright, Puppeteer, Crawlee i pozostałe — zakłada umiejętność programowania. Dla użytkowników nietechnicznych rozszerzenie Web Scraper do Chrome oferuje konfigurację typu point-and-click, choć planowanie zadań i funkcje chmurowe są dostępne dopiero w płatnej wersji. Bardziej praktycznym punktem startowym będzie no-code narzędzie agentowe, takie jak rozszerzenie Thunderbit, jeśli chcesz automatycznego wykrywania pól bez grzebania w selektorach.
Dlaczego Scrapy potrzebuje osobnej wtyczki do renderowania JavaScriptu?
Scrapy został zbudowany jako framework HTTP-first — wysyła żądania i parsuje to, co wraca w HTML, bez wykonywania skryptów po stronie klienta. Ta architektura sprawia, że jest szybki i lekki przy crawlach statycznych stron, ale oznacza też, że treści renderowane przez JavaScript po prostu nie ma w odpowiedzi, którą Scrapy otrzymuje. scrapy-playwright wypełnia tę lukę, przekierowując konkretne żądania przez rzeczywistą instancję Playwrighta wtedy, gdy renderowanie jest nieuniknione.
Dowiedz się więcej
- 15 najlepszych projektów web scrapingowych na GitHubie w 2026 roku, plus najlepsza alternatywa no-code
- Crawl4AI uruchamia prawdziwą przeglądarkę, żeby tworzyć Markdown — i nie, nie naprawi za ciebie selektorów
- Przetestowałem Playwright i Puppeteer w tych samych testach scrapingu
- Top 10 no-code web scraperów do zautomatyzowanych rozwiązań
- Czy web scraping jest nielegalny? Zrozumienie konsekwencji prawnych
