fetchLater() API

概念与用法

开发者经常需要将数据发送（或称为 beacon）回服务器，尤其是在用户访问页面结束时——例如，用于分析服务。有几种方法可以做到这一点：从在页面中添加 1 像素的 <img> 元素，到 XMLHttpRequest，再到专用的 Beacon API，以及 Fetch API 本身。

问题在于，所有这些方法在页面访问结束时进行 beacon 发送时都存在可靠性问题。虽然 Beacon API 和 Fetch API 的 keepalive 属性会在文档被销毁时发送数据（尽力而为），但这只解决了一部分问题。

要解决的另一个——也是更困难的——部分是决定何时发送数据，因为在页面的生命周期中没有一个理想的时间来发出 JavaScript 调用来发送 beacon。

• unload 和 beforeunload 事件不可靠，并且被几个主要浏览器完全忽略。
• pagehide 和 visibilitychange 事件更可靠，但在移动平台上仍然存在问题。

这意味着希望通过 beacon 可靠地发送数据的开发者需要比理想情况更频繁地发送。例如，他们可能在每次更改时发送 beacon，即使页面的最终值尚未确定。这会增加网络使用、服务器处理以及在服务器上合并或丢弃过时 beacon 的成本。

或者，开发者可以选择接受一定程度的数据丢失——无论是通过

• 在指定截止时间后进行 beacon 发送，并且不收集后续数据。
• 在页面生命周期结束时进行 beacon 发送，但接受有时可能不可靠。

fetchLater() API 扩展了 Fetch API，允许提前设置 fetch 请求。这些延迟的 fetch 请求可以在发送前进行更新，从而使 payload 反映需要 beacon 的最新数据。

然后，浏览器会在标签页关闭或导航离开时发送 beacon，如果指定了时间，则会在设定的时间后发送。这避免了发送多个 beacon，但仍然确保了在合理预期内可靠的 beacon（即，不包括浏览器进程在崩溃期间意外关闭的情况）。

如果不再需要，也可以使用 AbortController 来中止延迟的 fetch 请求，从而避免进一步的额外成本。

配额

延迟的 fetch 请求会被批处理并在标签页关闭时发送；此时，用户无法中止它们。为了避免文档滥用带宽发送无限量数据，顶级文档的总配额上限为 640KiB。

fetchLater() 的调用者应保持防御性，在几乎所有情况下都应捕获 QuotaExceededError 错误，尤其是在嵌入第三方 JavaScript 时。

由于此限制使得延迟 fetch 带宽成为一种稀缺资源，需要由多个报告源（例如，多个 RUM 库）和来自多个源的子帧共享，因此平台提供了合理的默认配额划分。此外，它还提供了 deferred-fetch 和 deferred-fetch-minimal Permissions Policy 指令，允许在需要时进行不同的划分。

有关更多详细信息和示例，请参阅 fetchLater() 配额。

接口

Window.fetchLater()

用于将资源排队以便稍后发送。

DeferredRequestInit

表示可用于配置延迟 fetch 请求的选项集。

FetchLaterResult

表示请求延迟 fetch 的结果。

HTTP 标头

deferred-fetch

控制 fetchLater() API 的顶级配额。

deferred-fetch-minimal

控制 fetchLater() API 的共享跨源子框架配额。

规范

浏览器兼容性

另见

• fetchLater() 配额
• Fetch API