WordPress画像圧縮とWebP最適化｜LCPを悪化させない実務手順

WordPressの画像圧縮は、プラグイン名を選ぶ作業ではありません。

実務では、重い画像の棚卸し、ファーストビューのLCP画像の特定、表示サイズに合わせたリサイズ、WebP/AVIF配信、Lazy Loadの除外、CTA画像の見え方、既存画像のバックアップ、今後のアップロードルールまでを一つの流れとして扱います。

GoogleのLargest Contentful Paintでは、ビューポート内で最大の画像やテキストブロックなどが表示されるまでの時間が重要な指標になります。WordPressでも、メインビジュアルやアイキャッチ画像がLCP対象になりやすいため、画像の扱いはCore Web Vitalsの改善に直結します。

WordPress Coreでも画像パフォーマンスは継続的に改善されており、WordPress 6.3の画像パフォーマンス強化では、LCP画像候補へのfetchpriority="high"付与や、Lazy Load制御の改善が説明されています。

WordPress画像圧縮で最初に決めるべきなのは、使うプラグインではなく、LCP画像、CTA画像、記事中画像、生成サイズのどこから直すかです。

この記事では、WordPressの画像圧縮とWebP最適化を、表示速度と保守運用の両方から整理します。

WordPressの画像が重いと何が遅くなるか

WordPressの画像が重いと、最初に悪化しやすいのはLCPです。

トップページのメインビジュアル、サービスページのファーストビュー、記事のアイキャッチ、LPのCTA直前画像などが大きすぎると、ユーザーが「ページの主な内容が表示された」と感じるまでの時間が延びます。

画像の状態	起きる問題	影響しやすい場所
4000px以上の写真をそのまま使う	転送量が増える	トップ、記事、LP
ファーストビュー画像が大きい	LCPが悪化する	メインビジュアル、アイキャッチ
画像サイズ指定がない	レイアウトがずれる	記事、カード、CTA
下部画像まで初期読み込みする	初期表示が重くなる	長い記事、制作事例
CTA画像が粗くなる	クリック前の信頼感が下がる	問い合わせ導線、資料請求導線

WordPressは、メディアライブラリに画像を追加すると複数のサムネイルサイズを生成します。テーマやプラグインが独自サイズを増やしている場合、1枚のアップロードが複数ファイルに増え、圧縮対象も管理対象も増えます。

画像が重い問題は「容量を小さくする話」だけでなく、LCP、CLS、CTAの見え方、メディア運用、生成サイズの管理まで広がります。

まずは「画像圧縮をするか」ではなく、「どのページのどの画像が、表示速度やCVに影響しているか」を確認します。

まず確認すべき画像の棚卸しとLCP画像

画像の棚卸しでは、容量、表示位置、表示サイズ、ページの重要度を分けて見ます。

確認項目	見る理由	使う道具
重要URL	CVやSEOへの影響が大きいページを優先する	GA4、Search Console、広告LP一覧
LCP対象	最初の体感速度に直結する	PageSpeed Insights、Lighthouse、DevTools
ファイルサイズ	転送量の大きい画像を見つける	DevTools Network、メディアライブラリ
表示サイズ	実表示より大きすぎる画像を見つける	DevTools、テーマ設定
生成サイズ	不要なサムネイルや巨大サイズを見つける	WordPress設定、テーマ、プラグイン

LCP画像は、ページごとに違います。トップページではメインビジュアル、記事ではアイキャッチ、サービスページではファーストビューの背景画像や見出し横画像が対象になることがあります。

PageSpeed Insightsで対象URLを測り、診断結果やLighthouseのLCP要素を見ます。さらにChrome DevToolsのPerformanceやNetworkで、どの画像がいつ読み込まれているかを確認します。

画像棚卸しでは、容量が大きい順だけでなく、LCP対象、ファーストビュー、CTA近辺、検索流入がある記事を優先します。

この段階で「全画像を一括で圧縮する」判断を急がないことが重要です。先にLCP画像だけを適切なサイズに直す方が、全体圧縮より効果が分かりやすいことがあります。

圧縮・リサイズ・WebP変換の違い

画像最適化では、圧縮、リサイズ、形式変換を分けて考えます。

施策	何を変えるか	向いているケース	注意点
圧縮	画質やメタデータを調整して容量を下げる	JPEG/PNGが重い	画質劣化を確認する
リサイズ	横幅・高さを表示サイズに近づける	4000px画像を1200px表示している	元画像のバックアップが必要
WebP変換	JPEG/PNGをWebPとして配信する	対応ブラウザに軽い画像を出したい	配信ルールとキャッシュ確認が必要
AVIF変換	WebPよりさらに軽い形式を狙う	写真が多く、対応環境が整う	生成時間、互換性、画質確認が必要
生成サイズ整理	WordPressのサムネイルサイズを見直す	不要なサイズが多い	テーマや過去記事への影響を確認する

よくある失敗は、巨大画像をリサイズせずに圧縮だけで済ませることです。たとえば、表示幅が900pxなのに横幅4000pxの画像を使っている場合、圧縮しても無駄なピクセルを配っている状態は残ります。

逆に、リサイズだけで画質や形式を見ないのも不十分です。写真が多いサイトでは、適切に圧縮したJPEGやWebPの方が軽くなることがあります。

WordPress画像最適化は、圧縮率を強くする作業ではなく、表示サイズ、画像形式、生成サイズ、配信条件をそろえる作業です。

まずはLCP画像を「実表示サイズに近い寸法」「許容できる画質」「WebP/AVIFの配信可否」「Lazy Load除外」の観点で見直します。

画像圧縮プラグインの選び方

画像圧縮プラグインは、機能一覧だけで選ばない方が安全です。

選定時には、次の観点を確認します。

観点	確認すること
既存画像の一括処理	途中停止、再開、失敗ログ、対象除外ができるか
新規アップロード時	自動圧縮、最大サイズ制限、生成サイズごとの処理ができるか
WebP/AVIF配信	.htaccess、Nginx、pictureタグ、CDN配信のどれで出すか
バックアップ	元画像を残せるか、復元できるか
画質調整	LCP画像やCTA画像だけ圧縮を弱められるか
サーバー条件	exec、GD、Imagick、外部API利用の条件に合うか
個人情報・権利	外部APIに画像を送ってよい素材か
他プラグインとの重複	キャッシュ、CDN、Lazy Load、WebP変換が競合しないか

WordPress公式のOptimizationでも、ページを速く届けるための圧縮や、画像を含むメディアファイルの圧縮が重要な観点として整理されています。

ただし、画像圧縮、Lazy Load、WebP変換、CDNを複数プラグインで重ねると、どの設定が効いているのか分からなくなります。既にキャッシュプラグインやCDN側で画像変換をしている場合は、二重変換になっていないかを確認します。

画像圧縮プラグインは「人気順」ではなく、既存画像の量、復元性、WebP配信方法、CTA画像の画質確認まで含めて選びます。

プラグイン導入前に、対象URL、対象画像、バックアップ方法、除外画像、確認ページを決めておくと、失敗時に戻しやすくなります。

EWWW・TinyPNG・Converter for Mediaの使い分け

EWWW、TinyPNG、Converter for Mediaは、どれが絶対に上というより、サイトの制約で使い分けます。

プラグイン	見るべき用途	注意点
EWWW Image Optimizer	既存画像の一括最適化、ローカル処理、リサイズ、WebP配信、Lazy Load周りも含めて見たい場合	サーバー環境や設定項目を確認する
TinyPNG	外部APIでJPEG/PNG/WebP/AVIFの圧縮や変換を扱いたい場合	無料枠、生成サイズごとの消費、外部送信可否を見る
Converter for Media	既存画像をWebP/AVIFとして配信することを中心にしたい場合	Nginxやサーバー設定、元画像の扱い、配信確認を見る

EWWWは、WordPress.orgの説明でも、ローカル画像最適化、WebP変換、リサイズ、Lazy Load、バックアップなどが機能として整理されています。TinyPNGは、アップロード時の自動圧縮、WebP/AVIF変換、バルク最適化、月間無料枠などを確認して使います。Converter for Mediaは、元画像を残しながらWebP/AVIFを別ディレクトリに生成し、対応ブラウザへ配信する考え方が特徴です。

ここで大事なのは、同時に複数の画像最適化プラグインを有効化しないことです。圧縮、WebP配信、Lazy Load、CDN、キャッシュが重なると、画像URL、srcset、キャッシュ削除、画質、表示崩れの原因が追いにくくなります。

EWWW、TinyPNG、Converter for Mediaはランキングではなく、圧縮、リサイズ、WebP/AVIF配信、バックアップ、サーバー条件のどこを任せるかで選びます。

既にCloudflare、画像CDN、ホスティング側のWebP変換を使っている場合は、プラグイン側で同じことを重ねないようにします。

既存画像を一括最適化する手順

既存画像の一括最適化は、影響範囲が広い作業です。

安全に進めるなら、次の順番にします。

順番	作業	確認すること
1	バックアップを取る	uploads、DB、復元手順
2	重要URLを決める	トップ、LP、記事、フォーム、CTA周辺
3	LCP画像とCTA画像を除外候補にする	画質、Lazy Load、表示順
4	小さな範囲でテストする	代表画像、過去記事、スマホ表示
5	圧縮・リサイズ設定を決める	最大幅、画質、生成サイズ
6	一括処理を分割実行する	タイムアウト、失敗ログ、再開可否
7	キャッシュとCDNを削除する	旧画像が残らないか
8	変更前後を比較する	PageSpeed Insights、実機、フォーム、CTA

特に、長年運用しているWordPressでは、メディアライブラリに未使用画像、古いアイキャッチ、サイズ違い、プラグインが生成した画像が混在しています。まず全量を触るより、重要URLに出ている画像から最適化します。

画像圧縮後は、ブラウザキャッシュ、ページキャッシュ、CDNキャッシュの影響で、変更が見えにくいことがあります。WebP配信を追加した場合は、Networkタブで実際にWebP/AVIFが返っているか、JPEG/PNGのままになっていないかを確認します。

既存画像の一括最適化は、ボタン操作ではなく、バックアップ、対象分割、除外、キャッシュ削除、表示確認を含む保守作業です。

「何枚処理したか」よりも、「重要ページのLCP、CTA、画質、表示崩れがどう変わったか」を完了条件にします。

ファーストビュー画像とCTA画像で注意すること

ファーストビュー画像とCTA画像は、通常の本文画像より慎重に扱います。

ファーストビュー画像はLCP対象になりやすく、読み込みが遅いとページ全体の体感速度が悪くなります。一方で、圧縮しすぎると、会社の第一印象やサービスの信頼感を落とします。

CTA画像も同じです。資料請求、問い合わせ、無料診断、セミナー申込などの直前にある画像が粗い、遅い、崩れる、差し替わらない状態だと、フォーム到達率やクリック率に影響します。

画像	注意すること	確認方法
メインビジュアル	LCP対象か、Lazy Loadされていないか	PageSpeed Insights、DevTools
アイキャッチ	記事一覧と記事詳細で適切なサイズか	srcset、生成サイズ
CTA画像	圧縮後に文字や図が読めるか	スマホ実機、Retina表示
背景画像	CSS背景でもLCP候補になるか	DevTools、Lighthouse
バナー	WebP配信後にキャッシュが残らないか	Network、CDN purge

WordPress 6.3以降では、CoreがLCP画像候補にfetchpriority="high"を付ける改善や、Lazy Loadの扱い改善を進めています。ただし、テーマやプラグインが独自に画像を出している場合、期待通りにならないことがあります。

wp_get_loading_optimization_attributes()は、画像やiframeに対してloading、fetchpriority、decodingなどの属性を返すWordPress Coreの関数です。LCP候補画像にloading="lazy"とfetchpriority="high"を同時に付けるような状態は避けるべきです。

ファーストビュー画像とCTA画像は、単に軽くするのではなく、LCP、Lazy Load除外、画質、クリック前の信頼感をセットで確認します。

速度改善後は、スマホでファーストビューからCTAまでスクロールし、画像の表示遅延、にじみ、ボタン周辺の崩れ、フォーム遷移を確認します。

Lazy Load・CDN・生成サイズの最適化

Lazy Load、CDN、生成サイズは、画像最適化の後半で確認します。

Lazy Loadは、画面外の画像を遅らせて読み込む仕組みです。記事下部の画像、ギャラリー、制作事例一覧などには有効です。一方で、ファーストビューのLCP画像をLazy Loadしてしまうと、表示開始が遅くなることがあります。

項目	使いどころ	注意点
Lazy Load	画面外の画像を遅らせる	LCP画像やCTA直前画像を遅らせすぎない
CDN	画像や静的ファイルを近い場所から配る	キャッシュ削除、URL、WebP変換の重複
生成サイズ整理	不要なサムネイル生成を減らす	テーマ、過去記事、一覧表示への影響
srcset	端末幅に合う画像を出す	生成サイズが多すぎると管理が複雑
画像プリロード	重要画像を早く読み込ませる	多用すると他リソースを圧迫する

WordPressのOptimizationでは、静的ファイルの配信や画像ファイルの圧縮もパフォーマンス改善の観点として扱われています。ただし、HTTP/2やHTTP/3、CDN、ホスティング環境によって最適解は変わります。

生成サイズも見落としがちです。テーマやプラグインが不要な画像サイズを多く登録していると、アップロード時の処理が重くなり、ストレージも増えます。使っていないサイズを止める場合は、過去記事、一覧ページ、OGP、メール配信、SNSシェア画像への影響を確認します。

Lazy Loadは下部画像には有効ですが、LCP画像や重要CTA画像まで遅らせると、表示速度とCV導線を悪化させることがあります。

CDNを使う場合は、画像圧縮プラグイン、キャッシュプラグイン、CDN側の画像最適化が重複していないかを確認します。

画質劣化とバックアップの確認方法

画像圧縮では、画質劣化と復元性を必ず確認します。

特に、次の画像は圧縮の影響が出やすいです。

画像タイプ	劣化の出方	確認ポイント
人物写真	肌や背景が荒れる	主要ページ、Retina表示
商品写真	質感が落ちる	拡大表示、EC、事例
図解画像	線や文字がにじむ	スマホで文字が読めるか
CTAバナー	信頼感が落ちる	ボタン周辺、フォーム導線
ロゴ	エッジが崩れる	SVG/PNGの使い分け

バックアップは、WordPressのDBだけでは足りません。画像ファイルはwp-content/uploadsにあるため、DBバックアップとファイルバックアップの両方が必要です。WebP/AVIFを別ディレクトリに生成する方式では、元画像と変換後画像の関係も確認します。

また、EXIFや著作権情報を削除してよいかも確認します。写真素材や商品写真では、メタデータ削除自体は容量削減に効くことがありますが、社内ルールや権利管理との整合が必要な場合があります。

!![marker]画像圧縮前には、DBだけでなくuploadsのファイルバックアップと復元手順を確認し、写真、図解、CTA画像を代表パターンとして見比べます。!!

圧縮後の確認は、PCだけでなくスマホ実機で行います。小さな画面では問題なく見えても、高解像度端末や大きなディスプレイで粗さが目立つことがあります。

今後重くしないための運用ルール

WordPressの画像最適化は、一度の一括処理で終わりません。

今後重くしないためには、アップロード前、アップロード時、公開後のルールを決めます。

タイミング	ルール例
アップロード前	横幅の上限、ファイル名、代替テキスト、画像用途を決める
アップロード時	最大サイズ制限、自動圧縮、WebP/AVIF生成を確認する
公開前	LCP画像、CTA画像、スマホ表示、フォーム導線を見る
公開後	PageSpeed Insights、Search Console、主要記事の転送量を見る
月次保守	未使用画像、巨大画像、生成サイズ、プラグインログを棚卸しする

特に社内運用では、「とりあえず高解像度でアップロードする」ルールをやめることが重要です。記事担当、デザイナー、外部ライター、制作会社がそれぞれ違うサイズで画像を入れると、メディアライブラリはすぐに重くなります。

運用ルールは細かすぎると守られません。最初は、次のような最小ルールで十分です。

1. 記事画像は横幅1200px程度を上限にする
2. メインビジュアルとCTA画像は公開前にスマホで確認する
3. PNGは図解や透過が必要な場合だけ使う
4. 写真はJPEGまたはWebP配信を前提にする
5. 月1回、重い画像とLCP悪化ページを確認する

画像最適化を維持するには、プラグイン設定よりも、アップロード前のサイズルール、CTA画像の確認、月次のLCP棚卸しが重要です。

このルールがあると、新しい記事やLPを追加しても、WordPressが少しずつ重くなる状態を抑えやすくなります。

WordPress高速化・保守改善を相談する判断基準

自社で対応しやすいのは、次の範囲です。

自社で対応しやすいこと	専門家に相談した方がよいこと
画像サイズの事前調整	LCP画像の特定と改善実装
画像圧縮プラグインの基本設定	WebP/AVIF配信とキャッシュの競合整理
記事画像の差し替え	テーマやsrcsetの出力調整
未使用画像の整理	CDN、Nginx、.htaccessの配信設定
簡単なPageSpeed確認	CTA、フォーム、計測イベントの確認

専門家に相談すべき境目は、作業が難しいかどうかではありません。失敗したときに、問い合わせ、資料請求、広告LP、検索流入、管理画面、復元に影響するかどうかです。

たとえば、ファーストビュー画像がLCP対象になっている、CTA画像に文字が入っている、画像CDNやキャッシュプラグインを既に使っている、Nginx環境でWebP配信をしたい、既存画像が数千枚ある、といった場合は、事前設計なしで一括処理しない方が安全です。

WordPress画像圧縮を相談する判断基準は、プラグイン設定の難しさではなく、LCP、CTA、WebP配信、バックアップ、復元に失敗したときの影響範囲です。

Bitlightでは、画像圧縮だけを単発作業として見るのではなく、重い画像の棚卸し、LCP改善、ファーストビューとCTAの確認、WebP/AVIF配信、今後のアップロード運用まで含めて、WordPress高速化と保守改善の一部として整理できます。