[译] 用 sendBeacon 发送分析信息的优点

云前端

共 1844字,需浏览 4分钟

 ·

2022-01-21 12:35

在实践中,我们使用 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 规范 (https://www.w3.org/TR/beacon/#sec-sendBeacon-method) 没有规定数据大小,但浏览器厂商一般会限制请求体积,这样一来 sendBeacon 函数将在传输失败时返回 false ,反之则是 true

如果以上限制妨碍到了某些信息的收集,则 fetch 函数提供的 “keepalive” 选项,可以作为 sendBeacon 的一种 替代方案,该选项允许请求的存活长于页面。

在最后一个例子中,我对比了三种方法:

  1. 普通 fetch 请求
  2. 配置了 keepalive 的 fetch 请求
  3. beacon (ping)


    总结

sendBeacon 为通过 HTTP 发送分析信息而生,善以用之可以改善站点的用户体验并增加应用曝光度。

原文:https://medium.com/fiverr-engineering/benefits-of-sending-analytical-information-with-sendbeacon-a959cb206a7a


浏览 48
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报