Proteside Docs

Desempenho e compatibilidade

Tamanho do SDK, forma de carregamento, requisições extras, impacto no checkout e navegadores suportados.

O SDK foi feito para não atrasar o checkout: a parte síncrona é pequena e não faz rede, e o restante carrega de forma assíncrona. Esta página mostra os números reais e o que o SDK faz em cada carregamento.

Tamanho

ParteTamanho sem compressãoTamanho com gzipComo carrega
Bootstrapper4,3 KB~1,9 KBInline no HTML, síncrono.
SDK shield.js60 KB~19,6 KBArquivo da CDN, com async. A CDN entrega com Brotli (~17 KB).

O bootstrapper aumenta o HTML de cada página em cerca de 4,3 KB antes da compressão do seu servidor. O shield.js fica em cache no navegador e na CDN (1 hora no canal stable, 5 minutos no latest).

Carregamento

  • Bootstrapper: executa em menos de 1 ms e não faz nenhuma requisição. Ele só instala os pontos de observação.
  • shield.js: carregado com async, não bloqueia o parser nem a renderização da página.
  • Inicialização: o SDK espera a configuração remota por no máximo 2 segundos antes de iniciar as detecções. O checkout não espera o SDK.

O SDK foi construído para nunca quebrar a página: todo o código roda protegido contra erros, e os envios de telemetria não bloqueiam nada.

Requisições por carregamento de página

RequisiçãoQuandoObservação
GET cdn.proteside.com/v1/shield.js1 vezEm geral vem do cache.
GET app.proteside.com/api/sdk/config1 vezPode vir do cache por 60 segundos.
GET da própria página1 vez, e a cada pageChanged()Lê os headers de segurança. Veja o aviso em CSP e headers.
GET dos scripts externos da páginaaté 20, com limite total de 1,5 sPara calcular o hash do conteúdo. Usa o cache do navegador sempre que possível.
POST app.proteside.com/api/sdk/eventsa cada 5 s, aproximadamente, enquanto houver eventosLotes de até 50 eventos; um último envio quando o cliente sai da página.

Processamento contínuo

Enquanto a página está aberta, o SDK:

  • verifica sobreposições sobre os campos de pagamento a cada 2 segundos (ajustável em Verificação de overlay (ms), mínimo de 500 ms);
  • confere os códigos de pagamento exibidos no mesmo intervalo;
  • procura códigos de pagamento no texto da página a cada 2 segundos durante o primeiro minuto;
  • observa mudanças na página para detectar scripts e códigos de pagamento novos.

Em páginas com muitos elementos, um intervalo de overlay maior reduz o trabalho periódico. Mantenha o padrão se não tiver um motivo para mudar.

NavegadorVersão mínima
Chrome80
Edge80
Firefox78
Safari14

Use HTTPS no checkout

O cálculo de hashes depende de uma API do navegador que só existe em páginas HTTPS. Em HTTP, o SDK continua funcionando, mas sem hash do conteúdo dos scripts, sem verificação de recebedores confiáveis e sem leitura dos headers de segurança.

Próximos passos

Nesta página