Przetestowałem Crawl4AI na pięciu typach stron — w czym błyszczy, a gdzie się potyka

Niektóre porównania scraperów firm trzecich przypisują Crawl4AI funkcję „Adaptive Intelligence” — czyli selektory, które uczą się struktury strony i same się naprawiają po zmianach w kodzie HTML. W testowanym API nie znalazłem takiego działania. Crawl4AI oferuje za to generowanie Markdown z użyciem przeglądarki oraz ekstrakcję przez CSS/XPath. Scrapling udostępnia osobną funkcję adaptacyjnych selektorów, ale w granicach opisanych we własnej recenzji.

Sprawdziłem Crawl4AI 0.9.0 na pięciu typach stron z ustalonym wzorcem odniesienia: statycznym katalogu, katalogu renderowanym przez JavaScript, artykule z dużą ilością boilerplate, celowo zwróconym błędzie 500 oraz grafie wielostronicowym po linkach. Testowane ścieżki Markdown i schematu zwracały oczekiwaną zawartość fixture. Surowy Markdown zawierał boilerplate, głębokie crawlowanie wymagało dopasowanych do strony opóźnień, a zwykły błąd 500 dostał etykietę błędu sugerującą anty-bot.

Czym Crawl4AI naprawdę jest

Zacznijmy od rzeczy, którą najczęściej myli się już na etapie instalacji. Crawl4AI to nie mały parser w Pythonie. Pierwsze crawl4ai-setup po cichu pobiera dwa pełne stosy przeglądarkowe — Playwright i Patchright — i gdy to zrozumiesz, cały sens narzędzia staje się jasny: to kontrolowana bezgłowa przeglądarka z konwerterem do Markdown na wierzchu, tylko ubrana jak scraper.

Oficjalnie to otwartoźródłowa biblioteka na licencji Apache-2.0 do zamiany stron WWW na Markdown na potrzeby pipeline’ów RAG, agentów i przepływów danych. Testowałem v0.9.0. Do podstawowych elementów należą AsyncWebCrawler, BrowserConfig, CrawlerRunConfig, generowanie Markdown oraz strategie ekstrakcji oparte o CSS/XPath albo LLM — zgodnie z oficjalnym szybkim startem.

Najważniejszy jest taki model działania. Większość bibliotek parsujących wysyła żądanie HTTP i analizuje odebrane bajty; Crawl4AI uruchamia prawdziwą przeglądarkę. Renderowanie w przeglądarce jest wbudowane, co sprawia, że instalacja jest cięższa niż w przypadku czystego parsera HTTP, a niezawodna ekstrakcja z elementów renderowanych asynchronicznie może nadal wymagać jawnego oczekiwania. Nic z testów nie przepisywało selektorów po redesignie. O „samonaprawiających się” selektorach lepiej myśleć jako o błędnym wniosku z porównania innej firmy, dopóki nie pojawi się konkretne oficjalne źródło i powtarzalne API.

Kluczowe funkcje i to, jak działają pod maską

Ścieżka jednej strony jest tu najważniejsza. Wskazujesz AsyncWebCrawler na URL, narzędzie ładuje stronę w przeglądarce i zwraca Markdown. Na oficjalnym przykładzie example.com ten pełny cykl zajął 1,81 s i zwrócił czysty status 200. Nic efektownego, ale potwierdza, że minimalna ścieżka działa niemal bez konfiguracji — bez schematu, bez oczekiwania, bez ustawień przeglądarki.

Samouczek wideo (1:02:38): Crawl4AI Official Tutorial, Full 1hr with Quickstart Examples.

Ekstrakcja ustrukturyzowana to drugi filar i najbliższa rzecz temu, co Crawl4AI robi w kierunku „rozumienia” strony — choć tak naprawdę nie chodzi o inferencję, tylko o schemat, który sam tworzysz. Zamiast wypluwać wyłącznie Markdown, podajesz schemat CSS przez JsonCssExtractionStrategy i dostajesz obiekty JSON z dokładnie tymi polami, o które prosisz. Na moim lokalnym statycznym katalogu zwrócił 6 czystych rekordów JSON — nazwa produktu, kategoria, cena, ocena, URL szczegółów — zgodnie ze wszystkimi 6 oczekiwanymi produktami. To różnica między „oto strona jako tekst” a „oto dane w wierszach”, a Crawl4AI potrafi zrobić jedno i drugie w ramach tego samego przejścia. Selektory trzeba jednak zdefiniować samemu; narzędzie dopasowuje się do tego, co mu podasz, ale nie odgaduje schematu za Ciebie.

Renderowanie dynamiczne to miejsce, gdzie przewaga przeglądarki naprawdę się zwraca. Wskaż katalog renderowany przez JavaScript z wait_for="css:.product-card", a Crawl4AI poczeka, aż zakończy się render po stronie klienta, zanim zacznie ekstrakcję. Dało to 8/8 trafienia produktów zarówno w Markdown, jak i w wyjściu schematu na moim lokalnym teście JS, w około 1,56 s. Na publicznej stronie Quotes to Scrape JS narzędzie zebrało wyrenderowane cytaty i zapisało użyteczny zrzut ekranu — treści, których zwykłe żądanie HTTP nigdy by nie zobaczyło, bo w początkowym HTML po prostu ich nie ma.

Potem dochodzi skala i crawlowanie. arun_many() uruchomił sześć lokalnych stron szczegółów równolegle z pełnym 6/6 trafieniem w 3,76 s. Crawl4AI ma też strategie deep crawl — BFS, DFS, BestFirst — które przechodzą po grafie linków z limitami głębokości, liczbą stron, filtrowaniem i scoringiem. Deep crawl BFS przeszedł po grafie linków mojej testowej strony głównej i pobrał pięć stron. To właśnie tutaj marketing i rzeczywistość zaczynają się rozchodzić, a wrócę do tego niżej.

Konfiguracja: ten fragment, którego nikt nie wkleja we wstępniak README

Instalacja na moim sprzęcie była z jednej strony płynniejsza, niż się spodziewałem, a z drugiej cięższa. pip install -U crawl4ai i test dymny zakończyły się sukcesem na Pythonie 3.14.2 na macOS arm64. Specyfikacja >=3.10 w PyPI już obejmuje 3.14; ten wynik potwierdza tylko testowaną instalację i przepływ pracy, nie szerszą kompatybilność.

Największy koszt pojawia się na etapie konfiguracji. crawl4ai-setup pobiera zasoby przeglądarkowe dla Playwright i Patchright — Chrome for Testing, FFmpeg, Headless Shell. Jeśli pracujesz na laptopie z małą ilością miejsca albo na łączu z limitem transferu, to realny koszt, a dokumentacja wspomina o tym mimochodem, zamiast od razu to wyeksponować. Następnie crawl4ai-doctor przeszedł pomyślnie i zeskrobał crawl4ai.com w 14,65 s, co jest dobrym testem typu smoke end-to-end, ale nie benchmarkiem czegokolwiek — nie wyciągałbym z tej liczby wniosków o szybkości.

Wniosek do własnej oceny konfiguracji: uwzględnij pobieranie przeglądarek, nie tylko samo pip install. To bliżej uruchamiania środowiska headless browser niż dodawania biblioteki do skryptu. Na dysk trafiają dwa stosy przeglądarkowe, zanim pobierzesz choć jedną prawdziwą stronę, i to jednorazowy koszt, który ponosisz niezależnie od tego, czy Twoje zadanie kiedykolwiek skorzysta ze stealth layer Patchright.

Praktyka: co się sprawdziło, a co warto zaznaczyć

Cztery wyniki warto zapisać dokładnie, bo to właśnie ten rodzaj niuansu, który strona marketingowa zwykle wygładza — a w jednym przypadku wręcz błędnie opisuje.

Dwie publiczne strony demonstracyjne też przeszły ścieżkę happy path. Na stronie głównej Books to Scrape Crawl4AI wygenerował 13 476 znaków Markdown w 2,43 s. Publiczna strona Quotes JS zwróciła 1 666 znaków renderowanego Markdown w około 3,1 s. Ani jedno, ani drugie nie mówi nam nic pewnego o skali, wrogich witrynach, długiej stabilności, sesjach, proxy, ponownych próbach czy zużyciu pamięci.

Fixture artykułu pokazuje zastrzeżenie dotyczące jakości Markdown. Crawl4AI zebrał tytuł i wszystkie 3/3 akapity treści — to dobrze. Ale surowy Markdown zachował też tekst nawigacji, linki powiązane, linię subskrypcji i stopkę. To nie błąd; bez filtra treści albo docelowego selektora „zamień tę stronę na Markdown” oznacza po prostu całą stronę. Wniosek: trzeba odróżnić surową konwersję Markdown od czystej ekstrakcji artykułu. Jeśli zależy Ci na tej drugiej, sięgniesz po filtr treści, np. PruningContentFilter, albo po selektor docelowy — tego jednak jeszcze nie testowałem wystarczająco mocno, więc nie będę podawał dla niego liczby czystości.

Uszkodzona strona dała najbardziej wymowny wynik. Serwowałem celowy HTTP 500 z krótką treścią. Crawl4AI zwrócił success=false i status 500 — poprawnie — ale komunikat błędu opisał to jako „Blocked by anti-bot protection: Structural: minimal_text on small page.” Nie było żadnej zapory anty-bot. To była mała strona błędu. Heurystyka strukturalna Crawl4AI zobaczyła bardzo mało widocznego tekstu i sięgnęła po wyjaśnienie związane z anty-botem. Dla każdego, kto buduje na tym rozwiązaniu, ma to znaczenie: nie ufaj etykiecie „anti-bot” bez sprawdzenia. Najpierw przejrzyj status code i faktyczną odpowiedź, zanim uznasz, że witryna Cię blokuje. Surowy wynik jest w repo benchmarków pod results/local_failure_500.json.

Deep crawling wymaga świadomej konfiguracji. Bezpośredni crawl dynamicznej strony z wait_for działał bez problemu, natomiast deep crawl BFS wykrył katalog dynamiczny i zakończył się niepowodzeniem. Klasyfikacja jako minimal-text pasuje do odczytu strony zanim renderowały się karty, a deep crawl nie przejął ustawienia wait z bezpośredniego przejścia. Z pięciu stron trzy zakończyły się sukcesem, dwie porażką. Ponieważ nie pokazano tu ponownego uruchomienia z konfiguracją wait, to wyjaśnienie pozostaje wnioskiem, a nie dowiedzioną przyczyną.

Jak wyglądają liczby

To są czasy testów dymnych, a nie benchmark wydajności: artykuł nie podaje sprzętu, liczby powtórzeń, stanu warm/cold, stanu cache, kontroli współbieżności ani odchyleń. Pokazują jedynie, że wymienione przepływy pracy zakończyły się na tym komputerze. Pełne artefakty uruchomień znajdują się w katalogu repo benchmarku.

Jeśli chcesz wykonać porównanie na poziomie decyzyjnym, powtórz każdy przepływ w świeżych i ponownie użytych sesjach przeglądarki, raportuj rozkłady zamiast jednej wartości do jednego miejsca po przecinku, zablokuj wersje przeglądarek i zapisz CPU, pamięć, stan cache oraz współbieżność. Dopiero to oddzieli narzut biblioteki od startu przeglądarki i wahań sieci.

Zalety i wady

Zalety:

• Jedna biblioteka robi surowy Markdown i ustrukturyzowany JSON oparty na schemacie CSS — nie trzeba składać dwóch narzędzi.
• Renderowanie w przeglądarce jest wbudowane; strony renderowane asynchronicznie mogą wymagać jawnego wait_for.
• Testowane workflow dla pojedynczej strony zakończyły się w obserwowanych czasach; nie formułuję tu żadnej porównawczej deklaracji szybkości.
• Licencja Apache-2.0 — przyjazna komercyjnie, bez niespodzianek związanych z copyleft.
• Aktywny projekt z nowszym wydaniem i dużą, zaangażowaną społecznością.

Wady:

• Ciężka pierwsza konfiguracja (dwa stosy przeglądarkowe), co we wstępie jest trochę niedopowiedziane.
• Surowy Markdown zawiera boilerplate, jeśli nie ustawisz filtrów treści.
• Deep crawling nie czeka automatycznie na dynamiczne strony — trzeba to skonfigurować dla każdego crawl albo pojawią się błędy.
• Komunikaty błędów mogą błędnie opisywać zwykły błąd jako „anti-bot”, co w logach jest mylące.
• Brak samoadaptujących się selektorów, mimo tego, co sugerują niektóre porównania — schematy są pisane ręcznie i statyczne.
• Sam utrzymujesz środowisko przeglądarkowe, wraz z aktualizacjami i naprawą awarii.

Dla kogo to jest — a kto powinien odpuścić

Crawl4AI warto rozważyć, jeśli jesteś deweloperem budującym pipeline RAG lub agenta, dobrze czujesz się w środowisku headless browser i chcesz z tego samego crawl uzyskać Markdown oraz ustrukturyzowany JSON. Testy nie obejmowały odporności na wrogie witryny, długiej stabilności, pamięci, sesji, ponownych prób, proxy ani wdrożenia produkcyjnego, więc rekomendacja dotyczy wyłącznie przepływów pracy, które tutaj sprawdzono.

Pomiń to — albo przynajmniej się zatrzymaj — jeśli szukałeś małego, lekkiego parsera HTTP (to dokładne przeciwieństwo), jeśli nie możesz przeznaczyć miejsca i transferu na pobranie przeglądarek albo jeśli nie chcesz brać na siebie utrzymania stosu przeglądarkowego w produkcji. I szczególnie odpuść, jeśli przyszedłeś po selektory samonaprawiające się: to nie jest to narzędzie, a budowanie procesu wokół funkcji, której nie ma, później się mści. Do czystej ekstrakcji tekstu artykułów z usuniętym boilerplate lżejsze narzędzie zaprojektowane właśnie do tego może sprawdzić się lepiej.

Alternatywy, w tym miejsce Thunderbit

Uczciwe ujęcie: Crawl4AI to darmowa, otwartoźródłowa biblioteka, którą hostujesz i utrzymujesz sam. Dostajesz pełną kontrolę i brak opłat licencyjnych dla dostawcy, ale nadal płacisz za compute, transfer, storage, aktualizacje przeglądarki, schematy i pracę operacyjną.

Na drugim końcu jest zarządzana usługa scrapingowa, taka jak Thunderbit, gdzie pobieranie i ekstrakcja działają przez API. Thunderbit nie był uruchamiany na tych fixture’ach, więc ten artykuł nie stawia porównywalnych twierdzeń o renderowaniu, obsłudze anty-botów, CAPTCHA, dokładności czy szybkości. Istotne porównanie dotyczy odpowiedzialności operacyjnej: sam hostujesz bibliotekę opartą na przeglądarce albo płacisz usłudze za utrzymanie tej warstwy.

Różnica sprowadza się do tego, kto uruchamia przeglądarkę. W Crawl4AI sam odpowiadasz za renderowanie, oczekiwanie, schematy i utrzymanie. W zarządzanym API płacisz za wywołania i przenosisz część odpowiedzialności operacyjnej na dostawcę. Ten eksperyment nie porównywał obu ścieżek pod kątem wyników.

Powiązane recenzje benchmarkowe: pełne porównanie otwartoźródłowych scraperów, recenzja self-hosted Firecrawl oraz recenzja ekstrakcji artykułów w trafilatura.

Wypróbuj Thunderbit do ekstrakcji danych z WWW

Werdykt

Crawl4AI to rozsądny kandydat, jeśli chcesz otwartoźródłowej ekstrakcji opartej na przeglądarce, która generuje Markdown i JSON o strukturze schematu, a jednocześnie jesteś gotów sam utrzymywać środowisko przeglądarkowe. Bezpośrednie workflow dla statycznych stron i dynamicznych stron z ustawionym wait zakończyły się sukcesem na tych fixture’ach. Apache-2.0 daje dużą swobodę, choć standardowa analiza zależności i dystrybucji nadal obowiązuje.

Zapewnij budżet na zasoby przeglądarkowe. Surowy Markdown wymaga filtrowania, zanim stanie się czystym artykułem. Oczekiwanie w deep crawl trzeba konfigurować świadomie, a log, który mówi „anti-bot”, należy sprawdzić względem status code i odpowiedzi. Selektory schematu nadal musisz pisać i utrzymywać sam. To właśnie testowane granice decyzji; skala produkcyjna i zachowanie wobec wrogich witryn pozostają otwartymi pytaniami.

Wypróbuj Thunderbit do ekstrakcji danych z WWW Get Started Free

FAQ

Czy Crawl4AI ma adaptacyjne albo samonaprawiające się selektory? Nie. Mimo że niektóre porównania przypisują mu „adaptive intelligence”, Crawl4AI dopasowuje się do schematu CSS/XPath, który napiszesz — nie tworzy fingerprintu elementów i nie odnajduje ich ponownie po zmianie HTML. W testach ekstrakcja strukturalna osiągnęła 6/6 i 8/8 trafień przy schematach przygotowanych ręcznie. Jeśli witryna zmieni klasy CSS, schemat przestaje działać, dopóki go nie zaktualizujesz. Samonaprawiające się śledzenie elementów to funkcja innej biblioteki, nie tej.

Dlaczego instalacja jest taka duża? crawl4ai-setup pobiera pełne zasoby przeglądarkowe dla Playwright i Patchright — Chrome for Testing, FFmpeg i Headless Shell. To cena za prawdziwe renderowanie w przeglądarce. Trzeba zarezerwować miejsce na dysku i transfer; jest to cięższe niż czysty parser HTTP, a koszt ponosisz nawet wtedy, gdy w Twoim procesie nigdy nie używasz stealth stack.

Czy Crawl4AI obsługuje strony renderowane przez JavaScript? Tak, bo steruje prawdziwą bezgłową przeglądarką. W testach dynamiczny katalog z wait_for="css:.product-card" zwrócił pełne 8/8 trafień produktu, a publiczna strona Quotes JS renderowała się poprawnie. Zastrzeżenie jest takie, że deep crawl nie stosuje automatycznie tego wait do odkrytych stron — BFS zakończył się niepowodzeniem na dynamicznej stronie, którą znalazł, bo nie poczekał. Czekanie konfigurujesz samodzielnie dla każdego crawl.

Czy Crawl4AI zwraca czysty tekst artykułu czy całą stronę? Domyślnie całą stronę. W testach zebrał wszystkie akapity treści, ale zachował też nawigację, linki powiązane i stopkę. Do czystej ekstrakcji artykułu trzeba użyć filtra treści (np. PruningContentFilter) albo selektora docelowego, zamiast polegać wyłącznie na surowym Markdown.

Czy można ufać komunikatom błędów Crawl4AI? Trzeba podchodzić do nich z rezerwą. Celowa strona 500 z krótką treścią została oznaczona jako „Blocked by anti-bot protection” wyłącznie z powodu heurystyki opartej na małej ilości widocznego tekstu — nie było żadnej bariery anty-bot. Surowy wynik znajduje się w repo benchmarku. Zawsze sprawdź rzeczywisty kod statusu HTTP i treść odpowiedzi, zanim uznasz, że witryna Cię blokuje.