WordPress画像を軽くする方法｜WebP・圧縮・サイズ・表示速度をまとめて確認

この記事は、WordPressが重い原因のうち「画像だけ」を軽くする記事です。全部を極端に圧縮するのではなく、表示サイズ・元画像・WebP・圧縮率・テーマが選ぶ画像サイズを順に確認します。画像以外のキャッシュやプラグインを見直す場合は高速化プラグインを増やす前の確認手順へ分けます。

最初に「表示サイズ」と「元画像サイズ」を分ける

たとえば本文で横幅700px程度に表示する画像に、横3000px以上の元画像を毎回そのまま使うと、必要以上のデータを読み込むことがあります。高解像度ディスプレイもあるため単純に表示幅と同じでよいとは限りませんが、用途に対して極端に大きな画像を避けることが基本です。

最初は「表示寸法／元画像寸法／ファイル容量」を記録します。その後、公開ページで配信される画像URL、見た目、重要画像の読み込み方も照合します。元ファイルを縮めても別の画像候補が配信されていれば、読者が読み込む容量は変わらないことがあります。ページ全体の評価は表示速度の改善手順で分け、画像容量の減少をそのままLCPや順位の改善と扱いません。

WordPressはアップロード画像から複数サイズを生成するため、テーマやブロックが適切なサイズを選べているかも確認します。元の写真はきれいなのに掲載後だけぼやける場合は、さらに圧縮する前に画像がぼやける・小さいときの確認手順で配信ファイルと表示幅を比べてください。

JPEG・PNG・WebP・AVIFをどう使い分ける？

YOHAKU FORMAT DECISION

web.devでも、写真やスクリーンショットではJPEG、WebP、AVIFなどを用途に応じて選び、実際の画質とファイルサイズを比較する考え方が案内されています。形式名だけで決めず、同じ画像で見比べます。

圧縮は「見た目を確認しながら」行う

圧縮率を上げすぎると、文字入り画像やグラデーション、細かい線がにじむことがあります。特にスクリーンショットや図解は、写真と同じ圧縮設定にしない方がよい場合があります。

• 人物・風景写真：多少の非可逆圧縮でも目立ちにくいことがある
• 管理画面スクリーンショット：文字が読めることを優先
• 図表・ロゴ：輪郭や透過の崩れを確認
• アイキャッチ：スマホ縮小時の文字可読性も確認

レスポンシブ画像でスマホに巨大画像を送らない

ブラウザはsrcsetやsizesなどの情報を使って、画面幅に合った画像候補を選べます。WordPressやテーマが自動出力していることも多いため、まずは公開ページの実際の表示を確認します。

web.devでも、レスポンシブ画像を使うことで、画面に対して必要以上に大きな画像を読み込む無駄を減らせると説明されています。

width・heightを持たせてレイアウトずれを減らす

画像の表示領域が事前に分かると、読み込み中に本文が大きくずれるのを防ぎやすくなります。WordPressでは通常、メディア挿入時に幅と高さの情報が出力されますが、カスタムHTMLや外部埋め込みでは抜けることがあります。

画像を軽くする作業とあわせて、読み込み前後でレイアウトが大きく動かないかもスマホで確認します。

遅延読み込みは重要画像まで遅らせない

遅延読み込みは、初期画面の外にある画像を候補にします。web.devは、最初に見える画像、とくにLCP画像を遅延読み込みしないよう案内しています。公開ページで主要画像のloading属性を確認し、重要画像にloading="lazy"が付いている場合は、WordPress・テーマ・画像プラグインのどこが付けているかを調べます。全画像の遅延読み込みを一括で無効化せず、原因が分かった設定だけ変更し、変更前後のLCPと表示を同じ条件で確認します。web.dev公式：初期画面とLCP画像の読み込み（確認日：2026年10月6日）。

YOHAKU LIVE IMAGE AUDIT｜2026-10-01

実例｜メディア庫で2MB超でも、公開ページがその画像を配信しているとは限らない

YOHAKU SELECTのメディアを再監査したところ、2026年10月1日時点で152件・alt欠損0件・2MB超0件まで整理できました。500KB超は1件だけで、残っているのはロゴ元画像です。サイト設定での参照を確認せず削除せず、通常の記事アイキャッチは軽量版へ切り替えています。

今回の整理では、旧PNGをそのまま削除せず、先に軽量版へfeatured imageを差し替え、本文や構造化データに旧画像URLが残っていないかを確認してから削除しました。featured imageとSNS/OG画像、構造化データのimageは同じ参照先とは限りません。画像を変更した後は、公開ページ側の参照も別々に確認します。

確認	今回の実測	判断
メディア総数	152件	alt欠損0件
2MB超	0件	大容量元画像の整理を完了
500KB超	1件	ロゴ元画像。サイト設定の参照確認なしに削除しない
削除前の確認	本文・featured image・構造化データ	参照切れを確認してから旧画像を削除

確認順：メディア庫の容量 → featured image → 公開ページのog:image・src・srcset → 実際の表示 → 必要な画像だけ差し替え、の順にすると二重作業を減らせます。アイキャッチを変えた＝SNS画像も変わったとは判断しません。

画像最適化でやらない方がよいこと

• すべての画像を同じ圧縮率にする
• 元画像を確認せず一括変換する
• 変換後の画像だけ残して元データを失う
• プラグインを複数入れて二重変換する
• 表示確認をせずファイル名やURLを一括変更する

公開後のチェックリスト

• PC・スマホで画像が正常表示される
• 文字入り画像が読める
• 縦横比が崩れていない
• サムネイルや関連記事でも表示される
• WebP等への変換後も404が出ていない
• キャッシュ削除後にも正常表示される
• バックアップやメディア容量が想定外に増えていない

どこから軽量化するか迷ったときの優先順位

画像が多いサイトでは、全部を一度に変換するより、アクセスされやすく容量の大きい画像から順に進める方が安全です。

1. トップページや主力記事の大きな画像：最初に表示される画像を優先
2. 2MB前後の大容量画像：転送量を減らせる余地が大きい
3. 同じ記事で複数使っている画像：ページ全体の容量を確認
4. 古いPNG・JPEG：WebP等へ変換する価値があるか比較
5. アクセスの少ない画像：急いで触らず後回しでもよい

比較の記入例（架空）：本文の写真1枚が元画像3000px・900KB、候補が1400px・180KBなら、ファイル容量の差は720KBです。ただし、その候補が実際の公開ページで配信され、スマホでも必要な画質を保てるかを確認して初めて採用します。確認結果は「URL／変更前後の容量／配信画像／画質／日付」で記録します。自サイトの速度改善を実測した例ではありません。画像の説明文や検索での理解も整える場合は画像・動画SEOの確認へ進みます。

サイト全体が遅い場合は、画像だけでなくWordPressの表示速度改善も確認します。画像をアップロードできない場合は画像アップロードエラーの確認手順、容量が増え続ける場合はサーバー容量不足の確認方法へ進みます。

DISPLAY SIZE FIRST

圧縮前に「その場所で何px必要か」を決める

元画像を全部同じサイズへ縮めるのではなく、アイキャッチ・本文画像・サムネイルごとに必要な表示幅を決めます。表示幅はCSSピクセル、ファイルの横幅は画像そのもののピクセル数として記録し、混同しないようにします。

たとえば表示幅360 CSS px、画面の密度を2と仮定するなら、横720pxが比較の目安です。これは計算用の例で、当サイトの端末実測や画質の保証値ではありません。MDN：画面のピクセル密度。

元画像の大きさだけで決めず、公開ページで選ばれる候補と実際の見た目を確かめます。メディアライブラリに大きい画像があっても、小さい候補を拡大していれば別の対応が必要です。全画像を一律に小さくする前に、問題の1枚で比べましょう。

まとめ

WordPress画像の最適化は、WebPへ変換するだけでは不十分です。元画像の大きさ、形式、圧縮、レスポンシブ配信、表示領域、遅延読み込み、公開後の確認までセットで見ると、画質を保ちながら無駄な転送量を減らしやすくなります。画像そのもののSEOや図解・動画の使い分けまで確認する場合はAI検索時代の画像・動画SEOへ進みます。

IMAGE BEFORE / AFTER

軽量化は「容量」と「見た目」を同時に記録する

確認	変更前	変更後
ファイル容量	○KB	○KB
表示幅	○px	○px
見た目	基準画像	文字・輪郭・写真を確認

数字だけ小さくするのではなく、スマホ表示で劣化が目立たないかまで確認します。ページ全体の速度はWordPress表示速度の改善手順と分けて考えます。

参考情報

• web.dev：Learn Images
• web.dev：Responsive images
• web.dev：画像形式の選び方