Detalhes técnicos

Esta página é para quem quer os detalhes. Tudo aqui foi medido ou verificado no código-fonte; nada foi estimado.

Como o widget carrega

Em duas etapas. Primeiro, um pequeno carregador desenha o botão e não faz mais nada. O chat em si só é buscado quando um de cinco gatilhos é acionado: o navegador fica ocioso (no máximo após três segundos), um mouse ou dedo toca o botão, um comando vem da página, há um sinal de frustração do MousePlayer ou um aviso push, por exemplo, do seu service worker.

Há um motivo: a maioria dos visitantes nunca abre o chat. Para eles, o chat não deve atrasar o carregamento da página; os gatilhos aplicáveis são definidos na tag script.

• Carregador: 3,48 kB, conforme transferido pela nossa CDN com gzip
• Widget inteiro: 85,5 kB, transferido da mesma forma e somente após um dos gatilhos ser acionado
• Até o botão aparecer: 11–21 ms
• Deslocamento de layout: 0,0000 – o espaço é reservado antes de qualquer coisa aparecer

Para comparar, também medidos e todos os três compactados com brotli: o carregador do Crisp tem 2.876 B, o do Intercom tem 3.161 B. Com 3.069 B, estamos entre eles, não ordens de grandeza abaixo. Quem afirma o contrário não mediu.

Não interfere no seu site

O widget fica em um shadow DOM fechado. Seus estilos não o alcançam, e os estilos dele não alcançam sua página, nem mesmo se você definir * { box-sizing: border-box } ou usar um framework CSS que redefine tudo.

Ele funciona com uma Content Security Policy rigorosa sem uma única mensagem no console: sem eval, fonte da web ou pixel de rastreamento. Define seus estilos por folhas de estilo construíveis, que não são abrangidas por style-src. Por isso, o botão, a janela do chat, os tours do produto e o console de atendimento no seu site não precisam de unsafe-inline: medidos com style-src 'self' e até com style-src 'none', sem violações e com todos os estilos aplicados. Medido no Chromium atual; navegadores antigos sem folhas de estilo construíveis (como Safari anterior ao 16.4) recorrem a um elemento <style>, bloqueado por uma política rigorosa.

Nenhuma requisição a outros servidores. Tudo vem do reactive.chat ou, com domínio próprio, do seu próprio endereço; imagens como logo e avatares vêm dos endereços que você mesmo informa.

O protocolo

A conexão usa WebSocket; quando uma rede não permite WebSocket, usa requisições HTTPS comuns (Server-Sent Events ou long polling). O protocolo tem versão e define 31 códigos de erro, 26 deles para o widget e os demais para o painel de atendimento e a pesquisa no site, cada um com uma reação prescrita para o cliente (tentar imediatamente, tentar após uma espera, tentar após reconectar, não tentar novamente), alguns também com código de fechamento. Um erro fora da lista é tratado como erro temporário do servidor: nova tentativa após uma espera e, depois de cinco tentativas, a mensagem é considerada não entregue e pode ser enviada novamente, sem loop infinito.

Reconexão com espera crescente. Se a conexão cair, as mensagens entram em um buffer e são enviadas assim que ela voltar. Cada mensagem tem um ID; o servidor reconhece repetições e não as armazena duas vezes.

Acessibilidade

Desenvolvido com base na WCAG 2.2 AA:

• Foco mantido dentro da janela aberta, ESC fecha, o foco volta ao lugar anterior
• Novas mensagens anunciadas por aria-live
• Contraste entre texto e superfície calculado, não presumido – veja abaixo
• Operação completa pelo teclado, contorno de foco visível

O contraste é calculado

Você informa uma cor. A superfície recebe exatamente essa cor. O texto sobre ela é ajustado até atingir uma relação de 4,5:1, exigência da WCAG para texto normal.

Medido em 178 cores, dois temas e três combinações, totalizando 1.068 pontos de dados: nenhum abaixo de 4,5:1, com pior valor de 4,50:1.

Essa é a diferença em relação a outros provedores: neles, é possível configurar um widget até ninguém conseguir lê-lo.

Dados pessoais

Os dados sensíveis são ocultos em dois lugares: no navegador do visitante, antes que qualquer coisa saia da máquina, e novamente no servidor, antes de qualquer armazenamento. São reconhecidos números de cartão (com verificação de Luhn), IBANs, endereços de e-mail, números de telefone, números fiscais e de documentos de identidade. Números de pedidos e de clientes não são alterados.

Dois lugares porque um só não basta: a proteção no navegador pode ser desativada, e a do servidor só vê o que chega.

Regras

O momento em que o widget aborda o visitante é definido em uma lista declarativa de regras, não em uma condição no código. São fornecidas seis regras por padrão (permanência na página, cliques de raiva, erro de JavaScript, formulário travado, intenção de compra, saída do checkout); cliques de raiva, formulário travado e intenção de compra só são detectados junto com o MousePlayer. Você pode adicionar suas próprias regras na conta. No plano Free, um aviso ativo por projeto entra em ação.

A diferença é prática: alterar uma regra significa alterar uma configuração na conta, não fazer uma implantação.

Integrações

Webhooks e Slack estão concluídos. Há uma conexão pronta para mais de 30 outros serviços; a maioria foi testada com contrapartes simuladas, mas nunca executada com o serviço real, e a página de integrações na conta os identifica assim.

A API do servidor (REST e MCP) lê conversas, mensagens, projetos, visitantes, eventos e regras, escreve mensagens e eventos e cadastra webhooks. A lista de visitantes e o MCP podem ser desativados por projeto.

Toda integração passa por uma fila com mecanismo de interrupção: se um serviço de terceiros travar, ele é ignorado por um tempo após falhas repetidas. Uma mensagem de chat nunca fica esperando por isso; essa é a regra mais importante dessa camada.

O que não está concluído

Para que ninguém descubra durante a integração:

• A ponte com o MousePlayer faz consultas periódicas porque o MousePlayer ainda não emite sozinho os eventos combinados.
• Anexos, testes A/B e domínio próprio funcionam como beta: funcionam e foram medidos, mas ainda podem mudar.
• Os canais de e-mail, Telegram, SMS, WhatsApp, Messenger e Instagram foram testados com contrapartes simuladas, ainda não com contas reais. Se uma resposta por um canal falhar definitivamente, a conversa ainda não mostra isso.

Mais na documentação

Como widget, servidor e conexão funcionam juntos: Arquitetura e fluxo. Conexão, fallback HTTP e reconexão: Transporte. Todos os capítulos: documentação.