MV（LCP画像）のdecodingは「async」と「sync」のどちらがいい？　速度だけを見てはいけない理由

サイトトップにMV（メインビジュアル）を用いたデザインは今時で格好いいですけど、重くなりがち。
そのためヒーロー画像回りの適切な設定が必要となります。
ここまで「読み込みのタイミング（lazy / eager）」と「表示領域の確保（width / height）」について説明してきました。

loading=”lazy”とloading=”eager”の違いと使い分け、そしてfetchpriority=”high” | きもおた・わーどぷれす。

WordPressでは画像にloading="lazy"が自動付与されます。しかしLCP画像には例外も。本記事ではloading="lazy"・loading="eager"・fetchpriority="high"の役割と実践的な使い分けを説明します。

http://wordpress.kimoota.net

「画像要素で width と height が明示的に指定されていない」の対処法｜CLSを防ぐ基本設定 | きもおた・わーどぷれす。

PageSpeed Insightsで「画像要素で width と height が明示的に指定されていない」と警告されたときの対処法を解説。CLS（Cumulative Layout Shift）の仕組みと、WordPressで発生しやすい原因、imgタグへのwidth・height指定方法を紹介します。

http://wordpress.kimoota.net

今回は、

MV・記事アイキャッチをはじめとするLCP画像の「デコード（描画処理）」の指定を採り上げてみます

なお、

LCP以外の画像についてはdecoding=”async”を推奨します。

ここは迷う必要ありません。

本稿における問題意識は「LCP画像かそうでないかを問わずdecodingを画一的に考える」という点にもあります。
項目立てはしませんが、その点は記事をお読みいただければ御理解いただけると思います。

decoding=”async”はサイト速度を上げてくれる

この手の記事でよく見かけるのが「サイトを高速表示するためにdecoding=”async”（非同期）を設定しよう」という解説。
まず、言っておきたいのは、

このこと自体は「正しい」です

decoding=”async” の効果：
画像のレンダリング処理を後回しにして、テキストなどの描画を優先する

async属性を設定しておくことで、いわゆるレンダリングブロックが発生しづらくなります。
レンダリングブロックはサイト速度改善の敵。
いかになくすかがサイトを高速にするための鍵です。

私は、サイト高速化にかけては、PageSpeed Insights（PSI）で本番サイトでのスコア100を10年にわたり獲り続けてきました。
現在の難易度がすさまじく高くなったPSIにおいてもです。

その私が言うのですから間違いありません

先述の通り、LCP画像以外であればdecoding=”async”を推奨します。
そして当サイトは、LCP画像であってもdecoding=”async”を設定しています。

decoding=”async”は正義ではない

しかし、その私があえて言います。

decoding=”async”は正義ではありません

なぜならLCP画像にdecoding=”async”を使った場合はデメリットがあるからです。

LCP画像におけるdecoding=”async”のデメリット：
背景や文字の描画（レンダリング）は終わっているのにブラウザが『画像データの展開（デコード）』を後回しにする。その結果、一番主役の巨大な画像だけが一瞬遅れてパッと現れる」という不自然なチラつき（フラッシュ現象）が発生する。

その結果、訪問者のUXを損ねてしまうおそれもあります。

syncとasyncはサイトの性格によって使いわける

「チラつくだけじゃん？」と思われるかもしれません。
個人サイトならそれでいいかもしれません。
読めればいいブログなどはもちろん、アフィリエイトサイトならチラつきよりも高速表示を優先した方がいいと思います。

しかしコーポレートサイトではどうでしょう？
画像表示が遅れてUXを損なわせることはサイトに対する信頼を損なわせる可能性があります。
ひいては企業のブランドイメージそのものを傷つけてしまうかもしれません。

つまり、

サイトの性格によって正解は異なるという話です

当サイトはKUSANAGIを中心とする高速化チューニングが軸です。
だからこそdecoding=”async”を付与するそのものがブランディング戦略に繋がります。

しかし一般的なコーポレートサイトなら、訪問者は企業のPSIスコアを読みに来るわけではありません。
情報を読みに来ます。
ひいては、どんな企業かを知りたくて訪問してくれたわけです。

だったら、それに応じたサイト設計が必要となってくるでしょう。
必ずしもdecoding=”async”が正解ではないといえます。

LCP画像は結局どうするのがいいの？

そこはそれこそサイト制作を受注した会社であり担当者の思想の問題となります。
何が正解とは言い切れませんし、言うべきでもないと思います。

ただ、

あくまで私としては、次のとおり考えます

個人サイト：decoding=”async”
企業サイト：何も書かない（ブラウザにお任せの auto）、あるいはdecoding=”sync”

企業サイトについては、LCP画像が十分軽量化され、preloadやfetchpriorityなども適切に設定されていることが前提です。

最近のブラウザは賢いですから、任せてしまっても問題は生じづらいと思います。
ただ確実を期したいなら同期デコードを指定します。

まとめ

decoding=”async”をめぐる問題意識は2つ。

LCP画像かそうでないか
サイトの性質はいかなるものか

私も相当なサイト高速化オタクだと思いますが。
その私でも闇雲にdecoding=”async”を指定するわけではありません

参考になりましたら幸いです

WRITTEN BY

天満川鈴

未経験からWEB業界に入り、現在はWEBディレクターとして実務に従事。要件整理・導線設計・コンテンツ構成などを学びながら、日々改善を重ねています。 AIを活用したコンテンツ制作・効率化を強みとし、プロンプト設計を含めた制作フローの最適化にも取り組んでいます。

詳しいプロフィールはこちら

X CodePen Amazon

KUSANAGI ON VPS

VPSは、もう「黒い画面」だけじゃない。

「VPSは難しそう」と諦めていませんか？ ConoHaのKUSANAGIなら、ブラウザ上の管理画面（KUSANAGI Manager）で、ドメイン設定からSSL発行まで直感的に操作可能です。

コマンド操作なしで世界最速級の環境を構築できる、今の時代の初心者にとっての最適解。私が長年愛用している理由がここにあります。

※当サイト経由で新規申し込みいただくと、特典として1000円分のクーポンをもらえます。

公式サイトで詳細を見る