問題と適用シナリオ
HTML の生成が遅く、リソースセットがユーザー、実験、または権限によって異なります。明示的な信頼度しきい値、プライバシー境界、および誤予測制御を備え、ルートおよびコホートごとに 103 Early Hints を生成する予測ポリシーを設計してください。
これは、バックエンド、エッジゲートウェイ、およびパフォーマンスエンジニアリングの面接に適しています。リクエストは最終的に 2xx 応答またはリダイレクトを返し、リソースセットはユーザー、実験、または権限によって異なる場合があると想定します。
面接官が評価しているポイント
- 103 が最終的なレスポンスやビジネス状態ではなく、暫定的なヒントであることを理解しているか。
- リソースの確実性、プロトコルバージョン、およびクロスオリジンの挙動に基づいて送信かスキップかを判断しているか。
- ヒントと最終レスポンスの不一致、リダイレクト、および CSP 境界を処理できるか。
- サーバー時間だけでなく、実際のブラウザ、キャッシュ、階層化されたプロトコルメトリクスを使用しているか。
回答前の明確化のための質問
- 最終的な HTML 生成前にリソースは判明していますか？不確実性があると投機的なダウンロードが無駄になります。
- 接続は HTTP/2 以降ですか？レガシーな HTTP/1.1 クライアントは情報レスポンスを誤って処理する可能性があります。
- どのリソースがヒントに値しますか？クリティカルな CSS、フォント、接続のウォームアップは、優先度の低い画像とは得られる効果が異なります。
- クロスオリジンリダイレクト、CSP、ユーザーコホート、または権限の違いはありますか？それぞれがヒントの有効性を変化させます。
30秒で答えるフレームワーク
「私は 103 を破棄可能なパフォーマンスヒントとして扱い、最終レスポンスに含まれる可能性が高い高信頼度の Link リソースのみを送信します。HTTP/2 以降を条件とし、CDN/オリジン境界でリストを導出し、リダイレクトやユーザー固有のリソースによって予測が不確実になる場合はスキップします。最終レスポンスには依然として決定権を持つ Link と CSP が含まれ、ビジネスロジックが 103 に依存することはありません。カナリア環境では、到達率、リードタイム、有用なプリロード率、重複ダウンロード、エラーを測定し、ユーザーに見えるメリットが得られない場合はオフにします。」
ステップごとの詳細解説
1. ビジネスレスポンスからヒントを切り離す
RFC 8297 は 103 を情報レスポンスとして定義しています。クライアントは待機中にヘッダーを投機的に処理できますが、それらを最終的なメタデータとして扱ってはなりません。パフォーマンスヒントのみを送信し、認証、価格設定、または成功状態を送信してはなりません。プロキシが 103 を破棄した場合でも、最終レスポンスが正しく保たれる必要があります。
2. 確実性の高い Link ヘッダーを選択する
ファーストビュー（above-the-fold）の CSS、フォント、または固定 CDN への preconnect を優先します。コホート、権限、または実験によってリソースセットが変わる場合は、安全な積集合（共通部分）を計算するか、ヒントをスキップします。ヒントは強制ダウンロードではありません。as、CORS、および CSP が依然としてフェッチを制御します。
3. プロトコルおよびリダイレクトのゲートを設定する
互換性と安全性のために、HTTP/2 以降をデフォルトのゲートとします。リクエストがクロスオリジンリダイレクトで終わる場合、ブラウザは最初の 103 を破棄することがあります。また、ゲートウェイが情報レスポンスをマージまたは順序変更することもあります。103 が最終レスポンスと誤認されないよう、カナリア環境でプロキシチェーンをテストしてください。
4. CSP と最終レスポンスの乖離を処理する
103 は投機的なロードを制限する CSP を保持する場合がありますが、最終レスポンスが依然として決定権を持ちます。サーバーが後から誤ったリソースを発見した場合、クライアントはすでにそれを開始している可能性があります。ヒントはリスクが低く、キャッシュ可能で、安全に破棄できるアセットに限定してください。最終的な CSP をバイパスするために 103 を使用してはなりません。
5. 階層化されたメトリクスで検証する
103 のないコントロールグループを維持し、実験では HTTP/2 以降にのみ有効にします。103 の到達率、リソースのリードタイム、有用なプリロード比率、重複リクエスト、最終的な LCP、帯域幅、およびエラーを測定します。キャッシュヒット、クロスオリジンリダイレクト、およびデバイス別に分析します。TTFB が改善しても LCP が改善しない場合はロールバックします。
質の高い模範解答
私はまず、103 がパフォーマンスヒントのみを伝達し、最終レスポンスがそれに依存しないことを確認します。HTTP/2 以降の場合、信頼性の高いファーストビューの CSS、フォント、または固定 CDN 接続のみをヒントとして送信します。ユーザーコホート、権限、またはクロスオリジンリダイレクトによってリソースセットが不確実になる場合はスキップします。ゲートウェイとブラウザのカナリアテストで情報レスポンスが最終的なものとして扱われないことを実証する一方で、最終レスポンスでは決定権を持つ Link と CSP を繰り返します。キャッシュおよびデバイスごとに到達率、有用なヒット率、重複ダウンロード、LCP、帯域幅、エラーを比較します。サーバーの TTFB のみが改善する場合は、Early Hints を無効にします。
よくある間違い
- 症状: 103 を成功レスポンスとして扱う。失敗する理由: ビジネスの完了セマンティクスを持たず、破棄される可能性があるため。対策: 最終レスポンスで認証、ステータス、およびボディを完了する。
- 症状: すべてのリソースをプリロードする。失敗する理由: 動的ページでは無駄なダウンロード、帯域幅の競合、およびキャッシュの汚染が発生するため。対策: 確実性の高いアセットのみをヒントにし、有用なヒットのしきい値を設定する。
- 症状: HTTP/1.1 とプロキシチェーンを無視する。失敗する理由: 古いクライアントが情報レスポンスを誤って処理する可能性があるため。対策: プロトコルゲート、プロキシテスト、およびキルスイッチを追加する。
- 症状: TTFB のみを測定する。失敗する理由: 早期のヒントがレンダリングを改善しない可能性があり、帯域幅を奪い合う可能性があるため。対策: LCP、重複、帯域幅、およびエラーを測定する。
フォローアップの質問と回答
ヒントを出したリソースが最終的に不要になった場合はどうなりますか？
ヒントは安全に投機できるアセットに限定し、無効なダウンロード率に上限を設けます。103 はリソースが使用されることを保証できません。
クロスオリジンリダイレクトをまたいで 103 を送信し続けるべきですか？
デフォルトではスキップするか、最終ターゲットに関係のない安全な接続ウォームアップに制限します。ブラウザが最初の 103 を破棄したり、プロキシがレスポンスの順序を変更したりする場合があるため、エンドツーエンドのテストに基づいて判断します。
最終的な Link は 103 の Link と異なっていてもよいですか？
はい。103 はヒントであり、最終レスポンスが決定権を持ちます。大きな不一致は予測精度が低いことを示すため、ヒントのセットを絞り込み、重複を監視します。
103 からのユーザー情報の漏洩をどのように防ぎますか？
認証情報、コホート、または機密性の高い URL を含めないでください。最終的な CSP と認証チェックを有効に保ちながら、リスクの低い公開アセットセットからヒントを生成します。
通常の HTML プリロードが 103 よりも優れているのはどのような場合ですか？
アセットが HTML 生成後にしか判明しない場合や、情報レスポンスを確実に配信できない場合は、最終 HTML プリロードを使用します。103 は、サーバーが HTML を生成するよりも早くアセットセットを把握できる場合に有用です。