navigator.sendBeaconと離脱時の確実な送信

ページを閉じる・別ページへ遷移する直前に、最後のアクセスログや計測データを送りたい場面は多くあります。素朴に unload で fetch() や非同期 XHR を投げると、送信が始まる前にページが破棄され、リクエストが握りつぶされることが珍しくありません。navigator.sendBeacon() は、この「離脱時の取りこぼし」を構造的に解決するために設計された API です。ここではキューイングの内部動作、fetch の keepalive との違い、そして計測用途で壊れない設計を原理から見ていきます。

なぜ離脱時の送信は失敗するのか

ブラウザはページを破棄するとき、そのページに紐づく実行コンテキスト・タイマー・進行中のネットワーク取得をまとめて停止します。unload ハンドラ内で fetch() を呼んでも、返る Promise の解決やネットワーク送出はイベントループ上の非同期処理で進むため（イベントループとマイクロタスク の上で動く）、ハンドラを抜けてページが消えると送信が中断されます。

歴史的な回避策は同期 XHR（xhr.open(..., false)）でした。同期送信ならハンドラを抜ける前に送り切れますが、代償としてメインスレッドを完全にブロックし、サーバー応答が遅いと離脱そのものがカクつきます。ユーザー体験を犠牲にして確実性を買う、筋の悪いトレードオフです。

sendBeacon のキューイング機構

navigator.sendBeacon(url, data) の核心は、送信をページから切り離してブラウザに委譲する点にあります。呼び出すとブラウザはリクエストを内部のバックグラウンドキューに登録し、その場では送信完了を待たずに即座に制御を返します。実際の送出は、呼び出し元のページが破棄された後でもブラウザプロセス自身が責任を持って完遂します。

window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    const data = JSON.stringify({ event: 'leave', t: Date.now() });
    const blob = new Blob([data], { type: 'application/json' });
    navigator.sendBeacon('/collect', blob); // 投入だけして即リターン
  }
});

戻り値は boolean で、キューへの投入に成功したかだけを表します。true は「ブラウザが送信を引き受けた」という意味であって、サーバーに届いたこと・2xx が返ったことは一切保証しません。false になるのは、データ量がブラウザのキュー上限を超えた場合などです（Beacon 標準は実装に上限を許し、多くの実装で 64KB 程度）。レスポンスやステータスを観測する手段はなく、これは「投げっぱなしで良い計測」という用途に最適化した割り切りです。

メソッド・Content-Type・CORS の制約

sendBeacon のリクエストは常に POST で、メソッドを選べません。Content-Type は第 2 引数 data の型から自動決定されます。設計上、ヘッダを自由に付けられない代わりに、型の選び方で「プリフライトを避けられるか」が決まる点が実務上重要です。

ここに落とし穴があります。JSON を送りたくて Blob の type に application/json を指定すると、これは CORS の単純リクエストの範囲外となり、クロスオリジンではプリフライト（OPTIONS）が必要になります。ところが離脱の瞬間にプリフライトと本送信の 2 往復を完了できるとは限らず、欠損率が上がります。同一オリジンへの送信、あるいはサーバーが text/plain ボディの JSON 文字列を受け付ける設計にしておくと、単純リクエストのまま確実に送れます。

credentials は明示指定できませんが、Beacon は内部的に**include 相当**で動き、対象オリジンの Cookie が同梱されます（クロスオリジンではサーバー側の CORS 許可が前提）。Cookie を使ったセッション計測ではこの挙動が効いてきます。

fetch keepalive との違い

fetch(url, { keepalive: true }) は、sendBeacon と**同じ下層機構（離脱後も生き残る取得）**を使いつつ、より柔軟な制御を提供します。違いは「何を犠牲にして何を得るか」です。

keepalive 付き fetch は通常の Fetch API と同じくレスポンスを読め、ヘッダも付けられます。一方で keepalive リクエストの本文合計サイズは 64KB に制限され（同時に飛ばす複数の keepalive 全体の上限）、超えると fetch が reject します。「ヘッダ・メソッド・レスポンスが要るなら keepalive、最小限の投げ捨て計測なら sendBeacon」が選び分けの基準です。なお両者とも、ページが本当に破棄されるとレスポンスは観測できない点は共通です（送信自体は完遂される）。

計測用途の壊れない設計

離脱検知の置き場所が、ビーコンの取りこぼし率を左右します。最も信頼できるのは visibilitychange で visibilityState === 'hidden' になった瞬間です。タブの非アクティブ化・アプリ切り替え・タブを閉じる操作のいずれでも発火し、モバイルでも比較的確実に呼ばれます。補完として pagehide も使い、両者で送ります（多重送信は計測 ID で冪等化する）。

function flush() {
  if (!buffered.length) return;
  const body = JSON.stringify(buffered);
  navigator.sendBeacon('/collect', body); // text/plain → 単純リクエスト
  buffered = [];
}
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') flush();
});
window.addEventListener('pagehide', flush); // bfcache 退避時も拾う

pagehide は bfcache への退避時にも発火するため、ここで送っておけば「戻る/進む」で凍結される直前のデータも拾えます。逆に、計測のために unload を登録すると bfcache を壊し、ページ復元を遅くするので避けます。パフォーマンス計測 API で集めた PerformanceObserver のエントリも、この hidden のタイミングで sendBeacon にまとめて流すのが王道です。

まとめ