プロンプトとコンテキスト
あなたは、ファーストビュー（above-the-fold）の HTML 生成に時間がかかる E コマースのホームページを担当しています。ブラウザがクリティカルな CSS、フォント、またはスクリプトの読み込みを開始できるように、最終レスポンスの前に 103 Early Hints を送信するという提案があります。これがどのような場合に役立つか、重複ダウンロードを回避する方法、および LCP の変化を検証する方法を説明してください。HTTP/2 または HTTP/3 を介したトップレベルのナビゲーションであり、最終レスポンスでも適切な Link ヘッダーが送信されることを前提とします。
面接官が見ているポイント
- 103 を決定的なリソースリストではなく「ヒント」として説明しているか：ブラウザは接続やプリロードを行う可能性がありますが、最終レスポンスが依然として決定権（authoritative）を持ちます。
- サーバーの思考時間をオーバーラップの期間として特定できているか：サーバーが即座に 200 を返せる場合、メインレスポンスでの通常の
preloadやpreconnectの方がシンプルです。 - リソースの安定性、キャッシュ、クロスオリジンリダイレクト、ブラウザのサポート状況、プロトコルの要件を網羅しているか。
- 単にステータスコードを暗唱するのではなく、LCP、キャッシュの再利用、重複リクエスト、エラーによって検証しているか。
回答前の明確化のための質問
- 最初のバイトまでのサーバー時間はどれくらいですか？ ほぼゼロの場合、得られるオーバーラップはわずかです。まずはバックエンドまたはメインレスポンスのヒントを最適化してください。
- ヒントを出すリソースは安定的で必要不可欠なものですか？ ユーザー、テスト（実験）、または権限に依存するリソースは、早期に予測すると無駄になる可能性があります。
- これは HTTP/2+ 上のトップレベルナビゲーションですか？ ブラウザの処理はナビゲーションを中心としており、MDN は HTTP/2 以降を推奨しています。
- リソースはキャッシュ可能ですか？ キャッシュ不可のプリロードは HTML 到着後に再度ダウンロードされる可能性があり、ヒントが余計な処理になってしまいます。
30秒の回答フレームワーク
「まず、ページに有意なサーバー思考時間があり、これがクライアントが 103 をサポートしているナビゲーションであることを確認します。次に、安定的でキャッシュ可能な CSS、フォント、または接続先オリジンのみをヒントとして提供し、最終レスポンスで適切な Link ヘッダーを再度送信します。実験や権限に依存するリソースへのヒントは避けます。リリース前後で、TTFB とリソースリクエストのオーバーラップ、LCP、重複バイト数、エラー率を比較します。103 をサポートしていないクライアントは通常のレスポンスパスを使用します。」
ステップごとの詳細な回答
1. オーバーラップ期間を定量化する
103 を使用すると、サーバーが最終的な HTML を準備している間に、ブラウザが接続または取得を行えます。有効な上限は、おおよそ「サーバーの準備時間」から「最終レスポンス後にブラウザが通常リソースを発見するまでの時間」を引いたものです。サーバーが迅速に 200 を返す場合、この期間はほぼゼロになります。その場合、Chrome は通常の Link または HTML の link を推奨しています。
2. すべての HTML ヒントをコピーするのではなく、安定したリソースを選択する
Early Hints は、最終的な HTML やそのユーザー固有のバリアントが判明する前に到着します。適切な候補には、共通の CSS、共通スクリプト、フォント、クリティカルな CDN 接続が含まれます。パーソナライズされた画像、実験ブランチ、権限で保護されたリソースは HTML を待つ必要があります。実用的な場合は、リソースをヒント用の安定した部分と最終レスポンス用の動的な部分に分割します。
3. キャッシュとプロトコルを正確性の条件として扱う
最終ページは、プリロードされたリソースを再利用する必要があります。キャッシュ不可能な場合、ブラウザはヒントから 1 回ダウンロードし、HTML 解析後に再度ダウンロードする可能性があります。クロスオリジンのフォントにも、一致する crossorigin セマンティクスが必要です。古いクライアントや中間機器が 1xx レスポンスを誤って処理する可能性があるため、MDN は HTTP/2 以降で 103 を送信することを推奨しています。
4. 最終レスポンスの決定権（authoritative）を維持する
103 を無視するクライアントや、HTML のレンダリング中に判明したリソースのために、最終レスポンスで Link ヘッダーを送信し続けます。クロスオリジンのリダイレクトにより、ブラウザが初期の接続やリソースを破棄する場合があるため、103 は取り消し不可能なダウンロード命令ではありません。
5. 実際の実験を測定する
Early Hints ありと Early Hints なしの実際のナビゲーションをランダム化します。サーバーの思考時間、リソースリクエストの開始時間、LCP、重複バイト数、およびエラー率を記録します。Chrome DevTools は Early Hints のイニシエーターとキャッシュの再利用を表示しますが、テスト中はキャッシュを有効にしておく必要があります。LCP が改善しない場合は、リソースがすでにキャッシュされていたか、ヒントの到着が遅すぎたか、リダイレクトによって破棄されたか、またはサーバー時間がボトルネックになっていないかを確認してください。
6. HTTP/2 Push と比較する
103 は手がかりを提供するだけで取得の制御はブラウザに委ねますが、HTTP/2 Push は積極的にリソースを送信したため、ブラウザによってすでにキャッシュされているアイテムが重複することがよくありました。トレードオフとして、Early Hints は依然としてラウンドトリップが必要でブラウザのサポートに依存しますが、クライアントから制御を奪うことはありません。
質の高い模範回答
まずは最初のバイトまでの時間から確認します。SSR に 300 ミリ秒かかり、メインの CSS とフォントがすべてのナビゲーションで安定している場合、103 はその 300 ミリ秒とそれらの接続およびダウンロードをオーバーラップさせることができます。キャッシュ可能な安定したリソースのみをヒントにし、クロスオリジンフォントには適切な crossorigin を含め、パーソナライズされた画像や実験スクリプトは最終レスポンスに委ねます。サポートされていないクライアントが通常通りフォールバックできるように、最終レスポンスにも Link を含めます。
ステータスコードを追加するだけで成果が保証されるとは主張しません。制御されたナビゲーション実験を実行し、LCP、リクエスト開始時間、重複バイト数、クロスオリジンリダイレクト率を比較します。サーバーがすでに素早く 200 を返している場合、リソースがキャッシュ内にある場合、または最終ページがヒントを頻繁に拒否する場合は、メインレスポンスでの通常のヒント—あるいはプリロードしないこと—の方が安全です。この回答は、メリットが得られる期間、予測が外れた場合のコスト、そしてフォールバックを明確に示しています。
よくある間違い
- 間違い → 103 を 200 と同等として扱う。 なぜ失敗するか：103 は情報提供（informational）です。最終レスポンスが結果とリソースを定義します。修正方法：ヒントは無視される可能性があることを述べ、最終的な
Linkヘッダーを維持する。 - 間違い → すべての HTML
preloadを 103 にコピーする。 なぜ失敗するか：ヒントの時点ではユーザーバリアントが不明であるため、動的リソースによって帯域幅が無駄になります。修正方法：安定的で確率の高いリソースのみを選択する。 - 間違い → LCP のみを測定する。 なぜ失敗するか：キャッシュ不可のプリロードや誤った cross-origin 属性により、総バイト数を増やしながら開始時間だけ早まる可能性があります。修正方法：キャッシュの再利用、重複リクエスト、帯域幅、エラーも測定する。
- 間違い → すべての HTTP/1.1 リクエストに送信する。 なぜ失敗するか：1xx の処理は様々であり、Early Hints はナビゲーションを対象としています。修正方法：プロトコル、リクエストタイプ、クライアント機能によって制御し、通常レスポンスへのフォールバックを用意する。
フォローアップの質問と回答
最終レスポンスが別のオリジンにリダイレクトされることがよくあります。それでも 103 を送信しますか？
慎重にのみ行います。MDN および Chrome のガイダンスでは、クロスオリジンリダイレクトによってブラウザが初期の接続やリソースを破棄する可能性があると指摘されています。ヒントを安定した最終エントリポイントまたはリダイレクト後も維持される同一オリジンのリソースに限定し、リダイレクト率のしきい値を設定します。
実験グループ間で CSS が異なります。何をヒントにできますか？
すべてのグループで共有されている CSS のみをヒントにします。実験固有のチャンクは最終的な HTML に委ねます。安定した共通部分が存在しない場合は、プリロードしないでください。予測が外れた場合の帯域幅コストは、節約される待機時間を超える可能性があります。
改善がウォームキャッシュではなく 103 によるものであることをどのように証明しますか？
一致したキャッシュ状態を持つグループをランダム化し、コールドキャッシュとウォームキャッシュを個別に報告します。単一の LCP 値だけでなく、リソースリクエストとサーバー思考時間のオーバーラップを測定します。Early Hints のイニシエーター、キャッシュヒット、重複ダウンロードを調査します。
ブラウザが特定の Early Hints ディレクティブをサポートしていない場合はどうなりますか？
フォールバックとして最終的な Link と HTML 宣言を維持します。広くサポートされている preconnect から始め、対象ブラウザのマトリックスに従って preload を展開し、エラーを監視します。