【入門編】 requestIdleCallbackによる低優先度タスクの実行 – Webブラウザの仕組み実践ガイド

こんにちは！日々Webサイトやアプリの開発に励んでいるみなさん、本当にお疲れ様です。

「リフレッシュレート」や「メインスレッド」、「リフロー」なんていう難しい言葉を耳にして、「うわぁ、難しそう…」と身構えてしまっていませんか？
大丈夫ですよ、その気持ち、とってもよく分かります。フロントエンドの世界は覚えることが多くて、時に目が回りそうになりますよね。

でも、安心してください。
今日は、Webブラウザという「超多忙な働き者」の頭の中をのぞき見しながら、「手の空いたスキマ時間に、ちょっとこの仕事をお願いね！」と賢くタスクを頼む魔法の道具、`requestIdleCallback`（リクエスト・アイドル・コールバック）について、どこよりも優しく、かつ現場のリアルな知見を交えてお話しします。

この記事を読み終える頃には、ブラウザの気持ちが手にとるように分かり、もっと仲良くなれているはずです。それでは、一緒に温かいお茶でも飲みながら進めていきましょう！

—

1. ブラウザの「メインスレッド」は、超人気店のワンオペ・シェフ！

Webブラウザが画面を描画する仕組みを理解するために、まずは身近な例え話から始めましょう。

ブラウザの中には、「メインスレッド」という名前の、すべての作業を仕切る「メインシェフ」が1人だけいます。
このシェフは、ものすごく優秀なのですが、残念なことに「一度にひとつのことしかできない（シングルスレッド）」という頑固な職人でもあります。

シェフの仕事は、信じられないほど過密スケジュールです。

1. 注文を受ける：ユーザーが画面をクリックした、スクロールした（JavaScriptの実行）
2. レシピ（設計図）を計算する：要素の大きさや位置を決める（リフロー / レイアウト）
3. 盛り付けをする：色を塗ったり、文字を描いたりする（リペイント）
4. お皿をお客さんのテーブルに運ぶ：描いた絵を重ね合わせて画面に出力する（コンポジット合成）

これだけのお仕事を、なんと「1秒間に60回（1回あたり約16.7ミリ秒）」という超ハイスピードで繰り返しています。お客さん（ユーザー）に「お、このサイト、動きがなめらかで気持ちいいな！」と感じてもらうためには、この「16.7ミリ秒の壁」を絶対に守らなければなりません。

もし、ここで「重いお仕事」を頼んでしまったら…？

そんな超多忙なシェフに、あなたが「ねえシェフ、今すぐ『過去3年間の売上データの分析（重いデータ処理）』と『顧客リスト1万件の間違い探し（ログの送信）』をやって！」と頼んだらどうなるでしょう？

シェフは真面目なので、その場でデータ分析を始めてしまいます。その間、料理を作る手は完全に止まります。
結果として、お皿がテーブルに届くのが遅れ、画面はピタッと止まり（カクつき）、ユーザーは「あれ？このサイト固まった？」とイライラしてしまいます。

これを現場では「フレーム落ち（Jank）」と呼びます。

—

2. そこで登場するのが `requestIdleCallback`！

「じゃあ、重い処理はいつやればいいの？」

その答えこそが、今回ご紹介する `requestIdleCallback` です！

これはシェフに対して、
「シェフ、料理（画面の描画）が一段落して、次の注文が入るまで『ちょっと手が空いたスキマ時間（アイドル時間）』ができたら、この作業を少しずつ進めておいてね」
と、ものすごく気遣いのある頼み方をする方法です。

【一般的な頼み方（今すぐやって！）】
[JavaScript実行（重い処理）] ───(シェフがパニック！)───> [描画が遅れて画面がカクつく]

【requestIdleCallback（空いた時間でいいよ）】
[描画処理] -> [余ったスキマ時間] -> [ちょっとだけ重い処理を進める] -> [次の描画処理]

これなら、画面のなめらかさ（描画パフォーマンス）を一切邪魔することなく、裏側で賢く重い処理を終わらせることができます。ブラウザにとっても、開発者にとっても、まさにWin-Winの仕組みなのです。

—

3. 「スキマ時間（アイドル時間）」って具体的にどれくらい？

ブラウザのシェフが「料理を盛り付け終わってから、次の16.7ミリ秒のタイマーが鳴るまで」の、ほんの数ミリ秒の時間が「アイドル時間」です。

`requestIdleCallback` を使うと、ブラウザは私たちに「今なら、あと `4.5ミリ秒` だけ手が空いてるよ！」と、残り時間を教えてくれます。

私たちはその残り時間を見ながら、「よし、じゃあこのデータを3件だけ処理しよう。残りはまた次のスキマ時間にお願いね」と、仕事を細切れにして進めていくのです。

—

4. 実際にコードを書いてみよう！

それでは、実際にエディタに貼り付けてブラウザで動かせる、丁寧なサンプルコードを見てみましょう。
「大量のデータを、ブラウザのスキマ時間を見つけながら少しずつ処理する」という、実務でもよく使うプロの書き方です。

// 処理したい大量のデータ（例：1,000件のユーザーデータ）
const massiveTasks = Array.from({ length: 1000 }, (_, i) => `タスク #${i + 1}`);

// スキマ時間を使ってタスクを少しずつ処理する関数
function processTasksWithIdle(deadline) {

// 「まだ処理するタスクが残っていて」かつ
// 「ブラウザの残り時間が1ミリ秒以上ある」か「何らかの理由で期限切れ（didTimeout）」の場合にループします
while (massiveTasks.length > 0 && (deadline.timeRemaining() > 1 || deadline.didTimeout)) {

// 配列から先頭のタスクを1つ取り出す
const task = massiveTasks.shift();

// ここで実際の重い処理（データの解析、ログの準備など）を行います
executeHeavyTask(task);
}

// もし、まだタスクが残っているなら…
if (massiveTasks.length > 0) {
console.log(`【休憩】残り時間は ${deadline.timeRemaining().toFixed(2)}ms。一度手を止めて、次のスキマ時間に持ち越します。`);

// 次の「手の空いた時間」に、この関数をもう一度実行するよう予約します（再帰呼び出し）
requestIdleCallback(processTasksWithIdle);
} else {
console.log(“【完了】すべてのタスクを無事に処理し終えました！お疲れ様でした。”);
}
}

// 模擬的な「重い処理」を行う関数
function executeHeavyTask(taskName) {
// コンソールに処理中のログを出力します
console.log(`[実行中]: ${taskName} を処理しています…`);

// 意図的に少しだけCPUに負荷をかける（実務ではここにデータ処理が入ります）
const start = performance.now();
while (performance.now() – start < 0.5) { // 0.5ミリ秒だけあえて待つ（処理をシミュレート） } } // --- 実行の引き金（トリガー） --- console.log("大忙しのメインスレッドを邪魔しないように、タスクの処理を開始します..."); // ブラウザに「手が空いたら呼んでね！」とお願いする requestIdleCallback(processTasksWithIdle, { timeout: 2000 }); // ※ timeout: 2000 は「最悪、2秒経っても手が空かなかったら、強制的に実行してね」という保険です

コードの優しい解説：

`deadline.timeRemaining()`：これが「今、何ミリ秒余っているか」をリアルタイムに教えてくれる魔法のメソッドです。
`deadline.didTimeout`：もし「何が何でも2秒以内にやって！」と設定した期限（timeout）が過ぎてしまった場合に `true` になり、「大急ぎで終わらせるモード」に切り替わります。
タスクを一度に全部やらず、`shift()` で1つずつ取り出し、時間がなくなったら `requestIdleCallback(processTasksWithIdle)` で「次のスキマ時間の予約チケット」を取って一旦休憩する…という、ブラウザへの素晴らしい気配りをしています。

—

5. ここだけは注意！つまずきやすいポイント

とても便利な `requestIdleCallback` ですが、使う上で絶対にやってはいけないお約束がいくつかあります。ここさえ押さえれば、あなたも立派なブラウザマスターです！

注意点①：この中で「DOMの操作（画面の書き換え）」は絶対にNG！

「スキマ時間の中で、ついでにHTMLを書き換えて画面を更新しちゃおう！」…これは絶対にダメです。

なぜなら、HTMLを書き換える（DOMを操作する）と、ブラウザのシェフは「ああっ！盛り付け（レイアウト・リフロー）をやり直さなきゃ！」とパニックになり、せっかく空いていた時間をすべて使い果たしてしまいます。

解決策：

データの計算や分析だけを `requestIdleCallback` で行い、「画面を書き換える（DOM操作）」ことだけは `requestAnimationFrame`（描画直前に実行してくれる別の仕組み）にお任せするようにしましょう。

注意点②：Safariなどのブラウザでのサポート状況

実は、この `requestIdleCallback` は非常に強力なのですが、一部のブラウザ（少し古い環境や、Safariなど）では標準でサポートされていないことがあります。

「えっ、使えないブラウザがあるなら諦めるしかないの…？」

大丈夫ですよ、がっかりしないでください！
現場のエンジニアたちは、もし使えないブラウザだった場合は「今すぐ実行する（`setTimeout` で代用する）」という、簡単な「お守り（ポリフィル / 代替処理）」をコードの先頭に数行書いて対策しています。

// もしブラウザが requestIdleCallback をサポートしていなかったら、
// 簡易的に setTimeout（4ミリ秒後に実行）で代用する、というお守りコードです
window.requestIdleCallback = window.requestIdleCallback || function (handler) {
const startTime = Date.now();
return setTimeout(function () {
handler({
didTimeout: false,
timeRemaining: function () {
// 簡易的に「残り時間」を計算して返します（最大50ms）
return Math.max(0, 50 – (Date.now() – startTime));
}
});
}, 1);
};

このお守りをコードの最初に書いておけば、どのブラウザでもエラーにならず、安心して動かすことができますよ。

—

6. まとめ：ブラウザに思いやりを持つことが、最高のユーザー体験への第一歩

Webブラウザの仕組みを知ることは、決して難しいお勉強ではありません。
それは、裏側で必死に動いてくれている「メインスレッドという名のシェフへの思いやり」を持つことなのです。

一気に重い仕事を押し付けない。
スキマ時間を見つけて、少しずつお願いする（`requestIdleCallback`）。
画面をキレイに彩る仕事は、最高のタイミングでお任せする。

この思いやりの積み重ねが、ユーザーが触ったときに「うわっ、このサイトすごくサクサク動いて心地いい！」と感じる、最高のWebサイトを作る秘訣です。

最初から完璧に使いこなせなくても、まったく問題ありません。
「あ、今ブラウザのシェフが忙しそうだな」と頭の中で想像できるようになっただけでも、あなたはフロントエンドの大きな一歩を踏み出していますよ。

これからも、焦らず一歩ずつ、楽しみながら学んでいきましょう。応援しています！