Recensione di Browsertrix Crawler: archivia ciò che il browser ha fatto, non ciò che dice il codice

Browsertrix Crawler è il crawler di archiviazione di Webrecorder: una singola immagine Docker che guida un vero Chromium tramite Puppeteer, registra tutto ciò che il browser recupera e lo salva in WARC — il formato standard per gli archivi web — con la possibilità di racchiuderlo in un pacchetto WACZ con indice, elenco delle pagine e log. Il suo scopo è proprio ciò che lo distingue dagli strumenti di scraping a cui assomiglia solo in apparenza. Uno scraper va a prendere i dati e poi lascia perdere la pagina una volta ottenuti i campi; un archiviatore conserva la visita stessa — i byte, gli header, l’ordine in cui sono arrivati — così la pagina può essere riaperta molto tempo dopo che il sito è cambiato o sparito. Webrecorder porta avanti questo strato dell’infrastruttura del web, inclusi formati e stack di replay, da ben prima che l’archiviazione sembrasse una categoria di prodotto, e biblioteche, redazioni e ricercatori ci lavorano sopra.

Ho eseguito la v1.14.0 in Docker su un fixture locale con quattro classi di endpoint volutamente diverse, strumentando entrambi i lati del crawl: i record WARC per il contenuto archiviato e un contatore lato server per le richieste effettive. La distinzione davvero utile non era semplicemente statico contro dinamico. Browsertrix ha catturato un link creato a runtime e una fetch() lanciata dalla pagina, ma non ha richiesto due URL letterali annidati dentro una funzione JavaScript mai chiamata.

Il file collegato app.js è stato archiviato per intero, compresi entrambi i path letterali, eppure nessuno dei due endpoint ha generato un record di risposta, un record di richiesta o un hit sul server. La funzione che li conteneva non è mai stata eseguita. Questo articolo valuta quindi Browsertrix come archiviatore di una sessione del browser, non come inventario di ogni URL citato nel codice sorgente.

Cos’è davvero Browsertrix Crawler

Molti arrivano aspettandosi uno scraper e se ne vanno delusi. Nel flusso predefinito non c’è nulla che ti consegni un CSV con i prezzi dei prodotti; aspettarselo è come pretendere che una dashcam scriva un report sul traffico. L’output è un record riproducibile di una sessione di navigazione, e ogni decisione progettuale a valle deriva da questo.

Ho testato v1.14.0 il 27 luglio 2026: webrecorder/browsertrix-crawler:latest con digest sha256:9d6800a8…, e crawl --version ha confermato la build. Il progetto è AGPL-3.0. Ogni misurazione è stata eseguita sotto Docker tramite Colima su macOS arm64 contro il fixture locale controllato; il contatore lato server ha fornito una prova indipendente sia dai log di Browsertrix sia dall’analisi dell’archivio.

AGPL-3.0 merita un momento a sé. Copyleft forte con clausole sull’uso in rete. Se Browsertrix Crawler deve finire dentro un prodotto commerciale invece che essere usato come strumento standalone, fate leggere bene la licenza a qualcuno prima del rilascio. È un avvertimento, non un parere legale.

L’archivio registra la sessione, non il codice sorgente

Il mio fixture serviva quattro tipi di endpoint, separati di proposito perché un archiviatore li tratta in modo completamente diverso:

• Classe A — <a href> semplice nell’HTML. Quattro pagine più una catena di profondità a tre livelli. Qualsiasi crawler al mondo le trova.
• Classe B — URL letterali dentro una funzione che non viene mai eseguita. Due path, /api/js-endpoint-7 e /api/js-endpoint-8, presenti come stringhe dentro una loadData() non chiamata in un app.js collegato.
• Classe C — un link costruito a runtime. Un <a href> assemblato da frammenti in JavaScript ('endpoint' + (6 * 7)) e inserito nel DOM. Il path contiguo /runtime-only/endpoint42 non esiste in nessun byte servito.
• Classe D — una fetch() che la pagina esegue davvero. Path costruito nello stesso modo ('runtime-xhr-' + (33 * 3)), poi realmente richiesto al caricamento.

Per le classi C e D, i path completi non erano presenti come stringhe contigue nei file serviti. I loro hit lato server e i record di risposta sono quindi la prova che in questo fixture la costruzione a runtime e i percorsi di richiesta sono stati davvero esercitati.

Cosa è stato catturato e cosa no

Due strumenti, confrontati tra loro in ogni cella: i record di risposta WARC (ciò che è nell’archivio) e il contatore lato server del fixture associato a (Host header, path) (ciò che è stato davvero richiesto). Hanno concordato ovunque.

La classe C è quella che separa un vero browser da un crawl statico. L’estrazione dei link predefinita legge il DOM renderizzato (a[href]->href, secondo la documentazione delle opzioni comuni), quindi un link che esiste solo dopo l’esecuzione di JavaScript viene comunque messo in coda, recuperato e archiviato. La classe D entra per un motivo diverso — è stata la pagina stessa a fare la richiesta, e l’archiviatore si trova sul percorso di rete a registrare tutto ciò che passa.

Un confine onesto sulla classe C: il mio link è stato inserito sincronamente al caricamento della pagina. I link che compaiono più tardi, durante i behaviors di Browsertrix, sono un caso a parte, e per questo c’è un issue aperto — #723, “Links on pages that are discovered during behaviors are not extracted”. Non ho testato quello scenario, quindi non sto affermando nulla in un senso o nell’altro.

Il file è stato archiviato. Gli endpoint no.

Confermare il mancato rilevamento della classe B ha richiesto un passaggio record per record nel WARC, invece di affidarsi a un conteggio riassuntivo.

app.js è nell’archivio — un record di risposta, un body JavaScript da 222 byte — e entrambe le stringhe letterali della classe B compaiono al suo interno parola per parola. Nel frattempo, né /api/js-endpoint-7 né /api/js-endpoint-8 è l’URI di destinazione di un solo record in tutto il file: zero record di risposta, zero record di richiesta. Ogni stringa letterale compare esattamente una volta in tutto l’archivio, e in entrambi i casi si trova nel body archiviato di app.js.

Questo esclude la spiegazione banale (“app.js non è mai stato scaricato”). L’archiviatore ha memorizzato il file che cita quegli endpoint e non ha mai inviato una richiesta per essi, perché loadData() non è mai stata chiamata. I behavior predefiniti di Browsertrix erano attivi — autoplay, autofetch, autoscroll, siteSpecific — e autofetch non li ha comunque salvati, il che è sensato se si legge cosa fa autofetch: va a prendere gli entry srcset delle img, i fogli di stile e gli URL data-*, non le stringhe letterali sepolte nei corpi delle funzioni.

Come confronto illustrativo sullo stesso fixture, ho eseguito anche Katana v1.6.1 come katana -u <seed> -jc -silent -nc -d 4. Il suo discovery summary grezzo registra il risultato opposto sulle due classi JavaScript costruite apposta:

Entrambi i comandi hanno usato lo stesso fixture e gli stessi nomi di endpoint. La tabella non è una classifica generale tra crawler browser-based e statici; mostra perché l’inventario degli endpoint e la conservazione della sessione richiedono test di copertura diversi.

“Browser vero, quindi cattura tutto ciò che fa JavaScript” è la frase che leggerai spesso nei post. È un’esagerazione. Cattura il traffico eseguito. Il codice che cita un URL senza mai chiamarlo non produce traffico, e senza traffico non c’è record.

I body per il replay ci sono, con una cosa che non ho verificato

Per i due endpoint generati a runtime, ho estratto i body delle risposte HTTP archiviate dal WARC e ho confermato che contengono il JSON servito: 206 byte per il target del link inserito a runtime, 201 byte per il target della fetch() a runtime. Quindi non si tratta di stub di indice che puntano al nulla — il contenuto stesso è nell’archivio, che è il prerequisito per un replay funzionante.

Ciò che non ho fatto è stato avviare pywb o replayweb.page e renderizzare l’archivio. Body nell’archivio e replay renderizzato corretto sono due affermazioni diverse, e questo test copre solo la prima. Il comportamento del replay, i controlli di autenticità, la catena di custodia e l’ammissibilità probatoria richiedono verifiche separate.

Un’acquisizione in produzione richiede un test di accettazione più ampio

Il fixture risponde bene a una domanda stretta: un link dinamico sincrono e una richiesta emessa dalla pagina sono diventati traffico di rete e record d’archivio? Un lavoro di preservazione in produzione ha di solito molti più modi per fallire pur producendo comunque un WACZ valido.

Si comincia dal replay. Apri il pacchetto nel sistema di replay che la collezione userà davvero e confronta un set fisso di pagine con il riferimento al momento della cattura. Controlla il testo renderizzato, le immagini, gli stili, la navigazione e qualsiasi interazione sia importante per il record. Poi ispeziona il pannello di rete del browser di replay per subresource mancanti. Un body può esistere nel WARC mentre il replay fallisce perché riscrittura, indici, timing, origin o dipendenze non combaciano. Questa recensione non ha oltrepassato quel confine.

Il comportamento dinamico merita un suo set di fixture. Il link di classe C qui è apparso sincronicamente durante il caricamento della pagina. Le applicazioni reali possono rivelare contenuti dopo timer, scroll, chiusura del consenso, cambi di route, custom elements o lunghe catene di API. Inserisci un target noto dietro ciascun comportamento su cui fai affidamento e verifica sia l’hit sul server sia il body archiviato. I behavior predefiniti di Browsertrix sono input utili per questo test, non la prova che ogni stato ritardato sia stato raggiunto. L’issue #723 è particolarmente rilevante se i link compaiono durante i behaviors e non durante l’esecuzione iniziale della pagina.

Le acquisizioni autenticate introducono domande di sessione. Verifica che lo stato di login entri nel profilo del browser, sopravviva alle navigazioni richieste e non trapeli in collezioni che dovrebbero restare isolate. Metti alla prova refresh dei token e logout. Se l’archivio contiene materiale privato o personale, testa anche i controlli di accesso e la retention sui file risultanti come parte dello stesso piano di accettazione. Una cattura tecnicamente completa può comunque essere gestita male dopo la raccolta.

Service worker, media in streaming, WebSocket, download, frame cross-origin e URL firmati meritano tutti una pagina rappresentativa se sono importanti per il target. Il fixture di undici pagine non dice nulla su di loro. Non stabilisce nemmeno come si comporta il crawler quando una pagina resta attiva per minuti, emette richieste dopo la normale finestra di assestamento o richiede gesti dell’utente. Evita di trasformare “vero Chromium” in una promessa di copertura totale; definisci i comportamenti del browser che la raccolta deve preservare e rendili osservabili uno per uno.

Infine, conserva le prove necessarie a diagnosticare i mancati rilevamenti. Salva il digest esatto dell’immagine e il comando, i log di Browsertrix, gli elenchi delle pagine, gli indici, i checksum di WARC/WACZ, le prove lato server delle richieste quando disponibili e un piccolo manifest di verità a terra. Per acquisizioni ripetute, registra tempo, configurazione e ambiente insieme all’artefatto. Questi record non creano l’ammissibilità legale, ma rendono riproducibile una tesi tecnica e fanno emergere se una differenza successiva è dovuta al target, al crawler o allo stack di replay.

Quanto è costato in byte questo fixture con body minuscoli

Questo fixture serve solo poche centinaia di byte per pagina, quindi i suoi rapporti di overhead non vanno proiettati su siti ricchi di asset. In questo regime ristretto, ho misurato la composizione dell’archivio e non solo la dimensione finale:

I conteggi per tipo e i totali in byte sono nel pubblico capture-summary.json; le quote usano come denominatore il totale di 17.024 byte di contenuto record.

In questa esecuzione con body piccoli, i record di richiesta superavano il contenuto di risposta, e la somma di richieste più byte urn:pageinfo: era circa 2,1× il payload di risposta. Descrive il mix di record di questo fixture, non un rapporto WARC generale.

Su disco, attraverso tre esecuzioni isolate:

Prendendo le mediane, emergono quattro rapporti:

E dentro il WACZ stesso:

L’ultima riga è quella che mi ha sorpreso. Quasi un terzo del pacchetto d’archivio, in un crawl piccolo, è il resoconto del crawl stesso più che del web.

La misurazione è stata stabile: il payload di risposta è tornato identico in byte in tutte e tre le esecuzioni (5.339 B ogni volta), con WARC.gz e WACZ che variavano meno dello 0,4%.

I rapporti non si trasferiscono a pagine reali con immagini, font e bundle JavaScript pesanti. Il punto strutturale sì: record di richiesta e di page-info creano overhead indipendente dalla dimensione del payload. Misura un campione rappresentativo prima di pianificare lo storage di produzione; non moltiplicare il rapporto 10× del fixture per una stima sul corpus.

Setup e spazio su disco da pianificare

Una volta installati e avviati Docker o Colima, la configurazione specifica di Browsertrix è docker pull webrecorder/browsertrix-crawler:latest, poi docker run … crawl --url … --generateWACZ. L’immagine include Chromium, quindi non serviva un browser separato né un ambiente Python.

Il costo di questa comodità, nei run misurati qui:

Il container è dove vive l’attrito, e quella riga download+estrazione è il costo del pacchettizzare un browser. Ho eseguito con --shm-size 1g, e dato che il mio fixture viveva sull’host mentre il crawl girava nel container, ho avuto bisogno di --add-host=host.docker.internal:host-gateway e di un fixture esposto su 0.0.0.0 invece che su loopback. Se stai crawlando l’internet pubblico salterai del tutto quel passaggio di rete, ma se stai archiviando qualcosa sul tuo computer o su un host interno di staging, metti in conto un pomeriggio per sistemarlo.

La directory di output è la voce più facile da sottostimare. Proietta quella crescita su un crawl reale e pianifica lo storage prima di iniziare, non dopo che il disco si è riempito alle 3 del mattino.

L’avvio del browser probabilmente contribuisce in modo materiale a un crawl da 28–30 secondi di sole undici pagine, ma non ho isolato l’avvio dal tempo di navigazione o di packaging. Da questo run non segue alcuna conclusione sul throughput per pagina.

Pianificare lo storage senza abusare dei rapporti del fixture

Il modo utile di dimensionare una collezione è empirico. Seleziona pagine che rappresentino la distribuzione reale del target: shell applicative leggere, landing page ricche di immagini, download di documenti, articoli lunghi e viste autenticate, se rientrano nello scope. Cattura ogni classe con i behavior e le impostazioni di packaging previsti. Misura payload di risposta, WARC, WACZ, indici, log, residui del profilo browser e qualsiasi workspace temporaneo che resti durante un run. L’uso massimo su disco conta quanto il pacchetto finale, se il packaging mantiene per un momento più copie.

Separare componenti fissi e variabili. L’immagine container da 3,51 GB è overhead di distribuzione che può essere condiviso tra molte catture sullo stesso worker. I record di richiesta, i record page-info, gli indici e gli elenchi delle pagine crescono con l’attività di crawl. I body di risposta dipendono molto dal target, mentre i log dipendono dalla durata del run e dal livello di verbosità. Retention e replica moltiplicano poi la collezione finale in modo indipendente dal comportamento del crawl. Un modello di capacità che riduca tutto a “byte per pagina” sarà fragile.

Anche compressione e deduplicazione hanno bisogno di contenuti rappresentativi. Il payload di risposta di questo fixture era identico in byte in tre esecuzioni, ma questo non descrive pagine con annunci variabili, timestamp, risposte personalizzate o asset URL con cache-busting. Se le catture ripetute fanno parte del programma, misura catture successive delle stesse pagine e ispeziona i record revisit invece di assumere che le pagine apparentemente uguali si deduplichino bene. Allo stesso modo, testa se log e indici sono mantenuti allo stesso livello di replica del payload di conservazione.

Operativamente, imposta soglie di avviso prima che la collezione inizi. Monitora lo spazio libero, la crescita per collezione, i fallimenti di packaging e la dimensione dei profili browser o delle directory temporanee. Esegui un esercizio di restore dal WACZ memorizzato, non solo un passaggio di checksum. I rapporti sopra sono utili perché rivelano quali componenti esistono; il campione rappresentativo è ciò che ti dice quanto saranno grandi per il tuo sito.

Documenta questi assunti accanto alla stima di capacità e rivedili dopo il crawl pilota.

Disciplina dello scope, testata con due controlli

I crawler di archiviazione che vagano sono un rischio operativo reale — puoi ritrovarti contemporaneamente con un problema legale e una bolletta di storage. La mia home page linkava http://outofscope.test:<port>/page/out, un hostname diverso che punta allo stesso fixture, quindi un hit con quell’header Host avrebbe provato un fetch fuori scope senza coinvolgere traffico internet reale.

La seconda riga è ciò che rende significativa la prima. Con any il link è stato raggiunto due volte, quindi era raggiungibile — lo zero con lo scope prefix predefinito è vera disciplina di scope, non un link che il crawler non ha notato. Esiste un report aperto su visite fuori scope in altre configurazioni, #788, che non ho riprodotto con lo scope prefix predefinito su questo fixture. Vale la pena sapere che esiste; non vale la pena che io dica di averlo visto.

La robustezza è stata notevole proprio perché non ha fatto notizia. Una route che restituiva HTTP 500 e un link morto sono stati entrambi richiesti, il crawl è terminato correttamente con un WARC e un WACZ validi, e il link morto è stato salvato come record revisit deduplicato invece di mandare tutto in errore.

Pro e contro

Pro

• Cattura link DOM inseriti a runtime e chiamate fetch() lanciate dalla pagina — entrambi confermati sia nell’archivio sia lato server, su path che non esistono da nessuna parte come letterali.
• L’HTML statico e l’attraversamento della profondità sono completi: 4/4 link, catena a 3/3 livelli, nessun mancato rilevamento.
• Una volta avviati Docker/Colima, un solo docker run ha prodotto un WARC e un WACZ; Chromium era dentro l’immagine.
• Lo scope prefix predefinito ha mantenuto zero fetch fuori scope; any si è allargato come documentato, quindi il controllo fa ciò che promette.
• L’output è un archivio basato su standard (WARC, impacchettato come WACZ con indice CDX e page list) e non un blob proprietario.
• Archivi quasi deterministici: payload identico in byte in tre run, dimensione su disco variata meno dello 0,4%.
• Comportamento pulito in caso di errore: una route 500 e un link rotto non hanno interrotto il crawl.

Contro

• Gli URL letterali in JavaScript non eseguito semplicemente non vengono scoperti (0/2), anche quando il file che li contiene è archiviato. Corretto per progettazione, ma resta un vero gap di copertura se il tuo obiettivo è l’inventario degli endpoint.
• Ingombro pesante: pull da ~1 GB, 3,51 GB su disco, e directory di output che crescono in fretta.
• Overhead in byte notevole sulle pagine piccole — richieste più record pageinfo superavano il payload reale, e circa il 30% del WACZ era il log del crawl.
• AGPL-3.0 implica un vero lavoro di compliance per l’integrazione commerciale.
• Non è uno strumento per dati strutturati. Non c’è schema, nessuna mappatura dei campi, nessuna riga pulita alla fine.
• Il throughput per pagina è volutamente modesto, perché ogni pagina passa attraverso un browser reale.

Chi dovrebbe usarlo e chi no

Browsertrix è pensato per team il cui artefatto richiesto è un archivio di risorse recuperate dal browser, non righe estratte. In questo fixture, i body delle risposte recuperate a runtime erano presenti nel WARC e impacchettati in WACZ. Biblioteche, redazioni e ricercatori sono utenti plausibili, ma l’adozione in produzione dovrebbe testare separatamente replay renderizzato, autenticazione, service worker, flussi di consenso, comportamenti ritardati, asset in streaming, controlli di retention e qualsiasi requisito di gestione delle prove.

Evitalo se ciò che ti serve davvero sono i dati. Se l’obiettivo è “dammi tutti i prodotti e i prezzi da queste 400 pagine in un foglio di calcolo”, un archiviatore è una strada strana per arrivarci — finiresti per archiviare gigabyte e poi dovresti comunque scrivere codice di estrazione sui file WARC. Evitalo anche se devi mappare la superficie API di un’applicazione, perché il risultato della classe B dice chiaramente che un parser statico JavaScript troverà endpoint che Browsertrix non tocca mai. E se non sopporti Docker o lavori in un contesto in cui un’immagine da 3,5 GB è un problema, questo non è lo strumento che si piegherà alle tue esigenze.

Autorizzazione e retention

I controlli di scope non forniscono autorizzazione. Definisci in anticipo host consentiti, retention e accesso agli archivi, soprattutto quando le catture persistenti possono includere dati personali. Il test prefix/any mostra che la configurazione modifica la raggiungibilità di rete; non stabilisce quale sia la reach consentita per una specifica collezione.

Recensione correlata: aspetti legali del web scraping e dell’archiviazione.

Alternative in base all’output richiesto

Scegli in base all’artefatto. Browsertrix punta alla preservazione in WARC/WACZ. Una libreria di automazione browser come Playwright espone una pagina programmabile ma lascia a te il packaging della cattura. I crawler per la scoperta degli endpoint enumerano gli URL, mentre gli strumenti di estrazione restituiscono testo o record strutturati. Queste categorie possono condividere un browser e comunque risolvere lavori diversi.

Recensione correlata: recensione di Heritrix.

Disclosure: Thunderbit è il prodotto dell’editore e non è stato testato in questo fixture di Browsertrix. Appartiene alla categoria dell’estrazione gestita, producendo testo di pagina o dati strutturati anziché un archivio basato su standard. Questa recensione supporta solo il confine dell’output, non una valutazione comparativa di prestazioni o capacità.

Prova Thunderbit per l’estrazione di dati web

Verdetto

Usa Browsertrix Crawler quando l’output richiesto è una cattura WARC/WACZ e un Chromium containerizzato si adatta al tuo ambiente. In questo fixture, i record dell’archivio e gli hit del server coincidevano per i fetch DOM runtime sincroni e per i fetch lanciati dalla pagina, lo scope prefix predefinito escludeva il secondo host e le route di errore non impedivano la produzione di un archivio valido.

Prima dell’uso in produzione, valida replay, comportamenti ritardati, sessioni autenticate, service worker, composizione dello storage su pagine rappresentative e obblighi di licenza. Il confine testato è più stretto: i riferimenti nel codice che non vengono mai eseguiti non hanno prodotto né richiesta né record di archivio per i loro target, anche se lo script contenitore è stato preservato.

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

FAQ

Qual è la differenza tra WARC e WACZ qui? WARC contiene i record di richiesta, risposta e quelli correlati catturati. WACZ impacchetta WARC con indici, page list, metadati e log per la distribuzione e gli strumenti di replay. Questa recensione ha ispezionato entrambi i pacchetti ma non ha renderizzato un replay.

Come dovrei stimare lo storage? Misura pagine rappresentative e conserva la composizione completa del WACZ, inclusi log e indici, nel campione. I rapporti in questo articolo provengono da body di risposta insolitamente piccoli e non sono adatti a essere moltiplicati per un conteggio di URL di produzione.

Finirà fuori dal sito che gli ho indicato? Non con l’impostazione predefinita, nei miei test. Con --scopeType prefix, un link verso un altro hostname è stato recuperato zero volte; passando a --scopeType any è stato recuperato due volte, il che dimostra che il link era raggiungibile e che lo zero del default era vera disciplina di scope. Esiste un report upstream aperto su visite fuori scope in altre configurazioni che non ho riprodotto con il default, quindi controlla le tue impostazioni di scope invece di dare tutto per scontato.

Cosa devo testare prima di dichiarare la fedeltà del replay? Carica il WACZ nel sistema di replay previsto e confronta pagine renderizzate, interazioni e subresource richieste con la cattura live o di riferimento. La presenza del body nel WARC è necessaria, ma da sola non verifica il replay renderizzato.

Browsertrix trasforma una pagina archiviata in righe strutturate? No. Il suo output è un pacchetto d’archivio, non una tabella di campi selezionati. Se il deliverable è prodotti, prezzi, contatti o un altro schema, dopo la cattura serve ancora una fase di estrazione — oppure uno strumento diverso il cui output principale sia già dati strutturati.