ブラウザの鼓動に同期せよ：requestAnimationFrameが支えるレンダリングの深淵
フロントエンドの戦場において、「滑らかな60fps」は単なる心地よさではない。それは、ブラウザという複雑怪奇なエンジンをいかに手懐けているかを示す、エンジニアの誇りそのものだ。
君たちが書くJavaScriptのコードは、往々にしてブラウザのレンダリング・パイプラインという「巨大な歯車」と衝突する。今回は、その衝突を回避し、ブラウザの同期タイミング（VSync）を掌握するための鍵、`requestAnimationFrame` (rAF) の深淵について語ろう。
なぜ `setTimeout` や `setInterval` で描画を制御してはいけないのか
多くの駆け出しエンジニアが犯す最大の過ちは、UIの更新をタイマーイベントに委ねることだ。`setTimeout(fn, 16)` は、ブラウザの描画更新サイクル（一般的に16.6ms）と全く無関係に発火する。
ブラウザのレンダリングパイプラインは、「JavaScript実行 → スタイル計算 → レイアウト（リフロー） → ペイント → コンポジット（合成）」という一連の儀式を厳格に守っている。タイマーがこの儀式の最中や、中途半端なタイミングで割り込むと何が起きるか？
- フレーム落ち（Jank）: 描画の準備が整っていないタイミングでDOMを操作し、無理やりリフローを強要する。
- 無駄なペイント: 1フレームの間に何度も画面を書き換えようとして、GPUのメモリ帯域を浪費する。
`rAF` は、ブラウザが「次のフレームを描画する直前」に、そのコールバックを強制的にねじ込む。これこそが、ブラウザとJavaScriptが「阿吽の呼吸」で同期するための唯一の作法なのだ。
rAFによる描画同期のアーキテクチャ
`rAF` を使う最大のメリットは、「読み取りと書き込みの分離」によるリフローの最小化にある。以下のコードを見てほしい。
/
- 悪い例：読み取りと書き込みが混在し、強制同期レイアウト（Layout Thrashing）を引き起こす
/
function updateBad(elements) {
elements.forEach(el => {
const height = el.offsetHeight; // レイアウトを強制計算（読み取り）
el.style.height = (height + 10) + ‘px’; // レイアウトを汚染（書き込み）
// 次のループでまた読み取りが発生し、ブラウザは何度もリフローを繰り返す
});
}
/
- 良い例：rAFとバッチ処理による最適化
/
function updateGood(elements) {
// 1. 読み取りフェーズ（DOMから値を吸い出す）
const heights = elements.map(el => el.offsetHeight);
// 2. 書き込みフェーズ（rAFでブラウザの同期タイミングに合わせる）
requestAnimationFrame(() => {
elements.forEach((el, i) => {
el.style.height = (heights[i] + 10) + ‘px’;
});
});
}
この「読み取り → 書き込み」の分離こそが、ブラウザエンジンの内部構造を知る者が到達する最適化の第一歩だ。リフローを1フレーム内で完結させ、GPUへのコマンド送信をコンポジット層で一元管理させる。これが、重厚なDOM操作でも60fpsを維持する秘訣だ。
高度な設計：非同期の競合をどう防ぐか
大規模なアプリケーションでは、複数のモジュールが同時に `rAF` を要求する。ここで発生するのが「コールバックの乱立」という名の競合だ。
これを解決するアーキテクチャとして、`rAF` の実行を管理する「スケジューラ」を自作することを推奨する。
// シンプルな描画スケジューラ
const FrameScheduler = {
tasks: [],
isPending: false,
push(task) {
this.tasks.push(task);
if (!this.isPending) {
this.isPending = true;
requestAnimationFrame(() => {
// 次のフレームで全てのタスクを一括処理
this.tasks.forEach(t => t());
this.tasks = [];
this.isPending = false;
});
}
}
};
// コンポーネント側からは、ただタスクを積むだけ
FrameScheduler.push(() => {
element.style.transform = `translateY(${offset}px)`;
});
この設計により、画面の更新をアプリケーションのメインループから分離し、描画負荷を制御可能な状態に置くことができる。メモリリークを防ぐために、不要になったタスクは適切に破棄する実装を加えることも忘れないでほしい。
現場のエンジニアへ：魂を込めた最適化を
最後に、上級エンジニアとしての心得を一つ。
ブラウザの仕組みを理解している人間は、`rAF` を使って「いつ描画するか」を制御するだけでなく、「そもそも描画する必要があるか？」を常に自問自答する。`Intersection Observer` で画面外の要素の描画を停止し、`will-change` プロパティでレイヤーを分離し、コンポジットレイヤーを賢く使いこなす。
`rAF` は強力だが、魔法ではない。君たちが書くコードの「重さ」を理解し、ブラウザというエンジンの限界に寄り添ったとき、初めてそれは「滑らかな体験」へと昇華される。
ブラウザのレンダリングパイプラインを愛し、その鼓動を感じながらコードを書いてほしい。それが、卓越したフロントエンド・スペシャリストへの唯一の道だ。
コメント