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
| Parte | Tamanho sem compressão | Tamanho com gzip | Como carrega |
|---|---|---|---|
| Bootstrapper | 4,3 KB | ~1,9 KB | Inline no HTML, síncrono. |
SDK shield.js | 60 KB | ~19,6 KB | Arquivo 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 comasync, 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ção | Quando | Observação |
|---|---|---|
GET cdn.proteside.com/v1/shield.js | 1 vez | Em geral vem do cache. |
GET app.proteside.com/api/sdk/config | 1 vez | Pode vir do cache por 60 segundos. |
GET da própria página | 1 vez, e a cada pageChanged() | Lê os headers de segurança. Veja o aviso em CSP e headers. |
GET dos scripts externos da página | até 20, com limite total de 1,5 s | Para calcular o hash do conteúdo. Usa o cache do navegador sempre que possível. |
POST app.proteside.com/api/sdk/events | a cada 5 s, aproximadamente, enquanto houver eventos | Lotes 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.
Navegadores suportados
| Navegador | Versão mínima |
|---|---|
| Chrome | 80 |
| Edge | 80 |
| Firefox | 78 |
| Safari | 14 |
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.