Análise do Browsertrix Crawler: ele arquiva o que o navegador fez, não o que o código promete

O Browsertrix Crawler é o crawler de arquivamento do Webrecorder: uma única imagem Docker que controla um Chromium real via Puppeteer, registra tudo o que o navegador buscou e grava isso em WARC — o formato padrão de arquivo para web archives — com opção de empacotar tudo em um WACZ com índice, lista de páginas e logs. O que ele foi criado para fazer é justamente o que o diferencia das ferramentas de web scraping com as quais ele se parece à primeira vista. Um scraper vai atrás dos dados e descarta a página assim que encontra os campos; um arquivador preserva a própria visita — os bytes, os cabeçalhos, a ordem em que chegaram — para que a página possa ser reaberta muito tempo depois de o site ter mudado ou sumido. O Webrecorder mantém essa camada da infraestrutura da web, incluindo formatos e stack de reprodução, desde muito antes de arquivamento parecer uma categoria de produto, e bibliotecas, redações e pesquisadores já dependem dele.

Executei a v1.14.0 no Docker contra um ambiente local de teste com quatro classes de endpoints propositalmente diferentes, e instrumentei os dois lados da captura: registros WARC para o conteúdo arquivado e um contador de acessos no servidor para as requisições reais. A distinção relevante não era apenas entre estático e dinâmico. O Browsertrix capturou um link criado em tempo de execução e um fetch() disparado pela página, mas não solicitou duas URLs literais dentro de uma função JavaScript que nunca foi chamada.

O app.js vinculado foi arquivado por completo, incluindo os dois caminhos literais, mas nenhum dos endpoints gerou registro de resposta, registro de requisição ou hit no servidor. A função que os continha simplesmente nunca executou. Portanto, este artigo avalia o Browsertrix como arquivador de uma sessão de navegador, e não como inventário de todas as URLs mencionadas no código-fonte.

O que o Browsertrix Crawler realmente é

Muita gente chega esperando um scraper e sai frustrada. Nada no fluxo padrão entrega um CSV com preços de produtos; esperar isso seria como esperar que uma dashcam escreva um relatório de trânsito. A saída é um registro reproduzível de uma sessão de navegação, e todas as decisões de design a jusante decorrem disso.

Testei a v1.14.0 em 27 de julho de 2026: webrecorder/browsertrix-crawler:latest com digest sha256:9d6800a8…, com crawl --version confirmando a build. O projeto é AGPL-3.0. Todas as medições rodaram em Docker via Colima no macOS arm64, contra o fixture local controlado; o contador do lado do servidor forneceu evidência independente dos logs do Browsertrix e da análise do arquivo arquivado.

A AGPL-3.0 merece destaque próprio. É copyleft forte com cláusulas de uso em rede. Se o Browsertrix Crawler for entrar em um produto comercial em vez de ser usado como ferramenta isolada, peça para alguém ler a licença direito antes de publicar. Isso é um alerta, não aconselhamento jurídico.

O arquivo arquiva a sessão, não o código-fonte

Meu fixture servia quatro tipos de endpoint, separados de propósito porque um arquivador os trata de forma totalmente diferente:

• Classe A — <a href> simples no HTML. Quatro páginas mais uma cadeia de profundidade de três níveis. Qualquer crawler do mundo encontra isso.
• Classe B — literais de URL dentro de uma função que nunca é executada. Dois caminhos, /api/js-endpoint-7 e /api/js-endpoint-8, guardados como strings dentro de um loadData() que nunca é chamado em um app.js vinculado.
• Classe C — um link montado em tempo de execução. Um <a href> formado a partir de fragmentos em JavaScript ('endpoint' + (6 * 7)) e inserido no DOM. O caminho contínuo /runtime-only/endpoint42 não existe em nenhum byte servido.
• Classe D — um fetch() que a página realmente dispara. Caminho montado do mesmo jeito ('runtime-xhr-' + (33 * 3)), e então solicitado de fato no carregamento.

Nas classes C e D, os caminhos completos não apareciam como strings contínuas nos arquivos servidos. Os hits no servidor e os registros de resposta, portanto, são prova de que a construção em tempo de execução e os caminhos de requisição foram exercitados neste fixture.

O que foi capturado e o que não foi

Dois instrumentos, conferidos um contra o outro em cada célula: registros de resposta WARC (o que está no arquivo) e o contador de hits do servidor do fixture, com chave em (Host header, path) (o que realmente foi solicitado). Eles concordaram em tudo.

A classe C é a que separa um navegador real de uma coleta estática. A extração de links padrão lê o DOM renderizado (a[href]->href, conforme a documentação de opções comuns), então um link que só existe depois que o JavaScript roda ainda entra na fila, é buscado e arquivado. A classe D entra por outro motivo — a própria página fez a requisição, e o arquivador está no caminho de rede registrando tudo o que passa.

Um limite honesto da classe C: meu link foi injetado sincronamente no carregamento da página. Links que aparecem depois, durante os behaviors do Browsertrix, são outro caso, e existe uma issue aberta exatamente sobre isso — #723, "Links on pages that are discovered during behaviors are not extracted". Eu não testei esse cenário, então não estou afirmando nada sobre ele.

O arquivo foi arquivado. Os endpoints, não.

Confirmar a falha na classe B exigiu uma passada registro por registro no WARC, e não apenas uma contagem resumida.

app.js está no arquivo — um registro de resposta, um corpo JavaScript de 222 bytes — e os dois literais da classe B aparecem nele, literalmente. Ao mesmo tempo, nem /api/js-endpoint-7 nem /api/js-endpoint-8 é o URI de destino de um único registro em todo o arquivo: zero registros de resposta, zero registros de requisição. Cada string literal aparece exatamente uma vez em todo o arquivo, e as duas ocorrências estão dentro do corpo armazenado de app.js.

Isso elimina a explicação óbvia (“app.js nunca foi buscado”). O arquivador armazenou o arquivo que faz referência a esses endpoints, mas nunca chegou a requisitá-los, porque loadData() não foi chamado. Os behaviors padrão do Browsertrix estavam ativos — autoplay, autofetch, autoscroll, siteSpecific — e o autofetch também não os resgatou, o que faz sentido quando se lê o que o autofetch faz: ele busca entradas img srcset, folhas de estilo e URLs data-*, não literais de string enterrados dentro de corpos de função.

Para um contraste ilustrativo no mesmo fixture, também rodei o Katana v1.6.1 como katana -u <seed> -jc -silent -nc -d 4. O resumo bruto de descoberta registra o resultado oposto nas duas classes JavaScript construídas de propósito:

Os dois comandos usaram o mesmo fixture e os mesmos nomes de endpoint. A tabela não é um ranking geral entre navegadores e crawlers estáticos; ela mostra por que inventário de endpoints e preservação de sessão exigem testes de cobertura diferentes.

“É um navegador real, então captura tudo o que o JavaScript faz” é a frase que você verá repetida por aí. É exagerada. Ele captura o tráfego que realmente foi executado. Código que referencia uma URL sem nunca chamá-la não produz tráfego, e sem tráfego não há registro.

Os corpos para replay estão lá, com uma coisa que eu não verifiquei

Para os dois endpoints produzidos em tempo de execução, extraí os corpos das respostas HTTP arquivadas do WARC e confirmei que eles contêm o JSON servido: 206 bytes para o destino do link injetado em runtime e 201 bytes para o destino do fetch() em runtime. Então não se trata de stubs de índice apontando para lugar nenhum — o conteúdo em si está no arquivo, o que é pré-requisito para um replay servi-lo.

O que eu não fiz foi subir o pywb ou o replayweb.page e renderizar o arquivo. Corpo no arquivo e replay renderizado corretamente são afirmações diferentes, e este teste cobre apenas a primeira. Comportamento de replay, controles de autenticidade, cadeia de custódia e admissibilidade como evidência exigem validações separadas.

Uma captura de produção precisa de um teste de aceitação mais amplo

O fixture responde bem a uma pergunta estreita: um link sincronamente criado em runtime e uma requisição disparada pela página viraram tráfego de rede e registros de arquivo? Um trabalho real de preservação costuma ter várias outras formas de falhar e ainda assim gerar um WACZ válido.

Comece pelo replay. Abra o pacote no sistema de replay que a coleção realmente vai usar e compare um conjunto fixo de páginas com a referência capturada no momento da coleta. Verifique texto renderizado, imagens, estilos, navegação e qualquer interação importante para o registro. Depois inspecione o painel de rede do navegador de replay em busca de subrecursos ausentes. Um corpo de resposta pode existir no WARC e, ainda assim, o replay falhar porque reescrita, índices, timing, origens ou dependências não se alinham. Esta análise não cruzou essa fronteira.

Comportamento dinâmico merece seu próprio conjunto de fixtures. O link da classe C aqui apareceu de forma síncrona no carregamento da página. Aplicações reais podem revelar conteúdo depois de timers, scroll, dismiss de consentimento, mudanças de rota, elementos personalizados ou longas cadeias de API. Coloque um alvo conhecido atrás de cada comportamento do qual você depende e verifique tanto o hit no servidor quanto o corpo arquivado. Os behaviors padrão do Browsertrix são insumos úteis para esse teste, não prova de que qualquer estado atrasado foi alcançado. A issue #723 é especialmente relevante se links aparecem durante behaviors e não durante a execução inicial da página.

Capturas autenticadas trazem perguntas de sessão. Confirme que o estado de login entra no perfil do navegador, sobrevive às navegações necessárias e não vaza para coleções que deveriam ficar isoladas. Teste refresh de token e logout. Se o arquivo contiver material privado ou pessoal, teste também controles de acesso e retenção sobre os arquivos resultantes como parte do mesmo plano de aceitação. Uma captura tecnicamente completa ainda pode ser tratada de forma errada depois da coleta.

Service workers, mídia em streaming, WebSockets, downloads, frames de outro domínio e URLs assinadas também merecem uma página representativa, se isso for relevante para o alvo. O fixture de onze páginas não diz nada sobre esses casos. Ele também não estabelece como o crawler se comporta quando uma página permanece ativa por minutos, emite requisições após a janela normal de estabilização ou exige gestos do usuário. Evite transformar “Chromium real” em uma promessa genérica de cobertura; defina quais comportamentos do navegador a coleção precisa preservar e torne cada um observável.

Por fim, guarde a evidência necessária para diagnosticar falhas. Salve o digest exato da imagem e o comando usado, logs do Browsertrix, listas de páginas, índices, checksums de WARC/WACZ, evidência de requisições do lado do servidor quando houver, e um pequeno manifesto de verdade-terreno. Em capturas repetidas, registre também tempo, configuração e ambiente junto com o artefato. Esses registros não criam admissibilidade jurídica, mas tornam a alegação técnica reproduzível e mostram se uma diferença posterior veio do alvo, do crawler ou da stack de replay.

Quanto este fixture de corpo pequeno custou em bytes

Este fixture serve apenas algumas centenas de bytes por página, então suas razões de overhead não devem ser extrapoladas para sites pesados em assets. Dentro desse regime estreito, medi a composição do arquivo em vez de olhar só para o tamanho final:

As contagens por tipo e os totais de bytes estão no público capture-summary.json; as participações usam o total de 17.024 bytes de conteúdo dos registros como denominador.

Neste teste com corpo pequeno, os registros de request superaram o conteúdo de response, e os bytes de request mais urn:pageinfo: somaram cerca de 2,1× o payload de response. Isso descreve o mix de registros deste fixture, não uma proporção geral de WARC.

No disco, ao longo de três execuções isoladas:

Tomando as medianas, saem quatro proporções:

E dentro do próprio WACZ:

Essa última linha foi a que mais me surpreendeu. Quase um terço do pacote de arquivamento, numa coleta pequena, é o registro da própria coleta, e não da web.

A medição foi estável: o payload de resposta voltou byte a byte idêntico nas três execuções (5.339 B todas as vezes), com WARC.gz e WACZ variando menos de 0,4%.

As proporções não valem para páginas reais com imagens, fontes e grandes bundles de scripts. O ponto estrutural, sim: registros de request e page-info criam overhead independente do tamanho do payload. Meça uma amostra representativa antes de planejar armazenamento de produção; não multiplique a razão de 10× do fixture por uma estimativa de corpus.

Configuração e o espaço em disco que você deve planejar

Depois que Docker ou Colima está instalado e em execução, a preparação específica do Browsertrix é docker pull webrecorder/browsertrix-crawler:latest, depois docker run … crawl --url … --generateWACZ. A imagem já traz o Chromium, então não foi preciso instalar navegador separado nem ambiente Python.

O custo dessa conveniência, nas execuções medidas aqui:

O contêiner é onde está o atrito, e essa linha de download + descompactação é o custo de empacotar um navegador junto. Rodei com --shm-size 1g, e como meu fixture estava no host enquanto a coleta rodava no contêiner, precisei de --add-host=host.docker.internal:host-gateway e de um fixture vinculado a 0.0.0.0 em vez de loopback. Se você estiver coletando a internet pública, pode pular essa etapa de rede; mas se estiver arquivando algo na sua máquina ou em um host interno de staging, reserve uma tarde para isso.

A pasta de saída é a linha que mais facilmente se subestima. Extrapole esse crescimento para uma coleta real e planeje o armazenamento antes de começar, não depois que o disco lotar às 3 da manhã.

Provavelmente o startup do navegador contribui de forma material para uma coleta de 28–30 segundos com apenas onze páginas, mas eu não isolei o startup do tempo de navegação ou de empacotamento. Não se pode tirar daqui nenhuma conclusão de throughput por página.

Planejar armazenamento sem abusar das proporções do fixture

A forma útil de dimensionar uma coleção é empírica. Escolha páginas que representem a distribuição real do alvo: cascas leves de aplicação, landing pages ricas em imagens, downloads de documentos, artigos longos e visualizações autenticadas, se isso estiver no escopo. Capture cada classe com os behaviors e configurações de empacotamento pretendidos. Meça o payload de resposta, WARC, WACZ, índices, logs, resíduos do perfil do navegador e qualquer área de trabalho temporária que permaneça durante a execução. O uso de disco no pico importa tanto quanto o tamanho final do pacote se o empacotamento mantiver várias cópias por um instante.

Separe componentes fixos e variáveis. A imagem de 3,51 GB é overhead de implantação que pode ser compartilhado por muitas capturas em um único worker. Registros de request, registros de page-info, índices e listas de páginas crescem com a atividade de coleta. Os corpos de resposta dependem fortemente do alvo, enquanto os logs dependem da duração e da verbosidade da execução. Retenção e replicação depois multiplicam a coleção final independentemente do comportamento da coleta. Um modelo de capacidade que coloque tudo isso em “bytes por página” será frágil.

Compressão e deduplicação também precisam de conteúdo representativo. O payload de resposta deste fixture foi byte a byte idêntico nas três execuções, mas isso não descreve páginas com anúncios variáveis, timestamps, respostas personalizadas ou URLs de assets com cache-busting. Se capturas repetidas fazem parte do programa, meça capturas sucessivas das mesmas páginas e inspecione os registros de revisit em vez de presumir que páginas aparentemente estáveis deduplicam bem. Da mesma forma, teste se logs e índices são mantidos no mesmo nível de replicação que o payload de preservação.

Operacionalmente, defina limiares de alerta antes de a coleta começar. Monitore espaço livre, crescimento por coleção, falhas de empacotamento e o tamanho dos perfis do navegador ou diretórios temporários. Faça um exercício de restauração a partir do WACZ armazenado, e não apenas uma verificação de checksum. As proporções acima são úteis porque revelam quais componentes existem; a amostra representativa é o que diz quão grandes eles serão para o seu site.

Documente essas premissas ao lado da estimativa de capacidade e revise-as depois da coleta piloto.

Disciplina de escopo, testada com dois controles

Crawlers de arquivamento que saem andando por aí são um risco operacional real — você pode acabar com um problema jurídico e uma conta de armazenamento ao mesmo tempo. Minha home page continha um link para http://outofscope.test:<port>/page/out, um hostname diferente apontando para o mesmo fixture, então um hit com esse Host header provaria uma requisição fora de escopo sem envolver tráfego da internet pública.

A segunda linha é o que dá sentido à primeira. Em any, o link foi alcançado duas vezes, então ele era alcançável — o zero sob o escopo prefix padrão é disciplina real, não um link que o crawler deixou passar sem perceber. Existe um relatório aberto sobre visitas fora de escopo em outras configurações, #788, que eu não reproduzi sob o escopo prefix padrão neste fixture. Vale saber que existe; não vale eu dizer que vi.

A robustez foi notável justamente por ser sem drama. Uma rota que retornava HTTP 500 e um link quebrado foram ambos solicitados, a coleta terminou de forma limpa com um WARC e um WACZ válidos, e o link quebrado foi armazenado como um registro revisit deduplicado, sem quebrar nada.

Prós e contras

Prós

• Captura links injetados no DOM em tempo de execução e chamadas fetch() feitas pela página — ambos confirmados no arquivo e no lado do servidor, em caminhos que não existem em lugar nenhum como literais.
• HTML estático e navegação por profundidade são completos: 4/4 links, cadeia de profundidade 3/3, sem falhas.
• Depois que Docker/Colima estava rodando, um único docker run produziu WARC e WACZ; o Chromium já vinha dentro da imagem.
• O escopo prefix padrão segurou com zero requisições fora de escopo; any ampliou como documentado, então o controle faz o que promete.
• A saída é um arquivo baseado em padrão (WARC, empacotado como WACZ com índice CDX e lista de páginas), em vez de um blob proprietário.
• Arquivos quase determinísticos: payload idêntico byte a byte nas três execuções, com variação de tamanho em disco abaixo de 0,4%.
• Comportamento de falha limpo: uma rota 500 e um link quebrado não abortaram a coleta.

Contras

• Literais de URL em JavaScript não executado simplesmente não são descobertos (0/2), mesmo quando o arquivo que os contém é arquivado. Isso é correto por design, mas ainda é uma lacuna real de cobertura se seu objetivo for descoberta de endpoints.
• Pegada pesada: download de ~1 GB, 3,51 GB em disco e diretórios de saída que crescem rápido.
• O overhead em bytes é considerável em páginas pequenas — request mais pageinfo superaram o payload real, e cerca de 30% do WACZ era log da coleta.
• AGPL-3.0 significa trabalho real de conformidade para incorporação comercial.
• Não é uma ferramenta de dados estruturados. Não há schema, não há mapeamento de campos, não há linhas limpas no final.
• O throughput por página é modesto por design, já que cada página passa por um navegador real.

Quem deve usar e quem não deve

O Browsertrix é voltado para equipes cujo artefato necessário é um arquivo de recursos buscados pelo navegador, e não linhas extraídas. Neste fixture, os corpos de resposta obtidos em runtime estavam presentes no WARC e empacotados em WACZ. Bibliotecas, redações e pesquisadores são usuários plausíveis, mas adoção em produção deve testar separadamente replay renderizado, autenticação, service workers, fluxos de consentimento, comportamentos atrasados, ativos de streaming, controles de retenção e qualquer requisito de manuseio de evidências.

Evite usar se o que você realmente precisa é dado. Se o objetivo é “me entregue todos os produtos e preços destas 400 páginas em uma planilha”, um arquivador é um caminho estranho até esse resultado — você arquivaria gigabytes e ainda teria que escrever código de extração sobre arquivos WARC. Também evite se você está mapeando a superfície de API de uma aplicação, porque o resultado da classe B mostra claramente que um parser estático de JavaScript encontrará endpoints que o Browsertrix nunca toca. E, se você não quer saber de Docker ou trabalha em um lugar onde uma imagem de 3,5 GB é um problema, esta não é a ferramenta que vai se adaptar a você.

Autorização e retenção

Controles de escopo não fornecem autorização. Defina hosts permitidos, retenção e acesso ao arquivo antes de coletar, especialmente quando capturas duráveis podem incluir dados pessoais. O teste prefix/any mostra que mudanças de configuração alteram o alcance de rede; não estabelece qual alcance é legal para uma coleção específica.

Análise relacionada: aspectos jurídicos do web scraping e do arquivamento.

Alternativas por tipo de resultado necessário

Escolha pelo artefato. O Browsertrix é voltado para preservação em WARC/WACZ. Uma biblioteca de automação de navegador, como Playwright, expõe uma página programável, mas deixa o empacotamento da captura por sua conta. Crawlers de descoberta de endpoints enumeram URLs, enquanto ferramentas de extração devolvem texto ou registros estruturados. Essas categorias podem compartilhar um navegador e ainda assim resolver trabalhos diferentes.

Análise relacionada: análise do Heritrix.

Divulgação: Thunderbit é o produto do editor e não foi testado neste fixture do Browsertrix. Ele pertence à categoria de extração gerenciada, produzindo texto de páginas ou dados estruturados em vez de um arquivo baseado em padrões. Esta análise sustenta apenas a fronteira de saída, e não uma comparação de desempenho ou capacidade.

Experimente Thunderbit para extração de dados da web

Veredito

Use o Browsertrix Crawler quando a saída exigida for uma captura WARC/WACZ e um Chromium em container se encaixar na implantação. Neste fixture, os registros de arquivo e os hits do servidor concordaram para links no DOM gerados em runtime de forma síncrona e para fetch() disparado pela página; o escopo prefix padrão bloqueou o segundo host, e rotas com falha não impediram um arquivo válido.

Antes de usar em produção, valide replay, comportamento atrasado, sessões autenticadas, service workers, composição do armazenamento em páginas representativas e obrigações de licença. A fronteira testada aqui é mais estreita: referências de código que nunca executam não produziram requisição nem registro de arquivo para seus alvos, mesmo com o script contido preservado.

Experimente Thunderbit para extração de dados da web Get Started Free

Perguntas frequentes

Qual é a diferença entre WARC e WACZ aqui? WARC contém a requisição capturada, a resposta e registros relacionados. WACZ empacota o WARC com índices, listas de páginas, metadados e logs para distribuição e ferramentas de replay. Esta análise inspecionou ambos os pacotes, mas não renderizou um replay.

Como devo estimar o armazenamento? Meça páginas representativas e mantenha, na amostra, toda a composição do WACZ, incluindo logs e índices. As proporções deste artigo vêm de corpos de resposta incomumente pequenos e não servem para multiplicar por uma contagem de URLs de produção.

Ele pode sair do site que eu apontei? No ajuste padrão, nos meus testes, não. Com --scopeType prefix, um link para um hostname diferente foi buscado zero vezes; ao mudar para --scopeType any, ele foi buscado duas vezes, o que prova que o link era alcançável e que o zero do escopo padrão era disciplina real. Existe um relatório aberto upstream sobre visitas fora de escopo em outras configurações que eu não reproduzi no padrão, então vale conferir suas próprias configurações de escopo em vez de assumir.

O que preciso testar antes de afirmar fidelidade de replay? Carregue o WACZ no sistema de replay pretendido e compare páginas renderizadas, interações e subrecursos necessários com a captura viva ou de referência. A presença do corpo no WARC é necessária, mas não verifica sozinha o replay renderizado.

O Browsertrix transforma uma página arquivada em linhas estruturadas? Não. A saída dele é um pacote de arquivo, não uma tabela de campos selecionados. Se o entregável for produtos, preços, contatos ou outro schema, ainda será preciso uma etapa de extração depois da captura — ou uma ferramenta diferente cuja saída principal seja dado estruturado.