Skip to main content
La maggior parte degli articoli sull’automazione tratta un solo strumento. È più utile osservare l’intero panorama: quali runtime esistono, in cosa eccellono e quale criterio conta davvero nello scraping. Il criterio decisivo non è linguaggio o motore, ma se il runtime è headless per impostazione predefinita o progettato con interfaccia grafica. Quasi tutto l’ecosistema appartiene al primo gruppo; le piattaforme integrate, di cui Octoparse è l’esempio più chiaro, al secondo. Questa distinzione rivela sul comportamento nei siti reali più di qualsiasi scheda tecnica.

Panoramica

La riga in grassetto mostra Octoparse, progettato con interfaccia grafica e un runtime dedicato allo scraping. ParseHub appartiene alla stessa categoria, ma Octoparse è l’esempio più diffuso.

Librerie di automazione open source

Qui inizia gran parte dello scraping basato sul codice. Puppeteer controlla Chromium da Node: rapido, moderno e limitato a Chrome. Playwright, spesso considerato il suo successore, supporta Chromium, Firefox e WebKit da Node, Python, Java e .NET ed è generalmente la scelta predefinita per nuovi progetti. Selenium è più anziano, lento e pesante, ma tramite WebDriver comunica con quasi ogni browser, caratteristica importante per Safari, Edge legacy o browser mobili. Il resto si divide per linguaggio ed ecosistema. Splash esegue rendering JS nelle pipeline Scrapy con Lua; WebdriverIO offre a Node un’API WebDriver/CDP simile a un framework di test; in Go si usano chromedp e Rod; Pyppeteer porta la forma di Puppeteer in Python; HtmlUnit è un browser Java puro utile quando la JVM conta più della fedeltà del motore JS. Tutti funzionano normalmente in headless. Possono mostrare una finestra, ma occorre uno schermo reale o virtuale come Xvfb e gli script comuni non lo fanno: la loro condizione naturale è invisibile.

Varianti di discrezione e anti-rilevamento

Quando il sito esegue il fingerprinting, Puppeteer o Selenium standard vengono rilevati tramite navigator.webdriver, plugin mancanti, User-Agent headless e anomalie canvas/WebGL. Le varianti di discrezione correggono queste falle. puppeteer-extra-stealth aggiunge a Puppeteer numerose tecniche di elusione. undetected-chromedriver svolge lo stesso ruolo per Chrome tramite Selenium ed è comune in Python. nodriver, dello stesso autore, usa CDP senza driver per simulare una sessione organica anche in rete. Patchright integra patch analoghe in un fork di Playwright. Restano headless per impostazione predefinita: riducono la distanza dal browser “reale”, ma devono rincorrere sistemi di rilevamento in continuo aggiornamento.

API browser cloud

Anziché ospitare browser, si chiama un endpoint HTTP e si riceve una pagina renderizzata o una sessione controllabile. Browserless è disponibile gestito o self-hosted e compatibile con Puppeteer/Playwright. Browserbase e Steel.dev sono orientati agli agenti AI. Bright Data Scraping Browser e Zyte API abbinano esecuzione browser e sblocco anti-bot. ScrapingBee e ScrapingAnt offrono API più semplici per piccoli team. Apify integra Browser Actors, code e archiviazione. Questi browser funzionano su server senza schermo: headless è l’unica modalità economicamente sensata e l’utente vede soltanto il risultato.

Piattaforme integrate di scraping

Questa categoria è strutturalmente diversa. Non è una libreria o un’API a cui inviare URL, ma un editor visuale con browser incorporato: lo scraper viene creato facendo clic sulla pagina, non scrivendo selettori. Octoparse usa due runtime: Electron Chromium, alleggerito e ottimizzato per le attività comuni, e Chrome for Testing controllato da Puppeteer per i siti che richiedono piena autenticità. Entrambi sono progettati con interfaccia grafica, perché la pagina visibile è l’editor. ParseHub adotta un approccio simile; anche la storica estensione Web Scraper.io appartiene a questa tradizione. È l’unica categoria in cui l’interfaccia grafica è la modalità predefinita e non un’opzione: è una scelta progettuale indispensabile al flusso di lavoro.

Headless o interfaccia grafica: il criterio decisivo

Headless è adatto quando l’operatore è uno sviluppatore: scrive codice, legge log e distribuisce su server senza schermi. L’interfaccia grafica è adatta quando la pagina stessa è l’interfaccia: si selezionano elementi, si osserva l’attività, si interviene su accessi o CAPTCHA e si esegue il debug visivamente. È il modello Octoparse; il suo Electron ottimizzato dimostra che un browser visibile non deve necessariamente essere pesante. Ne derivano due conseguenze:
  • Rilevamento bot. I browser reali visibili, con rendering ed eventi di input autentici, espongono meno segnali ricercati dai servizi anti-bot. Gli strumenti headless aggiungono livelli di discrezione; le piattaforme con interfaccia grafica ottengono gran parte del vantaggio nativamente.
  • Competenze dell’operatore. Headless presuppone che qualcuno gestisca script, Proxy, risolutore CAPTCHA e distribuzione. Le piattaforme visuali si rivolgono ad analisti, operatori e team growth, mentre la piattaforma gestisce la parte tecnica.
Per approfondire questa scelta, consulta Browser con interfaccia grafica e headless.

Come scegliere

  • Scraper scritto in codice per eseguire il rendering? Playwright è la scelta predefinita; Puppeteer se basta Chrome e si usa Node; Selenium se occorre un browser non supportato dagli altri.
  • Il sito esegue fingerprinting avanzato? Usa puppeteer-extra-stealth, undetected-chromedriver o nodriver, oppure un’API cloud con anti-bot integrato.
  • Non vuoi ospitare browser? Browserless, Browserbase o Steel per il rendering; Zyte API o Bright Data per lo sblocco incluso.
  • Non vuoi scrivere codice? Una piattaforma integrata come Octoparse o ParseHub offre selezione visuale, runtime e Estrazione cloud.
  • L’operatore non è tecnico e il sito ha difese anti-bot? È il caso più favorevole all’interfaccia grafica: meno segnali e possibilità d’intervento sui CAPTCHA.
La scelta non è quasi mai definitiva. Molti team iniziano con un’API cloud per un rendering occasionale, passano a una libreria con discrezione per attività ripetute e adottano una piattaforma integrata quando l’operatore non deve più essere lo sviluppatore.