HTTP/2に残ったServer Push、Chromeは受信を終了

要約

RFC 7540は、HTTP/2のサーバーが次に必要そうなファイルをPUSH_PROMISEで予告して送る仕組みを定めた。クライアントは無効化や拒否ができた。
RFC 9113は2022年にも機能を残し、予測が外れた場合の性能低下を説明した。Chrome 106の変更記録は、その受信と利用をやめたことを記している。

頼まれる前に届ける

HTMLにはスタイルシートへの参照がある。サーバーはその参照を、ブラウザーがページを読み終えるより先に知っている。ならばファイルを先に送れば、追加の要求を待つ時間を省ける。2015年のHTTP/2仕様はこの発想をPUSH_PROMISEというフレームにした。サーバーがクライアントの次の要求を組み立て、その応答を別のストリームで運ぶ。

何でも送れるわけではない。先送りはクライアントが始めた要求に結びつき、安全でキャッシュ可能な対象について、正しい提供元から行わなければならない。ブラウザーはSETTINGS_ENABLE_PUSH=0で受信を止め、不要なストリームを拒否できる。規格が認めたのは提案であり、サーバーがブラウザーの手元を知っているという保証ではなかった。

ブラウザーにはすでに同じファイルが保存されているかもしれない。内容の種類に応じて別の版が必要かもしれない。利用者がページを離れるかもしれない。使わないデータにも回線の空きとメモリーが要る。先回りした荷物が、いま必要な荷物の通路をふさぐこともある。

規格自身が難しさを書く

2022年6月のRFC 9113はServer Pushを削らず、章を設けて説明し直した。スタイルシートやスクリプトの要求を先取りすれば往復を省ける。一方、成功にはキャッシュの状態、内容交渉、利用者の行動まで見通す必要がある。外れた予測は重要な応答と通信路を奪い合い、かえって遅くする。クライアントが無効化できる設定も残った。

仕様が残ることと、製品が受信を続けることは別の判断である。後者にはストリームの管理、キャッシュとの調整、性能試験が伴う。RFCは交換の方法を定義できても、個々のブラウザーがその仕事を続ける理由までは作れない。

Chromeは2022年8月、106版でServer Pushを標準では無効にすると告知した。速度上の利益を安定して得るのは難しく、逆に遅くなる場合もあると説明した。106版の削除項目は具体的だ。サーバーから押し出されたHTTP/2ストリームを受け取り、メモリーに保ち、利用する能力を削除した。規格の文章は続いたが、Chromeの受け皿はなくなった。