Quasi tutte le classifiche sui “migliori scraper open source” hanno lo stesso difetto, solo che nessuno lo dice apertamente: gli strumenti non vengono mai provati sulle stesse pagine. Scrapy viene testato su un articolo di news, Playwright su una demo e-commerce, Colly su chissà quale esempio pescato dall’autore — e poi li si mette uno contro l’altro in classifica, come se quei numeri avessero davvero lo stesso peso. In realtà, quel ranking parla delle pagine, non degli strumenti.
Allora ho fatto la cosa più semplice e più ovvia, quella che di solito queste liste saltano. Ho costruito un unico set di fixture e ho passato tutti e nove gli strumenti su quello: un catalogo statico, un catalogo renderizzato in JavaScript, un articolo nascosto dietro nav e footer pieni di rumore, un errore HTTP 500 voluto, un piccolo grafo di link interni, più due siti pubblici di esercitazione. Stesso ground truth, 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 lineare che promettono le roundup: non esiste un vincitore assoluto. Esistono tre lavori diversi, e i nove strumenti si distribuiscono quasi da soli al loro interno.
Prova Thunderbit per l'estrazione di dati dal web
Come ha funzionato il banco di prova, e l’unico limite che voglio dirti subito
Ogni strumento è stato testato sugli stessi tipi di fixture: 12 prodotti statici distribuiti su due pagine, 8 prodotti inseriti da JavaScript dopo un ritardo, un articolo avvolto da elementi di navigazione e footer, un server 500 volutamente rotto e un grafo di link interni. È proprio questa struttura che rende confrontabili i risultati — “8/8 prodotti dinamici” significa esattamente la stessa cosa, sia che a produrlo sia stato Puppeteer o Crawlee.
Ecco però il confine che molte roundup ignorano. Il pacchetto di ogni tool replica quelle fixture per conto proprio, quindi i conteggi assoluti dei caratteri non sono davvero confrontabili tra strumenti — leggili come segnali interni a ciascun tool, mai come punteggi cross-tool. I numeri davvero comparabili sono il recall (da leggere come tasso), il superamento o fallimento del test JavaScript e il comportamento strutturale. Una precisazione nello stesso spirito: l’esecuzione di Crawl4AI sul catalogo statico ha coperto solo la prima pagina, quindi il suo 6/6 è un recall pieno su un perimetro più ristretto, mentre gli altri tool hanno esplorato entrambe le pagine arrivando a 12/12 — un campo di applicazione più piccolo, non una mancata rilevazione parziale. La spiegazione completa, fixture per fixture, è nel documento di metodologia.
Un’ultima precisazione prima dei numeri. Ogni pacchetto include anche un punteggio di ricerca provvisorio, ma scelgo apposta di non mostrarlo in forma di tabella classificata. Erano strumenti interni per verificare ogni tool rispetto alle proprie evidenze, non una graduatoria — e pubblicarli come se lo fossero ricreerebbe esattamente il problema di falsa precisione che questo esercizio vuole evitare. Questa è una sintesi di ciò che il banco di prova ha mostrato, non una classifica.
Tutto il campo, su un unico banco
Leggi le due colonne “Renders JS?” e “Built-in crawl queue” di questa tabella, e i tre lavori si delineano praticamente da soli.
| Tool | Language | Renders JS? | Static recall | Structured output | Built-in crawl queue | Setup weight | License |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Sì (browser) | 6/6 (prima pagina) | Schema CSS | BFS/DFS integrata | 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 | Motore opzionale | 12/12 | Tramite extraction | Sì (RequestQueue) | Medio (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Sì | 12/12 | Manuale | No (BFS scritta a mano) | Medio (browser) | Apache-2.0 |
| Puppeteer | Node | Sì (Chrome) | 12/12 | Manuale | No (BFS scritta a mano) | Medio (Chrome) | Apache-2.0 |
| Scrapy | Python | No | 12/12 | Export feed (JSON/CSV/XML) | Sì (integrata) | Medio (dipendenze Twisted) | BSD-3 |
| Colly | Go | No | 12/12 | Tramite callback | Controllo della profondità | Leggero (1 binario + Go) | Apache-2.0 |
| Scrapling | Python | No (fetcher HTTP) | 12/12 | Sì | No | Medio ([fetchers]) | BSD-3 |
Una nota sui metadati della tabella e di tutto quello che segue: conteggi delle stelle e versioni sono stati fotografati all’inizio di luglio 2026, e cambiano in fretta. Ricontrollali su GitHub e sulla pagina del pacchetto di ciascun progetto prima di considerarli dati attuali.
L’indice delle recensioni singole
Ogni progetto in questa roundup ha una recensione approfondita dedicata:
- Recensione di Crawl4AI
- Recensione di Firecrawl
- Recensione di trafilatura
- Confronto Playwright vs Puppeteer
- Recensione di Crawlee
- Recensione di Scrapy
- Recensione di Colly
- Recensione di Scrapling
Ecco le loro copertine — più due screenshot veri del test di rendering JavaScript, così il “8/8 dinamici” non resta solo un numero su una pagina.
Lavoro uno: trasformare una pagina in testo pronto per LLM
Se ti serve Markdown pulito da inserire in una pipeline RAG, tre strumenti si contendono il posto — e non potrebbero essere più diversi tra loro.
Crawl4AI è, al netto del marketing, un generatore di Markdown basato su browser. Vale la pena smontare la storia dell’“adaptive intelligence self-learning selector” che gli gira intorno nei risultati di ricerca: non esiste nulla del genere — è un trucco di un’altra libreria, non di Crawl4AI (ci torniamo quando parliamo di 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 i dati strutturati, e la sua BFS integrata ha attraversato in profondità 5 pagine sul fixture del grafo di crawl mentre renderizzava una pagina JavaScript e catturava uno screenshot. Due limiti veri, però. Il Markdown grezzo si porta dietro il boilerplate della pagina, a meno che tu non attivi un filtro sul contenuto, e il 500 intenzionale è tornato come success=false — non perché Crawl4AI abbia gestito in modo pulito l’errore HTTP, ma perché la sua euristica di contenuto ha guardato il minuscolo corpo dell’errore e lo ha classificato come minimal_text ... blocked. Inoltre l’installazione ti aggiunge 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 comparsa dopo lo script è apparsa nell’output, prova concreta che il rendering era reale. I due intoppi che ho incontrato erano colpa dell’ambiente, non di Firecrawl, e lo dico con precisione così nessuno copia la soluzione sbagliata: una build da sorgente si è impantanata in un problema del containerd snapshotter sotto colima (sono passato alle immagini precompilate), e l’intervallo DNS 198.18.x.x di colima ha fatto scattare il guard rail SSRF di Firecrawl, che ho sbloccato con ALLOW_LOCAL_WEBHOOKS=true — una scorciatoia da sviluppo locale, non qualcosa da disattivare in produzione. Il core self-hosted inoltre non include Fire-engine, il livello cloud anti-block, e non ho testato la API cloud. Il segnale più importante è la licenza: il core self-hosted di Firecrawl è AGPL-3.0, quindi prima di usarlo in ambito commerciale serve davvero un controllo legale, non una nota a piè di pagina. Circa 148k stelle a inizio luglio.
trafilatura è il contrarian del gruppo, ed è quello che le liste hype sull’AI si dimenticano sempre. Niente browser. Nessuna riga strutturata. Solo testo di articoli veloce e pulito, in puro Python. Sul fixture dell’articolo ha estratto titolo e tutti i 3 paragrafi reali su 3, eliminando del tutto il boilerplate — nessun “Login”, “Subscribe” o “Copyright” è finito 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 suggerisce: puntalo su un catalogo e ti restituisce 12 nomi prodotto come testo ma 0 righe strutturate — il testo c’è, la struttura no, e non renderizza JavaScript. Versione 2.1.0 (release attuale), Apache-2.0, circa 6,2k stelle. Per l’estrazione pura di articoli, è il primo strumento che prenderei.
Quei due conteggi di caratteri Markdown — 13.476 da Crawl4AI, 9.222 da Firecrawl — arrivano dalla stessa pagina pubblica, ma non leggerli come una misura di qualità. Riflettono strategie Markdown diverse (quanta cornice della pagina viene mantenuta), non una sentenza su quale output sia migliore. È la regola del segnale interno al tool di cui parlavo prima, qui applicata alla luce del sole.
Lavoro due: renderizzare JavaScript in modo affidabile
Alcuni dati non sono nell’HTML finché gli script non vengono eseguiti, ed è lì che un browser vero smette di essere opzionale. Tre strumenti coprono questo lavoro — e due di loro si sono rivelati praticamente lo stesso strumento.
Playwright e Puppeteer hanno pareggiato su ogni test che ho lanciato. Entrambi hanno renderizzato 8/8 prodotti dinamici nella fixture locale e 10 nel sito pubblico Quotes JS, entrambi hanno raggiunto 12/12 di recall statico, ed entrambi hanno gestito correttamente il 500 (Puppeteer restituisce un oggetto response invece di lanciare un’eccezione). Nessuno dei due include una coda di crawl, quindi per attraversare il grafo di link da 12 pagine è servita una BFS scritta a mano. L’unica vera differenza è il raggio d’azione: Playwright guida Chromium, Firefox e WebKit e parla Python e .NET, mentre Puppeteer è orientato a Chrome e funziona solo con Node. Due precisazioni, perché qui le versioni cambiano in fretta: ho testato Playwright 1.56.0 rispetto a una 1.61.1 attuale e ho usato solo Chromium, e Puppeteer 24.16.0 rispetto a una 25.3.0 attuale — quindi rileggi o sconta i risultati di conseguenza. Entrambi Apache-2.0; circa 92k e 95k stelle rispettivamente.
Crawlee è quello che risolve il problema della coda che gli altri due lasciano aperto. Incapsula un motore Cheerio (HTTP) e un motore Playwright (browser) dietro un’unica API, e il contrasto su una singola pagina dice tutto: il motore Cheerio ha visto 0 elementi iniettati da JavaScript, mentre il motore Playwright li ha visti tutti 8/8 in locale (e 10 sul sito pubblico), e il passaggio da uno all’altro è una modifica di una sola riga. Ti dà anche una vera RequestQueue, ed è questo che gli vale un posto in questo lavoro invece che nel terzo. La postilla 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 non c’è JavaScript nella pagina, un browser è un sovradimensionamento costoso. Tre strumenti HTTP-first si contendono questo spazio, uno per filosofia di linguaggio, e non la pensano allo stesso modo su tutto.
Scrapy è il framework di livello ingegneristico del gruppo — spider, export feed in JSON/CSV/XML, AutoThrottle, tutto il necessario. Ha ottenuto 12/12 di recall statico, ha estratto i 3/3 paragrafi dell’articolo, ha attraversato 11 pagine a profondità 0–2 sul grafo di crawl e ha intercettato il 500 tramite handle_httpstatus_list. La parte interessante è la sua filosofia: non renderizza, replica la richiesta. Se lo lanci sulla pagina JavaScript ha ottenuto 0 nodi — e poi la API JSON dietro quella stessa pagina gli ha restituito 8/8. Ecco Scrapy in un dato solo: trova la richiesta che la pagina fa e la riproduce, invece di guidare un browser. Il prezzo è uno stack di dipendenze non banale (Twisted, lxml, parsel), e l’ho testato solo su fixture piccole. Versione 2.17.0, BSD-3-Clause, circa 63k stelle.
Colly è la risposta Go, e dice in modo molto diretto cosa sia: un binario statico, guidato da callback tramite OnHTML, OnResponse e OnError, con controllo della profondità. Ha centrato 12/12 di recall statico, ha preso 8/8 dalla API JSON via OnResponse, ha intercettato il 500 via OnError e ha raggiunto 17 pagine in un crawl a profondità 2 — e la formula è voluta, perché quel conteggio è il numero 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 corre davanti alla release taggata (v2.2.0). Apache-2.0, circa 25k stelle.
Scrapling è lo specialista, e il titolo se lo merita. I suoi selettori adattivi sono fatti per ritrovare un elemento dopo che il markup cambia — quindi quando ho rinominato la classe HTML di un target da product-name a product-title, un selettore standard ha trovato 0 elementi, mentre il rematch adattivo ha recuperato comunque l’elemento monitorato. Nell’estrazione HTTP pura ha ottenuto 12/12 sul statico e 8/8 sulla API JSON. La parte che la documentazione non nasconde è questa: in un test sintetico multi-elemento ha recuperato 1 su 3 — è tracking resiliente degli elementi, non recupero totale, quindi non bisogna esagerare con le aspettative. Anche il pip install scrapling di base richiede l’extra [fetchers] per partire, e il suo StealthyFetcher è più un avvertimento di compliance che una feature da mettere in slide. Versione 0.4.10 (release attuale), BSD-3-Clause, circa 68,7k stelle.
Il pattern dietro i tre lavori
Mettendo in fila tutti e nove gli strumenti, il quadro si fa molto chiaro. Il recall statico pieno — un secco 12/12 — è il minimo sindacale per ogni tool HTTP-first; nessuno ha sbagliato il caso facile, quindi non è ciò che li distingue. Gli strumenti browser hanno senso solo quando il JavaScript entra davvero in gioco, e pagano sempre in termini di setup: uno stack browser, un’installazione extra o un’intera batteria di container. E la colonna “built-in crawl queue” è davvero la linea che separa un framework da un motore — Scrapy e Crawlee portano l’orchestrazione, mentre Playwright e Puppeteer ti costringono a scrivere da solo la BFS. Questa è la forma del campo. Nessuno vince in assoluto perché nessuno sta giocando la stessa partita.
Quindi, quale dovresti scegliere davvero
Il banco di prova 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 quando vuoi testo pulito da articolo, Crawl4AI quando vuoi anche estrazione CSS e rendering JavaScript in un’unica libreria, e Firecrawl quando vuoi in particolare un servizio self-hosted e puoi accettare sia la licenza AGPL-3.0 sia il peso dei sei container.
- Ti serve JavaScript renderizzato? Usa Playwright o Puppeteer per il rendering puro — scegli in base a motore e linguaggio, perché per il resto sono in parità — 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à Go in un singolo binario, e Scrapling quando il tuo problema specifico e ricorrente è sopravvivere al cambiamento del markup.
Abbina lo strumento al lavoro, e tutte queste sono scelte difendibili. Prendine uno della categoria sbagliata — un tool browser per pagine statiche, o un parser HTTP per una web app JavaScript — e persino la libreria più quotata su internet continuerà a fallirti.
Dove entra invece una API AI gestita
Tutti gli strumenti sopra sono gratuiti, open source e li puoi eseguire da solo. È anche il compromesso comune che il banco di prova mette sempre in evidenza: sei tu a gestire l’ambiente browser, il codice di crawl, la corsa agli armamenti contro i bot e tutta la manutenzione. Per molti team questo controllo è esattamente il punto, e la mappa delle licenze conta quando te ne assumi la responsabilità — la maggior parte del campo è permissiva (Apache-2.0 per Crawl4AI, Crawlee, Playwright, Puppeteer e Colly; BSD-3 per Scrapy e Scrapling), mentre il core self-hosted di Firecrawl con licenza AGPL-3.0 è quello che richiede una vera revisione prima dell’uso commerciale.
Ma nota anche cosa ha mappato il banco: ciò che questi strumenti non fanno. Renderizzare, crawlare, strutturare e aggirare i blocchi — raramente tutto insieme, e mai senza manutenzione da parte tua. Una API AI gestita comprime tutto questo in una singola chiamata. La nostra interfaccia developer su Thunderbit è una delle opzioni in questo spazio, e per un pubblico tecnico contano soprattutto la 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 sulla tua macchina. Esiste 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) eseguono il lavoro — e una CLI che puoi installare con npx @thunderbit/thunderbit-cli per terminale e job cron. Per i colleghi non sviluppatori c’è anche una estensione Chrome no-code, e il pricing copre entrambe le dimensioni.
Il compromesso è lo stesso che attraversa tutto questo banco di prova: gestire e mantenere fino a nove librerie da soli a costo zero per chiamata, oppure scaricare l’impianto 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 lo mostra passo dopo passo.
{{INTERNAL_BLOG_LINKS}}
Verdetto
Non esiste il miglior scraper open source in assoluto, e qualsiasi lista che te ne consegna uno con troppa 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 campo si divide in modo netto in queste tre categorie, e dentro ciascuna la scelta dipende da linguaggio e peso del setup, non da un campione universale.
Se prendi un solo abitudine da tutto questo, prendi questa: testa sui tuoi siti prima di impegnarti con qualsiasi soluzione. Ogni numero qui è riproducibile nel repository del benchmark proprio per questo motivo — perché lo strumento che domina una roundup generica e quello che sopravvive ai tuoi target reali non sono sempre lo stesso.
Prova Thunderbit per l'estrazione di dati dal web Get Started Free
FAQ
Qual è il miglior web 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 strumento è risultato più forte nella propria categoria e sensibilmente più debole fuori da essa, ed è per questo che le classifiche “taglia unica” ingannano.
Quali scraper open source renderizzano JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer e il motore Playwright di Crawlee renderizzano JavaScript. Scrapy, Colly, trafilatura e il fetcher HTTP 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.
Mi serve un browser headless per fare scraping di un sito? Solo se i dati compaiono dopo l’esecuzione di JavaScript. Se una semplice richiesta HTTP più un parser riescono a raggiungere il contenuto, un browser è un sovraccarico costoso — in quel caso Scrapy, Colly o Scrapling saranno molto più leggeri e veloci.
Quale di questi ha la licenza più amichevole per uso commerciale? La maggior parte è permissiva: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) o BSD-3-Clause (Scrapy, Scrapling). L’eccezione è il core self-hosted di Firecrawl, che è AGPL-3.0 e merita una vera revisione della 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 strumenti, ma i conteggi assoluti dei caratteri sono solo segnali interni al singolo tool, perché ogni pacchetto replica le fixture invece di condividere una copia canonica — quindi confronta tassi e pass/fail, non i totali grezzi dei caratteri.
