Scripts de terceiros se tornaram silenciosamente uma das maiores fontes de ruído, distorção e falsos erros em testes de carga. Cada ferramenta de marketing, pixel de analytics, framework de otimização e widget adiciona outra dependência remota que sua aplicação não controla. Sob tráfego real, a maioria deles se comporta “bom o suficiente”. Sob carga sintética, eles se comportam como minas terrestres, frequentemente reportando suas falhas como falhas suas.
Este artigo reduz o problema ao que realmente acontece no navegador, por que o tráfego sintético exagera esses efeitos e como testar carga de forma inteligente — sem deixar o código de terceiros sequestrar seus resultados. Foi escrito para equipes que usam o LoadView, mas os princípios se aplicam em qualquer lugar onde você faça testes de desempenho baseados em navegador.
O peso oculto do código de terceiros
Páginas modernas não são apenas HTML e seu próprio JavaScript. Elas são um conjunto de:
- Motores de analytics
- Frameworks de teste A/B
- Rastreadores de reprodução de sessão
- Gerenciadores de tags
- Widgets de chat
- Bibliotecas hospedadas em CDN
- Banners de consentimento
- Beacons de publicidade
- Carregadores de feature-flag
Cada um desses scripts roda em sua própria linha do tempo, faz suas próprias chamadas de rede e pode travar a página de maneiras que sua equipe de backend nunca vê.
Em um teste de carga, você não está apenas testando seu sistema — você está testando a disponibilidade global de 15–30 serviços que você não possui e não pode controlar. Alguns são rápidos. Alguns são lentos. Alguns enlouquecem quando você gera milhares de “visitas” quase idênticas por minuto.
É por isso que as equipes costumam ver este padrão:
- Métricas do servidor de aplicação: estáveis
- Latência do banco de dados: inalterada
- Teste sintético de carga: “página lenta”, “waterfall bloqueado”, “execução de JS travada”
- Quando essas coisas não se correlacionam, o código de terceiros quase sempre é o culpado.
O que realmente acontece quando scripts de terceiros são executados durante um teste de carga
Para entender por que os resultados dos testes ficam poluídos, olhe para o que o navegador precisa fazer:
- Fazer o parse do seu HTML.
- Carregar seu CSS e JS.
- Detectar scripts externos e emitir DNS → TCP → TLS → GET.
- Aguardar a resposta do provedor remoto.
- Executar o código que chega.
- Esse código frequentemente carrega mais scripts.
- Esses scripts frequentemente fazem mais requisições.
Nada disso é hipotético. Abra a waterfall nas devtools e você verá: gerenciadores de tags gerando uma dúzia de scripts adicionais, trackers buscando configuração, ferramentas de replay carregando ativos de gravação, analytics chamando endpoints de batching.
Sob carga, essas cadeias externas não ficam mais rápidas. Elas ficam mais lentas. Às vezes muito mais lentas.
Mais importante: o navegador não sabe nem se importa que isto é um teste de carga. Ele executa tudo exatamente como faria para um usuário real. Se o provedor de terceiro trava, o navegador trava.
Como scripts de terceiros inflacionam e induzem a erro nos resultados
Testes sintéticos em navegador medem o que os usuários sentem: LCP, DOMContentLoaded, evento de load, TTI e outros marcos em tempo de execução. Scripts de terceiros distorcem todos eles de maneiras como:
Scripts bloqueantes travam o parsing
Se uma tag de script não for async ou defer, o navegador interrompe o parsing do HTML até que o provedor remoto responda. Se esse provedor for lento — ou limitar sua taxa de tráfego — seus tempos de teste explodem.
Latência de cauda longa altera percentis
O desempenho de terceiros é inerentemente errático. Algumas requisições levam 50 ms. Outras levam 800 ms. Quando você executa um teste de carga completo, esses outliers se acumulam nos seus percentis 95 e 99, fazendo sua aplicação parecer instável quando não está.
Código assíncrono ainda consome CPU e tempo do event loop
Mesmo carregando assincronamente, analytics pesados ou scripts de replay impõem pressão no tempo de execução do JS. Sob carga, isso se amplifica.
Expansão do waterfall oculta o gargalo real
Quando cada script de terceiro desencadeia mais cinco requisições, identificar o que é seu vs. o que é externo fica doloroso. Muitas equipes perdem horas perseguindo um “problema de latência no backend” que na verdade é um gerenciador de tags travado.
A conclusão: seu sistema pode estar saudável, mas seu teste de carga não parecerá saudável.
Variabilidade de CDN e latência em cascata sob carga sintética
Scripts de terceiros não rodam na sua infraestrutura; eles rodam em CDNs espalhados pelo mundo. Esses CDNs roteiam tráfego com base em geografia, congestionamento, acordos de peering, manutenção em andamento e qualquer lógica dinâmica de balanceamento que estejam usando no momento. Sob carga sintética, onde você dispara requisições de múltiplas regiões simultaneamente, essa variabilidade é amplificada.
Cem navegadores atingindo o mesmo script externo ao mesmo tempo podem ser roteados para POPs totalmente diferentes. Uma região pode cair em um nó de borda quente e responsivo e retornar o arquivo instantaneamente. Outra pode acertar um POP congestionado ou “frio” e travar por algumas centenas de milissegundos. Uma terceira região pode degradar temporariamente ou rerotar, adicionando ainda mais imprevisibilidade. Nada disso reflete a saúde da sua aplicação, mas tudo aparece nos resultados do teste como se refletisse.
A consequência é previsível: uma zona de carga que aparece lenta no seu relatório na verdade não está lutando com seus servidores — está lidando com um pixel de marketing, uma tag de analytics ou um script de replay hospedado em um CDN cujo POP mais próximo está tendo um horário medíocre. Enquanto isso, suas métricas de infraestrutura contam uma história diferente: CPU estável, memória estável, latência do banco de dados inalterada. Tudo do seu lado parece limpo.
Mas seu waterfall está estourado com barras longas externas, execução de script atrasada e marcos de tempo inflacionados. Esse descompasso é a assinatura indicativa de código de terceiros sob pressão sintética.
Provedores de terceiros detestam testes de carga (problemas de rate-limiting)
Um dos padrões de falha mais enganosos em testes de carga baseados em navegador vem de serviços de terceiros que se protegem, não de falhas. Plataformas de analytics, gerenciadores de tags, ferramentas de replay e pixels de marketing são construídos para lidar com tráfego de usuários normal e orgânico — espalhado, irregular e diverso. O que eles não foram feitos para lidar é com milhares de sessões sintéticas quase idênticas atingindo os mesmos endpoints em um surto uniforme e apertado. Para seus sistemas de detecção, isso não é “teste”. É um ataque.
Veja o que acontece:
- O teste de carga começa.
- Todos os navegadores acessam sua página.
- O alvo de terceiro vê um fluxo repetitivo nada natural.
- O provedor decide que isso parece scraping ou DDoS.
- As requisições ficam mais lentas ou retornam erros.
- O navegador fica parado aguardando respostas.
- Suas métricas de teste despencam.
O resultado parece que sua aplicação desmoronou, quando na realidade nada na sua infraestrutura mudou. CPU fica estável, memória se mantém, latência do banco não oscila. A lentidão não é sua — é um serviço de terceiro limitando a taxa por achar que o tráfego é abusivo. A menos que você inspecione arquivos HAR ou trace cuidadosamente waterfalls externos, é fácil diagnosticar mal isso como um problema interno. A correção não é afinar seus servidores — é reconhecer que uma dependência externa está se protegendo contra seu tráfego de teste.
Por que usuários reais não veem as mesmas lentidões (ad blockers e consentimento)
Uma das maiores lacunas entre resultados sintéticos e desempenho do mundo real vem do simples fato de que usuários reais não carregam tudo o que seu ambiente de teste carrega. Uma parte significativa do seu público usa bloqueadores de anúncios ou extensões de privacidade que impedem a execução de analytics, pixels de rastreamento e scripts de marketing. Mesmo sem extensões, muitos sites exigem consentimento do usuário antes de carregar esses scripts, o que os atrasa ou suprime completamente.
Usuários sintéticos, por outro lado, carregam todas as dependências porque se comportam como navegadores limpos, sem bloqueios, sem extensões e sem gating de consentimento. Isso significa que todo script de terceiro — tags de rastreamento, ferramentas de replay, frameworks de otimização e mais — é executado em cada sessão sintética, embora uma grande parcela dos usuários reais nunca os dispare.
O resultado é um descompasso previsível: a produção parece estável, enquanto o teste de carga mostra tempos inflacionados e waterfalls pesados. O teste não está errado — ele mede um cenário em que o peso total dos scripts de terceiros é aplicado uniformemente. Mas também não reflete a distribuição real do comportamento dos usuários, razão pela qual essas discrepâncias aparecem com frequência.
Quando incluir scripts de terceiros nos testes de carga — e quando bloqueá-los
Não existe uma única abordagem certa. Depende do que você está medindo.
Inclua scripts de terceiros se você se importa com:
- Experiência real do usuário
- Tempos de UX (LCP, FID, TTI)
- Renderização da página sob pico de tráfego
- Como seu site se comporta quando tudo — incluindo “enfeites” de marketing — está ativo
Exclua ou bloqueie-os se você se importa com:
- Escalabilidade do backend
- Performance de APIs
- Throughput do banco de dados
- Gargalos de infraestrutura
- Ajuste de rede e balanceador de carga
- SLAs de taxa de transferência e taxa de erros
A abordagem inteligente — o que a maioria das equipes maduras faz — é executar ambos:
- Execuções limpas (bloquear ou simular dependências externas).
- Execuções completas (deixar o navegador carregar tudo).
A diferença entre os dois diz exatamente quanto peso os provedores de terceiros estão colocando na sua experiência real.
O LoadView facilita isso: use os recursos de blocklist/allowlist para executar ambos os cenários sem reescrever scripts.
Scripts de terceiros não são apenas front-end
Um equívoco frequente em testes de carga é presumir que scripts de terceiros interagem apenas com provedores externos e, portanto, não impactam sua infraestrutura. Na prática, isso raramente é verdade. Muitos scripts buscam dados, enviam eventos ou requisitam configuração diretamente do seu backend, gerando tráfego adicional que as equipes frequentemente negligenciam.
Exemplos incluem:
- Frameworks de teste A/B consultando sua API por configuração de experimentos.
- Scripts de personalização requisitando atributos de usuário logado.
- Scripts de atribuição postando transições de página ou marcadores de sessão.
- Widgets de chat chamando endpoints de disponibilidade ou lista.
- Ferramentas de analytics agrupando eventos de volta para seu domínio para evitar bloqueio cross-site.
O resultado é um efeito de amplificação silenciosa: um único script de terceiro pode gerar várias chamadas backend adicionais por carregamento de página. Sob carga, isso se multiplica dramaticamente — o que parecia um teste “apenas frontend” de repente produz tráfego backend significativo. Se suas métricas de infraestrutura mostram picos inesperados de API ou atividade elevada no banco durante um cenário centrado na UI, esse padrão de interação frequentemente é a razão.
Reconhecer esses pontos ocultos de contato com o backend é essencial para interpretar corretamente os resultados do teste de carga. Sem contabilizá-los, é fácil culpar a parte errada do sistema ou subestimar a demanda real que sua aplicação enfrenta no comportamento de navegador real.
Testes mais inteligentes: stubs, mocks, overrides e comportamento externo controlado
Quando o objetivo é executar testes de carga limpos e confiáveis, o objetivo não é fabricar uma realidade diferente — é isolar o sistema específico que você está tentando medir. Dependências de terceiros introduzem ruído, imprevisibilidade e comportamentos de rate-limiting que não têm nada a ver com sua infraestrutura. Controlar essas variáveis permite medir sua própria performance sem herdar a instabilidade de serviços externos.
Uma opção é usar overrides de DNS, roteando domínios conhecidos de terceiros para um endpoint mock local que responde instantaneamente. Isso permite que o navegador complete a sequência de requisições esperada sem esperar por CDNs remotos ou provedores de analytics. Bloquear scripts alcança o mesmo resultado com menos configuração: no LoadView, você pode simplesmente bloquear domínios como googletagmanager.com, hotjar.com ou optimizely.com para que o navegador não perca tempo executando ou recuperando-os durante o teste.
Endpoints mock oferecem outra camada de controle retornando payloads mínimos e previsíveis. Isso mantém a execução do script consistente entre execuções e remove a latência de cauda longa que, de outra forma, poluiria as métricas de tempo. Em alguns casos, equipes optam por hospedar cópias locais de bibliotecas externas para controlar tanto a disponibilidade quanto o tempo, sem alterar a lógica da aplicação.
Todos esses métodos preservam o comportamento realista do navegador enquanto eliminam os atrasos e falhas aleatórias que provedores de terceiros introduzem sob carga. O resultado é um teste que reflete a performance da sua aplicação — não a saúde ou o nível de congestionamento do CDN de outra pessoa.
Como o LoadView lida com o ruído de scripts de terceiros em testes de carga
O teste de carga baseado em navegador do LoadView dá a visibilidade necessária para separar “seu código está lento” de “o serviço de outra pessoa engasgou”.
Principais vantagens:
- Visibilidade ao nível da waterfall: Veja exatamente quais requisições de terceiros bloquearam a página.
- Bloquear/Permitir domínios externos: Execute testes limpos vs. completos sem manter múltiplas versões de script.
- Execução ao nível do navegador: Meça exatamente o que os usuários experimentam — inclusive se scripts de marketing estão degradando a performance.
- Load Zones: Identifique lentidões externas específicas por geolocalização que, de outra forma, seriam atribuídas aos seus servidores.
- Controle de scripting (Selenium): Injete condições para evitar chamadas externas ou substituí-las por mocks previsíveis.
Isto é o que testes de carga modernos exigem: controle refinado sobre o ruído.
Lendo os resultados: não persiga fantasmas de terceiros
Quando um teste dá errado, aqui está um padrão rápido de triagem que impede as equipes de perseguirem a causa raiz errada.
Se as métricas do servidor estão estáveis, mas os resultados do navegador parecem horríveis:
Quase sempre são scripts de terceiros ou sobrecarga de execução do lado do cliente.
Se os percentis 95/99 incham enquanto as médias permanecem limpas:
Esse é o comportamento clássico de cauda longa de terceiros.
Se apenas uma zona geográfica de carga está lenta:
Você atingiu um POP de CDN externo que está tendo um dia ruim.
Se as falhas mostram erros de DNS ou TLS para domínios externos:
Você está sendo rate-limited ou bloqueado.
Se o tráfego do backend está maior do que o esperado durante um teste “frontend”:
Algum script “apenas cliente” está secretamente chamando suas APIs.
Interpretar resultados corretamente não é apenas uma habilidade — é um requisito para testes válidos.
Conclusão
Scripts de terceiros não vão desaparecer. Cada equipe de marketing, fornecedor de analytics e produto de personalização adiciona outra dependência à página. Assim funciona a web moderna.
Mas testes de carga não devem deixar o servidor lento de outra pessoa convencê-lo de que sua infraestrutura está falhando.
Testes realistas significam:
- Saber quando incluir código de terceiros
- Saber quando bloqueá-lo
- Saber como interpretar a diferença
- Executar cenários limpos e completos
- Não deixar o ruído de CDNs ou provedores de analytics com rate-limiting distorcer seus SLAs
O LoadView dá às equipes a visibilidade e o controle para fazer exatamente isso — testar o sistema que você realmente executa, não o amontoado de scripts externos colados a ele.