プロンプトとスコープ
あるニュースサイトが Speculation Rules API を使用して記事詳細へのナビゲーションを高速化したいと考えています。prefetch と prerender をどのように選択するか、ルールのスコープ設定、ログイン時の副作用、鮮度、ブラウザのフォールバック、キャンセル処理、モニタリングへの対応方法を説明してください。
Chrome のドキュメントでは、prefetch は主に事前にリソースを取得するのに対し、prerender は不可視のコンテキストでページを読み込み、レンダリングすると記載されています。そのため、prerender はナビゲーションにおいてより大きなパフォーマンス向上をもたらす可能性がありますが、スクリプトを実行し、より早い段階で副作用を引き起こす可能性があります。この質問は、パフォーマンスエンジニアリング、プログレッシブエンハンスメント、およびセキュリティ境界をテストします。
面接官が評価するポイント
候補者は、戦略をナビゲーションのヒット率や副作用のリスクと結び付けられるか、セレクタ、オリジン、キャッシュ、プライバシーを制約できるか、API がサポートされていない場合や投機実行がキャンセルされた場合に通常のナビゲーションを維持できるか、そしてラボスコアだけでなく実ユーザーのデータで影響を証明できるかが評価されます。
30秒の回答フレームワーク
「確率が高く、読み取り専用で同一オリジンの記事リンクに対して、まずは保守的な prefetch から始めます。書き込みの副作用がないこと、十分なヒット率、およびリソースバジェットを確認できた後にのみ prerender を使用します。ルールからはログイン、決済、パーソナライズ、および状態変更を伴うルートを除外します。サーバー側では冪等性とプライベートキャッシュを強制し、クライアント側では document.prerendering を検出してアナリティクスを遅延させます。未対応のブラウザでは通常のリンクを使用します。アクティベーション率、LCP、INP、帯域幅、およびキャンセル率を比較します。」
ステップバイステップの詳細な回答
ステップ 1: ナビゲーションリスクを分類する
読み取り専用の記事やヘルプページを含め、チェックアウト、ログアウト、いいね、決済、強くパーソナライズされたページを除外します。Prerender はページのライフサイクルコードを実行するため、書き込みには実際のユーザーによるアクティベーションが必須でなければなりません。
ステップ 2: prefetch か prerender かを選択する
ヒット率が低い場合や副作用が不確実な場合は prefetch を使用します。確率が高く、初回描画が安定しており、CPU とメモリのバジェットが十分にある同一オリジンのページには prerender を使用します。デフォルトですべてのリンクを prerender することは絶対に避けてください。
ステップ 3: ルールとリソースコストを制限する
記事リンクにのみ一致するドキュメントルールまたはサーバールールを生成します。同時処理候補数とリソースサイズを制限します。適切なキャッシュ、Vary、および無効化の挙動を設定し、プライベートなレスポンスが誤って共有されないようにします。
ステップ 4: 副作用とログイン状態を分離する
書き込みエンドポイントは実際のインタラクションと CSRF 保護を必須とする必要があり、投機的リクエストが状態を変更してはなりません。document.prerendering が true の間はアナリティクス、広告、通知を遅延させ、アクティベーション後に重複排除されたイベントを1回送信します。プライベートキャッシュを使用するか、パーソナライズされたレスポンスを除外します。
ステップ 5: フォールバックとキャンセルを設計する
未対応のブラウザでは通常のリンクを使用します。投機実行はメモリ、ネットワーク、またはブラウザの制限によってキャンセルされる可能性があるため、ページは依然として通常通り読み込まれる必要があります。投機的なページを待つ間、クリックフィードバックをブロックしないでください。
ステップ 6: 鮮度を処理する
頻繁に編集される記事については、キャッシュの有効期間を短くし、アクティベーション時にバージョンを検証します。ETag を使用した条件付きリクエストを利用します。prerender 後にコンテンツが変更された場合は、古いコンテンツが一瞬表示されたりユーザーアクションが再実行されたりすることなく、変更可能な領域を更新します。
ステップ 7: 実ユーザーの価値を測定する
アクティベーション率、ナビゲーション待機時間、LCP、INP、CLS、帯域幅、CPU、メモリ、キャンセルの対照比較を実施します。ブラウザ、ネットワーク、デバイス、ログイン状態ごとにセグメント化します。速度は向上したもののコストやエラーが増加した場合は、ルールを狭めるか prefetch に戻します。
トレードオフと境界
ヒット率とリソースコスト
ヒット率の低い prerender は、CPU、メモリ、帯域幅を浪費します。prefetch はコストが抑えられますが得られるメリットは小さくなります。観測されたアクティベーションと定義されたバジェットからしきい値を設定します。
鮮度と瞬時のナビゲーション
キャッシュ期間を長くするとヒット率は向上しますが、コンテンツの陳腐化が進みます。静的 URL をバージョニングし、アクティベーション時に動的コンテンツを検証して変更可能な領域のみを更新します。
互換性とメンテナンス
投機実行はプログレッシブエンハンスメントレイヤーであり、通常のリンクが正規のまま維持されます。ビジネス状態の遷移を prerender のライフサイクルから独立させておきます。
障害訓練と進化
投機的なページが書き込みをトリガーする
ステージング環境で投機的リクエストをログに記録し、いいね、アナリティクス、通知に変更が生じていないことを確認します。ルールから該当ルートを削除し、書き込みを実際のアクティベーションの後に移動します。
低いヒット率がリソースを浪費する
リソースが制限されたデバイスやネットワークでは prerender を無効化し、帯域幅と INP を比較し、データによる裏付けが得られた場合にのみ小規模な prefetch 実験から prerender へと移行します。
アクティベーション前にコンテンツの有効期限が切れる
prerender とクリックの間に出版物の更新が発生する状況をシミュレートします。アクティブ化されたページに最新のタイトルと本文が表示されるよう、ETag の検証と部分更新を確認します。
よくある間違いとフォローアップ
間違い 1: すべてのリンクを prerender する
ヒット率、同時実行数、メモリのしきい値に加えて、明示的な無効化条件について質問します。
間違い 2: prerender をキャッシュとして扱う
どのスクリプトが実行され、アナリティクスやログイン状態がどのように遅延または分離されるかについて質問します。
間違い 3: Lighthouse のみを見る
実ユーザー測定において、アクティベーション、キャンセル、帯域幅がどのようにセグメント化されているかを質問します。
間違い 4: 通常のナビゲーションを考慮しない
ブラウザがサポートしていない場合や投機実行をキャンセルした場合でも、クリックが正常に機能するかどうかを質問します。
間違い 5: 鮮度を無視する
prerender とクリックの間に出版物の更新があった場合、どのように古いコンテンツを回避するかを質問します。
発展的なフォローアップと模範回答
なぜすべてのページを prerender しないのですか？
Prerender は余分なリソースを消費し、スクリプトを実行する可能性があります。バジェット内で、ヒット率が高く、読み取り専用で同一オリジンのページのみを選択します。
アナリティクスの重複をどのように防ぎますか？
document.prerendering を検出し、アクティベーションまでイベントを遅延させ、ナビゲーション識別子を用いて重複を排除します。
最適化が機能していることをどのように証明しますか？
実ユーザーを割り当て、デバイスやネットワークごとにアクティベーションナビゲーションの LCP、INP、待機時間、帯域幅、キャンセル率を比較します。