Recensione di Puppeteer 24.16: automazione browser incentrata su Chrome, senza orchestrazione del crawling

Puppeteer è la libreria Node di Google per controllare un vero Chrome da JavaScript: tu scrivi l’automazione, il Chrome DevTools Protocol trasporta i comandi e un browser completo renderizza la pagina prima che tu ne legga anche solo un byte. Il progetto vive su puppeteer/puppeteer su GitHub: licenza Apache-2.0, scritto in TypeScript, e con circa 95,3k stelle (95.307 nel giorno in cui ho preso lo snapshot). Il suo posizionamento ufficiale è volutamente ristretto — "un’API JavaScript per controllare Chrome (ed experimentalmente Firefox)" — e questo ti dice sia cosa sia, sia altrettanto utilmente cosa non sia.

Ho messo alla prova Puppeteer 24.16.0 con lo stesso server di fixture e gli stessi demo pubblici che usiamo per ogni libreria di automazione browser: un catalogo statico con paginazione, un articolo, un catalogo renderizzato via JavaScript, una JSON API, una route che restituisce 500, un piccolo grafo di crawl, oltre a Books to Scrape e Quotes to Scrape. Il rendering è stato pulito, senza fronzoli. Mi ha lasciato però esattamente un compito sulla scrivania — lo stesso che lascia ogni libreria di browser headless — e raccontare onestamente quel vuoto è gran parte di ciò che separa una recensione utile da un comunicato stampa.

Un numero è saltato fuori più di altri. Su una pagina i cui dati arrivano da un endpoint JSON, Puppeteer ha estratto tutti gli 8 record senza toccare il DOM: ha eseguito fetch dentro la pagina e ha letto direttamente l’oggetto risposta. Questo, insieme al rendering nativo con screenshot funzionanti, è la vera natura dello strumento: un renderer Chrome maturo, non un framework di crawling, e la differenza conta prima ancora di scrivere una riga di codice.

Cos’è davvero Puppeteer (e con cosa compete)

L’etichetta della categoria qui fa davvero la differenza, quindi partiamo da lì. Puppeteer è una libreria di automazione browser. Avvia Chrome, apre le pagine, lascia eseguire il JavaScript della pagina e ti restituisce il risultato renderizzato da leggere o da catturare in screenshot. È questo il motivo per cui lo scegli al posto di un client HTTP più un parser HTML: vuoi la pagina dopo l’esecuzione degli script, non il guscio vuoto che il server invia per primo.

Per forma, compete con le altre librerie per browser reali — Playwright e Selenium — non con framework di crawling come Scrapy o con strumenti LLM-Markdown. Se punti Puppeteer su mille URL e ti aspetti che faccia coda, deduplichi, limiti il ritmo con tatto e scriva un dataset, stai portando un renderer a risolvere un problema di crawling. Renderizzerà ogni pagina in modo impeccabile, ma non gestirà alcuna orchestrazione. (È un confine di ambito, non un bug — ci torno perché è il punto più importante da interiorizzare prima di adottare lo strumento.)

Puppeteer nasce dal team Chrome di Google, ed è per questo che è Chrome-first per progettazione e che la sua API sembra un guanto sottile e rodato sopra il protocollo di debug del browser. È abbastanza maturo da essere noioso nel senso buono: i metodi che servono sono stabili da anni, la documentazione è approfondita e l’ecosistema attorno è solido.

Rendering nativo e pattern fetch in pagina

Ci sono due comportamenti che vale la pena isolare dalla tabella dei risultati perché definiscono come lo useresti davvero.

Primo, il rendering nativo. Il catalogo renderizzato in JavaScript — una pagina che costruisce la griglia prodotti lato client dopo il caricamento — è tornato con 8/8, con uno screenshot dell’intera pagina salvato su disco. La configurazione era minimale, ma prevedeva l’attesa del contenuto target dopo goto. Anche la pagina pubblica Quotes to Scrape JS ha restituito tutte e dieci le citazioni con lo stesso schema. Questi sono risultati su fixture, non un punteggio generale di recall sul rendering.

Secondo, la fixture JSON-API caricava i prodotti da /api/dynamic-products. Eseguire un fetch same-origin tramite page.evaluate ha restituito tutti gli otto record senza analizzare le righe renderizzate. Questo è un pattern generale di valutazione nel browser, non una funzionalità di discovery specifica di Puppeteer. Può semplificare l’estrazione quando endpoint e contratto della richiesta sono noti; header di autenticazione, token runtime, policy di credenziali, CORS/CSP, service worker e paginazione possono comunque far divergere una richiesta applicativa.

Il terzo elemento da portarsi via non è un numero, ma il quadro generale: Puppeteer è un renderer Chrome maturo e non un crawler. Entrambe le cose sono vere, e la seconda è quella che molti articoli sorvolano.

Come Puppeteer parla con Chrome

Su Chrome, Puppeteer usa il Chrome DevTools Protocol (CDP), il canale JSON su WebSocket usato dagli strumenti DevTools del browser. puppeteer.launch() avvia Chrome e apre quella connessione; chiamate come goto, $$eval e screenshot espongono le operazioni del browser tramite un’API di livello superiore. Il supporto Firefox segue il percorso WebDriver BiDi descritto più sotto, quindi non tutte le operazioni di Puppeteer sono universalmente comandi CDP.

page.evaluate esegue una funzione nel contesto della pagina, quindi un fetch('/api/...') relativo usa l’origine di quella pagina e può riutilizzare cookie e stato di sessione idonei. Non riproduce automaticamente header di autorizzazione creati dall’app, opzioni di richiesta, token o comportamento dei service worker. Su questa fixture same-origin ha restituito JSON direttamente; le richieste in produzione vanno verificate rispetto al contratto reale.

È anche il motivo per cui Puppeteer è pesante. Ogni pagina è una vera scheda del browser con un motore di rendering reale dietro. Questo ti dà correttezza sulle pagine ricche di JavaScript, ma costa memoria e tempo di avvio rispetto a un fetch solo HTTP. Non esiste rendering gratis; CDP rende solo la spesa più leggibile.

La questione del motore, detta senza giri di parole

C’è una scorciatoia molto diffusa secondo cui Puppeteer sarebbe "solo Chrome". Per la versione che ho testato, è falso, e correggerlo cambia il confronto.

Sia Chrome for Developers sia Mozilla hanno documentato il passaggio a Firefox quando è arrivato. La build che ho eseguito, 24.16.0, è ben oltre v23, quindi dire "solo Chrome" sottostima ciò che c’è davvero nel pacchetto. L’assenza di WebKit, insieme alla relativa giovinezza del supporto cross-engine rispetto a Playwright, è la vera differenza di ampiezza — non "un motore contro tre".

Il percorso Firefox/BiDi è documentato e disponibile nella versione testata, ma non ho eseguito le mie fixture su quel motore, quindi sto riportando una capacità, non una misurazione. Se Firefox è fondamentale per i tuoi target, verifica sul tuo sito prima di impegnarti. Per chi vuole il confronto completo su motore e linguaggio, il nostro confronto Playwright-vs-Puppeteer fa passare entrambe le librerie attraverso gli stessi test e chiude lì la domanda "quale scegliere"; qui il soggetto è solo Puppeteer.

Setup e installazione: la parte pesante è il browser

Il percorso predefinito npm install puppeteer scarica una build compatibile di Chrome for Testing. Quel comportamento può essere saltato o reindirizzato tramite configurazione, e l’utente può puntare Puppeteer a un altro eseguibile, quindi l’allineamento delle versioni dipende dalla scelta di deployment. Il download del browser è stato la parte più pesante di questa installazione; uno snapshot di audit del package manager non va trattato come proprietà di sicurezza duratura.

L’auto-bundling è un vantaggio ergonomico reale, ma anche un costo di ingombro reale, e vale la pena nominare entrambe le facce. Il vantaggio: non devi cercare un browser compatibile né bloccare le versioni a mano; npm install ti fornisce una coppia funzionante. Il costo: stai scaricando un browser, quindi prepara spazio su disco e banda, soprattutto in CI, dove una cache fredda paga quel prezzo su ogni runner nuovo.

È anche un contrasto reale con Playwright, che separa i due passaggi: installi la libreria e poi esegui un npx playwright install separato per scaricare le build del browser. Nessuno dei due approcci è problematico; semplicemente falliscono in modi diversi. Il comando unico di Puppeteer può sorprenderti per dimensioni su una connessione tariffata, mentre il secondo passaggio di Playwright può sorprenderti perché ti dimentichi di eseguirlo. È bene sapere quale stai usando.

Risultati pratici

Ogni test è stato eseguito contro un server di fixture locale su 127.0.0.1 più due siti pubblici di pratica, su Node v22.22.3, macOS arm64, con Puppeteer 24.16.0 e il suo Chrome incluso. La verità a terra per ogni fixture è stata annotata prima dell’esecuzione, quindi il recall viene misurato contro un insieme atteso fisso e non contro quello che Puppeteer ha stampato per caso.

Il pacchetto pubblico di ricerca include il fixture server, il test runner e la ground truth. Il lock delle dipendenze e il riepilogo grezzo dell’esecuzione sono stati volutamente esclusi dal bundle di pubblicazione perché la revisione di sicurezza rigorosa ha respinto i dati del dependency lock e i materiali specifici dell’ambiente. Per riprodurre la fixture locale sicura, esegui npm install e poi node run_puppeteer_material_tests.mjs dentro tools/puppeteer/tests, quindi confronta il risultato con la ground truth pubblicata. Le demo pubbliche possono cambiare, quindi la fixture locale è la base stabile per i controlli sui conteggi attesi.

Per una ricostruzione storica esatta delle dipendenze, crea e controlla localmente un nuovo lockfile invece di trattare un lock non pubblicato come prova pubblica.

Alcuni di questi meritano una frase in più rispetto alla tabella.

Il codice di paginazione scritto ad hoc ha recuperato tutti i 12 elementi attesi del catalogo. Il selettore dell’articolo ha recuperato il titolo e i tre paragrafi di corpo attesi; il boilerplate circostante è rimasto disponibile nel DOM. Puppeteer ha fornito il DOM renderizzato, mentre la logica dei selettori — non Puppeteer stesso — ha definito cosa contasse come contenuto dell’articolo.

Sulla route HTTP 500 testata, goto ha restituito un oggetto risposta con status 500 ispezionabile e non ha sollevato eccezioni. Questo non dice nulla su timeout, fallimenti DNS, crash del browser, frame scollegati o altri errori di navigazione, che restano da gestire esplicitamente.

Il grafo di crawl è quello che racconta davvero tutta la storia. Attraversare i link interni della fixture fino a 12 pagine, tenendo traccia della profondità per non rivisitare gli URL, ha richiesto una breadth-first search scritta a mano — perché Puppeteer non ha una coda di crawl integrata. Ha trovato tutte e 12 le pagine nelle profondità {0:1, 1:4, 2:7}, il che significa che la BFS ha funzionato. Ma la BFS era mia. Puppeteer ha renderizzato ogni pagina; la logica di attraversamento del sito era codice scritto da me. Per dodici pagine è una dozzina di righe e nessun problema. Per migliaia di URL con deduplica, retry e delay di cortesia, quelle dozzine di righe diventano un progetto.

Un avvertimento che ripeto perché è facile abusarne: gli artifact includono i tempi per test, ma si tratta di osservazioni a singola esecuzione e su una sola macchina, non di benchmark. Non sto confrontando la velocità di Puppeteer con quella di altri strumenti sulla base di un portatile e di una sola run. I numeri supportano il recall e il comportamento su otto tipi di pagina diversi — non una rivendicazione da cronometro.

Cosa non ho testato

Per evitare che i risultati vengano letti in modo più ampio di quanto permettano, ecco cosa è rimasto fuori dall’esecuzione e quindi fuori da questi numeri:

Nessuno di questi è un difetto. Sono i confini di ciò che una sola esecuzione su fixture può onestamente affermare.

Pro e contro

Pro:

• Rendering JavaScript nativo con attesa esplicita del contenuto: 8/8 sulla fixture dinamica e tutte le dieci citazioni sul demo pubblico, con screenshot.
• I selettori scritti per paginazione e articolo hanno recuperato gli elementi attesi della fixture.
• fetch in pagina ha restituito tutti gli otto record dall’endpoint same-origin noto senza parsing del DOM.
• Il 500 HTTP testato è tornato come risposta ispezionabile senza eccezioni.
• L’installazione predefinita scarica una build compatibile di Chrome for Testing; restano possibili configurazioni alternative con eseguibile diverso o senza download.
• API matura e focalizzata su Chrome via CDP, con ecosistema profondo e documentazione solida. Apache-2.0.
• Più ampio della sua reputazione: supporto documentato per Firefox via WebDriver BiDi da v23.

Contro:

• Nessuna coda di crawl integrata, nessun writer di dataset, nessun throttle: per il crawling su larga scala serve codice tuo o un wrapper.
• Nessun motore WebKit, e la sua storia cross-engine è più giovane di quella di Playwright.
• Peso reale del browser: un Chrome incluso da scaricare e un costo di memoria per pagina rispetto agli strumenti solo HTTP.
• Basato su Node; usarlo da un altro linguaggio significa costruire e mantenere un ponte.
• La versione che ho eseguito (24.16.0) è indietro di una major rispetto all’ultima disponibile su npm (25.3.0): verifica di nuovo sulla release corrente prima di fidarti dei numeri esatti.

Per chi è adatto, e chi dovrebbe evitarlo

Scegli Puppeteer se lavori in Node, i tuoi target si renderizzano bene in Chrome (la maggior parte sì) e vuoi una libreria matura e focalizzata che trasformi "la pagina dopo l’esecuzione del suo JavaScript" in qualcosa che puoi leggere e catturare in screenshot. Per estrarre un gruppo di pagine dinamiche, oppure recuperare una JSON API usando la sessione della pagina, o salvare screenshot renderizzati come prova, è un default forte e poco complicato. L’opzione Firefox via BiDi c’è se ti serve crescere in quella direzione, e l’ecosistema significa che la maggior parte dei problemi che incontri è già stata incontrata da altri.

Pensaci due volte se il tuo problema è l’orchestrazione del crawl più che il rendering. Se devi attraversare centinaia o migliaia di URL con deduplica, retry e rate limit, Puppeteer da solo ti costringerà a ricostruire un crawler a mano — ed è il livello sbagliato per lui. Evita del tutto un browser headless se le tue pagine non hanno davvero bisogno di JavaScript per rivelare i dati; quando una richiesta HTTP e un parser restituiscono il contenuto, un browser vero è un sovradimensionamento costoso che consuma solo memoria e tempo di setup. E se ti serve fedeltà WebKit o un client in un linguaggio non JavaScript, questo non è lo strumento giusto per quell’asse.

Alternative e dove si colloca Thunderbit

La premessa onesta prima di tutto: Puppeteer è gratuito, Apache-2.0, self-hosted, e ogni parte dell’esecuzione resta in carico a te — la flotta di browser, il codice di crawl che ci aggiungi sopra e la continua corsa agli armamenti contro i bot. Per molti progetti questa responsabilità è esattamente la scelta giusta, e nessun servizio gestito renderizzerà una pagina autorizzata più economicamente di un browser che hai già a disposizione.

Nell’open source, i confronti utili si fanno per compito, non per logo. Per il crawling su scala, Crawlee è il compagno naturale: il suo PuppeteerCrawler avvolge Puppeteer con la request queue, il dataset e il throttling che la libreria omette di proposito, così ti tieni il rendering ma ottieni l’orchestrazione. Se il tuo obiettivo di output è Markdown pulito per una pipeline LLM invece del DOM renderizzato, Crawl4AI guida un browser reale e produce esattamente quello. Se le tue pagine non hanno bisogno di un browser, un framework HTTP-first come Scrapy appartiene a una categoria diversa e più leggera. Quando stai valutando più opzioni insieme, il nostro panoramica degli scraper open source mette le categorie una accanto all’altra.

Un servizio gestito come Thunderbit sposta operazione del browser ed estrazione dietro un’API. Non è stato eseguito attraverso queste fixture di Puppeteer, quindi questa recensione non fa alcuna affermazione comparabile su rendering, blocchi, qualità dell’estrazione o costi. Il confine decisionale è la proprietà operativa: mantenere tu il browser e il codice di crawl, oppure pagare un provider per gestire parte di quello strato.

Con Puppeteer non c’è un canone d’uso del vendor, ma compute, banda, manutenzione del browser, orchestrazione e operations restano tuoi. Una soluzione gestita addebita l’uso e sposta parte di quella responsabilità sul provider. Questo esperimento non ha confrontato i risultati.

Prova Thunderbit per l’estrazione di dati web

Verdetto

Puppeteer 24.16.0 merita di essere valutato se lavori in Node e ti serve automazione browser incentrata su Chrome. Il codice di fixture scritto ad hoc ha recuperato 12 elementi statici, otto elementi dinamici e dieci citazioni dal demo pubblico; la nota API same-origin ha restituito otto record tramite page.evaluate; gli screenshot hanno funzionato; e il 500 HTTP testato è rimasto ispezionabile. Questi risultati appartengono alle fixture nominate e a una major version precedente, non al recall di estrazione in generale.

Però le affermazioni vanno dimensionate correttamente. Puppeteer è un renderer, non un crawler: la mia navigazione di 12 pagine ha richiesto una BFS scritta a mano perché non esiste una coda integrata, e su scala quel vuoto è lavoro vero — affidalo a Crawlee oppure costruisciti da solo la meccanica. È Chrome-first con supporto documentato per Firefox via BiDi ma senza WebKit, quindi non è lo strumento per l’ampiezza cross-engine. Porta il peso di un browser vero. E ho testato la 24.16.0 mentre l’ultima su npm era la 25.3.0, quindi ritesta sulla versione corrente prima di fidarti dei numeri esatti. Con questi quattro punti chiari fin dall’inizio, Puppeteer è una libreria eccellente per l’automazione Chrome. Se ti aspetti che ti faccia crawling di un sito, finirai per scrivere il crawler che pensavi di scaricare.

Prova Thunderbit per l’estrazione di dati web Get Started Free

FAQ

Puppeteer renderizza pagine JavaScript o serve un plugin? Le renderizza nativamente, senza plugin. Nella mia fixture dinamica ha restituito 8 su 8 prodotti costruiti lato client con recall 1.0 e uno screenshot dell’intera pagina, e la pagina pubblica Quotes to Scrape JS ha restituito allo stesso modo tutte e 10 le citazioni — un semplice goto, poi lettura del DOM renderizzato. Siccome Puppeteer controlla un vero Chrome tramite il DevTools Protocol, gli script della pagina vengono davvero eseguiti prima che tu legga qualsiasi cosa.

Puppeteer può estrarre una JSON API senza parsare l’HTML? Sì, quando endpoint e contratto della richiesta lo consentono. page.evaluate può inviare una richiesta dall’origine della pagina e può riutilizzare cookie idonei, ma non riproduce automaticamente header, token, opzioni o comportamento del service worker creati dall’app. Sulla fixture same-origin ha restituito tutti gli otto record senza parsing del DOM.

Puppeteer è un web crawler? No: è una libreria di automazione browser, non un framework di crawling. Non ha coda di richieste, writer di dataset o throttle integrati, quindi il mio crawl di 12 pagine (profondità {0:1, 1:4, 2:7}) ha richiesto una breadth-first search scritta a mano. È un confine di ambito, non un difetto. Per il crawling su scala, affiancalo a un wrapper come PuppeteerCrawler di Crawlee, che aggiunge la coda e la gestione del dataset che Puppeteer lascia fuori.

Puppeteer è solo per Chrome? Non più. È Chrome-first via CDP, ma da v23 ha supporto documentato per Firefox tramite WebDriver BiDi, e la versione che ho testato (24.16.0) è ben oltre quel punto. Quello che non controlla è WebKit, e la sua storia cross-engine è più giovane di quella di Playwright: questa, non "solo Chrome", è la limitazione corretta. Qui ho esercitato solo Chrome, quindi riporto il supporto Firefox via BiDi come documentato, non come qualcosa che ho misurato.

Cosa scarica davvero l’installazione di Puppeteer? Di default, npm install puppeteer scarica una build compatibile di Chrome for Testing. Il download può essere saltato o reindirizzato, e si può configurare un altro eseguibile, quindi l’allineamento delle versioni dipende dalle scelte di deployment. Metti in budget spazio su disco e banda per il browser, soprattutto su runner CI senza cache. Questa recensione ha testato la 24.16.0; riesegui le fixture core sulla release corrente al momento della pubblicazione.