Os aplicativos da Web geralmente precisam emitir solicitações que relatam eventos, atualizações de estado e análises para um ou mais servidores. Tais solicitações normalmente não requerem processamento de resposta no cliente (por exemplo, resultam em 204 ou 200 códigos de resposta HTTP com um corpo de resposta vazio) e não devem competir por rede e recursos de computação com outras operações de alta prioridade, como buscar recursos críticos, reagir para inserir, executar animações e assim por diante. No entanto, essas solicitações unidirecionais (beacons) também são responsáveis por fornecer dados críticos de aplicativos e medições, forçando os desenvolvedores a usar métodos caros para garantir sua entrega:
Os desenvolvedores optam pela entrega imediata de cada beacon, em vez de combinar e adiar a entrega, pois isso proporciona melhores taxas de entrega. Adiar a entrega pode significar que a solicitação de beacon pode não ter tempo suficiente para ser concluída com sucesso, o que leva à perda de dados importantes do aplicativo.
Os desenvolvedores optam por emitir solicitações de bloqueio por meio de XMLHttpRequest síncronos, inserindo loops ocupados no-op ou usando outras técnicas que impedem o agente do usuário de executar operações de tempo crítico (por exemplo, clicar, descarregar e outros manipuladores) e prejudicar a experiência do usuário. O comportamento de bloqueio é usado para fornecer uma taxa de entrega aprimorada, pois evita que o agente do usuário e o sistema operacional cancelem a solicitação se a página for descarregada, suspensa ou eliminada pelo sistema.
A incompatibilidade entre os requisitos de entrega e processamento acima deixa a maioria dos desenvolvedores com uma escolha difícil e adoção generalizada de técnicas de bloqueio que prejudicam a experiência do usuário. Esta especificação define uma interface que os desenvolvedores da Web podem usar para agendar a entrega assíncrona e sem bloqueio de dados que minimiza a contenção de recursos com outras operações de tempo crítico, garantindo que tais solicitações ainda sejam processadas e entregues ao destino:
- As solicitações de beacon são priorizadas para evitar a competição com operações de tempo crítico e solicitações de rede de prioridade mais alta.
- As solicitações de beacon podem ser agrupadas de forma eficiente pelo agente do usuário para otimizar o uso de energia em dispositivos móveis.
- As solicitações de beacon são garantidas para serem iniciadas antes que a página seja descarregada e podem ser executadas até a conclusão sem exigir solicitações de bloqueio ou outras técnicas que bloqueiam o processamento de eventos interativos do usuário.
Enviar um beacon é simples(já esta em todos os navegadores modernos!)
- As solicitações de beacon não exigem uma resposta. Esta é uma grande diferença das solicitações regulares XHR ou fetch em que o cliente (navegador) espera uma resposta do servidor.
- As solicitações de beacon são iniciadas antes que uma página seja descarregada, mesmo quando você fecha o navegador.
- As solicitações de beacon são concluídas sem exigir uma solicitação de bloqueio (XHR, por exemplo).
- As solicitações de beacon usam o método HTTP POST.
navigator.sendBeacon('/url-que-vai-receber-o-dado', data);
Uma implementação maior!
//evento não bloqueante! Não bloqueia o loop de eventos do JS no cliente!
function reportEvent(event) {
var data = JSON.stringify({
event: event,
time: performance.now()
});
navigator.sendBeacon('/collector', data);
}
// emite beacon sem bloqueio com análise de sessão da página
// transições para o estado de segundo plano (Page Visibility API)
document.addEventListener('visibilitychange', function() {
if (document.visibilityState === 'hidden') {
var sessionData = buildSessionReport();
navigator.sendBeacon('/url', sessionData);
}
});
As solicitações iniciadas por meio do sendBeacon()método não bloqueiam ou competem com o trabalho de tempo crítico, podem ser priorizadas pelo agente do usuário para melhorar a eficiência da rede e eliminar a necessidade de usar operações de bloqueio para garantir a entrega de dados beacon.
OBS:
O método sendBeacon() não fornece capacidade de personalizar o método de solicitação, fornecer cabeçalhos de solicitação personalizados ou alterar outras propriedades de processamento da solicitação e resposta. Os aplicativos que exigem configurações não padrão para tais solicitações devem usar a API [ FETCH ] com keepalive definido como true.
Beacons são úteis para enviar dados ao servidor quando uma página é descarregada(load completo) (por exemplo, fechamento do navegador, navegações de página, etc.).
if (navigator.sendBeacon) {
// faça a magica acontecer
navigator.sendBeacon('/collector', Data);
} else {
// esse navegador não tem beacon
// use XHR ou fetch
}
Formatos aceitos pelo beacon para envio
- ArrayBufferView
- Blob
- DOMStringou
- FormData O data é opcional!
Casos de uso
- Saber quanto tempo um usuário ficou numa sessão!
- Quais são os controles de interface do usuário usados pelos usuários!
- Qualquer outro tipo de informação de telemetria a ser capturada!
Há um limite nos dados que podem ser enviados ao servidor usando a API Beacon. No entanto, esse limite não é uniforme em todos os navegadores e agentes de usuário.
Você já usa a API?
Fontes:
https://www.w3.org/TR/beacon/
Top comments (2)
Que massa isso aí, não conhecia essa API
Sim muito neh!
O bom dela que é super simples e funciona em todos os navegadores modernos!