有幾次，當用戶執(zhí)行導航到不同頁面或提交表單等操作時，我需要發(fā)送帶有一些數(shù)據(jù)的 HTTP 請求以進行記錄?？紤]這個在點擊鏈接時向外部服務發(fā)送一些信息的人為示例：

(相關資料圖)

Go to Page<script>document.getElementById("link").addEventListener("click", (e) => { fetch("/log", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ some: "data" }) });});</script>

這里沒有什么非常復雜的事情發(fā)生。該鏈接可以正常運行（我沒有使e.preventDefault()），但在該行為發(fā)生之前，會在單擊時觸發(fā) POST 請求。無需等待任何形式的響應。我只是希望它被發(fā)送到我正在訪問的任何服務。

乍一看，您可能希望該請求的分派是同步的，之后我們將繼續(xù)導航離開頁面，而其他服務器成功地處理該請求。但事實證明，情況并非總是如此。

瀏覽器不保證保留打開的HTTP請求

當瀏覽器中發(fā)生終止頁面的情況時，并不能保證進程內(nèi)的HTTP請求會成功(參見更多關于“終止”和頁面生命周期的其他狀態(tài))。這些請求的可靠性可能取決于幾個方面——網(wǎng)絡連接、應用程序性能，甚至外部服務本身的配置。因此，在這些時刻發(fā)送數(shù)據(jù)可能是不可靠的，如果您依賴這些日志來做出數(shù)據(jù)敏感的業(yè)務決策，那么這可能會帶來一個潛在的重大問題。為了幫助說明這種不可靠性，我使用上面包含的代碼設置了一個帶有頁面的小型 Express 應用程序。單擊鏈接時，瀏覽器會導航到 /other，但在此之前，會觸發(fā) POST 請求。當一切都發(fā)生時，我打開了瀏覽器的網(wǎng)絡選項卡，并且我使用的是“慢 3G”連接速度。一旦頁面加載并且我已經(jīng)清除了日志，事情看起來很安靜：

1.webp

但是一旦鏈接被點擊，事情就會出錯，當導航發(fā)生時，請求被取消。

2.webp

這使得我們對外部服務是否能夠處理請求缺乏信心。為了驗證這種行為，當我們使用window.location以編程方式導航時也會發(fā)生這種情況:

document.getElementById("link").addEventListener("click", (e) => {+ e.preventDefault(); // Request is queued, but cancelled as soon as navigation occurs. fetch("/log", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ some: "data" }), });+ window.location = e.target.href;});

無論導航以何種方式或何時發(fā)生，以及活動頁面何時終止，那些未完成的請求都有被放棄的風險。

但是為什么被取消了呢?

問題的根源在于，默認情況下，XHR 請求（通過 fetch 或 XMLHttpRequest）是異步且非阻塞的。一旦請求被排隊，請求的實際工作就會被移交給幕后的瀏覽器級 API。由于它與性能有關，這很好——你不希望請求占用主線程。但這也意味著當頁面進入“終止”狀態(tài)時，它們有被遺棄的風險，無法保證任何幕后工作都能完成。以下是 Google 對特定生命周期狀態(tài)的總結：

一旦頁面開始被瀏覽器卸載并從內(nèi)存中清除，頁面就處于終止狀態(tài)。在這種狀態(tài)下沒有新的任務可以啟動，并且正在進行的任務如果運行時間過長可能會被殺死。

簡而言之，瀏覽器的設計假設當一個頁面被關閉時，沒有必要繼續(xù)處理它排隊的任何后臺進程。

那么，我們有哪些選擇呢？

避免這個問題最明顯的方法可能是，盡可能地延遲用戶操作，直到請求返回響應。在過去，通過使用XMLHttpRequest中支持的同步標志來實現(xiàn)這一點是錯誤的。使用它會完全阻塞主線程，導致大量的性能問題——我在過去寫過一些這方面的文章——所以這個想法甚至不應該被接受。事實上，它正在退出平臺(Chrome v80+已經(jīng)刪除了它)。相反，如果您打算采用這種類型的方法，那么最好在響應返回時等待Promise解析。在它回來之后，您可以安全地執(zhí)行該行為。使用我們之前的代碼片段，它可能看起來像這樣：

document.getElementById("link").addEventListener("click", async (e) => { e.preventDefault(); // Wait for response to come back... await fetch("/log", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ some: "data" }), }); // ...and THEN navigate away. window.location = e.target.href;});

這可以完成工作，但也有一些不小的缺點。首先，它會延遲所需行為的發(fā)生，從而損害用戶體驗。收集分析數(shù)據(jù)肯定會給業(yè)務(以及未來的用戶)帶來好處，但讓當前用戶為實現(xiàn)這些好處而支付成本并不理想。更不用說，作為一個外部依賴項，服務本身的任何延遲或其他性能問題都會暴露給用戶。如果分析服務的暫停導致客戶無法完成一項高價值的行動，那么所有人都是輸家。其次，這種方法并不像它最初聽起來那么可靠，因為一些終止行為無法通過編程延遲。例如， e.preventDefault() 無法延遲某人關閉瀏覽器選項卡。因此，它充其量只能涵蓋為某些用戶操作收集數(shù)據(jù)，但不足以全面信任它。

指示瀏覽器保留未完成的請求

值得慶幸的是，有一些選項可以保留絕大多數(shù)瀏覽器中內(nèi)置的未完成的 HTTP 請求，并且不需要損害用戶體驗。

使用Fetch的keepalive標志

如果在使用fetch()時將keepalive標志設置為true，那么相應的請求將保持打開狀態(tài)，即使發(fā)起該請求的頁面被終止。使用我們最初的例子，它的實現(xiàn)如下所示：

Go to Page<script> document.getElementById("link").addEventListener("click", (e) => { fetch("/log", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ some: "data" }), keepalive: true }); });</script>

當點擊該鏈接并進行頁面導航時，不會發(fā)生請求取消：

3.webp

相反，我們得到的是一個(未知)狀態(tài)，原因很簡單，活動頁面從來沒有等待接收任何響應。像這樣的一行程序很容易修復，特別是當它是常用瀏覽器API的一部分時。但是，如果您正在尋找一種功能更集中、界面更簡單的選擇，那么還有另一種方法，它實際上具有相同的瀏覽器支持。

使用 Navigator.sendBeacon()

Navigator.sendBeacon() 函數(shù)專門用于發(fā)送單向請求（beacon）。一個基本的實現(xiàn)看起來像這樣，發(fā)送一個帶有字符串化 JSON 和“text/plain” Content-Type 的 POST：

navigator.sendBeacon("/log", JSON.stringify({ some: "data"}));

但是此 API 不允許您發(fā)送自定義標頭。因此，為了讓我們以“application/json”的形式發(fā)送數(shù)據(jù)，我們需要做一些小調(diào)整并使用 Blob：

Go to Page<script> document.getElementById("link").addEventListener("click", (e) => { const blob = new Blob([JSON.stringify({ some: "data" })], { type: "application/json; charset=UTF-8" }); navigator.sendBeacon("/log", blob)); });</script>

最后，我們得到了相同的結果——即使在頁面導航之后也允許完成的請求。但是還有一些事情可能使它比 fetch() 更有優(yōu)勢：beacon以低優(yōu)先級發(fā)送。為了演示，當同時使用帶有 keepalive 的 fetch() 和 sendBeacon() 時，Network 選項卡中顯示的內(nèi)容如下：

4.webp

默認情況下，fetch() 獲得“高”優(yōu)先級，而beacon（上面稱為“ping”類型）具有“最低”優(yōu)先級。對于對頁面功能不重要的請求，這是一件好事。直接取自 Beacon 規(guī)范：

該規(guī)范定義了一個接口，[…]最大限度地減少與其他時間關鍵操作的資源爭用，同時確保此類請求仍然被處理并交付到目的地。

換句話說，sendBeacon() 確保它的請求不會妨礙那些對您的應用程序和用戶體驗真正重要的請求。

因為ping屬性而被光榮提及

值得一提的是，越來越多的瀏覽器支持 ping 屬性。當附加到鏈接時，它會觸發(fā)一個小的 POST 請求：

Go to Other Page

這些請求標頭將包含單擊鏈接的頁面（ping-from），以及該鏈接的 href 值（ping-to）：

headers: { "ping-from": "http://localhost:3000/", "ping-to": "http://localhost:3000/other" "content-type": "text/ping" // ...other headers},

它在技術上類似于發(fā)送beacon，但有一些明顯的限制：

它嚴格限制在鏈接上的使用，如果您需要跟蹤與其他交互相關的數(shù)據(jù)，例如按鈕點擊或表單提交，這將使其無法啟動。

瀏覽器支持很好，但不是很好。在撰寫本文時，F(xiàn)irefox 特別沒有默認啟用它。

您無法隨請求一起發(fā)送任何自定義數(shù)據(jù)。正如前面提到的，您最多只能得到幾個ping-*頭文件，以及隨程序一起出現(xiàn)的任何其他頭文件。

綜合考慮，如果您可以發(fā)送簡單的請求并且不想編寫任何自定義 JavaScript，那么 ping 是一個很好的工具。但是，如果您需要發(fā)送更多實質(zhì)內(nèi)容，則可能不是最好的選擇。

那么，我應該選擇哪一個呢?

使用 fetch 和 keepalive 或 sendBeacon() 發(fā)送您的最后一秒請求肯定存在權衡。為了幫助辨別哪種方法最適合不同的情況，需要考慮以下幾點：

如果出現(xiàn)以下情況，您可能會使用 fetch() + keepalive：

您需要輕松地隨請求傳遞自定義標頭。您想向服務發(fā)出 GET 請求，而不是 POST。您正在支持較舊的瀏覽器（如 IE）并且已經(jīng)加載了 fetch polyfill。

但在以下情況下 sendBeacon() 可能是更好的選擇：

您正在進行簡單的服務請求，不需要進行太多定制。您更喜歡更簡潔、更優(yōu)雅的 API。您希望確保您的請求不會與應用程序中發(fā)送的其他高優(yōu)先級請求競爭。

原文：https://css-tricks.com/send-an-http-request-on-page-exit/作者：Alex MacArthur

標簽： HTTP