Aproape toate articolele de tip „cel mai bun scraper open-source” au aceeași hibă discretă: nimeni nu rulează instrumentele pe aceleași pagini. Scrapy e testat pe un articol de știri, Playwright pe un demo e-commerce, Colly pe ce avea autorul la îndemână — apoi sunt comparate direct, ca și cum acele cifre ar însemna același lucru. De fapt, acel clasament îți spune mai mult despre pagini decât despre instrumente.
Așa că am făcut lucrul evident, dar ignorat de majoritatea listelor. Am construit un singur set de fișiere de test și am împins toate cele nouă instrumente prin el: un catalog static, un catalog randat cu JavaScript, un articol ascuns în spatele meniului și al footerului, un răspuns HTTP 500 intenționat, un mic graf de crawl cu linkuri interne, plus două site-uri publice de practică. Aceeași sursă de adevăr, aceleași măsurători, de fiecare dată. Scripturile și rezultatele brute sunt într-un singur repo public de benchmark, ca să poți rerula totul singur. Ce a ieșit nu e clasamentul ordonat promis de roundup-uri — nu există un câștigător unic. Există trei tipuri diferite de sarcini, iar cele nouă instrumente se așază aproape singure în ele.
Încearcă Thunderbit pentru extragerea datelor web
Cum a funcționat testul și singura limită pe care o spun pe față
Toate instrumentele au trecut prin aceleași forme de test: 12 produse statice împărțite pe două pagini, 8 produse injectate prin JavaScript după o întârziere, un articol înconjurat de conținut de navigație și footer peste trei paragrafe reale, un 500 de server intenționat și un graf de linkuri interne. Exact asta face rezultatele comparabile — „8/8 produse dinamice” înseamnă același lucru, indiferent dacă au fost obținute cu Puppeteer sau Crawlee.
Iată însă limita pe care majoritatea roundup-urilor o sar: pachetele fiecărui instrument oglindesc propriile versiuni ale acestor fișiere de test, deci numărătoarea absolută de caractere nu este strict comparabilă între instrumente — citește-le ca semnale în interiorul aceluiași instrument, nu ca scoruri între instrumente diferite. Cifrele care sunt comparabile sunt recall-ul (tratează-l ca rată), trecerea/eșecul pe JavaScript și comportamentul structural. O precizare similară: rularea Crawl4AI pe catalogul static a acoperit doar prima pagină, deci 6/6 înseamnă recall complet pe un segment mai restrâns, în timp ce celelalte instrumente au parcurs ambele pagini pentru 12/12 — un scop mai mic, nu o omisiune parțială. Raționamentul complet, test cu test, se află în documentația metodologiei.
Încă o precizare înainte de cifre. Fiecare pachet conține și un scor provizoriu de cercetare, dar am ales să nu îl public sub forma unui tabel ierarhic. A fost un ajutor intern ca să verific fiecare instrument în raport cu propriile dovezi, nu un clasament — iar publicarea lui ca atare ar recrea exact problema de „falsă precizie” pe care acest exercițiu vrea s-o evite. Aceasta este o sinteză a ceea ce a arătat testul, nu un tabel de medalii.
Tot câmpul de instrumente, pe un singur banc de test
Citește cele două coloane din tabelul de mai jos — „Randează JS?” și „Coada de crawl integrată” — și cele trei tipuri de sarcini devin evidente.
| Instrument | Limbaj | Randează JS? | Recall static | Output structurat | Coada de crawl integrată | Complexitate de instalare | Licență |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Da (browser) | 6/6 (pagina 1) | schemă CSS | BFS/DFS integrat | Greu (2 stack-uri de browser) | Apache-2.0 |
| Firecrawl | Self-hosted | Da (playwright-service) | Markdown complet | Da | /v1/crawl | Cel mai greu (6 containere) | AGPL-3.0 |
| trafilatura | Python | Nu | 3/3 articol | Nu (doar text) | Nu | Ușor | Apache-2.0 |
| Crawlee | Node/TS | Opțional, în funcție de motor | 12/12 | Prin extragere | Da (RequestQueue) | Mediu (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Da | 12/12 | Manual | Nu (BFS scris manual) | Mediu (browser) | Apache-2.0 |
| Puppeteer | Node | Da (Chrome) | 12/12 | Manual | Nu (BFS scris manual) | Mediu (Chrome) | Apache-2.0 |
| Scrapy | Python | Nu | 12/12 | Feed export (JSON/CSV/XML) | Da (integrat) | Mediu (dependențe Twisted) | BSD-3 |
| Colly | Go | Nu | 12/12 | Prin callback-uri | Control pe adâncime | Ușor (1 binar + Go) | Apache-2.0 |
| Scrapling | Python | Nu (fetcher HTTP) | 12/12 | Da | Nu | Mediu ([fetchers]) | BSD-3 |
O notă despre metadatele din tabel și din restul articolului: numărul de stele și versiunile au fost capturate la începutul lui iulie 2026, iar ambele se schimbă rapid. Verifică-le pe GitHub și pe pagina de pachet a fiecărui proiect înainte să le tratezi ca actuale.
Indexul recenziilor pentru fiecare instrument
Fiecare proiect din acest roundup are și o recenzie detaliată dedicată:
- Recenzie Crawl4AI
- Recenzie Firecrawl
- Recenzie trafilatura
- Comparație Playwright vs Puppeteer
- Recenzie Crawlee
- Recenzie Scrapy
- Recenzie Colly
- Recenzie Scrapling
Aici sunt coperțile lor — plus două capturi reale din testul de randare JavaScript, ca să nu rămână „8/8 dinamic” doar o cifră pe pagină.
Sarcina 1: transformă o pagină în text pregătit pentru LLM
Dacă vrei Markdown curat pentru un pipeline RAG, trei instrumente intră în luptă — și nu ar putea fi mai diferite ca abordare.
Crawl4AI este, dincolo de marketing, un generator de Markdown bazat pe browser. Merită demolată povestea cu „adaptive intelligence self-learning selector” care apare prin rezultate: nu are așa ceva — asta e o caracteristică a unei alte biblioteci (mai multe despre asta când ajungem la Scrapling). Ce face efectiv, face bine. Pe site-ul de practică Books to Scrape a scos 13.476 de caractere de Markdown, suportă extragerea bazată pe schemă CSS pentru date structurate și crawlerul său BFS integrat a parcurs 5 pagini în graful de crawl, în timp ce a randat o pagină JavaScript și a salvat o captură de ecran. Două minusuri reale, totuși. Markdown-ul brut păstrează boilerplate-ul paginii dacă nu activezi un filtru de conținut, iar răspunsul 500 intenționat a revenit ca success=false — nu pentru că Crawl4AI ar fi prins curat eroarea HTTP, ci pentru că propria sa euristică de conținut a văzut corpul mic al erorii și l-a etichetat drept minimal_text ... blocked. Și instalarea îți adaugă două stack-uri de browser pe disc. Versiunea 0.9.0, Apache-2.0, aproximativ 71k stele la început de iulie.
Firecrawl este greul din grup, iar self-hosting-ul chiar funcționează — spun „chiar” pentru că stack-ul cu șase containere (api, playwright-service, redis, rabbitmq, nuq-postgres și foundationdb) a pornit efectiv și a generat 9.222 de caractere de Markdown pregătit pentru LLM din aceeași pagină Books to Scrape. A randat o pagină JavaScript prin playwright-service-ul inclus, iar citatul Einstein apărut după script a fost prezent în output, ceea ce a dovedit că randarea era reală. Două probleme pe care le-am întâmpinat au ținut de mediu, nu de Firecrawl, și vreau să fiu precis ca să nu copieze nimeni fixul greșit: un build din sursă a dat peste o eroare flaky de snapshotter containerd sub colima (am trecut la imaginile prebuild), iar intervalul DNS 198.18.x.x al colima a declanșat protecția SSRF din Firecrawl, pe care am rezolvat-o cu ALLOW_LOCAL_WEBHOOKS=true — un workaround pentru dezvoltare locală, nu ceva de dezactivat într-o implementare reală. Componenta self-hosted de bază nu include nici Fire-engine, stratul anti-block din cloud, iar API-ul cloud nu l-am testat. Steagul cel mai mare rămâne licența: nucleul self-hosted al Firecrawl este AGPL-3.0, ceea ce înseamnă muncă juridică serioasă înainte de orice utilizare comercială, nu o notă de subsol. Cam 148k stele la început de iulie.
trafilatura este contrarianul grupului și exact instrumentul pe care listele cu hype AI îl uită mereu. Fără browser. Fără rânduri structurate. Doar text de articol curat și rapid, în Python pur. Pe fișierul de test pentru articol a extras titlul plus toate cele 3 din cele 3 paragrafe reale, a eliminat complet boilerplate-ul — nu a scăpat nici „Login”, nici „Subscribe”, nici „Copyright” — și a recuperat și autorul și data. Pe o pagină publică de produs a returnat 1.324 de caractere de text curat. Limita lui este exact ce sugerează designul: dacă îl pui pe un catalog, îți dă 12 nume de produse ca text, dar 0 rânduri structurate — text există, structură nu, iar JavaScript nu îl randează deloc. Versiunea 2.1.0 (versiunea curentă), Apache-2.0, aproximativ 6,2k stele. Pentru extragerea pură de articole, este primul pe care l-aș folosi.
Cele două numărători de caractere din Markdown — 13.476 de la Crawl4AI și 9.222 de la Firecrawl — provin din aceeași pagină publică, dar nu le citi ca diferență de calitate. Ele reflectă strategii diferite de Markdown (cât din chrome-ul paginii păstrează fiecare), nu un verdict despre care output e mai bun. Aceasta este regula semnalului în interiorul aceluiași instrument, spusă mai devreme, aplicată la vedere.
Sarcina 2: randarea fiabilă a JavaScriptului
Unele date nu există în HTML până nu rulează scripturile, iar aici un browser real nu mai e opțional. Trei instrumente acoperă această sarcină — iar două dintre ele s-au dovedit aproape același instrument.
Playwright și Puppeteer au ieșit la egalitate în toate testele pe care le-am rulat. Ambele au randat 8/8 produse dinamice pe fișierul local și 10 pe site-ul public Quotes JS, ambele au atins 12/12 la recall static și ambele au gestionat corect 500-ul (Puppeteer întoarce un obiect de răspuns în loc să arunce o excepție). Niciunul nu vine cu o coadă de crawl, așa că ambele au avut nevoie de un BFS scris manual pentru a parcurge graful de linkuri de 12 pagini. Singura diferență reală este acoperirea: Playwright controlează Chromium, Firefox și WebKit și vorbește Python și .NET, în timp ce Puppeteer e orientat întâi spre Chrome și doar Node. Două precizări, pentru că versiunile se mișcă repede aici: am testat Playwright 1.56.0 față de un 1.61.1 actual și am folosit doar Chromium, iar Puppeteer 24.16.0 față de un 25.3.0 actual — rerulează sau ajustează în consecință. Ambele Apache-2.0; aproximativ 92k și 95k stele, respectiv.
Crawlee este cel care rezolvă problema cozii pe care celelalte două o lasă deschisă. Împachetează un motor Cheerio (HTTP) și unul Playwright (browser) sub aceeași API, iar contrastul pe o singură pagină spune tot: motorul Cheerio a văzut 0 elemente injectate prin JavaScript, motorul Playwright le-a văzut pe toate 8/8 local (și 10 pe site-ul public), iar trecerea între ele se face printr-o singură linie. Îți oferă și un RequestQueue real, motivul pentru care intră în această sarcină și nu în a treia. Călcâiul lui Ahile pe care nimeni nu-l pune în titlu: motorul de browser necesită un npx playwright install separat, cam 80 MiB pe care npm install crawlee nu le descarcă pentru tine. Versiunea 3.17.0, TypeScript, Apache-2.0, în jur de 24.6k stele.
Sarcina 3: crawl rapid, fără browser
Dacă nu există JavaScript pe pagină, un browser e o risipă costisitoare. Trei instrumente HTTP-first concurează aici, câte unul pentru fiecare filozofie de limbaj, și au diferențe interesante.
Scrapy este framework-ul de nivel ingineresc din grup — spiders, exporturi feed în JSON/CSV/XML, AutoThrottle, toate cele. A obținut 12/12 la recall static, a extras cele 3/3 paragrafe din articol, a parcurs 11 pagini pe adâncimile 0–2 în graful de crawl și a prins răspunsul 500 prin handle_httpstatus_list. Partea interesantă e filosofia lui: nu randează, reproduce cererea. Dacă îl pui pe pagina JavaScript, obține 0 noduri — iar apoi API-ul JSON din spatele aceleiași pagini îi livrează 8/8. Asta este filosofia Scrapy într-un singur punct de date: găsește cererea pe care o face pagina și reexecut-o, nu conduce un browser. Costul este un stack de dependențe considerabil (Twisted, lxml, parsel), iar eu l-am testat doar pe fișiere de test mici. Versiunea 2.17.0, BSD-3-Clause, aproximativ 63k stele.
Colly este răspunsul din lumea Go și spune foarte direct ce este: un singur binar static, condus prin callback-uri OnHTML, OnResponse și OnError, cu control pe adâncime. A nimerit 12/12 la recall static, a extras 8/8 din API-ul JSON prin OnResponse, a prins 500-ul prin OnError și a ajuns la 17 pagini într-un crawl cu adâncime 2 — iar formularea asta e exactă, pentru că acel număr de pagini este contorul propriu al harness-ului, nu o garanție de completitudine oferită de Colly. Ce nu face este JavaScript: fișierul dinamic și site-ul Quotes JS au revenit ambele cu 0, intenționat. Ai nevoie de toolchain Go pentru build, iar versiunea de modul (v2.3.0) este în prezent înaintea release-ului etichetat (v2.2.0). Apache-2.0, aproximativ 25k stele.
Scrapling este specialistul și își merită eticheta. Selecțiile sale adaptive sunt construite ca să regăsească un element după ce markup-ul se schimbă — așa că atunci când am redenumit clasa HTML a unui target din product-name în product-title, un selector normal a găsit 0, iar re-match-ul adaptiv a recuperat totuși elementul urmărit. La extragerea HTTP simplă a atins 12/12 la static și 8/8 pe API-ul JSON. Partea pe care propriile documentații nu o ascund: într-un test sintetic cu mai multe elemente a recuperat 1 din 3 — este o urmărire rezilientă a elementelor, nu o recuperare totală, deci nu o supraevalua mental. Instalarea de bază pip install scrapling are nevoie și de extra-ul [fetchers] ca să pornească, iar StealthyFetcher este mai degrabă o atenționare de conformitate decât o caracteristică pe care aș pune-o pe un slide. Versiunea 0.4.10 (curentă), BSD-3-Clause, în jur de 68,7k stele.
Tiparul de dedesubt al celor trei sarcini
Dacă pui cele nouă instrumente unul lângă altul, apare ceva foarte clar. Recall-ul static complet — un plat 12/12 — este minimul necesar pentru orice instrument HTTP-first; niciunul nu a ratat cazul ușor, deci asta nu diferențiază nimic. Instrumentele cu browser își justifică greutatea suplimentară doar când JavaScriptul chiar intră în ecuație, iar pentru asta plătesc toate în setup: un stack de browser, o instalare extra sau o întreagă flotă de containere. Iar coloana „coada de crawl integrată” este, de fapt, granița dintre un framework și un motor — Scrapy și Crawlee aduc orchestrare, în timp ce Playwright și Puppeteer te obligă să scrii BFS-ul manual. Aceasta este forma reală a domeniului. Nimeni nu câștigă per total, pentru că nimeni nu joacă același joc.
Deci pe care ar trebui, de fapt, să-l alegi
Bancul de test refuză să încoroneze un câștigător unic, pentru că răspunsul corect nu este un instrument, ci o întrebare — care dintre cele trei sarcini faci?
- Ai nevoie de Markdown pregătit pentru LLM? Alege trafilatura când cauți text curat de articol, Crawl4AI când vrei și extragere CSS plus randare JavaScript într-o singură bibliotecă, și Firecrawl când vrei în mod special un serviciu self-hosted și poți accepta atât licența AGPL-3.0, cât și greutatea celor șase containere.
- Ai nevoie de randare JavaScript? Playwright sau Puppeteer pentru randarea brută — alege după motor și limbaj, pentru că altfel sunt la egalitate — iar Crawlee când vrei și orchestrarea crawl-ului livrată gata, nu scrisă manual.
- Vrei crawl de pagini statice sau API-uri reproductibile, la scară? Scrapy pentru un framework Python complet, Colly pentru viteză brută în Go, într-un singur binar, și Scrapling când problema ta recurentă este supraviețuirea la drift-ul de markup.
Potrivește instrumentul cu sarcina și fiecare dintre ele devine o alegere perfect defensibilă. Ia din categoria greșită — un instrument cu browser pentru pagini statice sau un parser HTTP pentru o aplicație JavaScript — și chiar și biblioteca „cea mai bine cotată” de pe internet tot te va lăsa baltă.
Unde se potrivește în schimb un API AI gestionat
Toate instrumentele de mai sus sunt gratuite, open-source și pot fi rulate de tine. Dar acesta este și compromisului comun pe care îl evidențiază bancul de test: tu deții mediul de browser, codul de crawl, cursa de înarmare anti-bot și toată întreținerea. Pentru multe echipe, exact acest control este ideea, iar harta licențelor contează când îți asumi asta — majoritatea instrumentelor au licențe permisive (Apache-2.0 pentru Crawl4AI, Crawlee, Playwright, Puppeteer și Colly; BSD-3 pentru Scrapy și Scrapling), iar nucleul self-hosted al Firecrawl, cu AGPL-3.0, este singurul care cere o analiză juridică serioasă înainte de uz comercial.
Dar observă și ce a mapat testul: ce nu fac aceste instrumente. Randare, crawl, structurare și ocolirea blocajelor — rareori toate odată, și niciodată fără întreținerea ta. Un API AI gestionat comprimă acest stack într-un singur apel. Suprafața noastră pentru dezvoltatori la Thunderbit este o opțiune aici, iar pentru un public tehnic contează API-ul, serverul MCP și CLI-ul, nu extensia de browser. POST /distill returnează Markdown curat și POST /extract returnează JSON definit prin schemă, cu randarea JavaScript și anti-bot gestionate pe server, nu pe mașina ta. Există un server MCP oficial pentru agenți și asistenți de codare — thunderbit_suggest_fields rulează gratuit pentru a planifica o extragere, apoi thunderbit_distill (1 credit) și thunderbit_extract (20 de credite) fac treaba — plus un CLI pe care îl poți aduce cu npx @thunderbit/thunderbit-cli pentru terminal și joburi cron. Pentru colegii non-developeri există și o extensie Chrome no-code, iar tarifele acoperă ambele dimensiuni.
Compromisul este același în jurul căruia gravitează tot acest benchmark: rulezi și întreții singur până la nouă biblioteci, fără cost per apel, sau delegi infrastructura și plătești per cerere. Niciuna dintre opțiuni nu e greșită. Totul ține de cât din stack vrei, de fapt, să deții. Dacă preferi să vezi cum arată extragerea în practică, canalul de YouTube Thunderbit explică pas cu pas.
{{INTERNAL_BLOG_LINKS}}
Verdict
Nu există un singur cel mai bun scraper open-source, iar orice listă care îți oferă cu încredere unul ascunde discret întrebarea care decide de fapt totul: ce fel de sarcină faci? Transformi o pagină în text, randare JavaScript sau crawl rapid fără browser — domeniul se împarte curat în aceste categorii, iar în interiorul fiecăreia alegerea se reduce la limbaj și greutatea instalării, nu la vreun campion universal.
Dacă iei un singur obicei din tot ce am scris aici, ia-l pe acesta: testează pe propriile pagini înainte să te angajezi la ceva. Fiecare număr de aici poate fi reprodus în repo-ul de benchmark tocmai din acest motiv — pentru că instrumentul care câștigă un roundup generic și instrumentul care supraviețuiește țintelor tale reale nu sunt întotdeauna același lucru.
Încearcă Thunderbit pentru extragerea datelor web Get Started Free
Întrebări frecvente
Care este cel mai bun scraper web open-source? Nu există unul singur — depinde de sarcină. Pentru text pregătit pentru LLM, trafilatura sau Crawl4AI; pentru randare JavaScript, Playwright, Puppeteer sau Crawlee; pentru crawl HTTP rapid, Scrapy sau Colly. Pe un banc de test comun, fiecare instrument a fost cel mai puternic în propria categorie și vizibil mai slab în afara ei, motiv pentru care clasamentele „one-size-fits-all” sunt înșelătoare.
Ce scrapers open-source pot randa JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer și motorul Playwright din Crawlee pot randa JavaScript. Scrapy, Colly, trafilatura și fetcherul HTTP implicit din Scrapling nu pot — fie au nevoie de un API reproductibil în spatele paginii (abordarea Scrapy, care a obținut 8/8 de pe endpoint-ul JSON), fie de un mod separat de browser.
Am nevoie de un browser headless ca să scrapez un site? Doar dacă datele apar după ce rulează JavaScript. Dacă un request HTTP simplu plus un parser pot ajunge la conținut, un browser este un exces costisitor — Scrapy, Colly sau Scrapling vor fi mult mai ușoare și mai rapide în acel scenariu.
Care dintre acestea are cea mai prietenoasă licență pentru uz comercial? Majoritatea sunt permisive: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) sau BSD-3-Clause (Scrapy, Scrapling). Excepția este nucleul self-hosted al Firecrawl, care este AGPL-3.0 și merită verificare juridică serioasă înainte să construiești un produs comercial pe baza lui.
Sunt reproductibile aceste cifre de benchmark? Da. Fiecare runner, fiecare fișier de test și fiecare rezultat brut sunt într-un repo public cu licență MIT. Singura nuanță de reținut: recall-ul și rezultatele structurale sunt comparabile între instrumente, dar numărul absolut de caractere este doar un semnal în interiorul fiecărui instrument, pentru că fiecare pachet oglindește fișierele de test în loc să împartă o copie canonică unică — deci compară ratele și trecerea/eșecul, nu totalul brut de caractere.
