Web Workerとは？重い処理でUIを止めないための仕組み

JavaScript の処理が重くて画面が固まる 入力が引っかかる スクロールがカクつく というのは、フロントエンドでよくある悩みです。
そのとき候補に上がるのが Web Worker です。

この記事では、Web Worker とは何かを、なぜ UI が止まるのか、何をワーカーに逃がすのか、何は逃がせないのか の順で整理します。
関連して ジョブキューとは？重い処理を後ろに回す理由 や Service Workerとは？PWAのキャッシュやオフライン対応を支える仕組みを解説 もつながります。

Web Workerとは何か

Web Worker は、Web アプリのメイン実行スレッドとは別のバックグラウンドスレッドで JavaScript を動かす仕組み です。
MDN でも、Web Workers API は background thread separate from the main execution thread と説明されています。

ブラウザの通常の JavaScript は、画面の描画やイベント処理に近いメインスレッドで動きます。
そこに重い計算が乗ると、クリック、入力、スクロール、アニメーションまで待たされます。

Web Worker は、その 重い計算の一部を別スレッドへ分ける ための仕組みです。

なぜUIが固まるのか

ここが分かると、Web Worker の役割も見えやすくなります。

ブラウザでは、メインスレッドが次のような仕事をまとめて担当しがちです。

• イベント処理
• DOM 更新
• 描画
• JavaScript 実行

そのため、たとえば大きな配列の計算、CSV のパース、画像変換、暗号処理のような重い仕事をメインスレッドで長く回すと、その間は他の仕事が詰まります。
結果として 画面が固まったように見える 状態になります。

Web Workerで何がうれしいのか

いちばん大きい利点は、重い処理と UI 操作を分けられること です。

1. 入力やスクロールが引っかかりにくくなる

計算処理をワーカーに逃がすと、メインスレッドは入力受付や描画に集中しやすくなります。
そのため、検索中、集計中、変換中でも画面の体感が悪化しにくくなります。

2. 大きいデータ処理をブラウザ側で持ちやすい

たとえば次のような処理は相性がよいです。

• 大量 JSON の整形
• CSV の読み込みや変換
• グラフ用データの集計
• 画像や音声の前処理
• 暗号化や圧縮のような CPU 寄り処理

3. メインコードの責務を分けやすい

UI は UI、計算は Worker という形にすると、コードの責務分離としても分かりやすくなります。

何でもWeb Workerに入れればいいわけではない

ここは大事です。
Web Worker は便利ですが、重そうなものを全部投げる箱 ではありません。

Web Workerでできないこと

MDN が説明している通り、ワーカーでは DOM を直接操作できません。
window の通常ページ向け API もそのまま全部使えるわけではありません。

つまりワーカーの中では、

• ボタンを書き換える
• 画面にエラーを表示する
• 要素を追加する

といった UI 操作は直接できません。

こうした反映は、ワーカーからメインスレッドへ結果を返し、メイン側で行います。

メインスレッドとどうやり取りするのか

Web Worker は、メインスレッドと postMessage() を使ってメッセージでやり取りします。
基本イメージはこうです。

メイン側

const worker = new Worker("worker.js");
worker.postMessage({ numbers: [1, 2, 3] });

worker.onmessage = (event) => {
  console.log(event.data);
};

worker側

self.onmessage = (event) => {
  const result = event.data.numbers.reduce((sum, n) => sum + n, 0);
  self.postMessage({ result });
};

この構成なので、UI と計算がきれいに分かれる代わりに、状態の受け渡し設計が必要 です。

どんな種類があるのか

MDN では、Web Workers API の中にいくつかのワーカー種類があります。

Dedicated Worker

もっとも基本的な Web Worker です。
単一のスクリプトから使う前提で、まず普通に Web Worker と言うとこれを指すことが多いです。

Shared Worker

複数のスクリプトや複数のウィンドウから共有できるワーカーです。
ただし扱いは少し複雑で、ポート経由の通信が必要です。

Service Worker

ここは混同しやすいですが、Service Worker は Web Worker と同じ役割ではありません。
MDN でも、Service Worker はアプリ、ブラウザ、ネットワークの間に入るプロキシのような存在として説明されています。

つまり、

• Web Worker
  UI を止めないための計算・処理分離

• Service Worker
  キャッシュ、通信制御、オフライン、Push など

という違いがあります。

どんな場面で使うべきか

次のようなときは、Web Worker を検討する価値があります。

1. 重い処理で入力や描画が止まる

フォーム入力中や検索中に固まる、表の並び替えで数秒止まる、グラフ生成で UI が引っかかるなら候補です。

2. ブラウザ側で大きいデータを扱う

サーバーへ送る前にブラウザで前処理する場合も相性がよいです。
たとえば CSV アップロード前の検査や、画像の縮小、ローカル集計などです。

3. 計算ロジックと画面ロジックを分けたい

保守性の面でも、計算専門の処理 を分離したいときに向いています。

逆に使わない方がいい場面

なんでもワーカー化すると、今度は設計と通信の方が重くなります。

1. 処理が軽い

軽い処理なら、ワーカー起動やメッセージ受け渡しの方が面倒です。

2. すぐDOMを触りたい

結果を返してからメインで DOM 更新する必要があるので、UI の細かい反応を直接書きたい処理とは相性がよくありません。

3. 状態共有が複雑すぎる

大量の状態を頻繁にやり取りするなら、分離メリットより通信設計の複雑さが勝つことがあります。

まとめ

Web Worker は、ブラウザのメインスレッドとは別で JavaScript を動かし、重い処理で UI を止めにくくする仕組み です。

大事なのは、

• UI はメインスレッド
• 重い計算はワーカー
• 結果はメッセージで受け渡す

という役割分担です。

画面が固まる 問題の答えが必ず Web Worker とは限りませんが、CPU 寄りで重い処理をブラウザ側に持ちたいとき にはかなり有力です。
一方で、DOM を直接触れないこと、Service Worker とは別物であることは最初に押さえておくと混乱しません。

このあと一緒に読みたい

1. Service Workerとは？PWAのキャッシュやオフライン対応を支える仕組みを解説
2. ジョブキューとは？重い処理を後ろに回す理由
3. フロントエンド、バックエンド、クライアントサイド、サーバーサイドの意味

参考リンク

• MDN: Web Workers API
• MDN: Using Web Workers
• WHATWG HTML Living Standard: Workers