1. 質問とコンテキスト
この質問は、フロントエンドのパフォーマンスとブラウザの基本原理をテストします。ページは、入力、スクロール、アニメーションを処理しながら、アナリティクス、優先度の低い計算、または遅延処理も並行して処理します。アイドルコールバックが何を解決するのか、無期限の待機をどのように回避するのか、そしてなぜ DOM の反映（コミット）が通常 requestAnimationFrame に属するのかを説明してください。
2. 面接官が評価しているポイント
requestIdleCallbackがブラウザのアイドル期間中に低優先度のタスクをスケジューリングするものであり、スレッドをプリエンプト（横取り）するものではないことを理解しているか。- 処理のチャンク化に
IdleDeadline.timeRemaining()を使用し、作業に期限がある場合にtimeoutを設定しているか。 - ブラウザサポートが限定的であることを認識し、明示的なフォールバックセマンティクスを持つ機能検出を設計しているか。
- 計算、ネットワーク送信、DOM 変更、アニメーションのタイミングを分離し、インタラクションへの影響を測定しているか。
Coursera のフロントエンド面接ガイドでは、パフォーマンスの最適化、本番環境のメトリクス、およびトレードオフを主要な評価分野として挙げています。MDN では、requestIdleCallback() をアイドル期間中のバックグラウンド処理として説明しており、その timeout オプションは必要な作業の過度な待機を防ぐことができますが、インタラクションを損なう可能性があります。Chrome の公式サンプルでは、アイドル時の計算と次のフレームでの DOM 更新をさらに分離しています。
3. 回答前の明確化のための質問
- その作業は遅延可能ですか？アナリティクスバッチ、プリフェッチ、および必須のユーザーフィードバックにはどのような期限が適用されますか？
- コールバックは DOM を変更しますか、状態を更新しますか、ストレージに書き込みますか、それともネットワークリクエストの送信のみを行いますか？
- 対象のブラウザはその API をサポートしていますか？サポートしていない場合、作業は遅延させるべきですか、即座に実行すべきですか、それとも破棄すべきですか？
- どのメトリクスが保護対象ですか：入力遅延、ロングタスク、アニメーションの滑らかさ、またはアナリティクスの配信ですか？
4. 30秒の回答フレームワーク
私は作業を「破棄可能」「遅延可能」「必須」に分類します。小さな非クリティカルな計算や送信キューに対しては、利用可能な timeRemaining() の予算内で requestIdleCallback を使用し、期限が重要な場合にのみ timeout を追加します。コールバックは予測不可能な DOM 変更を行うのではなくデータを準備し、次の requestAnimationFrame で可視の変更をコミットします。API を機能検出し、フォールバックでもキャンセル、有効期限、配信のセマンティクスを維持し、入力遅延、ロングタスク、およびビジネス上の完了率を測定します。
5. ステップごとの詳細解説
ステップ 1: 作業がアイドル時間に属するかどうかを判断する
ユーザーフィードバック、アニメーション、およびクリティカルなレンダリングをアイドル時間に依存させることはできません。アナリティクスのバッチ処理、非クリティカルなプリフェッチ、スライスされたインデックス作成、およびバックグラウンドでのシリアライズは待機可能です。期限までに完了しなければならない作業には timeout が必要ですが、タイムアウトによる実行パスはインタラクションと競合する可能性があります。そのコストが許容できない場合は、バッチを小さくするか作業を分割してください。
ステップ 2: 予算内で作業をチャンク化する
コールバックは deadline を受け取ります。timeRemaining() に収まる小さなバッチのみを処理し、作業が残っている場合は別のコールバックをキューに追加します。すべてのイベントが別のコールバックをスケジュールしないように、重複排除マーカーを使用します。ルート変更、アンマウント、または新しい結果バージョンが発生した場合はキューに入れられた作業をキャンセルし、古い結果がページを更新しないようにします。
ステップ 3: 計算、ネットワーク、DOM タイミングを分離する
アイドルコールバックは、データの準備、シリアライズ、または送信のエンキューを行うことができますが、ネットワークリクエスト自体は継続的なアイドル予算を保証しません。DOM の書き込みは予測不可能なレイアウトやペイントを引き起こす可能性があるため、アイドル時間中に計算またはフラグメントの構築を行い、requestAnimationFrame で可視の変更をコミットします。計算が依然として CPU 負荷の高いままである場合は、際限なくスライスするよりも Worker を使用する方がメインスレッドを確実に分離できます。
ステップ 4: 互換性と測定の設計
API を機能検出し、ネイティブのスケジューリング、タイマー、またはメッセージチャネルを選択します。フォールバックがネイティブのアイドルセマンティクスを持っていると主張してはいけません。遅延させるのか、即座に実行するのか、それともオプションの作業を破棄するのかを明記してください。キューの長さ、待機時間、タイムアウト回数、キャンセルヒット数、入力遅延、ロングタスクを記録し、変更前後の実ユーザーデータを比較します。
6. 高品質な回答例
まず、その作業が現在のインタラクションに影響を与えるかどうか、そしていつまでに完了する必要があるかを尋ねます。アナリティクス、非クリティカルなプリフェッチ、およびスライス可能なシリアライズには requestIdleCallback を使用できますが、入力フィードバック、アニメーション、およびクリティカルなレンダリングはアイドル時間を待つことができません。
timeRemaining() が不十分になるまで小さなバッチを処理します。実際のビジネス上の期限があるキューにのみ timeout を設定し、タイムアウトによる実行パスがジャンク（カクつき）を引き起こす可能性があることを許容します。コールバックでデータを準備し、requestAnimationFrame で DOM の変更をコミットします。アンマウントや新しい結果バージョンによってキューをキャンセルし、古い処理が書き戻されないようにします。
MDN ではサポートが限定的と記載されているため、機能検出を行います。ネイティブサポートがない場合は、タイマーやメッセージチャネルで遅延させるか、製品要件に応じてオプションの作業を破棄しつつ、同様の有効期限ルールを維持します。最後に、入力遅延、ロングタスク、キュー待機時間、タイムアウト回数、およびアナリティクス配信を測定して、ユーザー体験が向上したかどうかを検証します。
7. よくある失敗パターン
- アイドルコールバックをバックグラウンドスレッドとして扱うこと。依然としてメインスレッドで実行されるため、長い同期コードは入力をブロックします。
- 短い
timeoutを無条件に設定すること。タイムアウトによって、低優先度の作業がインタラクションの競合のバーストに変わります。 - アイドルコールバック内で大規模な DOM 変更を実行すること。予測不可能なレイアウトとペイントによって利点が打ち消される可能性があります。
- 機能検出をスキップし、限定的な API サポートを正しく動作するための前提条件にしてしまうこと。
- 合流（coalescing）、重複排除、キャンセル、または結果バージョンのチェックを行わずに、イベントごとにスケジュールすること。
8. フォローアップの質問と回答
フォローアップ 1: アイドル時間がない場合、コールバックは永久に待機する可能性がありますか？
timeout がない場合、必要な作業が長期間待機する可能性があります。期限のある作業にはタイムアウトを設定し、バッチを減らすか、タイムアウトパスでより直接的なスケジューラを選択してください。入力応答を犠牲にする代わりに、破棄可能な作業を期限切れにさせます。
フォローアップ 2: なぜ requestIdleCallback 内で DOM を更新してはいけないのですか？
DOM の変更には予測不可能なレイアウト、ペイント、コンポジットのコストが伴い、アイドルの予算を超える可能性があります。アイドル時間中に計算またはフラグメントの構築を行い、requestAnimationFrame でコミットし、ロングタスクと入力遅延の測定によって検証します。
フォローアップ 3: Worker はどのような場合に使用すべきですか？
チャンク化した後も、継続的な CPU 負荷の高い計算がメインスレッドを占有している場合に Worker を使用します。Worker にはシリアライズ、通信、キャンセルのコストが伴います。小さな遅延可能な作業であれば、アイドルコールバックを使用する方がシンプルです。