Os 6 melhores clientes HTTP em Python para web scraping

Comece pelo modelo de execução da sua aplicação. O Requests adapta-se a um script sequencial. O HTTPX oferece-lhe conceitos semelhantes de pedido e resposta tanto em código síncrono como assíncrono. O aiohttp adapta-se a um sistema que já coordena o trabalho de rede com o asyncio.

Só opte por um cliente especializado quando conseguir identificar a funcionalidade de que necessita. Mais opções de protocolo ou definições de transporte semelhantes às de um navegador introduzem outra dependência a compreender; não são um substituto para avaliar a falha que está a tentar resolver.

Utilize esta comparação de clientes HTTP em Python como uma lista de pré-seleção, e não como um ranking de desempenho. Por exemplo, um rastreador que solicita uma página de cada vez não beneficia da adição de uma biblioteca assíncrona, a menos que a sua programação também seja alterada. Por outro lado, um programa que já esteja à espera de muitas operações de rede independentes tem um motivo concreto para considerar um cliente HTTP assíncrono em Python.

Mantenha claros os limites da stack de scraping:

Esta separação torna as alterações futuras mais pequenas. Se a recuperação devolver o HTML correto, mas um seletor deixar de funcionar, corrija o analisador. Se os pedidos passarem a maior parte do tempo à espera de ligações, verifique o cliente e o agendador. Se a resposta não tiver conteúdo que só aparece após a interação com a página, verifique os requisitos de renderização.

O Requests é um bom ponto de partida quando o seu script realiza um número razoável de recuperações sequenciais e o alvo devolve diretamente HTML útil. O seu fluxo de pedidos simples facilita a análise de uma resposta com falha e a distinção entre um problema de rede e um problema de análise.

Instale o cliente e o analisador no ambiente virtual do seu projeto:

python -m pip install requests beautifulsoup4

Utilize uma sessão para pedidos repetidos. A documentação sobre sessões do Requests explica que as sessões preservam os cookies e utilizam o agrupamento de ligações, permitindo que as ligações sejam reutilizadas entre pedidos para o mesmo anfitrião.

Este exemplo apresenta um resultado estruturado para cada página, em vez de tratar cada pedido concluído como um rastreio bem-sucedido:

import requests
from bs4 import BeautifulSoup

URLS = (
    "https://books.toscrape.com/catalogue/page-1.html",
    "https://books.toscrape.com/catalogue/page-2.html",
)


def page_title(html):
    node = BeautifulSoup(html, "html.parser").find("title")
    if node is None or not node.get_text(strip=True):
        raise ValueError("Response has no usable page title")
    return node.get_text(strip=True)


def main():
    with requests.Session() as session:
        for url in URLS:
            try:
                with session.get(url, timeout=(5, 20)) as response:
                    response.raise_for_status()
                    title = page_title(response.content)
                print({"url": url, "title": title})
            except (requests.RequestException, ValueError) as exc:
                print({"url": url, "error": str(exc)})


if __name__ == "__main__":
    main()

A tupla define tempos de espera separados para a ligação e para a leitura. Não garante que toda a operação termine em 25 segundos. O Requests documenta tanto a ausência de um tempo de espera predefinido como a distinção entre a sua configuração de tempo de espera e um prazo para o download completo nas suas orientações sobre tempos de espera.

Passar os bytes da resposta para o analisador também mantém a descodificação como uma parte deliberada da extração. Um estado de resposta 200 é necessário para este exemplo, mas um coletor real deve validar mais do que apenas a presença de um título. Um ecrã de início de sessão, uma página de erro genérica ou uma página de desafio também podem apresentar um.

O Requests funciona bem quando a facilidade de manutenção é a principal restrição: um relatório periódico, uma integração com alguns pontos finais públicos ou uma base de código estabelecida com bons testes. Não é necessário substituí-lo simplesmente porque existe uma alternativa assíncrona. Primeiro, avalie se a espera na rede está realmente a impedir que a tarefa seja concluída a tempo.

Defina um contrato de retorno estável para a função de recuperação antes de adicionar mais funcionalidades. Por exemplo, registe o URL solicitado, o URL final, o estado e os campos analisados ou uma categoria de erro. Esse contrato torna as execuções parciais recuperáveis e evita que o código a jusante dependa do objeto de resposta de um cliente específico.

A sua limitação é a própria chamada bloqueante. Enquanto um pedido está em espera, essa thread não pode processar outro pedido. Um conjunto de threads limitado pode aumentar a concorrência, mas, nesse caso, a propriedade das threads, o estado de sessão partilhado e os limites da fila passam a fazer parte do seu design. Para uma nova aplicação asyncio, um cliente assíncrono nativo é normalmente a opção mais adequada.

Mantenha a recuperação e a extração separadas, tal como no exemplo. Isso permite-lhe testar seletores em relação a HTML guardado sem efetuar pedidos de rede, ou substituir posteriormente outro cliente sem reescrever o analisador. O nosso guia para criar um scraper com Beautiful Soup aborda a parte da extração com mais pormenor.

O HTTPX é uma escolha útil quando pretende um ponto de partida síncrono e um caminho assíncrono dentro da mesma biblioteca. Os seus objetos de resposta expõem conceitos familiares, tais como códigos de estado, texto, JSON e cabeçalhos, mas a migração continua a exigir a verificação do comportamento, em vez de se limitar a alterar uma importação.

Utilize o extra opcional HTTP/2 se esse protocolo fizer parte dos seus requisitos:

python -m pip install "httpx[http2]" beautifulsoup4

As aspas impedem que os shells interpretem os parênteses. Um cliente síncrono pode, assim, reutilizar ligações em chamadas repetidas:

import httpx

with httpx.Client(
    http2=True,
    follow_redirects=True,
    timeout=httpx.Timeout(20.0, connect=5.0),
) as client:
    response = client.get("https://books.toscrape.com/")
    response.raise_for_status()
    print(response.status_code, response.http_version)

Ativar o HTTP/2 permite a negociação; não obriga todos os servidores a utilizá-lo. Verifique a versão negociada da resposta em vez de a inferir a partir da sua configuração. O guia HTTP/2 do HTTPX descreve a dependência adicional, a configuração e o comportamento de fallback.

Para pedidos sobrepostos, utilize um cliente assíncrono reutilizável. O exemplo seguinte adiciona um semáforo para que apenas duas operações de obtenção entrem na secção de rede ao mesmo tempo:

import asyncio

import httpx
from bs4 import BeautifulSoup

URLS = tuple(
    f"https://books.toscrape.com/catalogue/page-{page}.html"
    for page in range(1, 4)
)


async def fetch_title(client, gate, url):
    async with gate:
        try:
            response = await client.get(url)
            response.raise_for_status()
            node = BeautifulSoup(response.content, "html.parser").find("title")
            if node is None or not node.get_text(strip=True):
                raise ValueError("Response has no usable page title")
            return {"url": url, "title": node.get_text(strip=True)}
        except (httpx.HTTPError, ValueError) as exc:
            return {"url": url, "error": str(exc)}


async def main():
    gate = asyncio.Semaphore(2)
    limits = httpx.Limits(max_connections=2, max_keepalive_connections=2)
    timeout = httpx.Timeout(20.0, connect=5.0, pool=5.0)
    async with httpx.AsyncClient(
        http2=True,
        follow_redirects=True,
        limits=limits,
        timeout=timeout,
    ) as client:
        results = await asyncio.gather(
            *(fetch_title(client, gate, url) for url in URLS)
        )
    for result in results:
        print(result)


if __name__ == "__main__":
    asyncio.run(main())

O semáforo limita as operações ao nível da aplicação, enquanto o conjunto de ligações limita os recursos de transporte. São controlos relacionados, mas não são intercambiáveis. Em particular, os fluxos HTTP/2 multiplexados fazem com que o número de pedidos em curso seja diferente do número de ligações abertas.

Este pequeno exemplo cria uma tarefa para cada URL. Para um rastreio de grande dimensão ou contínuo, alimente, em vez disso, uma fila limitada com um número fixo de trabalhadores. Caso contrário, pode acabar por alocar uma enorme coleção de tarefas em espera, mesmo que apenas algumas cheguem à rede. A documentação assíncrona do HTTPX também recomenda a reutilização de clientes, em vez de os criar repetidamente dentro de um loop ocupado.

Há dois detalhes de migração que vale a pena testar imediatamente. Em primeiro lugar, o HTTPX não segue redirecionamentos por predefinição, razão pela qual os exemplos os ativam explicitamente. Em segundo lugar, os seus tempos limite de ligação, leitura, escrita e do pool representam diferentes condições de falha. Um tempo limite do pool pode indicar que o trabalho local está à espera de uma ligação, em vez de que o servidor de destino está inacessível. Consulte o guia de compatibilidade e as definições de tempo limite antes de copiar pressupostos de outro cliente.

Mantenha um conjunto reduzido de fixtures de migração juntamente com o scraper: uma resposta normal, um redirecionamento, um estado de falha e uma resposta em que falta um campo obrigatório. Compare os registos finais em vez das representações dos objetos dos clientes. Quando um teste apresentar resultados diferentes, determine se o novo comportamento é intencional antes de alterar a análise a jusante. Isto também lhe proporciona uma verificação prática de reversão caso o destino comece a comportar-se de forma diferente após a implementação.

O HTTPX conquista um lugar entre os melhores clientes HTTP em Python para scraping da Web graças a essa combinação de interfaces e controlos. Escolha-o quando essas funcionalidades simplificarem o seu projeto e valide o comportamento real do destino antes de ativar novos protocolos em todo o lado.

O aiohttp é uma excelente opção quando a aplicação circundante já é assíncrona e necessita de controlo explícito sobre as ligações a cada alvo. A sua sessão de cliente gere ligações reutilizáveis e cookies, enquanto o seu conector permite definir limites totais e por host.

Instale o cliente e o analisador:

python -m pip install aiohttp beautifulsoup4

Eis a mesma tarefa de extração de títulos com uma sessão aiohttp. O conector permite, no máximo, duas ligações no total e, no máximo, duas ao site de treino. Um semáforo limita separadamente as operações de recuperação ativas:

import asyncio

import aiohttp
from bs4 import BeautifulSoup

URLS = tuple(
    f"https://books.toscrape.com/catalogue/page-{page}.html"
    for page in range(1, 4)
)


async def fetch_title(session, gate, url):
    async with gate:
        try:
            async with session.get(url) as response:
                response.raise_for_status()
                html = await response.read()
            node = BeautifulSoup(html, "html.parser").find("title")
            if node is None or not node.get_text(strip=True):
                raise ValueError("Response has no usable page title")
            return {"url": url, "title": node.get_text(strip=True)}
        except (aiohttp.ClientError, asyncio.TimeoutError, ValueError) as exc:
            return {"url": url, "error": str(exc)}


async def main():
    gate = asyncio.Semaphore(2)
    connector = aiohttp.TCPConnector(limit=2, limit_per_host=2)
    timeout = aiohttp.ClientTimeout(total=30, sock_connect=5, sock_read=20)
    async with aiohttp.ClientSession(
        connector=connector,
        timeout=timeout,
    ) as session:
        results = await asyncio.gather(
            *(fetch_title(session, gate, url) for url in URLS)
        )
    for result in results:
        print(result)


if __name__ == "__main__":
    asyncio.run(main())

O contexto da resposta encerra-se após o corpo da mesma ter sido consumido, e a sessão encerra-se quando a recolha termina. Esses limites do ciclo de vida fazem parte do exemplo, não são uma limpeza opcional. Deixar os fluxos de resposta abertos pode impedir que as ligações regressem ao conjunto.

A documentação do cliente avançado do aiohttp explica os limites do conector e o comportamento da sessão. Os limites por anfitrião são particularmente úteis quando um rastreio visita várias origens: uma origem rápida ou com uma fila muito longa não deve ser autorizada a consumir todos os recursos sem uma decisão deliberada de agendamento.

O objeto «timeout» também distingue um tempo limite total da solicitação das configurações de ligação e de leitura do socket. O guia de início rápido do cliente documenta estes campos. O tempo limite total aplica-se à operação da solicitação; o tempo gasto à espera fora dessa solicitação, como no semáforo da sua aplicação, ainda pertence ao orçamento mais amplo da tarefa.

Opte pelo aiohttp pela sua integração e controlos asyncio, em vez de partir do princípio de que «assíncrono» significa largura de banda ilimitada. Um site pode impor uma taxa de pedidos baixa, ou a análise do seu HTML pode tornar-se o gargalo. Nenhuma destas limitações desaparece quando mais pedidos se sobrepõem.

Para um rastilhador em produção, evite que a análise e o armazenamento monopolizem o ciclo de eventos. A análise das páginas pequenas neste exemplo é aceitável como padrão didático. Análises dispendiosas ou trabalho síncrono com bases de dados requerem uma estratégia de execução separada, para que as tarefas de rede possam continuar a avançar.

O aiohttp também oferece suporte a streaming e WebSocket, mas essas capacidades só são relevantes se os seus alvos ou infraestrutura as utilizarem. Se o HTTP/2 for um requisito, avalie um cliente que documente essa capacidade. Se o seu script for inteiramente síncrono, calcule o custo operacional de introduzir um ciclo de eventos antes de migrar.

Estes clientes merecem ser considerados quando a lista de opções padrão não oferece o controlo ou o comportamento de protocolo que a sua carga de trabalho exige. Cada um tem uma razão diferente para existir. Avalie essa razão diretamente, em vez de tratar as funcionalidades adicionais como uma atualização automática.

O urllib3 é útil quando está a construir uma abstração de obtenção de dados e pretende trabalhar mais de perto com os conjuntos de ligações. O Requests utiliza-o internamente, mas a utilização direta confere ao seu código uma interface diferente e maior responsabilidade pelo tratamento das respostas.

O guia do utilizador do urllib3 documenta o PoolManager, os corpos das respostas e a configuração dos pedidos. Este exemplo conciso verifica o estado explicitamente:

import urllib3

http = urllib3.PoolManager(
    timeout=urllib3.Timeout(connect=5.0, read=20.0),
)
try:
    response = http.request("GET", "https://books.toscrape.com/", retries=False)
    if response.status != 200:
        raise RuntimeError(f"Unexpected HTTP status: {response.status}")
    print(len(response.data))
finally:
    http.clear()

O acesso direto ao pool é valioso se precisar de padronizar o comportamento de transporte num sistema interno de maior dimensão. Para um scraper comum, no entanto, os clientes de nível superior podem permitir-lhe expressar a mesma tarefa com menos código de suporte. Não escolha o urllib3 apenas porque uma biblioteca que já utiliza depende dele.

O curl_cffi expõe uma interface semelhante à do Requests, suportada por um transporte baseado no curl. A sua característica distintiva documentada é a imitação das impressões digitais TLS e HTTP/2 dos navegadores suportados. Estas dizem respeito a detalhes da ligação e da troca de protocolos, para além do cabeçalho User-Agent.

A documentação do projeto descreve interfaces síncronas e assíncronas, e o guia de início rápido mostra a seleção de perfis. Esta é uma escolha especializada quando se tiver determinado que a compatibilidade de transporte é importante para o seu fluxo de trabalho de recolha de dados autorizado.

Um perfil de imitação não transforma o cliente num navegador. Não executa o JavaScript de uma página, não clica num diálogo de consentimento nem garante que um servidor aceite o pedido. Uma resposta rejeitada pode ter outra causa, incluindo o estado de autenticação ou uma quota de pedidos esgotada.

Verifique a disponibilidade do «wheel» nativo para a sua plataforma de implementação e teste o perfil selecionado com o seu conjunto de destinos. Evite depender de um perfil dinâmico não especificado se a reprodutibilidade for importante. Registe as escolhas do pacote e do perfil juntamente com a sua configuração de implementação, para que uma alteração de comportamento possa ser investigada.

O Niquests é outra opção para programadores que pretendem uma interface de pedidos de alto nível familiar, com capacidades HTTP mais recentes. A sua documentação oficial descreve o funcionamento síncrono e assíncrono, juntamente com o suporte a HTTP/1.1, HTTP/2 e HTTP/3.

O suporte a protocolos é uma capacidade, não uma garantia para cada ligação. O suporte do servidor, as condições da rede, os proxies e a negociação afetam o que é utilizado. Confirme o comportamento no ambiente onde o seu scraper será efetivamente executado, em vez de confiar numa solicitação bem-sucedida a partir do seu portátil.

Encare uma migração como uma dependência e uma alteração de comportamento, mesmo quando um projeto se descreve como um substituto de outra biblioteca. Utilize um ambiente isolado, inspecione o conjunto de dependências resolvidas e teste cookies, redirecionamentos, proxies, exceções e respostas transmitidas em fluxo antes de alterar uma tarefa existente.

Para as três opções especializadas, a questão prática é a mesma: que limitação observada é que isto resolve? Se não conseguir identificar nenhuma, mantenha o cliente mais simples e invista primeiro na validação, monitorização ou agendamento da extração.

O cliente define os controlos disponíveis; a sua aplicação decide como utilizá-los. Um scraper com uma reutilização sensata das ligações e um tratamento adequado de falhas é mais fácil de operar do que um que muda repetidamente de bibliotecas, mantendo o mesmo ciclo de pedidos ilimitado.

Distinga entre o estabelecimento da ligação, a espera por bytes de resposta, a espera por um espaço no pool e o tempo total que a sua tarefa pode demorar numa única URL. Trata-se de limites de tempo distintos. As tentativas de repetição e os atrasos na fila podem tornar a duração real muito mais longa do que um único argumento de tempo limite sugere.

Num fluxo de trabalho asyncio, um tempo limite da tarefa circundante pode impor um prazo mais alargado. Decida se esse prazo inclui o tempo de fila e o backoff, e registe em que fase ocorreu a expiração. Mantenha também os tempos limite ao nível do cliente, pois estes explicam a operação de rede específica que ficou bloqueada.

Uma política de repetição deve especificar as falhas elegíveis, os métodos elegíveis, um número máximo de tentativas e uma estratégia de atraso. Para um coletor GET de leitura apenas, determinadas falhas de ligação e estados de resposta transitórios podem justificar outra tentativa. Erros de autenticação repetidos ou falhas de análise que se mantêm inalteradas requerem, em vez disso, investigação.

As solicitações podem utilizar a política de repetição do urllib3 através de um HTTPAdapter. Este exemplo substitui a configuração de sessão simples quando a sua carga de trabalho necessita desse comportamento:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

retry = Retry(
    total=3,
    backoff_factor=0.5,
    status_forcelist=(429, 500, 502, 503, 504),
    allowed_methods=frozenset({"GET", "HEAD"}),
    respect_retry_after_header=True,
)

with requests.Session() as session:
    session.mount("https://", HTTPAdapter(max_retries=retry))
    with session.get("https://books.toscrape.com/", timeout=(5, 20)) as response:
        response.raise_for_status()
        print(response.status_code)

Aqui, «três» é o limite de tentativas após a tentativa inicial, não o número total de tentativas. A referência de Retry do urllib3 explica o filtro de métodos, a lista de estados, o backoff e o tratamento de Retry-After. Uma espera imposta pelo servidor pode prolongar a duração da tarefa, pelo que deve ter isso em conta na sua política geral de prazos.

Não presuma que a opção de repetição de outra aplicação tenha o mesmo significado. As repetições de transporte do HTTPX tratam de erros de ligação e tempos limite de ligação; não implementam uma política geral de repetição para respostas 429 ou 503. Mantenha as repetições da aplicação num único local para que as camadas aninhadas não multipliquem silenciosamente as tentativas.

Um limite de concorrência controla o trabalho simultâneo. Um limite de taxa controla a frequência com que o trabalho é iniciado ao longo do tempo. Duas solicitações rápidas a serem executadas simultaneamente ainda podem produzir uma taxa de solicitações elevada; por isso, os limites nos exemplos não constituem uma política de ritmo completa.

Utilize agendamento por origem e responda ao feedback do servidor. Limite tanto a fila como o trabalho ativo e persista os registos concluídos de forma incremental, em vez de reter todas as respostas até ao fim. Os downloads de grande dimensão necessitam de um caminho de streaming e de um limite explícito de bytes; o nosso guia de download de ficheiros em Python aborda esse fluxo de trabalho associado.

Acompanhe os URLs finais, os códigos de estado, os tipos de conteúdo e os campos extraídos necessários. Classifique as falhas separadamente para que uma alteração nos seletores não pareça uma interrupção no transporte. Preserve contexto suficientemente sanitizado para diagnosticar problemas sem registar credenciais ou conteúdo sensível das respostas.

Utilize sessões separadas para identidades autenticadas distintas. Mantenha a verificação do certificado TLS ativada e carregue as credenciais a partir do ambiente de implementação. Se os pedidos utilizarem proxies, teste explicitamente a sua configuração e o comportamento da ligação; este guia sobre proxies com o Python Requests fornece um ponto de partida específico.

Meça os registos válidos extraídos por unidade de tempo, juntamente com a taxa de falhas e a utilização de recursos. Um cliente que descarregue rapidamente uma página de erro não concluiu a tarefa empresarial. Os melhores clientes HTTP em Python para scraping na Web devem ser avaliados em função dos seus requisitos reais de resultados.

Crie um pequeno corpus representativo antes de comparar qualquer coisa. Inclua os tipos de respostas que o seu scraper encontra: uma página normal, um redirecionamento, uma resposta lenta, um corpo vazio, uma resposta de erro e uma página em que falte um campo esperado. Os cenários locais controlados tornam estes casos repetíveis sem impor um teste de carga ao site de outra pessoa.

Registe as versões do Python e das dependências em cada execução. Separe o comportamento da primeira solicitação do comportamento em estado estável, repita a experiência e analise a latência de cauda lenta, em vez de reportar apenas uma média. Mantenha a análise e o armazenamento consistentes para que esses custos não distorçam uma comparação entre clientes.

Utilize o resultado para justificar uma alteração, não para declarar um vencedor definitivo. Se todos os candidatos terminarem confortavelmente dentro do prazo da tarefa, a legibilidade e a familiaridade operacional podem decidir a escolha. Se um melhorar o débito mas introduzir modos de falha mais graves, documente essa compensação antes da migração. Execute as implementações antiga e nova com os mesmos cenários guardados e compare os registos extraídos antes de alterar o tráfego de produção.

Mudar de cliente só é útil quando o cliente é a camada limitante. Se a resposta HTML não contiver os dados, analise como a página os obtém. O site pode expor um endpoint JSON permitido, devolver dados estruturados incorporados ou preencher a interface através de JavaScript após o carregamento.

Um cliente HTTP pode recuperar um ponto de extremidade diretamente acessível sem renderizar a interface. Isso muitas vezes mantém o fluxo de trabalho mais simples. Mas um fluxo de trabalho que exija clicar em controlos, percorrer a página, aguardar o estado de uma página ou completar uma sequência de interações pode necessitar da execução no navegador.

A representação do transporte do navegador e a execução no navegador são capacidades diferentes. Da mesma forma, a multiplexação HTTP/2 não fornece um ambiente de execução de JavaScript. Identifique a capacidade em falta antes de introduzir outra ferramenta e mantenha o contrato de saída consistente, para que o seu analisador e a lógica de armazenamento possam permanecer estáveis.

Um serviço de navegador gerido é uma opção quando a execução da página e a interação são as tarefas que precisa de delegar. Um ponto final de scraping gerido é outra opção quando o fardo consiste no tratamento de acessos repetidos, no encaminhamento por proxy, nas tentativas de repetição ou na configuração da renderização. Nenhuma destas opções deve ser tratada como um motivo para remover a validação da resposta da sua aplicação.

Para um conjunto de alvos misto, mantenha uma política de escalonamento por alvo ou por falha observada, em vez de enviar tudo pelo caminho mais dispendioso. Comece com a resposta que pode recuperar diretamente, verifique os campos de que necessita e encaminhe apenas os fluxos de trabalho que requerem capacidades adicionais para outro fetcher. Registe a razão pela qual essa rota foi selecionada e avalie o seu sucesso utilizando as mesmas verificações de extração.

O seu cliente Python pode continuar a ser a interface para qualquer uma das abordagens. A decisão importante é determinar qual o componente responsável pela recuperação, renderização e comportamento de repetição de tentativas, para que duas camadas não repitam independentemente a mesma operação que falhou.

• Mantenha as Requests quando um scraper síncrono atingir o seu prazo e o seu comportamento for bem compreendido. Utilize uma sessão e tempos limite explícitos.
• Escolha o HTTPX para flexibilidade síncrona/assíncrona e HTTP/2 opcional, ou o aiohttp para um pipeline asyncio com controlos diretos de ligação por anfitrião.
• Adote um protocolo de transporte especializado apenas para um requisito verificado e teste a sua dependência e o comportamento do protocolo no seu ambiente de implementação.
• Controle separadamente as solicitações simultâneas, a taxa de solicitações, o tamanho da fila, as tentativas de repetição e o tamanho da resposta.
• Compare os registos extraídos válidos e a fiabilidade de ponta a ponta, e não apenas o tempo necessário para receber uma resposta HTTP.

Sim, mas uma chamada direta bloqueante impede que a thread do ciclo de eventos avance até que ela retorne. Utilize um cliente assíncrono nativo ou transfira a E/S de bloqueio para um caminho delimitado baseado em threads. A documentação do Python descreve o `asyncio.to_thread` para este fim. Defina também os tempos de espera de rede: cancelar o `await` não interrompe necessariamente uma operação de bloqueio já em execução na thread de trabalho.

Trate a descodificação como uma decisão separada do download. Guarde os bytes da resposta quando precisar de investigar problemas de codificação e verifique o conjunto de caracteres declarado juntamente com os metadados do documento. Se o texto descodificado contiver caracteres de substituição ou acentos distorcidos, corrija a suposição de codificação antes de executar seletores ou armazenar campos. Uma solicitação bem-sucedida não garante que o texto tenha sido descodificado corretamente.

Sim, utilize versões de dependências reprodutíveis para tarefas implementadas e atualize-as de forma deliberada. Registe a versão do Python e o conjunto de dependências resolvidas; em seguida, teste as atualizações em respostas representativas, redirecionamentos, erros e fixtures de extração. A reprodutibilidade facilita o diagnóstico de regressões; isso não deve significar congelar as dependências indefinidamente. Agende atualizações e analise as notas de lançamento dos projetos escolhidos como parte da manutenção de rotina.

Escolha o cliente HTTP mais pequeno que se adapte à tarefa que precisa de executar. O Requests é uma base de referência síncrona prática. O HTTPX oferece uma via intermédia entre código síncrono e assíncrono, com HTTP/2 opcional. O aiohttp adequa-se a um coletor baseado em asyncio que necessite de gestão explícita de ligações. O urllib3, o curl_cffi e o Niquests merecem ser avaliados quando as suas capacidades específicas respondem a um requisito que possa demonstrar.

Antes de migrar, defina o que significa «sucesso»: os campos obrigatórios foram extraídos, o registo foi armazenado, a tarefa cumpriu o prazo e os URLs com falha podem ser investigados ou repetidos com segurança. Em seguida, compare os candidatos sob limites equivalentes. Sessões reutilizadas, trabalho delimitado e diagnósticos úteis merecem frequentemente atenção antes da própria biblioteca.

Se a gestão da camada de acesso estiver a roubar tempo à extração, avalie a API Scraper da WebScrapingAPI num alvo representativo. Esta fornece encaminhamento de proxy gerido, novas tentativas e renderização opcional em JavaScript, enquanto o seu código Python continua responsável por verificar os dados devolvidos. Mantenha as mesmas regras de validação, quer faça a recuperação diretamente, quer utilize um ponto final gerido, para que uma alteração no transporte nunca altere silenciosamente o que é considerado uma extração bem-sucedida.