要約

  • W3Cが2013年10月に公開した最初のBeacon草案は、同期XMLHttpRequest、画像読み込み、空回りするループなど、ページ離脱を遅らせる手法を問題にした。
  • 2022年8月の候補勧告草案は、navigator.sendBeacon()で小さな一方向のデータをブラウザーに預け、読者の移動を妨げずに送信を予定する仕組みを記述した。

閉店間際の店を想像する。客はもうコートを着ている。店員が走ってきて、「退店の記録を本部へ送るまで、ここに立っていてください」と言う。記録は一枚の紙なのに、客の足は止まる。ウェブでも、前のページの事務仕事が次のページの始まりを遅らせていた。

2013年10月29日のW3C初公開作業草案は、この事情を具体的に記した。分析や診断のコードは、文書が消える直前のデータを送ろうとする。非同期の要求は、ページがなくなれば取り残されることがある。そこで同期XMLHttpRequestで離脱を待たせたり、画像の読み込みを使ったり、ただ時間を稼ぐだけのループを回したりした。読者から見れば、次の場所へ行く操作が重くなる。

最初の提案は、報告をユーザーエージェントに引き渡すことだった。2013年のメソッド名はbeaconで、後のnavigator.sendBeacon()とは形が違う。古い例の文法をそのまま今のAPIだと読むべきではない。受け継がれたのは責任の置き場所だ。消えかけたページが玄関を押さえる代わりに、ブラウザーが封筒を持つ。

そもそも最後の報告には理由がある。閲覧の終わりに初めて確定する出来事もある。一件ずつ直ちに送れば通信と電力を使う。最後までためれば、ページと一緒に消える恐れがある。この板挟みの請求書を読者の待ち時間で払わせるのが、以前の乱暴な解決だった。

2022年8月3日のW3C候補勧告草案は、navigator.sendBeacon(url, data)を小さな一方向の報告のために説明する。処理は非同期で、読者の操作を止めない。ブラウザーは優先度を考え、必要に応じて送信をまとめ、通信と電力の負担を調整できる。次のページの表示を待たせてまで、前のページの集計係を優先する必要がなくなった。

2022年の例はvisibilitychangeを使い、文書が非表示になったときにセッションの報告を預ける。携帯端末では、アプリが背景へ移った後にOSが処理を終わらせることがある。その場合、unloadという正式な別れの合図は来ないかもしれない。姿が見えなくなる時点のほうが、手紙を渡す合図として役に立つ。

返り値のtrueは、ブラウザーがデータを送信用の列に受け入れたという意味だ。受取先に届いたかはサーバー側で確かめる。このメソッドには応答を受け取るコールバックがない。配達人が封筒を鞄に入れた瞬間に、遠くの受付の受領印まで見えたことにしては困る。

大きさにも限度がある。2022年の草案はfetchのkeepaliveを用いる要求と結び付け、保留できるデータ量を制限する。独自のヘッダーやメソッド、応答の処理が必要なら、適したfetchの仕組みを使う。Beaconの鞄は小包用で、家具の運搬車ではない。

W3Cの公開履歴には、2013年の初公開草案、2017年の候補勧告スナップショット、2022年の候補勧告草案が並ぶ。規格文書の歩みを示す日付だ。複数の版を通じて残った問いは一つ。最後の記録を送りたいページのために、誰の足を止めるのか。

改良の効果は静かだ。読者は次へ進み、前のページの小さな報告はブラウザーの仕事になる。店員は帳簿を閉じられるし、客は出口でその作業を見守らずに済む。