Nenhuma página de vendas mostra o uptime real de um provedor CAPTCHA dentro do seu pipeline. A resposta confiável vem de uma medição própria: mesma página de staging, mesmo tipo de desafio CAPTCHA, janela de tempo comparável entre os provedores testados. Este guia mostra como montar essa comparação sem transformar números de terceiros em regra para o seu ambiente.
Este conteúdo vale só para ambiente próprio, QA, staging ou pré-produção com autorização explícita. Os exemplos usam páginas internas, dados fictícios e endpoints de validação controlados pela sua equipe — nada aqui automatiza serviços de terceiros, compras reais, filas públicas ou controles de acesso fora do seu ambiente.
Por que uma tabela pública não decide qual provedor CAPTCHA usar
Tempo de resolução muda conforme o tipo de desafio, a região do runner, a carga simultânea, a integração com o backend e até o horário do teste. Uma tabela publicada por terceiros, sem contexto de amostra, carga e período, não deve virar critério isolado para o seu caso. Use medições internas para decidir capacidade de threads, alertas e orçamento — os números públicos servem só como referência de contexto.
Como montar sua própria comparação de disponibilidade
Separe os testes por tipo de CAPTCHA — reCAPTCHA v2, Cloudflare Turnstile e GeeTest v3 não têm o mesmo comportamento de fila nem a mesma latência de verificação. Use a mesma página de staging para todos os provedores comparados, registre hora de envio, hora de conclusão, código de erro e resultado do backend em cada tentativa. Com uma amostra interna suficiente, calcule mediana, P90 e P99 para reduzir o efeito de outliers isolados.
Dados para registrar em cada execução
Documente a sitekey de QA usada, a região do runner (por exemplo, sa-east-1 para simular tráfego de usuários no Brasil), a versão do cliente HTTP e o endpoint interno de validação do token. Sem esse contexto, uma diferença de mediana entre dois provedores pode refletir uma mudança de rede, não uma diferença real de disponibilidade.
Modelo de tabela para registrar os resultados
Preencha a tabela abaixo com os números coletados no seu ambiente — os valores de exemplo indicam apenas onde cada dado entra, não uma previsão.
| Provedor | Tipo de CAPTCHA | Amostras | Mediana | P90 | P99 | Observações |
|---|---|---|---|---|---|---|
| CaptchaAI | reCAPTCHA v2 | 100 | preencher | preencher | preencher | amostra interna |
| Provedor B | Turnstile | 100 | preencher | preencher | preencher | valor indicativo |
| Provedor C | GeeTest | 100 | preencher | preencher | preencher | pode variar por região |
Planejamento de capacidade com P90 e P99
Use o P90 e o P99 — não a mediana — para dimensionar filas, timeouts e retentativas: são eles que capturam o pior caso que sua aplicação realmente vai enfrentar. Se o volume variar bastante entre janelas de tráfego, rode amostras separadas por período e compare apenas cenários equivalentes entre si.
Testando disponibilidade sob picos de tráfego
Um ponto que a documentação genérica costuma pular: o comportamento em pico é o que mais importa para o planejamento de capacidade. No Brasil, datas como a Black Friday concentram um volume de checkout e verificação muito acima da média — é exatamente a janela em que filas crescem e a variância de tempo de resolução aparece com mais clareza. Rode uma amostra dedicada nesses períodos, com o mesmo runner e a mesma página de staging usados no restante da comparação, e trate o resultado como um cenário à parte, nunca como uma extrapolação do dia normal. Ao registrar logs de teste com dados de usuários fictícios, considere também as obrigações da LGPD sobre retenção e descarte desses registros.
Script para coletar métricas em staging
O script abaixo é um ponto de partida para medir tempos de resolução no seu ambiente. Ele não compara provedores por uma conclusão fechada — apenas coleta dados brutos que você usa na sua própria análise.
import os, time, requests
API_KEY = os.environ['CAPTCHAAI_API_KEY']
SITEKEY = os.environ['QA_CAPTCHA_SITEKEY']
def criar_tarefa_captcha(pageurl):
resposta = requests.post('https://ocr.captchaai.com/in.php', data={
'key': API_KEY,
'method': 'userrecaptcha',
'googlekey': SITEKEY,
'pageurl': pageurl,
'json': 1,
}).json()
return resposta['request']
def aguardar_resultado(task_id):
while True:
time.sleep(5)
resposta = requests.get('https://ocr.captchaai.com/res.php', params={
'key': API_KEY,
'action': 'get',
'id': task_id,
'json': 1,
}).json()
if resposta.get('status') == 1:
return resposta['request']
task_id = criar_tarefa_captcha('https://staging.example.com/captcha-demo')
token_qa = aguardar_resultado(task_id)
print({'token_recebido': bool(token_qa)})
Por que a variância aumenta entre execuções
Se a variância dos seus números crescer de uma rodada para outra, confirme três coisas antes de suspeitar do provedor: se a página de staging está estável, se o endpoint interno responde de forma consistente sob carga e se os tipos de CAPTCHA não ficaram misturados no mesmo conjunto de amostras. Cada uma dessas três causas explica a maior parte da variância observada em comparações internas mal controladas.
Perguntas frequentes
Preciso medir a disponibilidade separadamente por tipo de CAPTCHA?
Sim. reCAPTCHA v2, Turnstile e GeeTest v3 passam por caminhos de verificação diferentes, com filas e latências próprias. Misturar tipos na mesma amostra mascara variações que só aparecem quando você segmenta por tipo.
Quantas amostras são necessárias para um P99 confiável?
Não existe um número fixo, mas amostras muito pequenas (abaixo de algumas dezenas de execuções) tornam o P99 instável — um único outlier desloca o valor inteiro. Rode a coleta por um período maior em vez de tentar acelerar com poucas amostras.
Posso usar números públicos de outros provedores como referência direta?
Use-os só como contexto inicial, nunca como previsão para o seu ambiente. Região, integração e horário do teste mudam demais entre configurações para que um número publicado por terceiros substitua a sua própria medição.
Faz sentido repetir a medição durante picos como a Black Friday?
Sim, principalmente se sua aplicação lida com tráfego sazonal. O comportamento sob carga alta costuma divergir bastante do dia normal, e é justamente esse cenário que revela limites reais de capacidade.
É seguro publicar os resultados da minha comparação?
Sim, desde que você publique metodologia, tamanho de amostra, período de coleta e limitações junto dos números — nunca os números isolados, sem esse contexto.
Guias relacionados
- Início rápido da CaptchaAI
- Testes QA autorizados de CAPTCHA
- Testes de endpoint CAPTCHA em formulários próprios
- Depuração quando o navegador falha e a API funciona
- Resolver reCAPTCHA v2 com API
- Resolver Cloudflare Turnstile com API
- Resolver GeeTest v3 com API
Antes de publicar sua comparação
Confirme que a documentação aponta para ambiente próprio, que os exemplos usam dados fictícios e que nenhum endpoint de produção é acionado pelo teste — e que os logs guardam correlação suficiente para auditoria. A página de staging precisa ter domínio autorizado, sitekey esperada, configuração de backend separada e uma política clara de expiração. Quando o resultado variar entre rodadas, trate os números como amostra interna: repita a medição, anote a janela de execução e compare apenas cenários equivalentes entre si.
Monte a sua própria comparação de disponibilidade com a CaptchaAI no seu ambiente de staging.
