HTTP 103 Early Hintsはサーバーが最終応答を準備している間にLink情報を先行して伝える情報応答だ。対応するブラウザーはpreloadやpreconnectを始める場合があるが、必ず取得される、またはページが速く表示されるとは限らない。103のヘッダーは最終文書を置き換えず、最終応答が文書の状態とヘッダーを決める。RFC 8297 Chromeの解説

最終HTMLの前にリソースヒントが届くHTTPフローの概念図

概念図であり、ブラウザー計測や通信の記録ではない。

103は情報応答で最終文書ではない

103はHTTPの1xx情報応答である。サーバーが最終応答にも含める可能性の高いヘッダー情報を先に送り、クライアントは待機中にそれを先行評価できる。処理中に初期情報が誤りだと分かれば、最終応答で省略または変更できる。したがって、先行メッセージだけから最終ステータスや確定ヘッダーを判断してはならない。103を無視するクライアントでも、最終応答を通常どおり処理できる必要がある。RFC 8297

preloadとpreconnectは異なる準備を表す

Link: <https://static.example.org/app.css>; rel=preload; as=styleは、特定リソースを先に取得できる機会をクライアントに伝える。rel=preconnectはそのoriginへの接続準備を依頼する別の指示だ。どちらもサーバーがすでに資源を届けたという意味ではなく、対応範囲はクライアントによって異なる。URL、型、クロスオリジンの資格情報が最終文書での利用と合わないpreloadは再利用されず、不要な通信を生む場合がある。例は文法説明用で、実ページの資源とパラメーターは個別に確かめる。RFC 8288 Chromeの解説

サーバー処理と一部の通信準備を重ねられる場合がある

クライアントが最終HTMLより先に有用なヒントを受け取れば、対応環境はサーバーの残り処理中にpreloadや接続準備を始められる場合がある。ヒントが遅い、最終応答が速い、資源がキャッシュ済み、実際のページが別資源を使うといった場合は、効果が小さいか得られない。誤ったpreloadは帯域を消費し、後続リクエストと重なることもある。Early Hintsは条件付きの最適化で、一定時間を必ず短縮する方法ではない。RFC 8297 Chromeの解説

専門家の視点：要求を実環境で測定する

実サービスでは、条件の近いページ訪問を103あり・なしに分けて比べると結果を読み取りやすい。初回訪問と再訪を分け、比較群のページ条件をそろえる。実際の配信経路、利用ブラウザー、接続方式も記録し、キャッシュ状態が103の効果を見えにくくしないようにする。ヒントの送信時刻、最終応答の到着、予告したリソースの実際の要求と完了、描画に使われたアセットを記録する。要求数だけでは、キャッシュ済みファイルや未使用のpreloadを効果と誤認するおそれがある。最終文書が使わなかったデータ量、接続の動き、リソース優先度の変化も確認し、ページごとにヒントを残すか決める。専門家の実装視点では、プロトコル上の意味をサービスの観測結果と結び付ける。この測定やガイド資料は性能向上を保証しない。

ページとクライアントを絞って検討する

Chromeの開発者向け資料は、訪問の多い入口ページと初期描画に関わる資源から検討する方法を示す。そこで説明される動作や制限はChromeの実装についてであり、すべてのブラウザーの対応表ではない。最終Link宣言、リダイレクト、キャッシュ、資格情報を合わせて確認する。103を無視するクライアントにも最終HTMLやヘッダーから必要な資源が届くようにする。実運用では対照群を設け、ユーザー指標、未使用preload、重複要求、転送バイトを確認してから範囲を広げる。Chromeの解説

Sources