Todo post sobre o “analisador HTML Python mais rápido” acaba citando selectolax, e quase todos encerram a história com “muito mais rápido que o BeautifulSoup”. Isso é verdade. O que quase ninguém conclui é o que acontece quando colocamos o selectolax lado a lado com o lxml — porque aí o “mais rápido” ganha um asterisco.
Então eu fiz um benchmark direito: selectolax (nos dois backends) contra lxml, BeautifulSoup com html.parser e com lxml, e parsel, em cinco tamanhos de página de 1 KB a 10 MB, medindo cada caso como a mediana de três execuções separadas em processos distintos. O selectolax venceu o BeautifulSoup com folga e empatou com o lxml bruto — e depois perdeu a etapa de parsing puro para o lxml. Todos os números abaixo são provisórios e foram obtidos em uma única máquina (macOS arm64, Python 3.14.2); os scripts estão no repositório, então rode no seu ambiente antes de citar meus resultados.
O que o selectolax realmente é — e o que não é
selectolax é uma interface Python para dois motores em C — Modest e Lexbor — que fazem parsing de HTML5 e permitem consultas com seletores CSS. Ele não é crawler, não é navegador, não é “scraper” no sentido de apertar um botão e pronto. É a peça que você usa depois de já ter baixado o HTML. A própria descrição do mantenedor é: “A fast HTML5 parser with CSS selectors, written in Cython, using Modest and Lexbor engines.”
Existem dois backends, e a diferença entre eles importa mais do que a documentação deixa claro:
LexborHTMLParser(motor Lexbor) — o que o README recomenda usar a partir de 2024.HTMLParser(motor Modest) — o original, cujo código C subjacente “não é mais mantido”, segundo o mesmo README.
Vale ter alguns fatos em mãos antes de falar de velocidade. No snapshot do repositório de 2026-07-10, o selectolax tinha 1.653 estrelas e a versão mais recente era a v0.4.10 (maio de 2026); o PyPI indica compatibilidade com Python >=3.9,<3.15. A instalação é a parte menos dramática desta avaliação: pip install selectolax baixou um wheel pré-compilado de 2,3 MB para cp314 e funcionou de primeira no Python 3.14 — sem download de navegador, sem etapa de doctor, sem compilação. Essa é a vantagem discreta de um parser puro em relação a uma ferramenta baseada em navegador: ele simplesmente importa e executa.
Também vale registrar já uma observação de licença: o binding Python é MIT, mas o wheel embute os motores compilados, e eles têm suas próprias licenças — Modest é LGPL-2.1, Lexbor é Apache-2.0. Ou seja, dizer que “selectolax é MIT” é verdadeiro para o código Python, mas incompleto para o binário que você realmente distribui. Se o seu jurídico se importa com componentes redistribuídos, esse é o detalhe importante.
A pergunta da velocidade, respondida com números reais
A tarefa que eu medi foi esta: fazer o parse da string HTML, extrair todo o texto de <h3 class="title"> e pegar o href de cada <a>. A latência está em milissegundos e usa a mediana de três execuções em processos separados; a variação entre execuções ficou abaixo de ~5% para os parsers em C na maioria dos tamanhos. Antes de medir qualquer célula, a saída de cada parser foi reduzida a um hash de conteúdo, para que um parser que fizesse menos trabalho sem avisar fosse detectado e excluído — nestas páginas, os seis bateram em todos os tamanhos, então a comparação é realmente justa. Os dados completos estão em bench_parse.json.
| Página | selectolax (Lexbor) | selectolax (Modest) | lxml | parsel | BS (lxml) | BS (html.parser) |
|---|---|---|---|---|---|---|
| 1 KB | 0.027 | 0.029 | 0.036 | 0.044 | 0.281 | 0.323 |
| 10 KB | 0.160 | 0.171 | 0.166 | 0.228 | 1.705 | 2.049 |
| 100 KB | 1.464 | 1.565 | 1.423 | 2.020 | 16.5 | 20.6 |
| 1 MB | 14.901 | 16.9 | 14.177 | 20.9 | 181.9 | 232.6 |
| 10 MB | 159.9 | 247.9 | 172.9 | 231.9 | 2261.6 | 2788.7 |
Contra BeautifulSoup: cerca de 12 a 17x, e o consenso popular subestima
Convertendo esses números em proporções, o selectolax-Lexbor fica cerca de 12x mais rápido que BeautifulSoup(html.parser) em uma página de 1 KB, chegando a cerca de 17x em 10 MB, e cerca de 10 a 14x mais rápido que BeautifulSoup(lxml) no mesmo intervalo. O número que circula por aí — “selectolax é cerca de 4 a 5x mais rápido que BeautifulSoup” — fica baixo demais quando comparado ao html.parser e só chega perto do real quando o BeautifulSoup usa lxml por baixo. O multiplicador exato depende de qual BeautifulSoup você está usando e de quanto você extrai por página.
Isso também bate com o benchmark do próprio README, que sugere uma vantagem de 25,5x sobre BeautifulSoup(html.parser). Nenhum dos dois números está errado. A tarefa do README (título, links, scripts e meta tags de homepages pequenas) faz menos extração em páginas menores, o que pesa mais no overhead por parse do BeautifulSoup. Em resumo, na faixa testada, o selectolax fica em algo como 10 a 15x mais rápido que o BeautifulSoup em trabalho real de parse + extração, com vantagem maior em páginas pequenas e extração mais leve.
Se o gargalo atual do seu projeto é um bloco grande de código com BeautifulSoup processando páginas, essa é a migração que já paga a conta. Esse caso é fácil de defender. O próximo, não tanto.
Contra lxml: empate — e o lxml vence a parte que muita gente esquece de isolar
Olhe de novo para as linhas de 100 KB e 1 MB. Lexbor e lxml ficam dentro de cerca de 5% um do outro, as faixas por execução se sobrepõem e, pelo meu critério, isso é empate — sem vencedor, sem “mais rápido”. O único ponto em que o selectolax realmente abre vantagem é a página de 10 MB (159,9 ms contra 172,9 ms, uma diferença de 8,1% sem sobreposição de intervalos). Então, na tarefa completa, o selectolax empata com o lxml e só vence em documentos realmente grandes.
Depois eu separei a construção da árvore da consulta CSS, e o resultado muda de forma que muita análise por aí não percebe. No parsing puro, sem consulta nenhuma, o lxml foi consistentemente cerca de 33 a 34% mais rápido que o selectolax-Lexbor nesta máquina — 77,9 ms contra 116,6 ms na página de 10 MB. Na tarefa completa os dois acabam convergindo de qualquer forma, e minha hipótese de trabalho — não algo que eu tenha provado com um experimento de atribuição — é que nessas páginas a consulta CSS representa uma fatia pequena do tempo total, então a vantagem do lxml no parsing acaba diluída até os totais se encontrarem.
Essa é a afirmação mais fácil de contestar em toda a análise, e eu quero deixar claro o motivo. Ela contraria a sabedoria comum, e o único benchmark publicado que encontrei isolando apenas parsing — aows.jpt.sh — mostra o contrário, com o selectolax cerca de 4x mais rápido. Então eu delimitei o resultado: ele é de uma única plataforma (macOS arm64, Python 3.14, wheels cp314 pré-compilados — em Linux x86_64 ou build via código-fonte não testei), foi checado em quatro tamanhos de página e se manteve em todos, e foi revalidado com duas APIs diferentes do lxml para descartar artefato de API. As duas APIs do lxml venceram o selectolax-Lexbor em todos os tamanhos. Não estou apresentando “lxml faz parsing mais rápido” como verdade final — estou mostrando o que meu benchmark produziu, com o script anexado, em contraste com boa parte dos números publicados. Rode no seu ambiente.
Mais uma fatia: ao consultar 100.000 <a> em uma página plana, lxml e selectolax-Modest empatam (33,30 ms contra 34,19 ms, com faixas sobrepostas), enquanto o selectolax-Lexbor fica cerca de 15% atrás de ambos. O que os três motores em C têm em comum é serem de 5 a 7x mais rápidos que parsel ou BeautifulSoup em seleção em massa, cujo modelo de um objeto Python por nó é o verdadeiro gargalo. Então a frase “selectolax é o mais rápido em seleção CSS em massa” também não se sustenta — o Modest apenas empata com o lxml, e o Lexbor perde para ele.
A conclusão que eu realmente sustentaria é esta: a vantagem do selectolax sobre o lxml não é uma velocidade ampla e geral. Ele só vence na maior página. Seu argumento está em outras coisas — ergonomia da API, comportamento com HTML ruim e CSS moderno — e é aí que o resto desta análise entra.
Memória e cold start: classifique por RSS, não pelo profiler
Memória é onde eu preciso corrigir meus próprios números anteriores, e a correção é justamente o ponto. Medindo como delta de RSS na página de 10 MB com tracemalloc desligado, BeautifulSoup usa cerca de 1,5 a 1,8x mais memória que selectolax ou lxml — a faixa vai de 1,51x (BS-lxml em 218,4 MB contra Lexbor em 144,6 MB) até 1,75x no extremo superior. selectolax e lxml ficam na categoria enxuta; lxml é o mais econômico em RSS.
Uma análise anterior minha dizia “~3x”, e esse número estava errado por um motivo útil: ele foi medido com tracemalloc ligado, e o controle de alocação por objeto do tracemalloc praticamente dobra o RSS aparente do parser que mais aloca. Então fica o alerta para quem estiver medindo memória de parsers: classifique por RSS com o profiler desligado. Classificar parsers pelo pico do tracemalloc inverte a ordem dos motores em C especificamente — fez o selectolax-Lexbor parecer mais pesado que o Modest quando, no RSS real, eles estão próximos. O BeautifulSoup é mesmo o mais pesado aqui; só não chega a ser 3x mais pesado como uma medição contaminada sugeriu.
O cold start é pequeno, mas existe: o selectolax importa em cerca de 14 ms, praticamente no mesmo nível do lxml e cerca de 2,3x mais rápido que bs4 ou parsel. Se você distribui uma CLI ou uma função serverless em que o tempo de importação faz parte de cada execução, essa diferença importa.
Cobertura de seletores CSS: forte, com alguns buracos reais
A cobertura de CSS passou por uma matriz de 41 casos, com cada seletor testado contra um fixture com resposta correta conhecida, além de uma rodada deliberada de casos problemáticos para quebrar o motor Lexbor. Cada teste rodou em seu próprio subprocesso, o que acabou sendo necessário — um deles derruba o interpretador inteiro. Os resultados:
| Motor | PASSOU | ERRADO | SEM SUPORTE | PROCESS_ABORT |
|---|---|---|---|---|
| soupsieve | 41 | 0 | 0 | 0 |
| selectolax Lexbor | 39 | 0 | 2 | 0 |
| lxml (cssselect) | 37 | 1 | 3 | 0 |
| parsel (cssselect) | 37 | 1 | 3 | 0 |
| selectolax Modest | 35 | 3 | 2 | 1 |
Quando colocamos seletores adversariais no meio, o Lexbor não é o vencedor absoluto — o soupsieve é, com 41/41 limpo contra 39/41 do Lexbor. As duas falhas do Lexbor são :lang(en) e :dir(rtl), que ele rejeita com erro de parse. Fora isso, ele acerta tudo, incluindo :has(), :is(), :where() e atributos com comparação sem distinção de maiúsculas/minúsculas.
Onde o Lexbor realmente se destaca é contra o conjunto cssselect. O seletor principal do README — div > :nth-child(2n+1):not(:has(a)) — retorna o conjunto correto nos dois motores do selectolax e no soupsieve, mas o conjunto errado no lxml e no parsel, sem levantar erro. Um scraper que copie esse seletor para Scrapy ou parsel vai gerar resultados errados em silêncio. Para ser preciso na formulação: o cssselect já faz parse de :has() desde a versão 1.2.0 (2022), e eu testei a 1.4.0, então o caso aqui é “suportado, mas avaliado de forma incorreta no composto”, e não “não suportado”. Esse comportamento silenciosamente errado nesse composto específico não aparece no rastreador do cssselect, que registra os limites de :has() como erros levantados. O Lexbor também lida com o seletor de atributo case-insensitive [data-role="LEAD" i], que o cssselect rejeita de imediato.
Mas existem duas lacunas que definem migrações. O selectolax não suporta XPath de forma alguma — nenhum dos backends expõe xpath() — e também não tem pseudo-elementos ::text / ::attr(), porque isso é uma extensão do parsel/Scrapy, não CSS de verdade. Se seus scrapers atuais dependem de XPath, esse é o maior obstáculo que você vai encontrar; você não estará trocando só de biblioteca, mas reescrevendo seletores. Por outro lado, o Lexbor traz a pseudo-classe :lexbor-contains("text" i) para busca de texto sem diferenciar maiúsculas/minúsculas, algo que nem lxml, nem parsel, nem o CSS padrão oferecem — e ela funciona como documentado.
Robustez com HTML feio, onde o selectolax realmente se paga
Scraping real significa jogar lixo no parser e torcer para ele não cair. Eu rodei 18 entradas adversariais, e é nessa categoria que o argumento do selectolax contra o lxml fica mais forte.
Se você passa lxml.html.fromstring uma string vazia ou só espaços em branco, ele levanta ParserError("Document is empty"). Os dois motores do selectolax retornam uma árvore vazia válida. Para um scraper que percorre uma lista de URLs e às vezes recebe resposta em branco, isso significa um try/except a menos envolvendo tudo. O selectolax também processou 100.000 elementos sem estourar a pilha.
O empilhamento profundo foi onde a diferença ficou mais nítida. Em níveis de 1.000 e 5.000 <div> aninhados, o lxml simplesmente descarta o conteúdo mais profundo enquanto o selectolax o preserva. O libxml2 limita a profundidade de parse em torno de 256 níveis e truncará a árvore sem erro, então o texto mais profundo fica inacessível. Os dois motores do selectolax retornam a árvore completa. É o espelho do problema com <template> que vou citar a seguir: lá o Lexbor descarta conteúdo que os outros mantêm; aqui o lxml descarta conteúdo que o selectolax mantém.
Nem tudo foi vitória. O backend Modest derruba o interpretador Python inteiro com SIGABRT quando encontra :dir() — não é uma exceção que você possa capturar, é o processo sendo encerrado de forma abrupta. Isso é uma limitação real de robustez para quem ainda usa o backend legado, e exatamente o tipo de problema que só aparece quando derruba um job de produção às 3 da manhã.
Dois riscos de perda silenciosa de dados que você precisa conhecer antes de colocar em produção
Nenhum dos dois é descoberta nova — ambos estão documentados a montante — mas os dois causam perda real de dados, em silêncio, e nenhum deles aparece com destaque no README.
Lexbor ignora <a> dentro de <template>
Na página do MDN em produção que eu testei, o selectolax-Lexbor encontrou 497 links, enquanto lxml, os dois backends do BeautifulSoup e até o próprio backend Modest do selectolax encontraram 508. Os onze links faltantes eram um alternador de idioma e um link de discussões dentro de elementos <template> (a página usa componentes web Lit).
A causa raiz é legítima: segundo a especificação HTML5, o conteúdo de <template> é analisado em um fragmento separado e inerte, não no DOM normal, e o Lexbor segue isso à risca — tree.css("a") não desce para dentro do conteúdo de template. O lxml, os dois backends do BeautifulSoup e o Modest achatam o conteúdo de template na árvore principal, então encontram esses links. Trata-se de um problema aberto e documentado (selectolax#146, com a causa no motor em lexbor#170), e as duas leituras são defensáveis — o Lexbor é, inclusive, talvez o mais correto em termos de especificação. Mas um desenvolvedor usando o backend recomendado perde esses dados em silêncio, sem qualquer erro. O reverso também merece ser dito: os outros parsers expõem conteúdo inerte de template que um navegador nunca renderizaria, então podem devolver dados fantasmas que o usuário não vê. A saída confiável para esse caso específico é o backend Modest ou outra biblioteca.
Bytes fora de UTF-8 corrompem .text() sem aviso
Se você passar ao selectolax bytes que não são UTF-8 válido, o parsing até funciona — a corrupção aparece depois, e isso é pior do que uma falha limpa. Em "<p>café éè</p>".encode("latin-1"), o .text() do Lexbor devolve caracteres de substituição, o .text() do Modest simplesmente ignora os bytes problemáticos, e os dois motores só levantam UnicodeDecodeError quando você acessa .html. O binding faz a decodificação como UTF-8 estrito na leitura de volta, não no momento do parse. Isso está relacionado a um problema conhecido do selectolax sobre rigidez de encode/decode.
A correção é uma linha só e vale virar hábito: decodifique os bytes você mesmo antes — LexborHTMLParser(resp.content.decode("latin-1")) — e os dois motores retornam 'café éè' corretamente. Na prática, sempre entregue uma str ao selectolax, nunca bytes crus fora de UTF-8. O README não explicita isso.
Dimensões de produção (uma única observação, então trate como tendência)
Os resultados a seguir eu medi uma vez, não em três execuções, então estou marcando como sinais, não como números fechados.
O escalonamento com threads é o mais interessante. Ao fazer o parse de uma página de 1 MB 48 vezes distribuídas em quatro threads, o selectolax mostrou ganho de cerca de 3,5 a 3,9x no tempo de parede — assinatura empírica de uma biblioteca que libera o GIL durante o parsing em C — enquanto BeautifulSoup(lxml) ficou várias vezes mais lento em threads, assinatura de trabalho serializando no GIL. O lxml ficou no meio, sem conclusão clara. Para a era de free-threading para a qual o Python está caminhando, o selectolax paralelizando entre threads enquanto o BeautifulSoup não paraleliza é uma vantagem real, embora provisória. É um único número de threads em um único tamanho de página, e o mecanismo é uma hipótese, não algo que eu tenha confirmado instrumentando o código em C.
Sobre vazamentos: em 2.000 iterações de parse-extract-drop em uma página de 1 MB, nenhum dos três parsers mostrou o crescimento linear de RSS típico de vazamento — todos se estabilizaram numa faixa limitada de uso. Eu confio nesse resultado especificamente porque rodei um caso de calibração conhecido por vazar no mesmo instrumento, e ele subiu +198 MB como esperado, o que prova que a ferramenta veria um vazamento e simplesmente não encontrou nenhum nos parsers. E um handle de nó mantido vivo depois que sua árvore original saiu de escopo continuou utilizável, sem segfault. Tudo isso foi observado uma única vez, nada disso é um soak test de várias horas.
Onde o selectolax se encaixa — e onde ele passa o bastão
Tudo acima fala de uma única tarefa: transformar HTML que você já tem em dados estruturados, rápido. O selectolax é muito bom nisso. O que ele deliberadamente não faz é buscar a página, renderizar JavaScript, girar proxies, resolver CAPTCHAs ou decidir quais elementos você quer. Isso continua sendo responsabilidade do seu código. O selectolax é a camada de parsing, e não finge ser mais do que isso.
É aí que entra um serviço gerenciado de extração acima do parser, em vez de substituí-lo. Se você prefere não construir e manter sozinho a pilha de fetch, renderização, anti-bot e extração, a Thunderbit oferece isso como API, servidor MCP e CLI — POST /distill transforma uma página em Markdown limpo e POST /extract devolve JSON estruturado compatível com o esquema, com renderização JS e anti-bot tratados para você. É outra camada do problema: você usa selectolax quando já tem o HTML e quer velocidade bruta de parsing sob seu controle; e usa algo como a API, o servidor MCP ou a CLI da Thunderbit quando quer que busca e extração sejam resolvidas e só precisa receber os dados estruturados. Não é troca direta — é outra altitude na mesma pilha.
Experimente Thunderbit para extração de dados da web
Prós, contras e quem realmente deveria usar
Onde o selectolax ganha:
- Cerca de 12 a 17x mais rápido que o BeautifulSoup em trabalho real de parse + extração, estável em três ordens de grandeza no tamanho das páginas.
- Memória enxuta (na faixa do lxml, cerca de 1,5 a 1,8x mais leve que BeautifulSoup) e importação em cerca de 14 ms.
- Comportamento gracioso em entradas que quebram o lxml — vazias, só com espaços e com aninhamento absurdamente profundo.
- CSS moderno, incluindo
:has(),:is(),:where(), atributos case-insensitive e o:lexbor-contains()exclusivo do Lexbor. - DOM de leitura e escrita seguro com
None: elementos ausentes retornamNoneou[]em vez de lançar erro, e você realmente pode alterar e reserializar a árvore. - Manutenção ativa (v0.4.10, meados de 2026) e instalação trivial.
Onde ele não ganha:
- Não é mais rápido que o lxml de forma ampla — empate na tarefa completa, e perde no parsing puro no meu teste.
- Sem XPath e sem
::text/::attr()— uma barreira dura para quem já usa XPath. - Dois riscos de perda silenciosa de dados: conteúdo de
<template>no Lexbor e bytes fora de UTF-8 via.text(). - O backend Modest é legado e pode encerrar o processo com SIGABRT em
:dir(). - Todos os números aqui são de uma única plataforma (macOS arm64, Python 3.14) e provisórios.
Vale usar selectolax? Sim, se você quer velocidade de classe lxml com uma API mais amigável e segura com None, além de comportamento visivelmente melhor em HTML vazio e malformado — e se você aceita ficar no mundo apenas com CSS. Se o seu código depende de XPath, o custo de reescrita é real e deve ser considerado com honestidade. E se o objetivo for achar “o parser mais rápido de todos”, a resposta correta com base neste benchmark é que selectolax e lxml estão próximos o bastante para que o desempate venha de ergonomia e robustez, não de velocidade bruta. E, sinceramente, esse já é um motivo melhor para escolher uma ferramenta.
Experimente Thunderbit para extração de dados da web Get Started Free
Perguntas frequentes
O selectolax é mais rápido que o BeautifulSoup?
Sim, claramente — cerca de 12 a 17x mais rápido que BeautifulSoup(html.parser) e de 10 a 14x mais rápido que BeautifulSoup(lxml) em uma tarefa real de parse + extração, mantendo desempenho estável de páginas de 1 KB a 10 MB (macOS arm64, Python 3.14). O valor frequentemente citado de “4 a 5x” subestima a diferença contra html.parser.
O selectolax é mais rápido que o lxml? Não de forma ampla. Na tarefa completa de parse + extração, eles empatam em 100 KB e 1 MB, com o selectolax vencendo apenas na página de 10 MB. No parsing puro, sem consulta, o lxml foi cerca de 33 a 34% mais rápido na minha máquina — um resultado fora do consenso que eu tratei como específico desta plataforma, então vale verificar no seu hardware.
Devo usar o backend Lexbor ou Modest?
Lexbor, quase sempre — ele é o motor mantido, mais completo e recomendado no README, com melhor cobertura de CSS. A exceção é uma página que esconde conteúdo dentro de <template>, onde o comportamento correto do Lexbor faz esse conteúdo desaparecer e o Modest, por acaso, o preserva. O Modest também tem arestas afiadas, incluindo o encerramento abrupto do interpretador em :dir().
O selectolax suporta XPath?
Não. Nenhum dos backends expõe um método xpath() — o selectolax é apenas CSS. Se seus scrapers dependem de XPath, migrar significa reescrever seletores, que é o maior custo de sair de uma stack baseada em lxml ou parsel.
Por que a saída do meu selectolax está corrompida ou com elementos faltando?
Os dois suspeitos mais comuns. Se o texto volta com caracteres de substituição ou acentos sumindo, você provavelmente passou bytes crus fora de UTF-8 — decodifique para str primeiro (resp.content.decode("latin-1")) antes de fazer o parse. Se links ou elementos estão faltando em um site moderno, eles podem estar dentro de tags <template> que o backend Lexbor não percorre; nesse caso, troque para Modest ou use outro parser para aquela página.
