Quasi ogni classifica dei “migliori scraper open-source” ha un difetto silenzioso: nessuno esegue i tool sulle stesse pagine. Scrapy viene testato su un articolo di news, Playwright su una demo e-commerce, Colly su quel che l’autore aveva a portata di mano — e poi li si mette uno contro l’altro come se quei numeri avessero davvero lo stesso significato. In realtà, quel ranking ti parla delle pagine, non degli strumenti.
Così ho fatto la cosa più noiosa e più ovvia che queste liste tendono a saltare. Ho costruito un unico set di fixture e ho fatto passare tutti e nove i tool attraverso di esso: un catalogo statico, un catalogo renderizzato in JavaScript, un articolo nascosto tra navigazione e footer, un HTTP 500 volutamente rotto, un piccolo grafo di link interni da crawlare, più due siti pubblici di pratica. Stessa verità di riferimento, stesse metriche, ogni singola esecuzione. Script e output grezzi sono disponibili in un repository pubblico di benchmark, così puoi rilanciare tutto da solo. Il risultato non è la classifica pulita promessa dalle roundup: non esiste un vincitore unico. Esistono tre lavori diversi, e i nove tool si distribuiscono quasi da soli.
Prova Thunderbit per l’estrazione di dati web
Come ha funzionato il benchmark, e l’unico limite che voglio dire chiaramente
Ogni strumento ha affrontato le stesse tipologie di fixture: 12 prodotti statici distribuiti su due pagine, 8 prodotti iniettati via JavaScript dopo un ritardo, un articolo con tre paragrafi reali circondati da boilerplate di navigazione e footer, un server 500 intenzionale e un grafo di link interni. È questo design che rende i risultati confrontabili — “8/8 prodotti dinamici” significa esattamente la stessa cosa sia che il risultato venga da Puppeteer sia che venga da Crawlee.
Ecco il confine che la maggior parte delle roundup evita. Il pacchetto di ciascun tool rispecchia la propria copia di quelle fixture, quindi i conteggi assoluti dei caratteri non sono strettamente confrontabili tra strumenti — leggili come segnali interni a uno strumento, mai come punteggi incrociati. Le metriche davvero confrontabili sono il recall (da trattare come un tasso), il pass/fail sul JavaScript e il comportamento strutturale. Un’altra nota di perimetro, per lo stesso motivo: il run statico di Crawl4AI copriva solo la prima pagina, quindi il suo 6/6 è un recall completo su un sottoinsieme più ristretto, mentre gli altri tool hanno crawlato entrambe le pagine per 12/12 — un ambito più piccolo, non una mancata copertura parziale. Tutto il ragionamento, fixture per fixture, è nella descrizione della metodologia.
Un’altra precisazione prima dei numeri. Ogni pacchetto include anche un punteggio provvisorio di ricerca, ma non li sto pubblicando intenzionalmente come tabella di classifica. Erano strumenti interni per verificare ogni tool contro le proprie prove, non una league table — e pubblicarli come tale ricreerebbe proprio il problema di falsa precisione che questo esercizio vuole evitare. Questa è una sintesi di ciò che il benchmark ha mostrato, non un tabellone.
Tutto il campo, su un unico benchmark
Leggi le due colonne di questa tabella — “Rende il JS?” e “Coda di crawl integrata” — e i tre lavori emergono praticamente da soli.
| Tool | Linguaggio | Rende il JS? | Recall statico | Output strutturato | Coda di crawl integrata | Peso di setup | Licenza |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Sì (browser) | 6/6 (pagina 1) | Schema CSS | BFS/DFS integrati | Pesante (2 stack browser) | Apache-2.0 |
| Firecrawl | Self-hosted | Sì (playwright-service) | Markdown completo | Sì | /v1/crawl | Molto pesante (6 container) | AGPL-3.0 |
| trafilatura | Python | No | 3/3 articolo | No (solo testo) | No | Leggero | Apache-2.0 |
| Crawlee | Node/TS | Opzionale per engine | 12/12 | Tramite extraction | Sì (RequestQueue) | Medio (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Sì | 12/12 | Manuale | No (BFS scritto a mano) | Medio (browser) | Apache-2.0 |
| Puppeteer | Node | Sì (Chrome) | 12/12 | Manuale | No (BFS scritto a mano) | Medio (Chrome) | Apache-2.0 |
| Scrapy | Python | No | 12/12 | Feed export (JSON/CSV/XML) | Sì (integrata) | Medio (dipendenze Twisted) | BSD-3 |
| Colly | Go | No | 12/12 | Tramite callback | Controllo profondità | Leggero (1 binario + Go) | Apache-2.0 |
| Scrapling | Python | No (HTTP fetcher) | 12/12 | Sì | No | Medio ([fetchers]) | BSD-3 |
Una nota sui metadati in questa tabella e in tutto ciò che segue: il numero di stelle e le versioni sono stati rilevati a inizio luglio 2026 e cambiano rapidamente. Verificali di nuovo su GitHub e sulla pagina del pacchetto prima di considerarli attuali.
Indice delle review dei singoli tool
Ogni progetto citato in questa roundup ha la sua review di approfondimento:
- Review di Crawl4AI
- Review di Firecrawl
- Review di trafilatura
- Confronto Playwright vs Puppeteer
- Review di Crawlee
- Review di Scrapy
- Review di Colly
- Review di Scrapling
Ecco le loro copertine — più due screenshot reali del test di rendering JavaScript, così la frase “8/8 dinamici” non resta solo un numero sulla pagina.
Lavoro uno: trasformare una pagina in testo pronto per LLM
Se ti serve Markdown pulito da alimentare in una pipeline RAG, competono tre tool — e non potrebbero essere più diversi come approccio.
Crawl4AI è, al di là del marketing, un generatore di Markdown supportato da browser. Vale la pena smontare la storia dell’“adaptive intelligence self-learning selector” che lo accompagna nei risultati di ricerca: non esiste nulla del genere — quel trucco appartiene a un’altra libreria (ne parleremo quando arriveremo a Scrapling). Quello che fa davvero, lo fa bene. Sul sito di pratica Books to Scrape ha prodotto 13.476 caratteri di Markdown, gestisce l’estrazione tramite schema CSS per le estrazioni strutturate e la sua BFS di deep crawl integrata ha percorso 5 pagine sul grafo di crawl, renderizzando una pagina JavaScript e catturando uno screenshot. Però presenta due limiti reali. Il Markdown grezzo si porta dietro il boilerplate della pagina se non attivi un filtro contenuti, e il 500 intenzionale è tornato con success=false — non perché Crawl4AI abbia intercettato in modo pulito l’errore HTTP, ma perché la sua euristica sui contenuti ha visto il piccolo corpo d’errore e lo ha etichettato minimal_text ... blocked. Inoltre, il setup deposita due stack browser sul disco. Versione 0.9.0, Apache-2.0, circa 71k stelle a inizio luglio.
Firecrawl è il peso massimo, e auto-ospitarlo funziona davvero — dico “davvero” perché lo stack da sei container (api, playwright-service, redis, rabbitmq, nuq-postgres e foundationdb) è effettivamente partito e ha prodotto 9.222 caratteri di Markdown pronto per LLM dalla stessa pagina Books to Scrape. Ha renderizzato una pagina JavaScript tramite il suo playwright-service integrato e la citazione di Einstein post-script è comparsa nell’output, prova che il rendering era reale. Due intoppi che ho incontrato erano dovuti all’ambiente, non a Firecrawl, e voglio essere preciso così nessuno copia la soluzione sbagliata: una build da sorgente è andata in errore per un problema casuale di containerd snapshotter sotto colima (sono passato alle immagini precompilate), e il range DNS 198.18.x.x di colima ha attivato la protezione SSRF di Firecrawl, che ho risolto con ALLOW_LOCAL_WEBHOOKS=true — una soluzione locale da sviluppo, non qualcosa da disattivare in produzione. Il core self-hosted, inoltre, non include Fire-engine, il livello cloud anti-block, e non ho testato l’API cloud. Il segnale più grande è la licenza: il core self-hosted di Firecrawl è AGPL-3.0, quindi prima di usarlo commercialmente serve una vera verifica legale, non una nota a piè di pagina. Circa 148k stelle a inizio luglio.
trafilatura è l’outsider del gruppo, ed è quello che molte liste piene di hype AI tendono a dimenticare. Niente browser. Niente righe strutturate. Solo testo articolo pulito in puro Python, veloce. Sulla fixture dell’articolo ha estratto il titolo più tutti e 3 i 3 paragrafi reali, eliminando completamente il boilerplate — nessun “Login”, “Subscribe” o “Copyright” è filtrato dentro — e in più ha recuperato autore e data. Su una pagina prodotto pubblica ha restituito 1.324 caratteri di testo pulito. Il suo limite è esattamente quello che il design lascia intendere: se lo punti a un catalogo, restituisce 12 nomi prodotto come testo ma 0 righe strutturate — il testo c’è, la struttura no, e non renderizza JavaScript. Versione 2.1.0 (la release attuale), Apache-2.0, circa 6,2k stelle. Per l’estrazione pura di articoli, è il primo strumento che sceglierei.
Quei due conteggi di caratteri del Markdown — 13.476 da Crawl4AI, 9.222 da Firecrawl — provengono dalla stessa pagina pubblica, ma non vanno letti come un divario di qualità. Riflettono strategie Markdown diverse (quanta parte del “chrome” della pagina ciascuno conserva), non una sentenza su quale output sia migliore. È la regola del segnale interno allo strumento, vista in azione.
Lavoro due: renderizzare JavaScript in modo affidabile
Alcuni dati non compaiono nell’HTML finché gli script non vengono eseguiti, e in quel momento un browser vero smette di essere opzionale. Tre tool coprono questo lavoro — e due di loro sono risultati quasi lo stesso identico tool.
Playwright e Puppeteer hanno pareggiato in ogni test che ho lanciato. Entrambi hanno renderizzato 8/8 prodotti dinamici sulla fixture locale e 10 sul sito pubblico Quotes JS, entrambi hanno raggiunto 12/12 di recall statico e hanno gestito il 500 in modo pulito (Puppeteer restituisce un oggetto response invece di lanciare un’eccezione). Nessuno dei due include una coda di crawl, quindi entrambi hanno richiesto una BFS scritta a mano, arrivando a 12 pagine tra profondità 0–2 sul grafo di crawl. La vera differenza è la copertura: Playwright controlla Chromium, Firefox e WebKit e parla Python e .NET, mentre Puppeteer è centrato su Chrome e solo Node. Due precisazioni, perché qui le versioni cambiano in fretta: ho testato Playwright 1.56.0 contro l’attuale 1.61.1 e solo su Chromium, e Puppeteer 24.16.0 contro l’attuale 25.3.0 — quindi rifai il test o considera questo dato con cautela. Entrambi Apache-2.0; circa 92k e 95k stelle rispettivamente.
Crawlee è quello che risolve il problema della coda lasciato aperto dagli altri due. Incapsula un motore Cheerio (HTTP) e un motore Playwright (browser) dietro un’unica API, e il contrasto su una singola pagina è l’intera promessa: il motore Cheerio ha visto 0 elementi iniettati via JavaScript, il motore Playwright ha visto tutti gli 8/8 in locale (e 10 sul sito pubblico), e passare da uno all’altro è una modifica di una sola riga. Ti dà anche una vera RequestQueue, ed è questo che lo fa rientrare in questo lavoro e non nel terzo. L’unico dettaglio che nessuno mette nel titolo: il motore browser richiede un npx playwright install separato, circa 80 MiB che npm install crawlee non scarica per te. Versione 3.17.0, TypeScript, Apache-2.0, circa 24,6k stelle.
Lavoro tre: crawlare velocemente senza browser
Se la pagina non usa JavaScript, un browser è un eccesso costoso. Qui competono tre tool HTTP-first, uno per filosofia di linguaggio, e i risultati divergono in modi interessanti.
Scrapy è il framework più solido dal punto di vista ingegneristico tra quelli qui presenti — spider, export feed in JSON/CSV/XML, AutoThrottle, tutto. Ha raggiunto 12/12 di recall statico, ha estratto i 3/3 paragrafi dell’articolo, ha percorso 11 pagine tra profondità 0–2 sul grafo di crawl e ha intercettato il 500 tramite handle_httpstatus_list. Il suo modo di vedere il mondo è la parte più interessante: non renderizza, riproduce la richiesta. Se lo metti davanti alla pagina JavaScript, ottiene 0 nodi — e poi l’API JSON nascosta dietro la stessa pagina gli restituisce 8/8. Questa è la filosofia di Scrapy in un solo dato: trovare la request che la pagina fa e riprodurla, non guidare un browser. Il prezzo è uno stack di dipendenze corposo (Twisted, lxml, parsel) e l’ho testato solo su fixture di piccole dimensioni. Versione 2.17.0, BSD-3-Clause, circa 63k stelle.
Colly è la risposta di Go, ed è piacevolmente letterale su ciò che è: un singolo binario statico, guidato da callback tramite OnHTML, OnResponse e OnError, con controllo della profondità. Ha centrato 12/12 sul recall statico, ha estratto 8/8 dalla JSON API via OnResponse, ha intercettato il 500 tramite OnError ed è arrivato a 17 pagine con un crawl a profondità 2 — e lo dico esattamente così, perché quel conteggio è quello del harness, non una garanzia di completezza che Colly promette. Quello che non fa è JavaScript: la fixture dinamica e il sito Quotes JS sono tornati entrambi 0, per design. Ti serve una toolchain Go per compilarlo, e la versione del modulo (v2.3.0) oggi è più avanti della release taggata (v2.2.0). Apache-2.0, circa 25k stelle.
Scrapling è il specialista, e il termine è meritato. I suoi selettori adattivi sono pensati per ritrovare un elemento dopo che il markup è cambiato — quindi quando ho rinominato la classe HTML del target da product-name a product-title, un selettore normale ha trovato 0 elementi, mentre il ri-match adattivo ha recuperato comunque l’elemento monitorato. Nelle estrazioni HTTP semplici ha centrato 12/12 sul statico e 8/8 sulla JSON API. La parte che persino i suoi documenti non nascondono: in un test sintetico con più elementi ha recuperato 1 su 3 — è tracking resiliente degli elementi, non recupero totale, quindi non esagerarlo mentalmente. Anche il base pip install scrapling richiede l’extra [fetchers] per partire, e il suo StealthyFetcher è una nota di compliance, non una feature da mettere in slide. Versione 0.4.10 (la release attuale), BSD-3-Clause, circa 68,7k stelle.
Il pattern dietro i tre lavori
Mettendo in fila i nove strumenti emerge un quadro molto pulito. Il recall statico completo — un piatto 12/12 — è il minimo sindacale per ogni tool HTTP-first; nessuno ha sbagliato il caso semplice, quindi non è un elemento distintivo. I tool browser giustificano il loro peso aggiuntivo solo quando il JavaScript entra davvero in gioco, e quel costo si paga sempre nel setup: uno stack browser, un’installazione extra o un intero parco container. E la colonna “coda di crawl integrata” è davvero la linea di demarcazione tra framework ed engine — Scrapy e Crawlee portano l’orchestrazione, mentre Playwright e Puppeteer ti chiedono di scrivere da solo la BFS. Questa è la forma del settore. Nessuno vince in assoluto perché nessuno sta giocando la stessa partita.
Quindi quale dovresti scegliere davvero
Il benchmark si rifiuta di incoronare un vincitore perché la risposta giusta non è uno strumento, ma una domanda — quale dei tre lavori stai facendo?
- Ti serve Markdown pronto per LLM? Scegli trafilatura se cerchi testo articolo pulito, Crawl4AI se vuoi anche estrazione CSS e rendering JavaScript in un’unica libreria, e Firecrawl se vuoi specificamente un servizio self-hosted e sei disposto a gestire sia la licenza AGPL-3.0 sia il peso di sei container.
- Ti serve il rendering JavaScript? Playwright o Puppeteer per il rendering puro — scegli in base all’engine e al linguaggio, perché per il resto sono sostanzialmente alla pari — e Crawlee quando vuoi anche l’orchestrazione del crawl già pronta, invece di scriverla a mano.
- Devi crawlare pagine statiche o API riproducibili su larga scala? Scrapy per un framework Python completo, Colly per la velocità grezza di Go in un singolo binario, e Scrapling quando il tuo problema ricorrente è sopravvivere al drift del markup.
Abbina lo strumento al lavoro e ognuno di questi diventa una scelta difendibile. Prendi quello della categoria sbagliata — un tool browser per pagine statiche, o un parser HTTP per un’app JavaScript — e anche la libreria più ben recensita del web ti lascerà a piedi.
Dove si inserisce invece un’API AI gestita
Tutti i tool qui sopra sono gratuiti, open-source e tuoi da eseguire. Ma è anche il compromesso comune che il benchmark fa emergere: sei tu a gestire l’ambiente browser, il codice di crawl, la lotta anti-bot e ogni pezzo di manutenzione. Per molti team, proprio questo controllo è il punto, e la mappa delle licenze conta quando ti assumi questa responsabilità — gran parte del panorama è permissiva (Apache-2.0 per Crawl4AI, Crawlee, Playwright, Puppeteer e Colly; BSD-3 per Scrapy e Scrapling), con il core self-hosted di Firecrawl in AGPL-3.0 come unico caso che richiede una vera revisione prima di un uso commerciale.
Ma nota anche cosa ha mappato il benchmark: ciò che questi tool non fanno. Renderizzare, crawlare, strutturare e aggirare i blocchi — raramente tutto insieme, e mai senza manutenzione da parte tua. Un’API di scraping AI gestita comprime tutto questo in una singola chiamata. La nostra interfaccia per sviluppatori su Thunderbit è una delle opzioni, e per un pubblico tecnico contano l’API, il server MCP e la CLI, non l’estensione browser. POST /distill restituisce Markdown pulito e POST /extract restituisce JSON definito da schema, con rendering JavaScript e anti-bot gestiti lato server invece che sul tuo computer. C’è un server MCP ufficiale per agenti e assistenti di coding — thunderbit_suggest_fields è gratuito per pianificare un’estrazione, poi thunderbit_distill (1 credito) e thunderbit_extract (20 crediti) fanno il lavoro — e una CLI che puoi richiamare con npx @thunderbit/thunderbit-cli per terminale e job cron. Per chi non sviluppa nel tuo team c’è anche una estensione Chrome no-code, e la pagina prezzi copre entrambe le dimensioni.
Il compromesso è lo stesso attorno a cui ruota tutto questo benchmark: eseguire e mantenere fino a nove librerie da solo a costo zero per chiamata, oppure delegare l’infrastruttura e pagare per richiesta. Nessuna delle due scelte è sbagliata. Dipende da quanta parte dello stack vuoi davvero possedere. Se preferisci vedere come funziona l’estrazione nella pratica, il canale YouTube di Thunderbit la mostra passo per passo.
Verdetto
Non esiste il miglior scraper open-source in assoluto, e qualunque lista che te ne consegni uno con sicurezza sta nascondendo la vera domanda che decide tutto: quale dei tre lavori stai facendo? Trasformare una pagina in testo, renderizzare JavaScript o crawlare velocemente senza browser — il settore si divide in modo netto in queste categorie, e dentro ciascuna la scelta dipende da linguaggio e peso di setup, non da un campione universale.
Se vuoi portarti a casa un solo abitudine da tutto questo, sia questa: testa sulle tue pagine prima di impegnarti con qualsiasi tool. Ogni numero qui è riproducibile nel repository del benchmark proprio per questo motivo — perché lo strumento che domina una roundup generica e quello che regge sui tuoi target reali non sono sempre lo stesso.
Prova Thunderbit per l’estrazione di dati web Get Started Free
FAQ
Qual è il miglior scraper open-source? Non ce n’è uno solo — dipende dal lavoro. Per testo pronto per LLM, trafilatura o Crawl4AI; per il rendering JavaScript, Playwright, Puppeteer o Crawlee; per il crawling HTTP veloce, Scrapy o Colly. Su un banco di prova condiviso, ogni tool è emerso forte nella propria categoria e sensibilmente più debole fuori da essa, ed è per questo che le classifiche “taglia unica” sono fuorvianti.
Quali scraper open-source renderizzano JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer e il motore Playwright di Crawlee renderizzano JavaScript. Scrapy, Colly, trafilatura e l’HTTP fetcher predefinito di Scrapling no — hanno bisogno o di una API riproducibile dietro la pagina (l’approccio di Scrapy, che ha ottenuto 8/8 dall’endpoint JSON) oppure di una modalità browser separata.
Serve un browser headless per fare scraping di un sito? Solo se i dati compaiono dopo l’esecuzione del JavaScript. Se una semplice richiesta HTTP più un parser riescono ad arrivare al contenuto, un browser è un costo inutile: Scrapy, Colly o Scrapling saranno molto più leggeri e veloci in quel caso.
Quale di questi ha la licenza più adatta all’uso commerciale? La maggior parte è permissiva: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) oppure BSD-3-Clause (Scrapy, Scrapling). L’eccezione è il core self-hosted di Firecrawl, che è AGPL-3.0 e merita una vera revisione di licenza prima di costruirci sopra un prodotto commerciale.
Questi numeri di benchmark sono riproducibili? Sì. Ogni runner, fixture e risultato grezzo è in un repository pubblico con licenza MIT. L’unica cautela da tenere a mente: recall e risultati strutturali sono confrontabili tra tool, ma i conteggi assoluti dei caratteri sono solo segnali interni allo strumento, perché ogni pacchetto rispecchia le fixture invece di condividere una copia canonica unica — quindi confronta tassi e pass/fail, non i totali grezzi dei caratteri.
