Análise do Botasaurus: um driver de 4 MB, uma instalação de 122 MB e o número de 0,08 ms que você não deveria citar

Botasaurus é um framework Python para web scraping da Omkar Cloud que se apresenta como um kit completo para criar scrapers. Você escreve uma função comum, adiciona o decorador @browser, @request ou @task, e o framework monta em volta dela um driver de navegador, um cliente HTTP com aparência de navegador, cache, paralelismo e saída em múltiplos formatos. Trata-se de um meta-package — e é isso que importa: pip install botasaurus não coloca uma única biblioteca no seu ambiente; ele reúne um pequeno conjunto de wheels próprias e uma ampla árvore de dependências. Esse detalhe operacional acabou sendo a parte mais interessante que consegui medir com honestidade.

O Botasaurus se vende com foco em anti-detecção, e justamente esse é o eixo que esta análise não aborda. Eu inventariei o framework — o que instala, o que importa, quais métodos existem, quanto pesa e sob quais licenças é distribuído — em vez de colocá-lo contra alguma defesa real em produção. Todos os números de footprint e import abaixo vêm de pip, de python -c "import ..." e da inspeção de classes que foram instanciadas, mas nunca instruídas a buscar uma página; nenhum navegador foi aberto para produzir qualquer um deles. Mais tarde, abri navegadores, mas apenas em páginas que eu mesmo escrevi e servi em 127.0.0.1, para ver o que o driver declara sobre si e se consegue extrair conteúdo de uma página que se constrói com JavaScript. Em nenhum momento houve acesso a um site real, nenhum serviço anti-bot foi contatado ou medido e nenhum CAPTCHA foi acionado. A eficácia contra sites reais está fora de escopo por definição, e prefiro deixar isso claro desde o início do que insinuar um benchmark que não executei.

Com essa fronteira estabelecida, a conclusão principal é uma história de footprint — e uma história benigna. Uma instalação limpa gera um diretório site-packages de 122,3 MB, distribuído por 44 pacotes, em uma máquina na qual o driver de navegador no centro de tudo isso ocupa cerca de 4 MB. O framework não é pesado porque o driver é pesado; ele é pesado porque “tudo em um” significa carregar numpy, lxml, gevent e mais uma dezena de componentes para uma tarefa de buscar HTML. E a segunda metade da descoberta é um número que costuma ser citado como virtude, mas que você não deveria tratar assim: import botasaurus marca apenas 0,08 ms, o que parece um framework quase sem custo e, na prática, é só uma porta de entrada vazia.

O que o Botasaurus realmente é

Botasaurus — omkarcloud/botasaurus no GitHub, com 5.561 estrelas, 486 forks e 58 issues abertas quando extraí os metadados em 14 de julho de 2026 — é um framework Python, não uma biblioteca de propósito único. As versões que testei foram botasaurus 4.0.97 para o meta-package e botasaurus-driver 4.0.92 para o mecanismo por baixo. O meta-package declara requires-python >=3.7 (o driver, >=3.5), e os classificadores do PyPI só prometem suporte até 3.11. Ele foi instalado e passou no teste de import em Python 3.14.2 na minha máquina. Isso é evidência sobre esta instalação, não uma garantia de compatibilidade para todos os recursos.

Vale fixar a categoria, porque ela define o que significa “bom”. O Botasaurus está no extremo de framework, na mesma vizinhança de Scrapy e Crawlee — você adota sua estrutura, seus decoradores e suas convenções e, em troca, ele cuida da infraestrutura. É uma proposta diferente de um driver focado como o nodriver, que entrega uma conexão com o Chrome DevTools Protocol e sai do caminho. O Botasaurus empacota um driver (o botasaurus-driver), mas o envolve em um executor de tarefas, uma camada de cache, serializadores de saída e um cliente de requisições. Você não está comprando só um driver; está comprando um fluxo de trabalho opinativo com um driver dentro.

Os três decoradores resumem todo o design, e os três pontos de entrada existem de fato — confirmei que botasaurus.browser.browser, botasaurus.request.request e botasaurus.task.task existem e importam corretamente. @browser executa sua função sobre o driver de navegador humanizado. @request roda a função em um cliente HTTP leve, com aparência de navegador. @task é o wrapper genérico para tudo o que não se encaixa claramente nas duas primeiras opções. Ao decorar, o Botasaurus fornece a maquinaria ao redor: execução paralela, reaproveitamento de driver, cache de resultados e gravadores para JSON, CSV, Excel e HTML. É uma ideia coerente. Se você quer tanto framework em volta de um scraper, isso já é uma questão de preferência — não um defeito.

A leitura geral e o limite desta análise

O Botasaurus é competente, bem estruturado e faz aquilo que frameworks devem fazer: encurta o caso comum. O modelo baseado em decoradores é limpo. A licença MIT é realmente generosa. A instalação funciona sem drama. Se eu estivesse avaliando a ergonomia da API, ele se sairia bem.

O ponto que continua voltando é que a principal promessa do próprio framework — anti-detecção — é exatamente o que uma análise responsável não pode validar sem apontá-lo para as defesas de produção de alguém. O driver, sim, expõe uma superfície de API explicitamente associada a anti-detecção: métodos cuja existência eu confirmei, mas cujo comportamento não exercitei contra nenhum alvo. Isso é o máximo que vou afirmar sobre o assunto. Não apontei o driver para um site protegido, não medi taxa de sucesso, não reverse-engineerei mecanismo nenhum e não vou sugerir qualquer uma dessas coisas por escolha de palavras. Os métodos existem na classe. O que eles fazem no mundo real é uma avaliação separada, e esta não é essa avaliação.

O que se segue é um inventário de capacidade, instalação, recursos e licença, além do que o driver faz em uma página sob meu controle — uma afirmação mais estreita do que a maioria das análises sobre essa ferramenta costuma fazer, e essa restrição é justamente o ponto.

O que ele declara sobre si mesmo

Aqui vai uma pergunta que você pode responder sem chegar perto de uma defesa real: quando o Botasaurus dirige um navegador, o que esse navegador entrega espontaneamente à página que está acessando? Eu escrevi uma página que lê as evidências mais óbvias — navigator.webdriver, user-agent, plataforma, idiomas, contagem de plugins e de hardware, a estrutura de window.chrome, o que a Permissions API informa, e a geometria da janela e da tela —, servi essa página em 127.0.0.1 e testei quatro stacks: Botasaurus, nodriver e os controles padrão do Playwright e do Puppeteer. As quatro usaram a mesma versão do Chrome (Chrome for Testing 151.0.7922.10), então qualquer diferença vem da biblioteca, não do navegador. Em modo headless e headed, três execuções cada. Todos os valores abaixo se mantiveram nas três repetições.

As diferenças dependem de qual controle você usa. Em comparação com o Puppeteer padrão, o Botasaurus alterou navigator.webdriver; a lista de idiomas e a geometria da janela em tamanho zero coincidiram, enquanto o user-agent diferiu apenas na formatação da versão. Contra o Playwright padrão, as diferenças observadas também incluíram a lista de idiomas e a geometria da janela. Contra o nodriver, o booleano e os idiomas coincidiram, com diferença apenas na formatação do user-agent nos campos mostrados aqui. Essas são observações sobre exposição padrão, não uma nota de anti-detecção.

Dois detalhes tornam isso mais interessante do que o simples false. O primeiro é como o valor aparece. Em todas as quatro stacks, a propriedade continua sendo o getter nativo do próprio navegador em Navigator.prototype — function get webdriver() { [native code] } — e nunca uma propriedade própria plantada na instância, nem uma função substituída. Ou seja, o Botasaurus não reescreve a propriedade depois que a página carrega; o valor é definido quando o navegador inicia, e a propriedade em si permanece intocada.

O segundo detalhe é o que relativiza o marketing. Em modo headless, o user-agent do Botasaurus ainda anuncia HeadlessChrome/151.0.0.0 — exatamente como o Puppeteer padrão e exatamente como o Playwright padrão. Em modo headed, ele vira Chrome/151.0.0.0, de novo de forma idêntica. O construtor Driver aceita o parâmetro user_agent, então definir um valor está a uma keyword argument de distância, mas nada na configuração padrão mascara a string mais famosa de identificação em automação de navegador.

Quase todo o resto foi igual nas quatro stacks, e vale dizer isso de forma clara porque isso estreita a história — cada propriedade abaixo apareceu igual no Botasaurus, no nodriver, no Playwright e no Puppeteer:

O velho caso em que a Permissions API e Notification.permission se contradizem não apareceu em lugar nenhum — todos os quatro reportaram default e prompt de forma consistente. Também procurei nos objetos document e window por sobras no estilo cdc_, conhecidas em stacks WebDriver mais antigas: nada em todas as quatro.

Uma última coisa importante antes de você implantar: apesar dos seus 122 MB, o Botasaurus não traz nem baixa um navegador. find_chrome_executable() resolve para o Chrome que já estiver instalado na sua máquina — no meu caso, /Applications/Google Chrome.app, versão 150.0.7871.187 — e essa é a versão que o user-agent acaba revelando. Sua frota anuncia o Chrome que ela já tiver instalado, o que, para um framework tão opinativo, é um padrão surpreendentemente pouco opinativo.

É importante dizer o que isso é e o que não é. É um registro do que uma stack automatizada divulga quando ninguém pediu que ela escondesse nada — útil para quem defende, útil para quem quer saber o que sua própria ferramenta expõe. Não é uma medida de relevância disso para um serviço específico. Eu não testei isso, e nenhuma linha acima deve ser lida como implicando um resultado.

Uma leitura mais tolerante desse fixture

Se anunciar a si mesmo é uma coisa, devolver o HTML correto é a tarefa. Eu executei o Botasaurus no mesmo fixture de três classes de conteúdo que o restante deste repositório de benchmark usa, para que os números fossem comparáveis com todas as outras ferramentas medidas aqui. A página contém três elementos: A, um link estático cujo marcador é um literal nos bytes servidos; B, um nó criado por um script inline durante o parse, com marcador e URL montados a partir de fragmentos de modo que só a execução do JavaScript revela o resultado; e C, um nó inserido 800 ms após o evento de load, montado da mesma forma. A classe C é a adversária — uma leitura feita no evento de load não consegue vê-la.

O Botasaurus se comporta como os pesos-pesados. driver.get() seguido diretamente por driver.page_html gera uma captura no momento do load: ele processa JavaScript corretamente — a classe B prova isso, já que B não existe nos bytes servidos —, mas, com um atraso de 800 ms, ele perde a classe C. Adicione driver.wait_for_element("#delayed-injected") e você obtém as três. O resultado se manteve estável nas três repetições e nas três execuções separadas de todo o conjunto, sem flutuações.

A parte interessante aparece quando você varre o atraso de injeção para encontrar onde cada stack abandona a leitura padrão:

Todas as outras stacks perdem a classe C assim que a injeção acontece 100 ms ou mais depois do load. O Botasaurus ainda a captura com 300 ms e só desiste em 400. Isso é o framework sendo framework, e a causa está logo no construtor: wait_for_complete_page_load=True é o padrão, então get() retorna de forma significativamente mais tardia do que um evento de load puro. Na prática, sua leitura padrão custa cerca de 401–431 ms de tempo de parede, enquanto a do nodriver fica em 119–129 ms e a do Puppeteer em 125–171 ms.

Nesse fixture local com injeção tardia, a troca foi de aproximadamente 250 ms por navegação para uma captura padrão mais tardia. Isso fez o Botasaurus enxergar conteúdo injetado até 300 ms após o load nestas execuções; isso não prova que ele é mais correto em sites arbitrários. Se você escreve scrapers rápidos sem condições explícitas de espera, essa margem pode evitar a perda de um nó que chega tarde. Em alto volume de navegação, ou quando você já espera uma condição precisa, isso é apenas overhead.

Mais dois tempos para dar escala. Subir o navegador deixou o Botasaurus praticamente no mesmo nível de nodriver e Puppeteer, e bem atrás do Playwright:

E wait_for_element() não acrescenta custo extra até um atraso de 300 ms — get() já havia passado do ponto de injeção — e então sobe para cerca de 1,42 s em atrasos de 400–800 ms e 2,43 s em 1500 ms.

A questão dos 122 MB: o que um meta-package realmente instala

Aqui está a conta, porque é a coisa mais útil que posso te entregar. Um pip install botasaurus limpo em um ambiente virtual novo produziu uma árvore site-packages de 122,3 MB espalhada por 44 pacotes dist-info. Se você remover o pip em si (10,9 MB, que é overhead do venv e não algo pedido pelo Botasaurus), sobra aproximadamente 111 MB de framework e dependências. O driver de navegador — a peça que realmente faz a automação do browser — representa cerca de 4 MB disso. Ou seja, algo como 107 MB é tudo o mais que o meta-package decidiu que você precisava.

Para onde isso vai? Só as cinco dependências transitivas mais pesadas respondem pela maior parte do total (cada linha abaixo corresponde a uma entrada install_footprint.heaviest_deps_mb em artifacts/raw/runs/resource_baseline.run1.json; o total é minha soma, não um campo do arquivo):

O fato de o numpy ser o item individual mais pesado foi o que me fez levantar a sobrancelha — é uma biblioteca de álgebra linear dentro de uma ferramenta cujo trabalho é buscar e analisar páginas web. Não está errado, exatamente; frameworks acumulam dependências utilitárias, e algo na árvore evidentemente quer matemática com arrays. Só é muita máquina para esse tipo de tarefa.

Em escala, o driver focado nodriver pesa cerca de 17,2 MB em 6 pacotes na mesma máquina — algo como 7x mais leve. (Esse número não vem deste pacote: ele é install_footprint.site_packages_total_mb no próprio artifacts/raw/runs/resource_baseline.run1.json do nodriver, medido em uma execução separada e escalonada no mesmo host, e 122,3 ÷ 17,2 = 7,1.) Nenhum dos números é defeito e isso não é um ranking de capacidade; é a diferença mecânica de custo entre um framework com “baterias incluídas” e um driver focado. Em um container, o footprint medido de site-packages contribui para a camada da aplicação. Isso não é o tamanho total da imagem, e este teste não mediu tempo de build nem cold deploy.

Mais uma nuance de footprint: durante a inspeção, o primeiro uso de from botasaurus.request import request disparou um download pontual de cerca de 12,8 MB. A execução capturada não identificou bem o artefato e o destino para tratar esse valor como um incremento estável do footprint instalado. Mas isso mostra que esse caminho de código pode precisar de acesso à rede no primeiro uso, algo que vale reproduzir na sua própria imagem antes de um deploy sem internet.

O número de import que engana

Tempo de import em cold start é onde uma leitura apressada dos números dá errado. Medido em sete subprocessos novos de import, import botasaurus no topo ficou numa mediana de 0,08 ms. Cite isso isoladamente e ele parece o framework mais leve da categoria.

Não é. Ele é rápido porque quase não há nada ali. O pacote botasaurus expõe nenhum __version__ e um namespace público quase vazio — importar o pacote faz pouquíssimo trabalho porque ele quase não contém nada. O número que realmente importa para uma ferramenta de linha de comando ou um cold start serverless é o import do mecanismo: from botasaurus_driver import Driver leva cerca de 135 ms, estável dentro de poucos milissegundos entre execuções. Esse é o custo fixo real que você paga antes de buscar qualquer página. E, uma vez importado o módulo do driver, a memória residente fica em torno de 29–30 MB — novamente, antes de existir qualquer processo do Chrome. Abra um navegador de verdade e isso cresce bastante; eu não medi memória com um navegador em execução, então não vou inventar um número.

A lição é pequena, mas forte: import botasaurus ser instantâneo é uma propriedade do pacote topo de árvore ser vazio, não do framework ser barato. Se você estiver dimensionando cold start, meça o import de que realmente vai depender.

Formato da API: 99 métodos atrás de uma porta quase vazia

A classe Driver do mecanismo expõe 99 métodos públicos — uma superfície ampla que cobre navegação, consultas de elementos, cookies e local storage, ações de mouse e teclado, screenshots, gerenciamento de abas, passthrough de CDP e upload de arquivos. O construtor aceita 18 parâmetros, o que mapeia de forma razoável a superfície ajustável: headless, proxy, profile, tiny_profile, block_images, block_images_and_css, wait_for_complete_page_load, chrome_executable_path, extensions, arguments, user_agent, window_size, lang e mais alguns. Como API de construção, ele cobre os controles usuais de um wrapper de navegador.

A pegadinha do formato está no topo, e é inocente, mas real. import botasaurus oferece um namespace quase vazio — sem __version__, praticamente sem nomes públicos no nível raiz. Tudo o que você realmente usa vive em submódulos: from botasaurus.browser import browser, Driver, from botasaurus.request import request, from botasaurus.task import task. Se você procurar botasaurus.__version__ para registrar qual build está rodando, não vai encontrar; terá de recorrer a importlib.metadata. Nada disso quebra coisa alguma. Só não é o layout que a maioria dos devs Python espera por reflexo — e saber disso evita cinco minutos de confusão no primeiro dia.

Uma observação sobre documentação dos métodos que destaquei antes permanece dentro da minha fronteira: dos métodos com nome associado a anti-detecção que existem, apenas 2 têm docstring no próprio código. Os demais são autoexplicativos apenas pelo nome, com documentação por método vivendo no site externo em vez de no código instalado. Isso é uma nota de localidade, não de qualidade — muitas bibliotecas excelentes mantêm a prosa fora do código —, mas se o seu fluxo é “ler a fonte para entender o método”, a maior parte dessa superfície vai te mostrar o nome e nada além.

Licença: MIT, inclusive no driver

Tanto o meta-package quanto o botasaurus-driver declaram MIT, com o classificador padrão License :: OSI Approved :: MIT License. MIT é permissiva: sem obrigação de copyleft, sem exigência de abrir o seu próprio código, com atrito mínimo para adoção comercial. Isso é um contraste real e nada trivial com o nodriver, driver adjacente de anti-detecção, que é distribuído sob AGPL-3.0 — uma licença copyleft cuja cláusula de uso em rede deixa muitos departamentos jurídicos apreensivos. Se licença é um fator decisivo para você, a posição MIT do Botasaurus é um ponto real a favor.

O cuidado é o mesmo de antes: a forma de meta-package. Essa MIT permissiva vale para as wheels próprias publicadas pela Omkar Cloud. Ela não garante automaticamente nada sobre os cerca de 40 pacotes transitivos que a instalação traz, cada um com a sua própria licença. Eu confirmei a MIT no topo dos pacotes publicados pela Omkar Cloud; não auditei a licença de cada dependência da árvore. Para um projeto de hobby, essa distinção raramente importa. Para adoção corporativa de uma árvore inteira, em uma empresa que cuida do seu software bill of materials, os 40 pacotes são algo que deve passar no seu próprio scanner de licença antes do compromisso — não porque eu tenha encontrado um problema, mas porque eu não olhei, e é exatamente em meta-packages que uma licença inesperada costuma se esconder.

Prós e contras

Prós:

• Design limpo com três decoradores (@browser / @request / @task), e os três pontos de entrada realmente existem — o framework encurta o caso comum.
• Licença MIT tanto no meta-package quanto no driver, um contraste real com a AGPL-3.0 de um driver comparável. Permissiva, amigável ao uso comercial, sem copyleft.
• Superfície de driver ampla: 99 métodos públicos e um construtor com 18 parâmetros cobrindo as necessidades comuns de automação de navegador.
• Instalou e passou em smoke tests de import em Python 3.14.2 e 3.12.13, além da faixa declarada nos classificadores (que para em 3.11); compatibilidade em runtime não foi estabelecida.
• A janela de correção da leitura padrão mais ampla entre todas as stacks que medi: ainda captura conteúdo injetado 300 ms após o load, enquanto nodriver, Playwright e Puppeteer perdem isso com 100 ms. wait_for_complete_page_load=True realmente faz trabalho.
• Reporta navigator.webdriver como false por padrão, enquanto os controles padrão reportam true, sem patchar a propriedade — o descriptor continua sendo o getter nativo do navegador.
• Vem com “baterias incluídas” por design — cache, paralelismo, reaproveitamento de driver e saída em JSON/CSV/Excel/HTML fazem parte do framework, não são acessórios.

Contras:

• Pesado em disco: 122,3 MB em 44 pacotes, cerca de 7x um driver focado, impulsionado por dependências como numpy (30,9 MB) e lxml (19,2 MB), e não pelo driver de ~4 MB em si.
• O reconfortante import de 0,08 ms no topo é enganoso; o import do mecanismo que você realmente usa fica em torno de 135 ms, e a memória pós-import é de ~29–30 MB antes de qualquer navegador.
• A janela de leitura padrão mais ampla não é gratuita: cerca de 401–431 ms por navegação+leitura contra 119–129 ms de um driver leve na mesma página e no mesmo Chrome.
• Em modo headless, o user-agent ainda anuncia HeadlessChrome por padrão, exatamente como os controles padrão; o parâmetro user_agent existe no construtor, mas nada o define para você.
• Para 122 MB, ele ainda não traz navegador: dirige o Chrome já instalado no host, então a versão exposta é a que sua frota já tiver.
• O primeiro uso de @request disparou neste teste um download único de cerca de 12,8 MB; o artefato e o destino não foram capturados bem o bastante para tratar isso como incremento estável de footprint.
• O pacote topo de árvore é quase vazio e não expõe __version__; a API real e a versão vivem em lugares menos óbvios.
• A maioria dos métodos com nome associado a anti-detecção não tem docstring no código, então ler a fonte mostra nomes, não comportamento.

Fora do que esses números cobrem — e portanto não testado aqui — estão: eficácia real contra anti-bot em produção (fora de escopo por definição), memória por página, tratamento de proxy e perfil, throughput em escala e qualquer plataforma além de macOS arm64. Os números de footprint e import foram produzidos sem abrir um navegador; os números de retenção e exposição vêm de navegadores que só falaram com um fixture em 127.0.0.1.

Para quem serve — e quem deveria passar

O Botasaurus faz sentido se você quer um framework, e não só uma peça. Se você vai iniciar um projeto de scraping a partir de um arquivo vazio e prefere adotar uma estrutura em vez de montar uma: decoradores para os pontos de entrada, cache e paralelismo já resolvidos, gravadores de saída embutidos — este é um caminho coerente e com licença MIT. A MIT é permissiva, mas seu modelo de uso e distribuição ainda merece a revisão normal de compliance. Times que já pensam em termos de Scrapy ou Crawlee vão achar a proposta familiar.

Vale pular, ou pelo menos pensar duas vezes, se seu alvo de implantação é sensível a tamanho. Uma instalação de 122 MB com numpy e gevent na árvore é muita coisa para enviar a um container enxuto quando sua necessidade real é “dirigir um navegador e extrair alguns campos”. Um driver focado entrega a automação com uma fração do peso, ao custo de você mesmo montar a infraestrutura ao redor. E vale pular completamente se o que você quer é uma decisão sobre eficácia anti-detecção, porque isso é justamente o que eu deliberadamente não testei — você estaria confiando em uma promessa de marketing que eu não confirmei nem refutei.

Alternativas e onde o Thunderbit se encaixa

Primeiro, o enquadramento honesto: o Botasaurus é gratuito, tem licença MIT e é auto-hospedado. Você roda a frota, gerencia as atualizações e assume toda a árvore de dependências — os 44 pacotes — incluindo correções, compliance de licença e qualquer coisa que o numpy decida fazer em uma versão futura. Para muitos times, essa autonomia é exatamente o que eles querem, e nenhum serviço gerenciado vence “um framework que você já tem” em custo bruto.

No universo open source, as comparações úteis são por formato. Se você está no extremo de framework com o Botasaurus, Scrapy e Crawlee são os pares óbvios para colocar na balança — maduros, opinativos e cada um com suas próprias convenções. Se você quer Markdown pronto para LLM a partir de uma página, e não um framework para estruturar um crawler, Crawl4AI e o Trafilatura, focado em conteúdo, miram exatamente esse trabalho. Se você gosta do eixo Python + anti-detecção, mas quer algo mais leve do que um meta-package, Scrapling merece atenção; e se uma linguagem compilada estiver no radar, a biblioteca Go Colly troca renderização de JavaScript por velocidade e um footprint mínimo. Qualquer opção que dirija navegador, Botasaurus incluído, herda o perfil de custo descrito na nossa comparação entre Playwright e Puppeteer — navegadores reais não são baratos de operar, e é parte disso que explica o peso do framework em volta deles.

Quando entra uma API gerenciada, você já está em outro ponto da mesma pipeline. O Botasaurus é a stack de desenvolvedor auto-hospedada; o Thunderbit oferece a opção gerenciada, voltada ao mesmo público técnico. A Open API tem dois endpoints. POST /distill (1 crédito) devolve uma página em Markdown limpo, pronto para LLM, com renderização e anti-bot tratados do lado do servidor, então você não precisa provisionar navegador nem árvore de dependências nenhuma. POST /extract (20 créditos) devolve JSON estruturado com base em um JSON Schema que você define, com renderMode em none, basic ou full, conforme o quanto de navegador a página realmente precisa. Ambos têm versões em lote para até cem URLs por vez. Há um servidor MCP para agentes e assistentes de código — thunderbit_suggest_fields é grátis e mostra o que uma página expõe antes de você gastar qualquer coisa — e também CLI via npx @thunderbit/thunderbit-cli para cron e CI. Para quem não programa e prefere não mexer com nada disso, a extensão do Chrome usa o mesmo motor como ferramenta no-code, e os tutoriais no canal do Thunderbit no YouTube cobrem os fluxos mais comuns.

A troca está em onde o trabalho acontece, não em qual ferramenta é “melhor”. O Botasaurus deixa framework, frota de navegadores, dependências, infraestrutura e manutenção do seu lado da linha, sem cobrança de fornecedor por requisição; ainda assim, computação, banda, proxies e operação continuam custando dinheiro. Uma API gerenciada tira da sua frente a renderização e a saída em formato de esquema e cobra por chamada — você pode comparar isso com uma implementação auto-hospedada na página de preços.

Experimente o Thunderbit para extração de dados da web

Veredito

Botasaurus é um candidato razoável se você quer um framework Python tudo-em-um e aceita seu peso em dependências. O design com três decoradores é limpo, a superfície do driver é ampla e ele passou em smoke tests de instalação e import em versões de Python mais novas do que os classificadores declaram. No meu fixture local, sua captura padrão também pegou conteúdo injetado 300 ms após o load, enquanto as outras stacks testadas perderam isso com 100 ms; esse é um resultado do fixture, não um ranking geral.

Mas é preciso dimensionar as alegações corretamente. Trata-se de uma instalação de 122 MB, com 44 pacotes, em que o driver ocupa cerca de 4 MB e o resto é numpy, lxml, gevent e companhia — algo em torno de 7x um driver focado, e esse peso vira imagem de container e tempo de build/deploy frio. O import de topo de 0,08 ms é uma porta vazia, não um framework leve; o import do mecanismo, em torno de 135 ms, é o número que realmente te cobra. Essa leitura padrão mais tolerante custa cerca de 250 ms em cada navegação. E, na questão de exposição padrão que eu de fato consegui responder, o quadro é mais estreito do que o marketing sugere: um booleano difere do Puppeteer padrão, o user-agent em headless ainda diz HeadlessChrome, e todas as outras propriedades que medi foram idênticas nas quatro stacks. A promessa de stealth que vende a ferramenta é justamente a parte que esta análise não classifica — confirmei que os métodos existem, usei o driver em uma página na minha própria máquina e parei por aí, de propósito. Saiba qual é o footprint, ignore o número de import lisonjeiro e trate o marketing de furtividade como uma questão em aberto; nesse cenário, o Botasaurus é um framework honesto que faz exatamente o que um framework faz. Espere um driver leve como pena e o susto vai aparecer no tempo de docker build.

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

Perguntas frequentes

O Botasaurus é gratuito e sob qual licença ele está? É gratuito e licenciado sob MIT — tanto o meta-package botasaurus quanto o mecanismo botasaurus-driver carregam o classificador MIT aprovado pela OSI. A MIT é permissiva, então não há obrigação de copyleft e o uso comercial é tranquilo, o que contrasta de forma significativa com drivers comparáveis de anti-detecção que saem sob AGPL-3.0. Um cuidado: a MIT cobre os pacotes próprios da Omkar Cloud, mas não garante automaticamente os cerca de 40 dependências transitivas que a instalação traz; por isso, faça sua própria varredura de licença antes de uma adoção corporativa da árvore inteira.

Quão grande é uma instalação do Botasaurus e por que import botasaurus parece instantâneo? Um pip install botasaurus limpo gerou, na minha máquina, uma árvore site-packages de 122,3 MB em 44 pacotes. O próprio driver de navegador ocupa só cerca de 4 MB — o peso vem do meta-package puxar uma árvore larga de dependências, liderada por numpy (30,9 MB), lxml (19,2 MB), botasaurus_requests (12,6 MB), gevent (11,3 MB) e pygments (8,4 MB). Isso dá algo em torno de 7x o footprint de um driver focado como o nodriver na mesma máquina. Nada disso é um defeito; é o custo de “baterias incluídas”, e isso pesa principalmente no tamanho da imagem de container. O tempo de import é onde esse peso fica escondido: import botasaurus mede cerca de 0,08 ms, mas só porque o pacote de topo é quase vazio — sem __version__, com pouquíssimos nomes públicos, então importar faz quase nada. O import que realmente custa é o mecanismo, from botasaurus_driver import Driver, em cerca de 135 ms, com memória residente em torno de 29–30 MB depois do import e antes de qualquer navegador iniciar. Está dimensionando cold start serverless? Meça o import do mecanismo, não o pacote vazio de topo.

O que o Botasaurus expõe sobre si mesmo e ele foi testado contra sistemas anti-bot reais? A primeira metade foi medida; a segunda foi deliberadamente não testada. Em uma página que eu servi de 127.0.0.1, usando a mesma versão do Chrome dos controles: navigator.webdriver volta false, enquanto o Playwright padrão e o Puppeteer padrão retornam true. Esse valor é definido no lançamento do navegador, e não por patch da propriedade — o descriptor continua sendo o getter nativo do Chrome. Fora esse booleano, quase tudo coincidiu exatamente com os controles: mesma string de plataforma, cinco plugins, doze núcleos, 16 GB de memória de dispositivo reportada, mesma estrutura de window.chrome, nenhuma contradição da Permissions API e nenhuma sobra no estilo cdc_ em document ou window. Em headless, o user-agent ainda anuncia HeadlessChrome/151.0.0.0, igual aos dois controles — o construtor Driver aceita user_agent, mas nada o define para você. Quanto à eficácia: nunca apontei o driver para um site real, nunca contatei um serviço anti-bot e nunca toquei em CAPTCHA. O driver inclui um conjunto de métodos com nomes ligados a anti-detecção, cuja existência eu confirmei, mas não os chamei, não exercitei seu comportamento contra qualquer alvo, não medi taxa de sucesso e não descrevi mecanismo algum. A tabela de exposição acima diz o que a stack anuncia — e nada sobre quem escuta ou o que faz com isso.

O Botasaurus lida corretamente com conteúdo renderizado em JavaScript? Sim, e o padrão dele é mais tolerante do que o da maioria. Em um fixture com três classes de conteúdo, driver.get() + driver.page_html retornou 2 de 3 com um atraso de injeção de 800 ms — ele executa JavaScript corretamente, mas lê antes que o conteúdo muito tardio apareça — e driver.wait_for_element() retornou 3 de 3. O diferencial está no ponto em que a leitura padrão desiste: o Botasaurus ainda captura conteúdo injetado 300 ms após o load, enquanto nodriver, Playwright e Puppeteer perdem isso com 100 ms. Isso vem de wait_for_complete_page_load=True no construtor e custa cerca de 250 ms por navegação.

Como eu importo e uso o Botasaurus depois de instalar? Não do jeito que você imagina. O namespace de topo botasaurus é quase vazio, então a API real vive em submódulos: from botasaurus.browser import browser, Driver, from botasaurus.request import request e from botasaurus.task import task. Você decora uma função comum com @browser, @request ou @task, e o framework cuida do driver, do cache e da saída ao redor. Como não existe botasaurus.__version__, use importlib.metadata se precisar registrar qual build está executando.