在实践中，我们使用 HTTP 请求将一些匿名指标从浏览器发送到服务器端。这些收集来的信息用于验证应用的行为是否正常、监控其质量和速度、服务恶化时发出警告等，也有助于通过统计分析和研究改善平台服务质量。
最近我们开始使用 sendBeacon API 来取代 XMLHttpRequests 完成以上任务。在本文中，我们将细数一些从此次转换中带来的好处。
sendBeacon 功能简介
sendBeacon 以一种将分析信息回传给服务端而无需响应的方式被创建出来。这种专注的设计目的和需要考虑行为、安全、性能和优先级的 XHR 有巨大的不同，这些稍后会详述。
首先值得强调的是其不需要响应的显著特性。当浏览器需要来自 web 服务器的响应时，就意味着应用可能会依照得到的信息行事 -- 这也是为何浏览器厂商们要实现某些防御机制以保护用户的原因，因而 sendBeacon API 也得以不受那些相同的约束。
下面的 Chrome Network 面板截图展示了截获的从 XHR 转向 sendBeacon 工作中，发往监控服务的请求。sendBeacon 请求被描述为 “ping” 类型，可以看到各种请求和它们之间的区别。
跨域资源共享 (CORS)
CORS 规定了一个域间（或子域间）发送数据的复杂协议，包含一个预检 OPTIONS 请求及默认不发送相关 cookie 头等策略。考虑到分析信息常被发送到不同的子域甚至完全跨域，这些限制还是必要的。
可以在 Network 面板中看到和每个 XHR 请求相伴而生的预检请求，也能发现 XHR 请求忽略了整个 cookie 头；而 sendBeacon 请求则没有这些限制 -- 不用预检请求，也携带了 cookie 头。
优先级
一旦浏览器能感知到某些请求是无关用户体验的，就能分出轻重缓急了，和用户体验相关的请求会被优先执行完毕。
在 Network 页签的 Priority 列中，这些请求的不同显而易见。
行为
因为 sendBeacon 请求无需响应，浏览器也就不用像对待 XHR 或 fetch 那样，每当页面一 unload 就得中断它们。Network 页签中包含了一个 status 和 time 列都为 (unknown) 的请求。该请求就是页面切换之前被执行而没来得及中断的；当下一个页面的请求被处理完后，浏览器才在后台将其完成了。
下面展示的，是一个发送页面有效期内累计指标的例子。我们在页面的生命周期内收集信息，并在页面可见性改变为隐藏时发送这些信息。这一事件发生在用户切换页签之时 -- 以及至关重要的是，在页面跳走并 unload 之前发生。这同时意味着你可以并行不悖地发送信息和跳转链接。
下图展示了这一特性如何增加了我们能够收集到的累积指标的数量。
限制
由于这个请求函数不接受响应，使得我们要设法让浏览器获知请求是否成功抵达服务端；这是切换到 sendBeacon 后为数不多需要应付的问题。通过函数返回值，我们将能够判断是否成功。
尽管 sendBeacon 规范 (www.w3.org/TR/beacon/#…) 没有规定数据大小，但浏览器厂商一般会限制请求体积，这样一来 sendBeacon 函数将在传输失败时返回 false ，反之则是 true。
如果以上限制妨碍到了某些信息的收集，则 fetch 函数提供的 “keepalive” 选项，可以作为 sendBeacon 的一种 替代方案，该选项允许请求的存活长于页面。
在最后一个例子中，我对比了三种方法：
- 普通 fetch 请求
- 配置了 keepalive 的 fetch 请求
- beacon (ping)
总结
sendBeacon 为通过 HTTP 发送分析信息而生，善以用之可以改善站点的用户体验并增加应用曝光度。
