WordPressレスポンシブ画像の仕組みと最適化術——表示速度を劇的に改善する方法
Webサイトを閲覧するデバイスは、27インチの巨大なモニターから数年前のスマートフォンまで多岐にわたる。すべてのユーザーに対して同じ1200pxの画像を配信することは、モバイルユーザーの帯域を無駄に消費し、表示速度を著しく低下させる要因となる。
WordPressにはバージョン4.4からレスポンシブ画像のサポートが標準で組み込まれているが、デフォルト設定のままでは十分な最適化が行われていないケースが多い。本稿では、WordPressがどのように画像を処理しているのか、そしてさらにパフォーマンスを引き出すための具体的な手法について解説する。
画像の最適化は、Googleの検索評価指標である「Core Web Vitals（コアウェブバイタル）」のスコア改善に直結する。特に、ページ内で最も大きなコンテンツの表示時間を指す「LCP（Largest Contentful Paint）」の改善において、レスポンシブ画像の適切な理解は不可欠だ。
レスポンシブ画像がサイト運営に不可欠な理由
レスポンシブ画像とは、閲覧者のデバイスや画面解像度に合わせて、最適なファイルサイズと解像度の画像を自動的に選択して配信する仕組みを指す。単にCSSで表示サイズを縮小するのではなく、物理的なファイルそのものを切り替える点が重要だ。
データ通信量の節約とユーザー体験の向上
モバイル端末で閲覧しているユーザーに対し、デスクトップ用の1MBを超える画像を送信するメリットはない。80KB程度の縮小版で十分きれいに見える場合、不要なデータ転送は読み込み待ち時間を増大させるだけだ。レスポンシブ画像を採用することで、各訪問者のコンテキストに合わせた最適なデータ量を届けることが可能になる。
Core Web Vitals（LCP）への直接的な影響
Googleの「Core Web Vitals」の中でも、LCPは画像の読み込み速度に大きく左右される。画像が重いページでは、LCPのスコアが悪化し、検索順位やユーザーの離脱率に悪影響を及ぼす。元記事の著者は、オーバーサイズの画像配信がLCPスコアを低下させる最も直接的な要因の一つであると指摘している。
WordPress標準機能による自動処理の仕組み
WordPressは、メディアライブラリに画像をアップロードした際、自動的に複数のサイズバリエーションを作成する。これにより、ユーザーが手動でリサイズ画像を用意する手間を省いている。
自動生成される5つの標準サイズ
デフォルトでは、以下のサイズが生成される仕組みだ。
- サムネイル (Thumbnail): 150x150px（切り抜き）
- 中 (Medium): 最大幅/高さ 300px
- 中大 (Medium Large): 最大幅 768px
- 大 (Large): 最大幅/高さ 1024px
- フルサイズ (Full): アップロードした元の画像
srcset属性とsizes属性によるブラウザへの指示
WordPressはこれらのバリエーションを利用し、HTMLの<img>タグにsrcsetとsizesという2つの属性を自動付与する。srcsetは利用可能な画像リストとその横幅をブラウザに伝え、sizesは画面サイズごとに画像がどのくらいの幅で表示されるべきかのヒントを与える役割を持つ。
<img src="image-1024x683.jpg"
srcset="image-300x200.jpg 300w,
image-768x512.jpg 768w,
image-1024x683.jpg 1024w"
sizes="(max-width: 600px) 100vw,
(max-width: 1024px) 768px,
1024px"
alt="サンプル画像">このコードにより、ブラウザは自身の画面幅や通信環境を確認し、リストの中から最適な画像を1つ選んでダウンロードする。この処理はすべてブラウザ側で完結するため、サーバー側に負荷をかけることなく高速な切り替えが実現される。
標準機能だけでは解決できない注意点
WordPressの自動機能は便利だが、万能ではない。使用しているテーマやブラウザの挙動によっては、期待通りに動作しないケースがある。
テーマによるsizes属性の制御不足
WordPressが生成するデフォルトのsizes属性はあくまで予測値だ。実際の表示幅はテーマのレイアウト（サイドバーの有無や最大コンテンツ幅など）に依存する。適切に設計されていないテーマでは、ブラウザが「実際よりも大きな画像が必要だ」と誤認し、必要以上に大きなファイルを読み込んでしまうことがある。記事によれば、古いテーマや安価なテーマではこの最適化が不十分な場合が多いという。
ブラウザ間での挙動の差異
すべてのブラウザがsrcsetを同じように解釈するわけではない。多くのブラウザはビューポート幅に近い画像を選択するが、一部のブラウザはキャッシュされている大きな画像を優先することもある。もし、モバイルとデスクトップで全く異なる構図の画像（アートディレクション）を見せたい場合は、srcsetではなく<picture>要素を使用すべきだとの見方がある。
画像寸法の明示によるレイアウトシフト防止
レスポンシブ画像であっても、widthとheight属性の指定は必須だ。これがないと、画像が読み込まれる前にブラウザが描画スペースを確保できず、読み込み完了時にコンテンツがガタつく「CLS（Cumulative Layout Shift）」が発生する。WordPressのブロックエディタで挿入した画像には通常これらの属性が付与されるが、カスタムコードで画像を記述する際は注意が必要だ。
Retina・高解像度ディスプレイへの対応戦略
現代のデバイスの多くは、物理的なピクセル数よりも高い解像度を持つ高DPI（Retina）ディスプレイを搭載している。これらに対応するには、通常の2倍の画素密度を持つ画像が必要になる。
「2x」画像の必要性と画質のトレードオフ
Retinaディスプレイで通常の解像度の画像を表示すると、少しぼやけた印象を与える。これを防ぐには、表示サイズの2倍の解像度を持つ画像を用意し、srcsetに含める必要がある。しかし、2倍の解像度はファイルサイズの大幅な増加を招くため、画質とパフォーマンスのバランスを慎重に検討しなければならない。
プラグインによるRetina対応の自動化
WordPress標準ではRetina専用のバリエーションは作成されない。そのため、専用のプラグインを導入して2倍サイズの画像を自動生成し、srcsetに追加する手法が一般的だ。これにより、高解像度デバイスを使用しているユーザーにのみ、鮮明な画像を届けることが可能になる。
さらに一歩進んだ画像最適化のテクニック
標準のレスポンシブ機能に加え、プラグインや外部サービスを組み合わせることで、最適化を極限まで高めることができる。
画像圧縮プラグインの併用
WordPressは複数のサイズを作成するが、それらを「圧縮」する機能は持っていない。元の画像が高画質（低圧縮）であれば、生成されるすべてのバリエーションも重いままとなる。画像圧縮プラグインを導入することで、生成されたすべてのサイズを一括で軽量化し、データ転送量を劇的に削減できる。
アダプティブ画像（動的配信）の導入
WordPressの静的なリサイズには限界がある。例えば、コンテナ幅が550pxの場合でも、WordPressは768pxのバリエーションを配信せざるを得ない。より高度なソリューションでは、リクエスト時にブラウザのコンテナサイズを分析し、その場でぴったりなサイズの画像を生成・配信する「アダプティブ画像」の手法がとられる。これはCDN（コンテンツ・デリバリ・ネットワーク）と組み合わせて運用されることが多く、究極のレスポンシブ配信と言えるだろう。
この記事のポイント
- レスポンシブ画像はCSSの縮小ではなく、デバイスに最適な「ファイル」を切り替える仕組みである
- WordPress 4.4以降は
srcsetとsizesを自動生成するが、テーマの設定次第で効果が半減する - LCPスコアを改善するには、適切な画像サイズ選択と圧縮プラグインの併用が不可欠だ
- Retina対応や動的なサイズ生成には、標準機能以外のプラグインや外部サービスの活用が有効である
- ブラウザの「検証」ツールを使い、実際に意図したサイズの画像が読み込まれているか定期的に確認すべきだ
出典
- WP Mayor「Responsive Images in WordPress: What You Need to Know」（2026年3月26日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
海田 洋祐
・ 複数業界における17年間のデジタルビジネス開発経験 ・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識 ・ 15ヶ国語対応の多言語SaaSの開発経験 ・ 17年間にも及ぶ、Eコマース長期運営経験 ・ 幅広い業界でのSEO最適化の豊富な経験