時間のかかるタスクを最適化する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

「メインスレッドをブロックしない」や「長いタスクを分割する」とよく言われますが、これらのことを意味するのでしょうか。

Jeremy Wagner

Brendan Kenny

公開日: 2022 年 9 月 30 日、最終更新日: 2024 年 12 月 19 日

JavaScript アプリの高速化に関する一般的なアドバイスは、次のアドバイスに集約されます。

• 「メインスレッドをブロックしないでください。」
• 「長いタスクを分割する」

これは良いアドバイスですが、どのような作業が必要になるのでしょうか？JavaScript を減らすことは良いことですが、レスポンシブなユーザー インターフェースに自動的につながるのでしょうか？場合によっては、

JavaScript のタスクを最適化する方法を理解するには、まずタスクとブラウザがタスクを処理する方法について理解する必要があります。

タスクとは

タスクとは、ブラウザが行う個別の作業のことです。レンダリング、HTML と CSS の解析、JavaScript の実行など、直接制御できない作業も含まれます。これらのタスクの中で、最も大きなソースは、作成する JavaScript です。

JavaScript に関連するタスクは、次の 2 つの方法でパフォーマンスに影響します。

• ブラウザが起動時に JavaScript ファイルをダウンロードすると、その JavaScript を解析してコンパイルするタスクがキューに追加され、後で実行できるようにします。
• ページのライフサイクルの他のタイミングでは、イベント ハンドラによるインタラクションへの応答、JavaScript 駆動のアニメーション、アナリティクスの収集などのバックグラウンド アクティビティで JavaScript が実行されるときにタスクがキューに追加されます。

これらの処理はすべて、ウェブワーカーなどの API を除き、メインスレッドで実行されます。

メインスレッドとは

メインスレッドは、ブラウザで実行されるほとんどのタスクと、記述したほとんどの JavaScript が実行されるスレッドです。

メインスレッドが処理できるのは、一度に 1 つのタスクだけです。50 ミリ秒を超えるタスクは長いタスクです。50 ミリ秒を超えるタスクの場合、タスクの合計時間から 50 ミリ秒を差し引いたものが、タスクのブロック期間と呼ばれます。

ブラウザは、長さの長いタスクの実行中に操作が行われないようにブロックしますが、タスクの実行時間が長すぎない限り、ユーザーは気付かないでしょう。ただし、長時間のタスクが多数あるときにユーザーがページを操作しようとすると、ユーザー インターフェースが応答しなくなり、メインスレッドが長時間ブロックされている場合は、破損する可能性もあります。

メインスレッドが長時間ブロックされないようにするには、長いタスクを複数の小さなタスクに分割します。

これは、タスクが分割されると、ブラウザは優先度の高い作業（ユーザー操作など）に、より迅速に対応できるため重要です。その後、残りのタスクが完了まで実行され、最初にキューに追加した作業が確実に完了します。

上の図の上部では、ユーザー操作によってキューに追加されたイベント ハンドラが、開始前に長時間のタスクを 1 つ待機しなければならず、操作が遅延しています。このシナリオでは、ユーザーは遅延に気付いた可能性があります。下部では、イベント ハンドラの実行がより早く開始されるため、操作が即時に行われたように感じることがあります。

タスクを分割することが重要な理由がわかったところで、JavaScript で分割する方法について学びましょう。

タスク管理戦略

ソフトウェア アーキテクチャに関する一般的なアドバイスは、作業を小さな関数に分割することです。

function saveSettings () {
  validateForm();
  showSpinner();
  saveToDatabase();
  updateUI();
  sendAnalytics();
}

この例では、saveSettings() という関数があり、5 つの関数を呼び出して、フォームの検証、スピナーの表示、アプリケーション バックエンドへのデータ送信、ユーザー インターフェースの更新、アナリティクスの送信を行います。

概念的には、saveSettings() は適切に設計されています。これらの関数のいずれかをデバッグする必要がある場合は、プロジェクト ツリーを走査して各関数の処理内容を確認できます。このように作業を分割することで、プロジェクトのナビゲーションとメンテナンスが容易になります。

ただし、これらの関数は saveSettings() 関数内で実行されるため、JavaScript ではこれらの関数を個別のタスクとして実行しません。つまり、5 つの関数はすべて 1 つのタスクとして実行されます。

最良の場合でも、これらの関数の 1 つだけで、タスクの合計時間に 50 ミリ秒以上を費やす可能性があります。最悪の場合、特にリソースに制約のあるデバイスでは、これらのタスクの多くが大幅に長時間実行される可能性があります。

この場合、saveSettings() はユーザーのクリックによってトリガーされます。関数全体の実行が完了するまでブラウザはレスポンスを表示できないため、この長時間のタスクの結果として、UI が遅く、応答しなくなるため、Interaction to Next Paint（INP）が低下すると測定されます。

コードの実行を手動で遅らせる

優先度の低いタスクよりも、ユーザー向けの重要なタスクと UI レスポンスが優先されるようにするには、作業を短時間中断してブラウザに優先度の高いタスクを実行する機会を与えることで、メインスレッドに譲渡できます。

タスクを小さなタスクに分割するためにデベロッパーが使用してきた方法の 1 つに setTimeout() があります。この手法では、関数を setTimeout() に渡します。これにより、0 のタイムアウトを指定しても、コールバックの実行が別のタスクに延期されます。

function saveSettings () {
  // Do critical work that is user-visible:
  validateForm();
  showSpinner();
  updateUI();

  // Defer work that isn't user-visible to a separate task:
  setTimeout(() => {
    saveToDatabase();
    sendAnalytics();
  }, 0);
}

これは「yield」と呼ばれ、順番に実行する必要がある一連の関数に最適です。

ただし、コードが常にこのように整理されているとは限りません。たとえば、ループで処理する必要がある大量のデータがあり、反復処理が多いと、そのタスクに非常に時間がかかる場合があります。

function processData () {
  for (const item of largeDataArray) {
    // Process the individual item here.
  }
}

ここで setTimeout() を使用することは、デベロッパーの作業効率の観点から問題があります。また、ネストされた setTimeout() が 5 回繰り返されると、追加の setTimeout() ごとにブラウザは最小 5 ミリ秒の遅延を適用するようになります。

setTimeout には、譲渡に関して別の欠点もあります。setTimeout を使用して後続のタスクで実行するコードを延期してメインスレッドに譲渡すると、そのタスクはキューの末尾に追加されます。待機中の他のタスクがある場合は、デフレート コードの前に実行されます。

専用の yielding API: scheduler.yield()

scheduler.yield() は、ブラウザのメインスレッドに譲渡するように特別に設計された API です。

これは言語レベルの構文でも特別なコンストラクトでもありません。scheduler.yield() は、今後のタスクで解決される Promise を返す関数にすぎません。その Promise が解決された後に実行するようにチェーンされたコード（明示的な .then() チェーン内、または非同期関数で await した後）は、その将来のタスクで実行されます。

実際には、await scheduler.yield() を挿入すると、関数はその時点で実行を一時停止し、メインスレッドに譲渡します。関数の残りの部分（関数の継続）の実行は、新しいイベントループ タスクで実行されるようにスケジュールされます。そのタスクが開始されると、待機中の Promise が解決され、関数は中断したところから実行を再開します。

async function saveSettings () {
  // Do critical work that is user-visible:
  validateForm();
  showSpinner();
  updateUI();

  // Yield to the main thread:
  await scheduler.yield()

  // Work that isn't user-visible, continued in a separate task:
  saveToDatabase();
  sendAnalytics();
}

ただし、他の yield アプローチと比較した場合の scheduler.yield() の真のメリットは、その継続が優先されることです。つまり、タスクの途中で yield した場合、他の同様のタスクが開始される前に、現在のタスクの継続が実行されます。

これにより、サードパーティ スクリプトからのタスクなど、他のタスクソースからのコードがコードの実行順序を中断するのを回避できます。

クロスブラウザのサポート

scheduler.yield() はまだすべてのブラウザでサポートされていないため、フォールバックが必要です。

1 つの解決策は、scheduler-polyfill をビルドにドロップし、scheduler.yield() を直接使用することである。ポリフィルは他のタスク スケジューリング関数へのフォールバックに対応するため、ブラウザ間で同様に動作します。

または、scheduler.yield() を使用できない場合にフォールバックとして Promise にラップされた setTimeout のみを使用して、よりシンプルなバージョンを数行で記述することもできます。

function yieldToMain () {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }

  // Fall back to yielding with setTimeout.
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

scheduler.yield() をサポートしていないブラウザは優先された継続を取得しませんが、ブラウザが応答し続けるように引き続き譲渡します。

最後に、継続が優先されない場合、コードがメインスレッドに譲渡できない場合があります（たとえば、ビジー状態が知られているページで、譲渡するとしばらく作業が完了しないリスクがある場合など）。その場合、scheduler.yield() は一種のプログレッシブ エンハンスメントとして扱うことができます。scheduler.yield() が利用可能なブラウザでは yield し、そうでない場合は続行します。

これは、便利な 1 行で、機能検出と 1 つのマイクロタスクの待機の両方を行うことで実現できます。

// Yield to the main thread if scheduler.yield() is available.
await globalThis.scheduler?.yield?.();

scheduler.yield() を使用して長時間実行処理を分割する

scheduler.yield() を使用するこれらの方法の利点は、任意の async 関数で await できることです。

たとえば、実行するジョブの配列があり、長いタスクにまとめられることが多い場合は、イールドを挿入してタスクを分割できます。

async function runJobs(jobQueue) {
  for (const job of jobQueue) {
    // Run the job:
    job();

    // Yield to the main thread:
    await yieldToMain();
  }
}

runJobs() の継続は優先されますが、長いジョブリストが完了するまで待機することなく、ユーザー入力に視覚的に応答するなど、優先度の高い処理を実行できます。

ただし、これは効率的な yield の使用方法ではありません。scheduler.yield() は高速で効率的ですが、オーバーヘッドがあります。jobQueue のジョブの一部が非常に短い場合、オーバーヘッドが急増し、実際の処理よりも、譲渡と再開に費やす時間が長くなる可能性があります。

1 つの方法は、ジョブをバッチ処理し、前回の yield から十分な時間が経過した場合にのみ yield を実行することです。タスクが長時間タスクにならないように、一般的な期限は 50 ミリ秒ですが、レスポンスとジョブキューの完了時間のトレードオフとして調整できます。

async function runJobs(jobQueue, deadline=50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    // Run the job:
    job();

    // If it's been longer than the deadline, yield to the main thread:
    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

その結果、ジョブは分割され、実行に時間がかかりすぎることはありませんが、ランナーは約 50 ミリ秒ごとにメインスレッドに譲渡します。

isInputPending() を使用しない

isInputPending() API を使用すると、ユーザーがページの操作を試みたかどうかを確認できます。入力が保留中の場合のみ、yield します。

これにより、入力が保留されていない場合は、JavaScript が続行され、タスクキューの後ろに移動することはありません。これにより、リリース予定で詳しく説明されているように、メインスレッドに返却されない可能性のあるサイトで、パフォーマンスが大幅に向上する可能性があります。

しかし、この API のリリース以降、特に INP の導入により、YouTube の収益化の理解は深まっています。この API の使用はおすすめしません。代わりに、入力が保留中かどうかにかかわらず、以下の理由から、譲渡することをおすすめします。

• isInputPending() は、ユーザーが操作したにもかかわらず、false を誤って返す場合があります。
• タスクが終了する必要があるのは入力の場合だけではありません。アニメーションやその他のユーザー インターフェースの定期的な更新は、レスポンシブなウェブページの提供と同様に重要です。
• その後、scheduler.postTask() や scheduler.yield() など、yield に関する懸念に対処する、より包括的な yield の API が導入されています。

まとめ

タスクの管理は難しいですが、タスクを管理することで、ページがユーザー操作に迅速に応答できるようになります。タスクの管理と優先順位付けには、1 つの方法ではなく、さまざまな方法があります。繰り返しになりますが、タスクを管理する際に考慮すべき主な点は次のとおりです。

• ユーザー向けの重要なタスクについては、メインスレッドに譲ります。
• scheduler.yield()（クロスブラウザ フォールバックあり）を使用して、人間工学に基づいて優先順位付けされた継続を取得する
• 最後に、関数内でできるだけ少ない処理を行う。

scheduler.yield()、その明示的なタスク スケジューリングの相対 scheduler.postTask()、タスクの優先順位付けの詳細については、優先タスク スケジューリング API のドキュメントをご覧ください。

これらのツールの 1 つ以上を使用すると、ユーザーのニーズを優先しながら、それほど重要でない作業も確実に行うように、アプリケーション内の作業を構造化できます。これにより、レスポンスが速く、より快適に使用できるユーザー エクスペリエンスが実現します。

このガイドの技術的な検証に協力してくれた Philip Walton に感謝します。

サムネイル画像は Unsplash の Amirali Mirhashemian 提供。