ブラウザの裏側を覗く：`decoding`属性でメインスレッドの息継ぎを取り戻す方法
こんにちは、アーキテクトの皆さん。日々、Webアプリケーションのパフォーマンスチューニングに明け暮れていることと思います。Lighthouseのスコアを睨み、「なぜTBT（Total Blocking Time）が跳ね上がるのか」「なぜこのアニメーションは60fpsを死守できないのか」と頭を抱えた経験は一度や二度ではないはずです。
多くのエンジニアは、JavaScriptの実行時間やバンドルサイズに目を奪われがちです。しかし、レンダリングパイプラインの深層を覗くと、「画像」という一見静的なアセットが、ブラウザのメインスレッドをいかに暴力的にブロックしているかに気づきます。
今回は、その隠れたボトルネックを鮮やかに断ち切るための強力な武器、HTMLの `` タグが持つ `decoding` 属性について、ブラウザエンジンの内部挙動のレベルから徹底的に解剖していきましょう。
—
1. メインスレッドの悲劇：なぜ画像デコードはフレームドロップを引き起こすのか？
Webブラウザのレンダリングエンジン（Blink, Gecko, WebKitなど）は、驚異的な最適化の塊です。HTMLをパースし、DOMツリーを作り、CSSOMとマージしてレンダーツリーを構築し、レイアウトとペイントを行う。ここまでは皆さんもよくご存知でしょう。
しかし、HTML内に `
` が現れた瞬間、ブラウザの内部では何が起きているでしょうか？
1. ネットワークフェッチ: 画像のバイトストリームがダウンロードされます（これは非同期です）。
2. デコード（復元）: JPEGやPNG、WebPといった圧縮されたバイナリデータを、GPUやCPUが直接扱える「生のビットマップ（ピクセルデータ）」へと展開します。
問題は「2. デコード」です。このデコード処理、実はなかなかにCPUを食う重い処理です。
同期デコード（デフォルト）の悪夢
`decoding` 属性を指定しない場合、ブラウザはデフォルトで Synchronous（同期）デコード を試みます。
DOMツリーに画像がアタッチされ、レイアウト（Layout）フェーズが完了し、画面に描画（Paint）しようとするその瞬間、ブラウザは「おっと、この画像まだピクセルに展開してないぞ」と気づきます。
結果どうなるか？
描画処理の真っ最中に、メインスレッドを強制的にストップさせ、その場で画像データを展開し始めるのです。これがメインスレッドのブロックです。
巨大なECサイトの製品画像一覧や、高解像度のヒーローイメージがドカンと読み込まれたとき、スクロールが「カクッ」と盛大に引っかかる。あのフレームドロップの主犯格の一つは、まさにこの「メインスレッド上での同期画像デコード」なのです。
—
2. `decoding` 属性の解剖：`async` はどうブラウザを救うのか？
この理不尽なメインスレッドの占有を防ぐために用意されたのが、`` タグの `decoding` 属性です。選択肢は3つあります。
- `decoding=”sync”`: 従来通りの同期デコード。DOMへの挿入と描画を同期させたい場合に指定しますが、実質的にデフォルトなので明示的に書く必要はほぼありません。
- `decoding=”async”`: 非同期デコード。画像を別のバックグラウンドスレッドでデコードし、メインスレッドのブロックを防ぎます。
- `decoding=”auto”`: ブラウザの賢い（あるいは気まぐれな）エンジンに判断を任せます。これが多くのブラウザのデフォルト挙動です。
ここで注目すべきは `decoding=”async”` です。これを指定すると、ブラウザは以下のように振る舞います。
[HTMLパース / DOM構築]
↓
[レイアウト計算 (Layout)]
↓
[描画 (Paint / Compositing)] → ★ ここで画像未デコードでも、プレースホルダーのまま描画を完了させる！
↓
[バックグラウンドスレッド] → 影でコツコツ画像をデコード中…
↓
[デコード完了] → 次の描画フレームで、スッとピクセルデータを画面に反映（Swap）
メインスレッドは画像が完全にデコードされるのを待つ必要がありません。「描画して、あとは裏でよろしく頼むわ」とスレッドを解放できるため、ユーザーがスクロールしている最中であっても、フレームレートが落ちにくくなります。
—
3. 実務での実践：モダンWebアプリケーションにおける戦略的配置
では、この `decoding=”async”` をどの画像に貼るべきで、どの画像に貼るべきではないのでしょうか？ ここにシニアエンジニアとしての見識が問われます。
ケースA：スクロールして初めて目に入る「下方（Below the fold）」の画像
迷わず `decoding=”async”` を付与すべきです。さらに `loading=”lazy”` と組み合わせることで、ネットワーク帯域とメインスレッドのCPUサイクルの両方を完璧に守ることができます。
ケースB：画面の最上部にある「ファーストビュー（Above the fold）」のヒーローイメージ
ここが議論の分かれ目です。
「非同期が良いなら全部 `async` だ！」と短絡的に考えてはいけません。ファーストビューの最重要画像に `decoding=”async”` を指定すると、「画像が綺麗に表示されるまでの数フレームの間、画面が真っ白、あるいはガタついたレイアウトになる」 という現象が起き得ます。
ファーストビューの画像は、ユーザー体験（LCP: Largest Contentful Paint）の観点から、一刻も早く描画を完了させたいアセットです。そのため、あえて `decoding=”sync”`（あるいはデフォルトの `auto`）のままにし、事前に `fetchpriority=”high”` や `` と組み合わせて最優先でフェッチ・デコードさせるべきケースが多いのです。
—
4. 動的生成（JavaScript）における非同期デコードの真骨頂
モダンなSPA（React、Vue、Svelteなど）や、JavaScriptでDOMをゴリゴリ動的に生成するアプリケーションでは、さらに高度なテクニックが求められます。
例えば、ユーザーがボタンを押した瞬間に大量の画像をモーダル内にポップアップさせたり、無限スクロールの新しいチャンクをDOMに挿入したりするシーンです。
JavaScriptで動的に `` 要素を作り、即座にDOMへ挿入すると、ブラウザはそれを同期的に処理しようとしてメインスレッドがフリーズします。
ここで使えるのが、DOMの `HTMLImageElement.decode()` メソッドです。これは `decoding` 属性のJavaScript API版であり、Promiseを返します。
/
- 重い画像をバックグラウンドで完全にデコードしてからDOMに挿入するユーティリティ関数
- @param {string} src – 画像のURL
- @returns {Promise
} デコード完了済みのimg要素
/
async function createPredecodedImage(src) {
const img = new Image();
img.src = src;
try {
// ネットワークからのロードとデコードを完全にメインスレッド外（バックグラウンド）で行う
await img.decode();
console.log(`[Performance] 画像のバックグラウンドデコード成功: ${src}`);
return img;
} catch (error) {
console.warn(`[Performance] 画像のデコードに失敗しました: ${src}`, error);
// 失敗した場合でもフォールバックとしてimg要素自体は返す
return img;
}
}
// 実際のコンポーネントやイベントハンドラでの使用例
async function handleOpenGallery(imageSrcList) {
const container = document.getElementById(‘gallery-modal’);
container.innerHTML = ‘
読み込み中…
‘;
// 全ての画像を並列でバックグラウンドデコード
const imagePromises = imageSrcList.map(src => createPredecodedImage(src));
// 全てがメインスレッドをブロックせずに準備完了するのを待つ
const loadedImages = await Promise.all(imagePromises);
// DOMを書き換える瞬間には、すでに画像データの準備が終わっているため、
// レイアウト後のペイントでカクつきが一切起きない
container.innerHTML = ”;
loadedImages.forEach(img => {
img.classList.add(‘gallery-item’);
container.appendChild(img);
});
}
このアプローチの何が美しいか分かりますか？
「DOMツリーへの挿入」と「重いデコード処理」を完全に切り離している点です。
通常、DOMに未デコードの要素を突っ込むとブラウザが勝手にパニックを起こしてメインスレッドで同期処理を始めますが、事前に `img.decode()` でPromiseを解決させておくことで、ブラウザに「もう準備は万端だから、あとは描画するだけだよ」と優しくエスコートできるのです。
—
5. アーキテクトとして知っておくべきブラウザの裏の顔と注意点
万能に見える `decoding=”async”` ですが、実務で使う際にはいくつかの「罠」やトレードオフが存在します。
1. メモリプレッシャー（メモリ消費の急増）
`async` デコードは、バックグラウンドで勝手にピクセルデータを展開します。もし、一度に何十枚もの巨大な画像を `async` で一気にデコードさせると、GPU/CPUのメモリ（VRAM/RAM）が一気に消費され、モバイルデバイスではOut of Memory（OOM）キラーの餌食になるか、ガベージコレクションの頻発による別のパフォーマンス低下を引き起こします。
「非同期＝無制限にやっていい」わけではないという点に注意してください。
2. レイアウトシフト（CLS）への配慮
非同期デコードや遅延ロードを行うと、画像が後から表示されるため、領域のサイズが適切に確保されていない場合にコンテンツがガタガタとずれる CLS（Cumulative Layout Shift） が発生しやすくなります。
`decoding=”async”` を使うときは、必ず CSS や HTMLの属性で `width` と `height` を明示し、アスペクト比（`aspect-ratio`）を固定しておくことが、プロフェッショナルとしての最低限の責務です。
—
結びにかえて
Webブラウザは私たちが想像している以上に、限られたメインスレッドのリソースをやり繰りしながら、懸命に60fps（あるいは120fps）の世界を維持しようとしています。
`decoding` 属性（そして `img.decode()` API）は、そのブラウザの苦労をエンジニア側からそっと肩代わりし、メインスレッドの呼吸を整えてやるための非常に洗練されたメカニズムです。
「ただ動くコード」を書くステージから、「ブラウザのエンジンと対話しながら、極限まで滑らかな体験をデザインする」ステージへ。
ぜひ、あなたのプロダクトの画像レンダリング戦略に、この非同期デコードの知見を組み込んでみてください。ユーザーの指先の滑らかさが、確実に変わるはずです。
コメント