Resumo

  • O primeiro rascunho público de Beacon, publicado pelo W3C em outubro de 2013, citou XMLHttpRequest síncrono, carregamento de imagem e laços vazios como maneiras de atrasar a saída da página para mandar dados.
  • O rascunho de Recomendação Candidata de agosto de 2022 descreveu navigator.sendBeacon() como uma entrega de dados pequenos ao navegador, que programa o envio sem deter a navegação.

Pense no garçom correndo atrás de alguém que já passou pela porta do café. “Espere, preciso avisar ao escritório que você saiu.” A pessoa volta, assina uma ficha, espera o recado ser enviado e só então pode ir embora. Uma estatística de poucos bytes consegue produzir uma cena dessas quando o site confunde a própria prestação de contas com a liberdade de movimento do visitante.

O primeiro rascunho público do W3C, de 29 de outubro de 2013, descreveu o dilema. Códigos de análise e diagnóstico tinham dados a transmitir quando o documento era descarregado. Um pedido assíncrono lançado nesse instante podia ficar pelo caminho. Alguns desenvolvedores usavam XMLHttpRequest síncrono, uma imagem pendente ou até um laço sem função além de gastar segundos. O destino seguinte parecia lento por causa das obrigações da página anterior.

A proposta inicial passou a incumbência do envio ao agente do usuário. Em 2013, o método se chamava beacon e tinha outra forma. O navigator.sendBeacon() descrito mais tarde não deve ser enxertado no exemplo antigo. O que atravessou os anos foi uma ideia de responsabilidade: a página entrega o bilhete; o navegador organiza a viagem depois que o leitor atravessa a porta.

O bilhete final não era capricho. Uma sessão pode produzir um evento derradeiro ou um dado de diagnóstico disponível apenas no fim. Mandar cada nota imediatamente custa rede e bateria. Guardar tudo até o último segundo aumenta a chance de perder a mensagem. A velha solução empurrava essa tensão para o visitante, cobrando dela em tempo de espera. Beacon deu ao navegador uma fila para assumir o trabalho.

O rascunho de Recomendação Candidata do W3C de 3 de agosto de 2022 descreve navigator.sendBeacon(url, data) para um pequeno pedido de mão única. O envio é assíncrono e não bloqueia interações urgentes. O navegador pode ajustar prioridade, agrupar pedidos e aproveitar melhor a energia de aparelhos móveis. O próximo clique e a próxima página não precisam ficar atrás do relatório de despedida.

O exemplo de 2022 usa visibilitychange quando o documento se torna oculto. Num celular, a página pode passar ao fundo e ter seu processo encerrado mais tarde pelo sistema, sem cerimônia de unload. Esperar a solenidade da saída é arriscado quando a luz pode apagar antes. O estado oculto oferece uma ocasião melhor para entregar o envelope; Beacon cuida do transporte.

O retorno true informa que o navegador conseguiu colocar os dados na fila. O registro de chegada mora no servidor. A API não devolve uma resposta para a página processar. Receber o pacote na portaria é um passo real, mas o carimbo de entrega aparece em outro lugar. Operar sem essa distinção produz gráficos mais otimistas do que a correspondência recebida.

O envelope também tem limite de tamanho. O texto de 2022 liga a transmissão ao fetch com keepalive e restringe a quantidade de dados em espera. Quem precisa de cabeçalhos próprios, método diferente ou resposta tem de usar os recursos de fetch apropriados. O mensageiro foi contratado para levar um bilhete, não uma mudança inteira.

O histórico de publicação do W3C marca o primeiro rascunho público em 2013, uma versão de Recomendação Candidata em 2017 e o rascunho candidato de 2022. São datas dos documentos. A pergunta que todos ajudam a responder cabe numa frase: quando o leitor parte, quem fica encarregado do último dado?

O benefício aparece como silêncio. A página seguinte começa sem ser refém da anterior. O site ainda pode mandar seu pequeno relatório, e o navegador assume o trabalho de rede. No café, o garçom encontrou um mensageiro; o cliente não precisou voltar para preencher a ficha.