decoding=”async”とは？効果と使い方、loading=”lazy”との違いと使い分け【WordPress】

2024年4月21日2026年9月20日

まめすけ

「decoding=”async”」って画像に付けるといいって聞いたんだけど、これって何をしてるの？「loading=”lazy”」と何が違うのかも、いまいち分からないんだよね…。

k-suke

その2つは名前が似ているから混同しやすいよね。実は「loading」は画像を読み込むタイミング、「decoding」は読み込んだ画像を描画できる形に変換するタイミングについての指定で、役割がまったく違うんだ。順番に整理していくよ。

画像の表示速度を改善しようとすると、必ず出てくるのが「loading=”lazy”」と「decoding=”async”」です。

どちらもHTMLの<img>タグに書き足すだけの属性ですが、何をしているのかを正確に説明した情報は意外と多くありません。

この記事では、MDN(Mozillaの公式ドキュメント)とWordPress公式リファレンスの記載をもとに、2つの属性の違いと使い分けを整理します。

※本記事は2026年9月時点の情報をもとに更新しています。以前の版ではdecoding=”async”を「非同期で読み込む属性」と説明していましたが、正しくは「デコード(描画の準備)のタイミングに関するヒント」です。MDNの記載に合わせて修正しました。

結論から言います

decoding=”async”は、画像のデコードを後回しにしてよいという、ブラウザへのヒントです。画像を読み込むタイミングは変わりません
loading=”lazy”は、画面に近づくまで画像の読み込み自体を後回しにする指定です
通常の静的な画像では、decoding=”async”の効果は目に見えて分かりにくいとMDNに書かれています
WordPress 6.1以降は、画像にdecoding=”async”が標準で付く仕様です。手動で書く場面は多くありません
ファーストビュー(最初に画面に見える範囲)の画像には、loading=”lazy”を付けないのが基本です

decoding=”async”とは？

ブラウザは、画像ファイルを受け取ったあと、そのまま画面に出せるわけではありません。画面に描画できる形に変換する作業が必要で、これを「デコード」と呼びます。

decoding属性は、このデコードをいつ行うかについてのヒントをブラウザに伝えるものです。指定できる値は3つです。

値	意味
sync	他のコンテンツの描画と同期して画像をデコードし、すべてを一緒に表示する
async	他のコンテンツを先に描画して表示し、画像のデコードはあとで行う
auto	指定なし。ブラウザが最適なほうを決める(既定値)

asyncを指定すると、次の画面の描画が、画像のデコードの完了を待たなくなります。

大事なのは、これが「画像をいつ読み込むか」ではなく「読み込んだ画像をいつ描画用に変換するか」の話だという点です。ネットワークから画像を取ってくるタイミングは、decoding属性では変わりません。

まめすけ

それって、付ければ劇的に速くなるってわけじゃないんだね？

k-suke

そうだね。MDNには、静的な<img>に使っても顕著な効果は認識しにくいと書かれているよ。

違いが出やすいのは、JavaScriptで画像を動的にページへ挿入する場合。「魔法の速度アップ設定」ではなく、描画のブロックを減らすための細かい調整、くらいに考えておきましょう。

loading=”lazy”とは？

こちらは「読み込むタイミング」の指定です。lazyを付けると、画像がブラウザの決めた距離まで画面に近づくまで、読み込み自体が延期されます。

<img src="photo.jpg" alt="説明文" width="800" height="533" loading="lazy">

画像の読み込みを後回しにできるので、ページを開いた直後の通信量を減らせます。使えるのは<img>タグと<iframe>タグの両方です。

注意したいのは、widthとheightの指定です。遅延読み込みされる画像は、読み込まれるまで幅と高さが0として扱われます。あとから画像が出てきたときに、周りの文章がガタッとずれることがあるので、MDNでもwidthとheightを明示することが推奨されています。

また、スライダーのように、あとから表示される画像は、表示のタイミングで読み込みが始まるため、表示が遅れることがあります。遅延読み込みの設定が原因でトラブルになった実例は、こちらの記事でまとめています。

あわせて読みたい

SWELLでYouTube埋め込みがエラー153になる原因と解決策【Lazyload設定が原因だった】 SWELLでYouTubeを埋め込んだら、スマホでエラー153が表示されて再生できない。実際のクライアント案件でこのトラブルに遭遇しました。PCでは問題なく再生できるのに、…

loading=”lazy”とdecoding=”async”の違い

	loading=”lazy”	decoding=”async”
何についての指定か	画像を読み込むタイミング	読み込んだ画像をデコードするタイミング
使える要素	img、iframe	img
期待できること	最初の通信量を減らす	描画がデコードの完了を待たなくなる
効果の分かりやすさ	画像が多いページで分かりやすい	静的な画像では分かりにくい
主な注意点	ファーストビューには付けない。width・heightを指定する	過度な期待をしない

WordPressでは自動で付く

WordPressを使っているなら、手動で書く必要は、実はあまりありません。

WordPress公式リファレンスには、「デフォルトでWordPressは画像にdecoding=”async”を追加する」と書かれています。この仕組みはWordPress 6.1から導入されました。

さらにWordPress 6.3以降は、loading=”lazy”、fetchpriority=”high”、decoding=”async”の3つを、状況に応じてまとめて付ける仕組みがあります。公式リファレンスでは、loading=”lazy”とfetchpriority=”high”を同じ要素に付けてはいけないとされています。

テーマやプラグインが、独自に遅延読み込みなどを制御していることもあります。このブログ(SWELL)の画像を確認してみたところ、decoding=”async”やfetchpriority=”high”が付いている画像、loading=”lazy”が付いている画像、何も付いていない画像が混在していました。実際にどうなっているかは、サイトごとに確認するのが確実です。

自分のサイトで確認する方法

STEP

確認したいページを、ブラウザで開きます。

STEP

ページ上で右クリックして「ページのソースを表示」を選びます。

STEP

検索(Ctrl+F)で「decoding」や「loading」を探し、<img>タグに付いているかを確認します。

補足: 遅延読み込みをテーマやプラグインが独自に行っている場合、ページのソース(サーバーから届いたHTML)では画像のsrcが仮の画像になっていることがあります。ブラウザが処理したあとの状態を見たいときは、F12で開発者ツールを開き、「要素」タブで確認してください。

付いていない画像があっても、慌てて全部に付ける必要はありません。テーマが管理している設定を手動で上書きすると、かえって二重になることがあります。

手動で付ける場面

WordPressのテーマや標準機能に任せられない場合は、手動で付けます。たとえば、自作のHTMLサイトや、ブロックエディタの「カスタムHTML」で画像を書く場合です。

基本の考え方は、次のとおりです。

ファーストビューの画像には、loading=”lazy”を付けない
ファーストビューより下の画像には、loading=”lazy”を付ける
decoding=”async”は、下の画像に一緒に付けておく

<!-- ファーストビューの画像:loading="lazy"は付けない -->

<img src="hero.jpg" alt="説明文" width="1200" height="630" fetchpriority="high">

<!-- ファーストビューより下の画像 -->

<img src="photo.jpg" alt="説明文" width="800" height="533" loading="lazy" decoding="async">

fetchpriority=”high”は、画像を取得するときの優先度が高いというヒントです。ファーストビューのいちばん大きな画像に付けると、優先的に読み込まれます。

まめすけ

ファーストビューにlazyを付けちゃうと、どうなるの？

k-suke

最初に見せたい画像なのに、読み込みが後回しになってしまうんだ。ファーストビューは「すぐ表示する」のが基本。lazyは、スクロールしないと見えない画像のための設定だよ。

実測の一例

自作のHTMLサイトに、ファーストビューは何も付けず、その下の画像に「loading=”lazy”」、動的に表示される画像に「decoding=”async”」を使い分けて適用したところ、PageSpeed Insightsのモバイルスコアが43から54に改善しました。

ただし、これは1サイトでの結果です。loading属性とdecoding属性をまとめて適用しているため、どちらがどれだけ効いたかまでは切り分けて測っていません。PageSpeed Insightsのスコアは、計測のたびに数点ぶれます。数点の差は誤差の範囲なので、実際に効果があったかは、複数回測って確認してください。

あわせて読みたい