やあ、ようこそ。ブラウザという広大な宇宙の裏側へ。
私は、長年ブラウザのレンダリングエンジンと格闘し、時にはその繊細さに涙し、時にはその合理的な美しさに救われてきた、一人のチーフアーキテクトです。

今日は、フロントエンド開発者が必ず一度はぶつかる壁——「なぜ、私の作ったサイトはカクつくのか？」という謎を解き明かすために、ブラウザの心臓部である「メインスレッド」のお話をしましょう。

難しい話は抜きです。コーヒーでも飲みながら、私たちのブラウザの中で健気に働く「一人の職人さん」の物語だと思って、リラックスして聞いてくださいね。

—

1. メインスレッドは「たった一人で切り盛りする定食屋」

Webブラウザを動かしているのは、実は驚くほど孤独なヒーローです。それが「メインスレッド」です。

想像してみてください。あなたは、地元で人気の定食屋の店主です。
この店には、あなた一人しかいません。

1. 注文を受ける（JavaScriptの実行）
2. 献立を考える（スタイル計算）
3. お皿の配置を決める（レイアウト/リフロー）
4. 料理を盛り付ける（ペイント/リペイント）

これを全部、あなた一人で、順番にこなさなければなりません。これがブラウザの「メインスレッド」の正体です。

ブラウザの画面が滑らかに動く（秒間60フレーム）ためには、これらすべての作業をわずか0.016秒（16ミリ秒）以内に終わらせて、次のお客さんに料理を出さなければならないんです。過酷だと思いませんか？

—

2. 作業の流れ：職人がこなす4つの工程

ブラウザが画面を書き換えるとき、メインスレッドは必ず以下のステップを順番に踏みます。これを飛ばすことはできません。

① JavaScript実行（注文の受付）

「ボタンが押されたら、この色を変えて！」という指示を処理します。ここで店主（メインスレッド）が複雑すぎる計算を始めると、次のお皿の準備に進めません。

② スタイル計算（レシピの確認）

「この要素にはどの色が塗られるべきか？」を計算します。CSSのルールを全部チェックして、最終的な見た目を決定します。

③ レイアウト / リフロー（お皿の配置）

「このボタンの幅は何ピクセルで、どこに置くか？」を決める作業です。
ここが一番大変な作業です。 誰か一人の場所が変わると、後ろに並んでいる全員の場所を再計算しないといけないからです。これを「リフロー」と呼びます。

④ ペイント / リペイント（盛り付け）

場所が決まったら、いよいよ色を塗ります。文字を書き、背景色を塗り、影をつけます。

—

3. なぜ画面が「固まる」のか？（ブロッキングの正体）

ここで一番の注意点があります。メインスレッドは「一度に一つのことしかできない」ということです。

もし、JavaScriptのステップで「100万回計算して！」なんていう重い注文が入ったらどうなるでしょう？
店主は計算に没頭し、料理を盛り付ける（ペイント）ことができなくなります。

お客さん（ユーザー）から見れば、「ボタンを押したのに反応しない」「スクロールが止まった」という状態になります。これが「メインスレッドのブロッキング」です。

現場の泥臭い話をすると、私たちはよく「JSを軽くしろ！」と言われます。それは、この店主を計算づめにせず、一刻も早く「盛り付け（描画）」の作業に戻してあげたいからなんです。

—

4. 実際に「ブロッキング」を体験してみよう

言葉で言うより、実際に見てみるのが一番です。
以下のコードは、メインスレッドをわざと「忙しく」させて、画面をフリーズさせる実験用のコードです。

メインスレッドの働きを見てみよう

この円は、メインスレッドが空いていればスムーズに回ります。

これを実行してボタンを押すと、上の「くるくる（アニメーション）」がピタッと止まるはずです。
店主がループ処理に捕まってしまい、「次のコマを描画する」という仕事ができなくなったからです。

---

5. 賢い店主の必殺技：コンポジット合成

「じゃあ、重い処理をしたら絶対にカクつくの？」
そんなことはありません。現代のブラウザには「コンポジット合成」という救世主がいます。

これは例えるなら、「別室にいる凄腕の看板職人（GPU）」です。

メインスレッド（店主）が忙しくても、特定の作業（透明度を変える、位置をずらすなど）だけは、店主を通さずにこの看板職人が直接画面を書き換えてくれます。
これを活用するのが、`transform` や `opacity` を使ったアニメーションです。これらはメインスレッドの負担を劇的に減らしてくれます。

---

6. 私たちが意識すべき「優しさ」

最後に、私がジュニアアーキテクトにいつも伝えていることをあなたにも贈ります。

ブラウザの仕組みを学ぶと、「効率的なコードを書かなきゃ」と身構えてしまうかもしれません。でも、一番大切なのは「メインスレッドという一人の職人を、いかに楽にさせてあげるか」という優しさです。

• リフローを避ける: 家具を全部動かすような大きな変更を頻繁にしない。
• 処理を小分けにする: 100個の仕事を一度に渡さず、隙間時間で少しずつやってもらう（`requestAnimationFrame` などの活用）。
• GPUを頼る: 派手な動きは、店主ではなく看板職人（GPU/CSS transform）に任せる。

最初は分からなくても大丈夫。
「あ、今店主を困らせてるかも？」とふと思う瞬間があるだけで、あなたの書くコードは昨日よりもずっと、ユーザーに優しいものになっているはずですよ。

もし迷ったら、いつでもこの定食屋の店主を思い出してくださいね。応援しています。