おい、最近「なぜかスマホでスクロールするとカクつく」「Largest Contentful Paint (LCP) のスコアがどうしても改善しない」って悩んでないか？
フロントエンドエンジニアとしてレイアウトやCSSの最適化をやり尽くした後に、「やっぱり画像が原因か…」と天井を見上げるその絶望感、めちゃくちゃよく分かる。でもな、大体のエンジニアは「画像をWebPにしました」「サイズを縮めました」で満足しちまうんだ。
そこからもう一歩踏み込んで、「ブラウザがネットワークから拾ったただのバイト列の塊を、どうやってGPUに送り込んでピクセルに変えているのか」という裏側のメカニズムを理解しているかどうかで、パフォーマンスチューニングの精度が文字通りケタ違いになる。
今日は、画像リソースのダウンロードからデコード、そして画面への描画（レンダリング）に至るまでのブラウザ内部の泥臭いドラマを、俺がみっちり解説してやる。現場ですぐに使える実践的なTipsも用意したから、最後までついてきな。
—
1. HTMLパースから画像リソース発見までの「タイムラグ」をぶっ壊せ
まずは、ブラウザがHTMLを読み込んでから画像が表示されるまでの前半戦だ。ここには、多くのエンジニアが見落としがちな「最大の罠」がある。
ブラウザのパーサー（HTML Parser）が上から順にDOMツリーを構築していくだろ？ `` タグにぶち当たった瞬間、パーサーは「おっと、画像だ」と認識する。しかし、この時点ではまだ画像は画面に出てこない。
1. プリロードスキャナー（Preload Scanner）の奔走
メインのパーサーがゴリゴリDOMを作っている裏で、ブラウザの「プリロードスキャナー」という優秀な裏方ワーカーが先回りしてHTML先読みし、`` や `` などのリソースを血眼になって探し出し、非同期でダウンロードを始める。
2. ネットワークリクエストとバイト列の受信
ブラウザはHTTP/2やHTTP/3のコネクションを駆使して、画像の圧縮データ（JPEGやPNG、WebPなど）のバイナリデータをチャンク（断片）ごとに受信する。
ここで現場のエンジニアがやりがちな致命傷が、LCP（Largest Contentful Paint）対象のメインビジュアル画像に `loading=”lazy”` をつけちまうミスだ。
これをやると、プリロードスキャナーがその重要リソースの発見とダウンロードを後回しにしやがる。結果、LCPの計測タイミングが遅れて、Core Web Vitalsのスコアが見事に爆死する。ファーストビューの主役には絶対に遅延ロードを仕込むな。これ、鉄則な。
—
2. メインスレッドの悪夢：画像デコードの裏側
ネットワークから画像のバイナリデータがブラウザのメモリに届いた。よし、これで描画できる――とはならないのが、ブラウザの奥深いところだ。
JPEGやPNG、WebPといった画像フォーマットは、いわば「圧縮された金庫の鍵」みたいなもんだ。画面に描画するためには、これを解凍して、ディスプレイが直接理解できる「生のビットマップ（ピクセルの塊）」に変換しなきゃいけない。これが画像デコード（Image Decoding）だ。
同期デコード（Sync Decoding）の恐怖
昔のブラウザや、設定をミスった現在のブラウザで何が起きるか。
メインスレッド（JavaScriptの実行やDOMの計算をやっている一番忙しいお兄ちゃん）が、画像のデコード作業まで丸抱えでやらされるんだ。
メガピクセル級の高解像度なJPEG画像をメインスレッドでデコードしようもんなら、数ミリ秒〜数十ミリ秒の間、メインスレッドが完全にフリーズする。これが、ユーザーが「おい、なんかこのボタン押したとき引っかかるぞ」と感じる、カクつき（Jank）の正体だ。
非同期デコード（Async Decoding）とオフスクリーン
現代のモダンブラウザは賢い。メインスレッドをブロックしないように、バックグラウンドの別スレッド（Raster Thread / Worker）でゴリゴリとデコード処理を行う。
しかし、CSSやJSの書き方次第では、そのデコード結果をメインスレッドに同期させるタイミングで画面描画がワンテンポ遅れることもある。
ここで、JavaScriptから明示的にブラウザのデコード処理をコントロールするためのモダンなAPI、`HTMLImageElement.decode()` の出番だ。
—
3. 実務で即効性抜群！非同期デコード制御のコード例
「画像を動的に生成してDOMに挿入する際、画面がガタつくのを完全に防ぎたい」
そんな現場の要望をスマートに解決するコードがこれだ。ReactやVueなどのモダンフレームワークのカスタムフックや、バニラJSの画像ローダーにそのまま組み込める。
/
- 画像を事前に非同期でデコードし、メインスレッドのブロックを防いでからDOMに挿入する関数
- @param {string} src – 読み込む画像のURL
- @returns {Promise
} デコード完了済みのimg要素
/
async function loadAndDecodeImage(src) {
return new Promise((resolve, reject) => {
const img = new Image();
img.src = src;
// 1. まずブラウザに画像のロードを裏でこっそり依頼する
img.onload = async () => {
try {
// 2. デコードが完了する（ビットマップへの変換が終わる）までメインスレッドをブロックせずに待つ
await img.decode();
console.log(`[Performance] 画像の非同期デコード成功: ${src}`);
// 3. デコード完了後に初めてDOMツリーへ組み込むことで、カクつき（Jank）をゼロにする
resolve(img);
} catch (error) {
console.error(`[Error] 画像のデコードに失敗しました: ${src}`, error);
reject(error);
}
};
img.onerror = (err) => {
reject(new Error(`画像のロードに失敗しました: ${src}`));
};
});
}
// 【使用例】ボタンクリックで画像を安全にフェッチしてDOMに追加するシチュエーション
document.querySelector(‘#load-btn’).addEventListener(‘click’, async () => {
const container = document.querySelector(‘#image-container’);
try {
// ローディング表示などをここに挟むと親切
const highResImg = await loadAndDecodeImage(‘https://example.com/huge-hero-image.jpg’);
// すでにデコード済みの完品なので、CSSレイアウトとコンポジットが爆速で終わる
container.appendChild(highResImg);
} catch (e) {
// エラーハンドリング
console.error(e);
}
});
このコードのミソは、`img.decode()` がPromiseを返す点にある。
画像をメモリ上でデコードし終えてからDOMの `appendChild` を実行するため、ブラウザのレンダリングエンジン（BlinkやWebKit）は「あ、もうピクセルデータは準備OKね」と即座にペイント処理へ移行できる。無駄な再計算（Reflow/Repaint）のループを発生させない、プロの技だ。
—
4. ラスボス：GPUによる合成（Compositing）とレイヤー昇格
画像がデコードされ、CSSOMと結合されてレイアウト（Layout）が確定したら、いよいよ最終工程のペイント（Paint）とコンポジット（Compositing）だ。
1. ペイント（Rasterization）
ブラウザはレイアウト情報に基づき、「ここにこういう色を塗る」というペイント記録（Display List）を作成し、それをラスタライザースレッドに渡してピクセルの塊（タイル）に変換する。
2. GPUへのアップロードと合成
変換されたピクセルデータは、PCI Expressを経由してメインメモリからGPUのVRAMへと転送される。最終的に、CSSの `transform` や `opacity` などを考慮しながら、コンポジットレイヤーとして画面上に合成（Composite）され、ディスプレイに光として映し出される。
ここで注意してほしいのが、「無駄なレイヤーを増やしすぎるな」ということだ。
「GPUに処理させれば速いんだろ？」とすべての画像に `will-change: transform` や `transform: translateZ(0)` をベタベタ貼り付ける馬鹿がいるが、それはVRAMのメモリをドカ食いさせ、かえってデバイス全体のパフォーマンスを悪化させる（いわゆるレイヤー爆発）。
画像自体のデコード最適化（適切なサイズ、次世代フォーマットの選定）と、適切な `loading` 属性の使い分けこそが、王道にして最強の最適化なのだ。
—
5. シニアからの実践チェックリスト
最後に、明日からの実務で即座にチェックできるポイントをまとめておく。チームのコードレビューでこれらを指摘できたら、お前はもう立派なフロントエンドのリードアーキテクトだ。
- [ ] ファーストビューの画像に `loading=”lazy”` がついていないか？（LCPを遅延させる最大の癌だから今すぐ剥がせ）
- [ ] 逆に、ファーストビュー外の画像には適切に `loading=”lazy”` と `decoding=”async”` が指定されているか？
- [ ] HTML側で `width` と `height` が明示的に指定されているか？（これがないと、画像デコード前後にレイアウトシフト（CLS）が発生してユーザーがイライラする）
- [ ] デバイスのピクセル比（DPR）を無視したバカデカい画像をそのまま配信していないか？（`srcset` と `sizes` を使って、スマホにはスマホ用の軽量画像を返せ）
ブラウザの仕組みを愛し、裏側の動きを想像できるようになれば、フロントエンド開発は単なる「画面の組み立て作業」から「最高にエキサイティングなパフォーマンス・エンジニアリング」に変わる。
さあ、エディタを開いて、自社サービスの画像読み込み処理をもう一度見直してみようぜ。
コメント