バックエンド面接：HTTP 103 Early HintsとPreloadのトレードオフを解説する

プロンプトとコンテキスト

このHTTP、ゲートウェイ、およびパフォーマンスに関する質問は、バックエンド、プラットフォーム、インフラストラクチャの役割に適しています。オリジンには最終的なHTMLの準備が整うまでに予測可能な待機時間があります。誤ったpreload、古いクライアントでのパースエラー、および重複ダウンロードを回避しながら、103を送信すべきかどうかを判断する必要があります。

面接官が評価するポイント

103のヒントセマンティクスと最終レスポンスのセマンティクスを区別できているか。
サーバーの思考時間（think time）、リソースの安定性、キャッシュヒット率を用いて価値を判断できるか。
103を必須パスにするのではなく、HTTP/2またはHTTP/3での適切なフォールバックを設計できるか。
preloadによって重複リクエスト、誤ったリソース、過剰な帯域幅の消費が発生していないかを検証できるか。

確認すべき質問

待機時間が動的なHTML生成に起因するのかネットワーク転送に起因するのか、リクエストがトップレベルナビゲーションであるか、クライアントやプロキシが1xxを確実に処理できるか、リソースURL、バージョン、asの値が安定しているか、そしてリソースがキャッシュ可能であるかを確認します。最終レスポンスを即座に送信できる場合は、通常のLinkヘッダーまたはHTMLのlink要素を使用する方がシンプルです。認証、リダイレクト、またはパーソナライズによってリソースが変動する場合、誤った早期ヒントは得られるメリット以上のコストを生む可能性があります。

30秒の回答フレームワーク

103は最終レスポンス前のヒントであり、ページ結果そのものではありません。HTMLを生成している間、オリジンはクライアントが並行してリソースを準備できるようにLink: rel=preloadやpreconnectを含む103を送信できます。最終的な200は依然として信頼できる確定的なヘッダーを提供します。サーバーの思考時間が十分にあり、予測が安定しており、HTTP/2またはHTTP/3が信頼できる場合にのみ有効化します。キャッシュ利用率、重複ダウンロード、LCP、エラー、帯域幅を測定し、古いクライアント向けには通常の最終レスポンスによるフォールバックを用意します。

ステップごとの詳細解説

最適化の余地を特定する。 リクエストを受信してから最終的なHTMLが完成するまでの待機時間を測定します。オリジンが迅速に200を返す場合、103を活用できる有効なギャップがないため、最終レスポンスでの通常のpreloadを維持します。
103のセマンティクスを定義する。 103は、最終レスポンスにこれらのフィールドが含まれる可能性が高いことを示します。クライアントは投機的に準備できますが、このヒントが最終レスポンスのセマンティクスを置き換えたり変更したりすることはできません。
ヒントの内容を選択する。 安定しており、クリティカルで、キャッシュ可能なCSS、スクリプト、または接続オリジンを優先します。リソースのバージョン、メディアタイプ、クロスオリジンクレデンシャルは最終レスポンスと一致していなければなりません。不確実なパーソナライズアセットをヒントに含めないでください。
プロトコルとクライアントを制約する。 HTTP/2またはHTTP/3を優先し、プロキシ、ブラウザ、オブザーバビリティパスが1xxを正しく処理できることを確認します。103を最終レスポンスとして扱ってしまう可能性がある古いHTTP/1.1クライアント向けには、無効化またはダウングレードします。
最終レスポンスを処理する。 最終的な200/3xx/4xxがページの結果を決定します。103のヒントが誤りとなった場合、クライアントは最終レスポンスに従います。中継機器はヒントを最終オブジェクトとしてキャッシュしてはなりません。
価値とコストを測定する。 導入前後の初回ビューLCP、リソースヒット率、重複ダウンロード、帯域幅、エラーを比較します。リダイレクト、キャッシュ無効化、またはリソースのバリエーションによってpreloadが無駄になる場合は、対象ページセットを絞り込むか103を削除します。

模範解答

高速化されそうだからといって、あらゆる場所で103を有効化することはありません。まず、意味のある動的HTML生成時間とトップレベルナビゲーションが存在することを確認します。CSSやクリティカルなスクリプトのURL、バージョン、as、キャッシュ動作が安定している場合は、HTTP/2またはHTTP/3経由でヒントを送信します：

http

HTTP/2 103 Early Hints
Link: </style.abc.css>; rel=preload; as=style
Link: </app.abc.js>; rel=preload; as=script

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Link: </style.abc.css>; rel=preload; as=style

最終レスポンスが常に確定的であり、103はそのリソースが必ず使われることを保証するものではありません。古いクライアント、信頼性の低いプロキシ、あるいはリダイレクトやパーソナライズによってリソースが変化するページでは、最終レスポンス内の通常のLinkヘッダーにフォールバックします。サーバーの待機時間、LCP、キャッシュヒット率、重複ダウンロード、帯域幅、4xx/5xxを測定する実験を実施します。ヒントが実際のギャップを埋められない場合は、103を削除します。

よくある間違い

103を最終ステータスとして扱う → クライアントがページの読み込みに成功したと判断する可能性がある → 最終レスポンスが結果を決定することを説明する。
すべてのHTMLリソースを103にコピーする → パーソナライズされたアセットやキャッシュ不可のアセットが2回ダウンロードされる → 安定したクリティカルリソースのみをヒントにする。
プロトコルやプロキシの互換性を無視する → 古いクライアントが1xxを誤ってパースする可能性がある → HTTP/2/3を優先し、フォールバックを提供する。
LCPのみを測定する → 無駄なpreload帯域幅が局所的な改善の裏に隠れてしまう可能性がある → 重複リクエスト、キャッシュ、エラーも監視する。
確定的な最終ヘッダーを省略する → ヒントは最終的なメタデータではない → 最終レスポンスで必要なLinkフィールドを再度含める。

フォローアップの質問

103はHTTP/2 Server Pushとどう違いますか？

103はフェッチするかどうかをクライアントに判断させます。一方、Server Pushは能動的にリソースを送信するため、クライアントがすでにキャッシュしているアセットをプッシュしてしまう可能性があります。キャッシュ状態が不確かな場合、103の方が不要な転送を回避しやすくなります。

最終レスポンスがクロスオリジンにリダイレクトされた場合はどうなりますか？

早期に開始された接続やリソース取得が破棄され、ヒントが余計な帯域幅や接続コストに変わる可能性があります。安定したエントリーポイントでのみ有効にし、リダイレクト率を実験の測定対象に含めます。

動的なアセットバージョンはどのように処理しますか？

既知のコンテンツハッシュ化されたURLを使用するか、最終レスポンスと一致することが保証されているバージョンのみをヒントにします。バージョンが不明な場合は、推測せずに最終的なHTMLを待ちます。

なぜすべてのページで103を送信しないのですか？

サーバーの思考時間がなければ並行して進める処理が存在せず、また深い階層へのナビゲーションではすでにクリティカルなアセットがキャッシュされている可能性があるためです。エントリーページ、プロトコル、キャッシュの動作、および測定された価値に基づいて段階的に展開します。