Ogni guida su "Scrapy vs. Selenium" in rete ripete sempre la stessa storia: Scrapy è più veloce, Selenium gestisce JavaScript, scegli il male minore. L’impostazione di base non è sbagliata, ma le affermazioni universali sui page-per-minute lo sono. La velocità reale dipende dal sito di destinazione, dalla rete, dal livello di concorrenza, dal ciclo di vita del browser, dai tempi di attesa e dai sistemi anti-bot.
Questa guida mette a confronto architetture e compromessi operativi che restano validi da un progetto all’altro. Include anche ciò che spesso manca nei confronti tradizionali: come l’automazione del browser cambia il modello di risorse, perché il rendering selettivo spesso batte una scansione interamente basata sul browser e quando una API gestita per l’estrazione è più adatta di entrambi i framework.
Verdetto rapido: Scrapy vs. Selenium nel 2026
Se vuoi la risposta breve: Scrapy vince in velocità, scalabilità ed efficienza delle risorse per tutto ciò che è server-rendered. Selenium vince quando ti serve un browser vero che faccia cose da browser vero — cliccare, digitare, aspettare che un modal compaia con l’animazione. Nessuno dei due è particolarmente forte contro le difese anti-bot moderne pronto all’uso, e Playwright si è silenziosamente preso gran parte dei casi d’uso per cui un tempo si sceglieva Selenium.
Ecco la matrice decisionale che uso davvero:
| La tua situazione | Scegli |
|---|---|
| Pagine statiche o server-rendered, volumi elevati | Scrapy |
| SPA pesanti in JS con login, click e flussi multi-step | Selenium o Playwright |
| Sito misto — per lo più statico, con alcune sezioni solo JS | Soluzione ibrida Scrapy-Playwright |
| URL noti, dati strutturati, manutenzione minima | API di estrazione AI (Thunderbit e simili) |
A metà 2026, Scrapy 2.17.0 è disponibile, Selenium 4 continua ad ampliare il supporto a WebDriver BiDi e scrapy-playwright offre un modo mantenuto per instradare richieste Scrapy selezionate attraverso un browser. Tieniti questa matrice a portata di mano: il resto dell’articolo spiega perché funziona.
Cosa sono Scrapy e Selenium (e perché gli sviluppatori continuano a discuterne)
Confrontare Scrapy e Selenium è un po’ come confrontare un camion da consegna con un’auto. Entrambi portano qualcosa da A a B, ma uno è stato progettato per trasportare grandi volumi in modo efficiente e l’altro per essere guidato da una persona che deve interagire davvero con la strada. Il dibattito continua perché entrambi gli strumenti possono fare scraping — semplicemente sono pensati per lavori diversi, e molte squadre scelgono quello sbagliato prima di rendersene conto.
Scrapy: il motore di crawling asincrono
Scrapy è un framework solo Python costruito sul modello I/O event-driven e non bloccante di Twisted. Non è un browser — non lo è mai stato — invia richieste HTTP e analizza l’HTML che riceve in risposta. È tutto qui il trucco. Poiché non deve aspettare che un browser renda qualcosa, può lanciare decine di richieste in parallelo senza bloccarsi.
Di base Scrapy include spider, item pipeline, feed exporter, retry middleware e rate limiting. Non è un framework in cui devi costruire tutto da zero: molte esigenze tipiche della produzione sono già coperte. La documentazione sull’architettura descrive Engine, Scheduler, Downloader e Item Pipeline come componenti separati e sostituibili, ed è proprio per questo che il framework ha retto bene nel tempo: puoi aggiungere pezzi senza riscrivere il nucleo.
Il limite è chiaro: niente browser significa niente esecuzione JavaScript. Se i dati vengono caricati tramite una chiamata fetch lato client dopo il rendering della pagina, Scrapy non li vede. Legge solo l’HTML iniziale, punto.
Selenium: il browser che puoi programmare
Selenium controlla browser reali — Chrome, Firefox, Edge — tramite il protocollo W3C WebDriver, lo standard che lo rende indipendente dal linguaggio e dal browser, invece di essere un trucco solo per Chrome. Renderizza JavaScript, esegue chiamate AJAX e può cliccare, scorrere e digitare esattamente come farebbe una persona.
Questo rende Selenium la scelta giusta per tutto ciò che dipende dall’interazione: login multi-step, wizard, infinite scroll, menu a tendina che attivano chiamate API. Ma ogni sessione del browser è pesante. La stessa guida al dimensionamento di Grid suggerisce di considerare circa 1 GB di RAM per sessione browser solo per la pianificazione — e questo prima ancora di considerare il carico CPU dovuto al rendering delle pagine.
Un dettaglio che manda in confusione molte persone: il completamento del caricamento della pagina non significa che l’interfaccia sia pronta. La documentazione di Selenium avverte anche di non mescolare implicit wait ed explicit wait perché i timeout diventano imprevedibili molto in fretta. Se il tuo script Selenium è instabile, spesso è per questo.
Scrapy vs. Selenium: prestazioni senza numeri universali inventati
Un benchmark affidabile deve pubblicare le pagine target, lo stato della cache, le condizioni di rete, la concorrenza, la strategia di riuso del browser, le condizioni di attesa e il codice completo. Senza questo contesto, un numero di page-per-minute è marketing, non evidenza. Il confronto architetturale resta comunque utile:
| Caratteristica del carico di lavoro | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| HTML server-rendered | Percorso HTTP diretto | Percorso completo via browser | Usa il percorso diretto di Scrapy |
| Contenuto renderizzato in JavaScript | Richiede un renderer aggiuntivo | Esecuzione nativa nel browser | Rendering selettivo nel browser |
| Modello di concorrenza | Scheduler asincrono delle richieste | Sessioni browser gestite dal tuo codice o da Grid | Scheduler di Scrapy + context del browser |
| Profilo risorse | Nessun overhead di rendering browser | Overhead CPU e memoria del browser | Costo del browser solo per richieste selezionate |
| Misura migliore | Elementi al minuto con tasso d’errore sicuro | Flussi completati al minuto con tasso d’errore sicuro | Throughput separato per richieste statiche e renderizzate |
L’impostazione predefinita della concorrenza in Scrapy è un limite superiore, non una promessa di throughput. La velocità reale è determinata da latenza, limiti per dominio, throttling, retry, dimensione delle risposte, lavoro di parsing e ritmo di richieste accettabile per il sito target. Selenium può riutilizzare una sessione browser, quindi non è limitato per forza a un browser nuovo per ogni pagina, ma ogni sessione attiva esegue comunque e renderizza un ambiente browser.
Il modello ibrido è interessante perché lascia le richieste normali sul percorso HTTP di Scrapy e invia al browser solo le pagine che necessitano di rendering. Di solito riduce il lavoro del browser, ma non è automaticamente più veloce: misura separatamente i percorsi statici e renderizzati, includi i tassi di errore e retry, e calibra la concorrenza sia sulla sicurezza per il sito sia sulla memoria disponibile.
Differenze fondamentali che influenzano la scelta
La velocità non è l’unica variabile. Una manciata di fattori pratici conta altrettanto quando porti tutto in produzione.
Rendering JavaScript e contenuti dinamici
Scrapy da solo non vede nulla che venga renderizzato lato client. Selenium vede tutto perché è un browser vero. La via di mezzo — Scrapy-Splash (più vecchio, basato su Lua) e scrapy-playwright (più moderno, consigliato) — consente di renderizzare in modo selettivo il JS all’interno del ciclo di crawl di Scrapy, invece di affidarsi a un browser completo per ogni richiesta. Se l’80-90% delle pagine target è HTML statico e solo poche richiedono JS, il rendering selettivo è l’architettura ovvia. Renderizzare tutto nel browser solo perché alcune pagine lo richiedono è uno spreco di risorse.
Scalabilità e concorrenza
Scalare Scrapy da 1.000 pagine a 1.000.000 è soprattutto una questione di provisioning — aggiungi richieste concorrenti, magari distribuite tra più worker con Redis. Scalare Selenium significa aggiungere browser instance in modo lineare, quindi aumentare in modo lineare RAM e CPU, e a quel punto stai gestendo una browser farm con Selenium Grid e recupero da crash. Non è che Selenium non possa scalare — è che scalarlo è un progetto infrastrutturale, non una modifica di configurazione.
Pipeline dei dati ed export
L’item pipeline di Scrapy gestisce validazione, deduplicazione ed export in JSON, CSV o database come funzionalità integrata. Selenium non offre nulla di tutto questo — devi scriverti da solo serializzazione e storage. Se per te qualità dei dati e integrazione a valle contano davvero (e dovrebbero), questa è una marcia in più concreta che Scrapy ti dà gratis.
Manutenzione e affidabilità nel lungo periodo
Ho notato questo schema: gli spider Scrapy in genere invecchiano abbastanza bene perché l’architettura basata su middleware impone una certa struttura. Gli script Selenium diventano fragili — gli aggiornamenti del browser rompono i driver, i problemi di timing causano esecuzioni instabili e ogni modifica al DOM richiede di aggiornare i selettori. Ho visto sviluppatori dire apertamente nei forum che uno scraper basato su Selenium “sembra non la scelta migliore per qualcosa che dobbiamo vendere a un cliente”, e onestamente l’istinto è corretto se il progetto deve sopravvivere più di qualche mese senza ritocchi.
Anti-bot: come se la cavano gli strumenti contro le difese del 2026
Questa è la parte che quasi tutti gli altri confronti sorvolano, ed è quella che decide davvero se il tuo scraper funziona oppure no. Né Scrapy né Selenium sono stati progettati pensando all’infrastruttura anti-bot moderna, e fingere il contrario porta solo a brutte sorprese in produzione.
| Livello di difesa | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Rendering JS | ❌ Richiede middleware | ✅ | ✅ | ✅ Integrato |
| Fingerprint TLS | ⚠️ Rilevabile | ⚠️ Rilevabile | ⚠️ Migliore, ma non risolto | ✅ Gestito |
| Risoluzione CAPTCHA | ❌ Manuale | ❌ Manuale | ❌ Manuale | ✅ Integrata |
| Rotazione rate limit | ⚠️ Proxy fai-da-te | ⚠️ Proxy fai-da-te | ⚠️ Proxy fai-da-te | ✅ Gestita |
Scrapy fallisce in modo diretto i controlli sui fingerprint del browser perché, in realtà, non c’è alcun browser da fingerprintare — è solo un client HTTP, e molti fornitori anti-bot segnalano traffico che non sembra provenire da un browser reale. Selenium supera i controlli JS di base perché è un browser vero, ma è comunque rilevabile tramite segnali come navigator.webdriver, un flag standard che vale true in automazione. Patch come undetected-chromedriver provano a mascherarlo, ma è una lotta continua contro fornitori di detection che aggiornano regolarmente le loro firme.
La corsa allo stealth (e perché il fai-da-te è fragile)
Ecco la verità scomoda sulle patch anti-detection: sono un tapis roulant di manutenzione, non una soluzione. undetected-chromedriver e playwright-stealth funzionano finché Cloudflare Turnstile o DataDome non rilasciano un aggiornamento che riconosce la tecnica usata. A quel punto devi patchare di nuovo. Ho visto team spendere più tempo ingegneristico per tenere in vita il layer stealth che per costruire lo scraper vero e proprio.
Anche il rate limiting merita una nota a parte. Quando un server restituisce 429 Too Many Requests, l’header Retry-After è un suggerimento, non un obbligo — molti siti non lo inviano affatto, e alcuni ti rallentano con altri segnali. L’AutoThrottle di Scrapy aiuta regolando il ritardo in base alla latenza osservata, ma è reattivo, non preventivo.
È qui che una API gestita per l’estrazione si ripaga da sola — la gestione anti-bot diventa un problema di qualcun altro, non tuo. Torneremo su questo punto tra poco.
Il fattore Playwright: perché "Scrapy vs. Selenium" non basta più
Impostare il dibattito come una scelta tra due strumenti ignora ciò che è successo davvero nella comunità dello scraping negli ultimi anni. Nei forum di sviluppatori trovi spesso versioni di “sono passato da Selenium a Playwright e mi sono trovato molto meglio” — eppure la maggior parte degli articoli di confronto cita Playwright solo di sfuggita, se lo cita.
Playwright, sviluppato da Microsoft, controlla Chromium, Firefox e WebKit tramite una singola API. Il suo modello di actionability aspetta che gli elementi siano visibili, stabili e davvero interattivi prima di eseguire un’azione — riducendo i problemi di timing che affliggono molti script Selenium. Gestisce anche i browser context in modo più efficiente, permettendo sessioni isolate senza il costo di avviare ogni volta un browser completamente nuovo.
Quando Playwright sostituisce completamente Selenium
Per lo scraping in senso stretto — non per il browser testing dentro un’infrastruttura Selenium già esistente — nel 2026 Playwright è spesso semplicemente lo strumento migliore. Creazione dei context più rapida, impronta risorse più leggera per pagina, supporto async nativo e intercettazione della rete integrata. Se stai iniziando un progetto di scraping da zero e non hai una suite di test Selenium da preservare, c’è poca ragione per partire da Selenium.
L’eccezione: se il tuo team ha già un’infrastruttura di test basata su Selenium, oppure ti serve una personalizzazione del profilo browser molto specifica che Playwright non supporta altrettanto bene, Selenium continua ad avere un suo posto.
Come funziona scrapy-playwright
scrapy-playwright è un download handler per Scrapy che instrada solo le richieste contrassegnate con meta={"playwright": True} attraverso un browser reale — tutto il resto resta sul percorso HTTP rapido e asincrono di Scrapy. Ecco uno spider semplificato che esegue il crawl di un catalogo paginato in cui le schede prodotto vengono renderizzate via JS lato client:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Solo le pagine che davvero hanno bisogno di rendering passano dal browser. È questo il senso dell’approccio ibrido — non paghi il costo del browser per ogni singola richiesta, ma solo per quelle che lo richiedono.
Scrapy-Splash vs. Scrapy-Playwright: quale middleware usare
Scrapy-Splash richiede di avviare un servizio Splash separato via Docker e scrivere script Lua per le interazioni — funziona, ma è una soluzione più pesante e più vecchia. scrapy-playwright si integra direttamente nell’event loop asincrono di Scrapy, supporta tutti e tre i principali motori browser e gestisce interazioni complesse senza dover aggiungere un secondo linguaggio di scripting. Se stai iniziando un progetto nuovo nel 2026, non c’è davvero motivo di scegliere Splash.
Architettura ibrida pronta per la produzione
Molti articoli dicono “puoi combinare Scrapy e Selenium” e si fermano lì. Non è un’architettura. È un suggerimento. Ecco come appare davvero una configurazione di produzione.
Il flusso: uno scheduler di Scrapy instrada le richieste attraverso un URL router che verifica se una pagina è statica o dinamica. Le richieste statiche passano direttamente attraverso il downloader standard di Scrapy. Le richieste dinamiche vengono contrassegnate e inviate al middleware Playwright, che gestisce un pool di browser context. Entrambi i percorsi confluiscono poi nello stesso item pipeline per validazione, deduplicazione ed export — che i dati arrivino da HTML grezzo o da un DOM renderizzato, finiscono nello stesso output JSON, CSV o database.
Qualche nota di deployment se vuoi portarlo in produzione: usa Docker per containerizzare, così i binari del browser Playwright arrivano in modo coerente in tutti gli ambienti; limita i context Playwright concorrenti in base alla RAM disponibile (io non andrei oltre 8-10 context su una macchina standard da 4 GB); ed esegui i job schedulati tramite cron o una pipeline CI/CD invece di lasciare un processo in esecuzione infinita.
Questa configurazione ti dà il massimo controllo. Significa anche che sei tu a gestire gli aggiornamenti dei binari del browser, i bug del ciclo di vita dei context (pagine non chiuse che bloccano il crawl), la rotazione dei proxy e qualunque patch anti-bot ti serva aggiungere. È un impegno ingegneristico vero, ed è giusto dirlo apertamente prima di prenderlo in carico.
Per i team che vogliono output strutturato senza gestire tutta quell’infrastruttura, la CLI di Thunderbit affronta lo stesso problema da un’altra angolazione:
thunderbit batch extract --schema schema.json --file urls.txt
Stesso output JSON strutturato. Niente codice dello spider, niente pool di browser, niente plumbing anti-bot da mantenere. Sacrifichi un po’ di personalizzazione per arrivare prima in produzione — è un compromesso legittimo, non un miglioramento universale, e dipende interamente da quanto controllo richiede davvero il tuo progetto.
La strada “salta il framework”: quando una API di scraping AI batte entrambi
A un certo punto, uno sviluppatore si rende conto di non aver bisogno di un framework di crawling. Gli servono dati strutturati da 500 URL noti, e costruire uno spider, un browser pool e un layer anti-bot per quello sembra eccessivo — perché spesso lo è davvero.
È il vuoto che Thunderbit è pensato per colmare, e lo dico subito: non è un sostituto di Scrapy per un crawl complesso, ricorsivo e con logiche custom. È uno strumento diverso per un problema diverso e più circoscritto.
Open API: POST /extract accetta uno schema JSON e restituisce dati strutturati che lo rispettano — non HTML grezzo, non una pila di Markdown da parsare a mano. POST /distill fa il contrario, restituendo Markdown pulito pronto per una pipeline RAG o un LLM. Il servizio gestito supporta rendering JavaScript e gestione anti-bot, quindi non devi occuparti tu di quell’infrastruttura. La guida attuale Distill vs. Extract indica 1 credito per pagina Distill e 20 per pagina Extract; controlla la documentazione aggiornata prima di fare budget, perché i termini del prodotto possono cambiare.
MCP Server: per agenti AI come Claude o Cursor, il server MCP di Thunderbit espone distillazione, estrazione strutturata, suggerimento dei campi e job batch come strumenti, permettendo a un agente di recuperare dati web aggiornati nel bel mezzo di un’attività senza uscire dal proprio ambiente.
CLI: la Thunderbit CLI documentata supporta comandi come thunderbit extract <url> --schema schema.json e si integra bene nei flussi da terminale e nei job schedulati. Puoi anche passare il Markdown distillato a un altro strumento per ricerche rapide e occasionali.
Se preferisci saltare del tutto il codice, la Thunderbit Chrome Extension copre lo stesso terreno con un’interfaccia point-and-click, ed è molto utile se nel team ci sono anche persone non tecniche che hanno bisogno di dati senza toccare il terminale. Ho scritto di più sul panorama più ampio dell’AI web scraping e del web scraping senza codice se vuoi una visione più completa.
Sii onesto con te stesso su quale categoria appartieni: Scrapy resta la scelta giusta per crawl complessi su più siti, con logiche personalizzate e follow ricorsivo dei link. Selenium o Playwright per flussi molto interattivi. Ma “mi servono dati strutturati da questi URL noti” è un problema più ristretto di quanto uno dei due strumenti sia stato pensato per risolvere, e una API può davvero eliminare il codice dello spider, il plumbing anti-bot e la manutenzione continua che deriva dal gestire da soli quell’infrastruttura.
Scrapy vs. Selenium vs. Playwright vs. API AI: confronto diretto
| Funzionalità | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Supporto linguaggi | Solo Python | Python, Java, C#, JS, Ruby | Python | REST (qualsiasi linguaggio) |
| Rendering JS | No (serve middleware) | Sì | Sì | Sì, integrato |
| Async/concorrenza | Nativo, elevato | Limitato per istanza | Nativo tramite Scrapy | Gestito lato server |
| Gestione anti-bot | Fai-da-te | Fai-da-te | Parziale | Integrata |
| Pipeline/export dati | Integrato | Fai-da-te | Integrato | JSON strutturato in output |
| Complessità di setup | Media | Bassa all’inizio, alta su larga scala | Da media ad alta | Minima |
| Carico di manutenzione | Basso-medio | Alto | Medio | Quasi nullo |
| Ideale per | Crawl statici ad alto volume | Flussi molto interattivi | Siti misti statici/dinamici | URL noti, output strutturato |
Se stai valutando altre opzioni oltre a queste quattro, vale anche la pena dare un’occhiata a come si posizionano le alternative a Instant Data Scraper e i migliori AI web scraper — il panorama è diventato affollato, e non tutti gli strumenti risolvono lo stesso problema.
Note legali ed etiche per il web scraping nel 2026
La tengo breve perché non è il focus principale, ma è importante. L’impostazione ROBOTSTXT_OBEY di Scrapy fa rispettare al tuo spider le regole di robots.txt — buona pratica, ma utile sapere che il Robots Exclusion Protocol specifica esplicitamente che le sue regole non equivalgono a un’autorizzazione legale all’accesso. Selenium e Playwright non hanno alcun supporto nativo per robots.txt — tutta la responsabilità è tua. Qualunque strumento tu scelga, verifica i termini di servizio del sito e la normativa applicabile nella tua giurisdizione prima di fare scraping e riutilizzare i dati; il fatto che qualcosa sia visibile pubblicamente non significa automaticamente che sia sempre lecito usarlo ovunque.
Scegliere lo strumento giusto per il tuo progetto di scraping nel 2026
La decisione si riduce davvero a quattro domande: che tipo di contenuto hai, quanto è grande la scala, quanta interazione ti serve e quanta manutenzione continua sei disposto ad accettare. Pagine statiche su larga scala? Scrapy. Pagine molto pesanti in JS con interazioni reali? Selenium o Playwright. Un mix di entrambe? Costruisci l’ibrido. URL noti in cui servono solo dati strutturati e poca manutenzione? Un’API come quella di Thunderbit probabilmente ti fa risparmiare più tempo di quanto costi.
"Scrapy vs. Selenium" non è mai stata davvero la domanda completa — era solo la cornice più comune. Playwright ha cambiato la zona centrale, e le API di estrazione AI hanno aperto una nuova strada per chi ha capito di stare costruendo infrastruttura invece di risolvere un problema di business. Vale la pena provare il livello gratuito prima di impegnarsi in una direzione o nell’altra — suggest-fields è gratuito e distill costa un solo credito, quindi puoi verificare se il percorso API fa per te prima di scrivere una riga di codice per lo spider.
FAQ
Scrapy è più veloce di Selenium per il web scraping? Nei miei test, sì — spesso di un ordine di grandezza sulle pagine statiche, perché l’architettura asincrona di Scrapy elimina del tutto l’overhead del browser. Il divario si riduce quando Scrapy usa il middleware Playwright per pagine molto pesanti in JS, ma Scrapy mantiene comunque il vantaggio sul throughput complessivo nei carichi misti, perché le pagine senza JS restano sul percorso rapido.
Scrapy può gestire pagine renderizzate in JavaScript?
Non da solo — Scrapy vede solo l’HTML iniziale. Aggiungere scrapy-playwright o il più vecchio Scrapy-Splash come middleware permette di renderizzare selettivamente richieste specifiche attraverso un browser vero, mantenendo il resto del crawl sul percorso nativo e più veloce di Scrapy.
Quando dovrei usare Selenium invece di Scrapy? Quando ti serve l’interazione completa con il browser — login multi-step, click attraverso wizard, compilazione di form — e il numero di pagine è moderato, non enorme. È anche la scelta sensata se hai già un’infrastruttura di test basata su Selenium che vuoi riutilizzare per lo scraping.
Playwright è meglio di Selenium per lo scraping nel 2026? Per lo scraping specificamente, in generale sì — Playwright tende a offrire prestazioni migliori, auto-wait integrato e un’impronta di risorse più leggera per ogni browser context. Selenium conserva ancora un vantaggio per i team che usano suite di test cross-browser consolidate che Playwright non è nato per sostituire.
Cos’è una API di scraping AI e quando sostituisce Scrapy o Selenium? Una API di scraping AI, come l’Open API di Thunderbit, gestisce rendering JS, difese anti-bot ed estrazione dati lato server, restituendo JSON strutturato che segue uno schema definito da te. È la scelta giusta quando hai URL noti e ti serve output strutturato senza costruire o mantenere l’infrastruttura di crawling — non è un sostituto di Scrapy per crawl complessi, ricorsivi e con logiche personalizzate.
Scopri di più
