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