画像のデコードとレンダリング（loading/decodingとIntrinsic Size）

画像が遅さとガタつきを生む2つの理由

<img> 1つを表示するまでに、ブラウザは大きく分けて3つの仕事をします。取得（ネットワークからバイト列を受け取る）、デコード（PNG/JPEG/WebP などの圧縮データを画素の並んだビットマップに展開する）、ペイント（そのビットマップをレイアウト済みの箱へ描く）です。実務でつまずくのは後半2つで、症状は2系統に分かれます。1つはデコードが重くて操作が固まること、もう1つは画像が後から届いて箱が広がりレイアウトがずれることです。前者は decoding 属性とスレッド配分の問題、後者は Intrinsic Size と CLS の問題で、原因も対策も別物です。本稿はこの2つを内部動作から分けて整理します。画像のペイントが描画全体のどこに位置するかは レンダリングパイプラインの内部動作 を合わせて押さえてください。

デコードのスレッド配分とブロッキング

デコードは見た目以上に重い処理です。たとえば 2000×1500 の写真は約300万画素あり、展開後は1画素4バイト（RGBA）で約12MBのビットマップになります。この展開をどのスレッドで走らせるかが体感を左右します。

問題は、ブラウザのメインスレッドがJavaScript実行・スタイル計算・レイアウト・フレーム生成をすべて担う単一スレッドだという点です。ここで同期的に大きな画像をデコードすると、その間フレームが生成されず、スクロールやクリックへの応答が止まります。これが「画像が出る瞬間にカクつく」現象の正体です。

decoding 属性は、このデコードをいつ・どこで行うかの指示です。

decoding="async" は「この画像のデコードでメインスレッドのフレーム生成を止めないでほしい」という意思表示です。多くのブラウザは画像デコードをラスタライズ用の別スレッド（デコーダ／ラスタスレッド）で実行でき、async はその経路を後押しします。ただし保証ではなくヒントで、最終判断はブラウザにあります。

より明示的に制御したいときは HTMLImageElement.decode() を使います。これは取得とデコードをPromiseで待てるAPIで、完了してからDOMへ挿入すれば、挿入フレームでの同期デコードを避けられます。

// デコードを済ませてから挿入する。挿入フレームが詰まらない
const img = new Image();
img.src = "/photo.avif";
img.decode().then(() => {
  document.querySelector("#gallery").append(img);
}).catch(() => {
  // デコード失敗（壊れた画像など）はここで握る
});

loading=lazyの発火境界

loading="lazy" は、画像がビューポートに近づくまで取得自体を始めない遅延読み込みです。画面外にある大量の画像のリクエストを初期ロードから外せるため、回線と接続数を本当に必要な画像へ回せます。

重要なのはいつ取得が始まるか（発火境界）です。仕様は厳密なピクセル距離を定めておらず、実装は内部的に IntersectionObserverとResizeObserverの内部動作 と同種の交差判定を使い、ビューポートを一定のルートマージン分だけ広げた領域に画像が入った時点で取得を始めます。このマージンは固定値ではなく、実効的な接続速度に応じて変わるのが実装の通例です（遅い回線ほど早めに取りに行く）。つまり lazy の発火点は「スクロールで画像が見えた瞬間」より手前で、間に合うよう先読みされます。

<!-- 画面外の本文画像。ビューポート手前まで取得を遅らせる -->
<img src="/figure.avif" width="800" height="450"
     loading="lazy" decoding="async" alt="図">

loading と decoding は直交します。loading は取得を始めるか否かのタイミング、decoding は展開をどのスレッドでやるかで、別々の段を制御します。両者を取り違えると、固まり対策のつもりで lazy を付けて LCP を落とす、といった事故が起きます。リソースの取得優先度そのものは クリティカルレンダリングパスの最適化原理 で扱っています。

Intrinsic SizeとCLS抑止

画像由来のレイアウトシフトは、画像の実寸（Intrinsic Size、本来の幅×高さ）がデコードヘッダを読むまで分からないことから起きます。寸法指定のない <img> は、画像が届く前は高さ0の箱として扱われ、画像到着で本来の高さに広がります。その瞬間、後続の段落や画像が下へ押しやられ、これが CLS として加算されます。スコアの計算式は Core Web Vitalsの計測アルゴリズム の通り、ずれた領域の割合×移動量で決まるため、大きな画像ほど打撃が大きくなります。

対策は、画像が届く前にブラウザへ縦横比を教えておくことに尽きます。手段は2つあり、内部的には同じ「比率からプレースホルダ高さを先に確保する」仕組みに帰着します。

注意したいのは、現代のレスポンシブ実装では width: 100% のように CSSで表示幅を可変にするのが普通だという点です。このとき height 属性を併記してもピクセル高で固定されてしまいそうに見えますが、実際は違います。ブラウザは width/height の両属性から縦横比だけを取り出し、表示幅に応じた高さを比率で自動計算します（この挙動を以前は CSS の aspect-ratio で手当てしていました）。

/* 属性の縦横比を尊重しつつ表示幅は可変にする現代の定石 */
img {
  height: auto;       /* 高さは比率から自動算出させる */
  max-width: 100%;
}

<!-- 属性で 16:9 を伝える。CSSで幅可変でも高さは比率で予約される -->
<img src="/hero.avif" width="1600" height="900" alt="図">

object-fit を使うときも比率予約は有効です。aspect-ratio で箱を確保し、object-fit: cover で中身を切り抜けば、実寸が来る前から最終的な箱サイズが固定され、シフトが起きません。

取得・展開・予約をまとめて効かせる

3つの段はそれぞれ独立の対策を持ちます。実務では役割で属性を選び分けるのが要点です。

まとめ