設問とコンテキスト
オリジンは最終レスポンスの前にLinkを含む103を送出できますが、本番トラフィックはTLSターミネーター、ロードバランサー、リバースプロキシ、CDNを通過します。1xxレスポンスがサポート対象ブラウザに到達することを証明するエンドツーエンドの互換性マトリクス、カナリアスイッチ、透過的フォールバック、可観測性計画を設計してください。
面接官がテストするポイント
優れた回答では、中間レスポンスと最終レスポンスを区別し、確度の高いリソースを選択し、HTTP/2、HTTP/3、プロキシ、CDNについて議論し、103が無視された場合に透過的なフォールバックを提供します。また、誤ったヒント、キャッシュやクロスオリジンのリスク、実ユーザーのメリットの測定についてもカバーします。
明確にすべき質問
- サーバーはどれくらい早期に、どの程度の確度でリソースセットを把握できるか？
- クライアント、TLSターミネーター、リバースプロキシ、CDNは1xxレスポンスを維持するか？
- リソースはバージョニングされており、クロスオリジンの
preconnectは必要か？ - ターゲットはLCPか、TTFB後のギャップか、それともCSSやフォントの早期発見か？
- エラー、キャッシュヒット、103非対応クライアントはどのように観測・処理されるか？
30秒での回答
最終レスポンスの前に、確度の高い少数のLinkヒントを含む103を送信し、その後に通常の最終レスポンスを送信します。リソースにはバージョニングされたURLを使用し、クロスオリジン接続は信頼できるドメインに制限します。最終HTMLが依然としてリソースを参照しているため、103が無視されてもページの正確性は保たれなければなりません。カバレッジを拡大する前に、トレースとRUMを使用して、対応パスと非対応パスにおけるLCP、発見時間、重複バイト数、エラーを比較します。
ステップごとの詳細な回答
ステップ 1: タイミングを理解する
103は情報提供のための中間レスポンス（interim response）であり、必ず最終レスポンスが後に続く必要があります。サーバーが処理を行っている間に、Link: </app.css>; rel=preload; as=styleなどのヒントを運ぶことができます。クライアントがそれらに基づいて動作するかどうかは、プロトコルスタック、ブラウザ、ポリシーに依存します。ビジネスロジックの正しさがそれらに依存してはなりません。
ステップ 2: リソースを選択する
ほぼ確実で、適切なサイズであり、安定しているリソース（クリティカルCSS、フォント、preconnectなど）のみをヒントとして提供します。確率の低い画像、パーソナライズされたスクリプト、権限に依存するアセットなどは、帯域幅を浪費したり誤った対象をプリフェッチしたりするため避けます。
HTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8ステップ 3: 中間者とフォールバックを検証する
実際のロードバランサー、TLS終端、CDN、ブラウザパスにおいて、103の転送や処理をテストします。103を無視するクライアントであっても、最終レスポンスで通常の参照を受け取る必要があります。ページが中間メッセージに依存するような設計には絶対にしないでください。
ステップ 4: キャッシュとセキュリティの影響を制限する
ヒントは現在のリクエストコンテキストと一致している必要があります。コンテンツハッシュ化されたURLと正しいCache-Controlを使用し、ユーザー入力から任意のLink値を構築しないでください。クロスオリジンのpreconnectは接続の意図を露呈しリソースを消費するため、信頼できるオリジンと必要なパラメータのみを許可します。
ステップ 5: 誤ったプリロードを回避する
認証、実験、地理的位置によってリソースセットが変化する場合は、確度が高まるまで待つか、ヒントを省略します。最終レスポンスでヒントされたリソースが参照されなくなった場合、ブラウザが無駄なダウンロードを行った可能性があるため、そのコストを測定します。
ステップ 6: 観測とロールバック
103が送信されたか、最終ステータス、発見時間、キャッシュヒット、重複バイト数、プロキシごとの差異をログに記録します。フィーチャーフラグを使用して、ルートまたはトラフィックごとにロールアウトを制御します。帯域幅、エラー、ユーザーメトリクスが悪化した場合はヒントを無効化します。最終HTMLは変更されないまま残ります。
トレードオフと境界条件
103とpreloadリンクの比較
103はヒントのタイミングを前倒しにしますが、通常のHTML内のlinkが依然として最終的な信頼できる参照（authoritative reference）です。重複ダウンロードや優先度の競合を避けるため、これらは一致している必要があります。ヒントはCSP、整合性（integrity）、パーミッションポリシーの代替にはなりません。
プロトコルバージョンと中間者
RFC 8297がセマンティクスを定義していますが、プロキシチェーンが1xxレスポンスをドロップする場合があります。実際のHTTP/2、HTTP/3、CDN、クライアントの組み合わせを測定し、103を使用しないベースラインを保持してください。
ロールアウト計画と検証
段階的リリース
1つのルートで静的CSSから開始し、最終レスポンスと参照を検証してから、フォントや安全なpreconnectに拡大します。キルスイッチを維持し、初回訪問、キャッシュ済み訪問、低速ネットワークを分けて比較します。
メトリクスと合否判定
LCP、リソース発見時間、重複バイト数、キャッシュヒット率、4xx/5xx、帯域幅を追跡します。ブラウザツール、エッジログ、RUMを照合します。サーバーの送信ログだけではクライアントの動作を証明できません。
よくある間違いとフォローアップ
間違い: 103を最終的な成功として扱うこと
ビジネス状態、キャッシング、エラー処理には最終レスポンスが使用されます。103が失われてもリクエストが失敗してはなりません。
間違い: すべてのリソースをヒントすること
確度の低いアセットは帯域幅と接続を浪費します。小さく安定したクリティカルセットを優先してください。
間違い: 直接のローカルパスのみをテストすること
本番環境のCDN、プロキシ、TLS終端は1xxの動作を変更する可能性があります。エンドツーエンドでテストしてください。
フォローアップ: 103がサポートされていない場合はどうなるか？
通常の最終HTMLの参照と既存のキャッシングに依存します。正確性は維持され、潜在的なパフォーマンス向上が失われるだけです。
フォローアップ: 維持する価値があることをどのように証明するか？
キャッシュとネットワーク条件でセグメント化し、LCP、発見時間、重複バイト数、エラー、帯域幅に関するスプリット実験を実行します。