WordPressの画像圧縮｜プラグインあり・なし両方の最適解

画像圧縮の話は「とりあえず最適化プラグインを入れましょう」で終わらせられがちですが、それだと入れなくていい人まで入れることになります。プラグインは1本増えるごとに更新と互換性の面倒を抱えるので、要るのか要らないのかを先に決めた方がいい。

結論を先に書きます。

• 既に数百枚の画像を抱えているサイト → 一括最適化プラグイン（EWWW、ShortPixel など）で過去分をまとめて処理する。これが最も効く
• これから運用を始める、または枚数が少ないサイト → アップロード前に圧縮する運用にすれば、プラグインは不要
• スマホで撮った写真をそのまま上げている → まずここを直す。1枚3〜6MBの原本を上げているなら、他の対策より効果が大きい

その前に：WordPressは既に圧縮している

意外と知られていませんが、WordPressは何もしなくてもJPEGを再圧縮しています。アップロードした画像は品質82で保存し直され、原本そのままでは保存されません（WordPress 4.5以降の既定値）。

さらにWordPress 5.3以降は、長辺が2560pxを超える画像を自動でリサイズします（big_image_size_threshold）。デジカメやiPhoneの原本をそのまま上げても、表示用には縮小版が使われる仕組みです。

品質を変えたい場合は、テーマの functions.php に次を追加します。

add_filter('jpeg_quality', function () {
  return 75; // 既定は82。下げるほど軽くなるが劣化も進む
});

ただし75を下回ると、写真では輪郭のノイズが見えるようになります。数値を下げるより、後述する「アップロードする画像そのものを小さくする」方が副作用がありません。

方法1: プラグインで自動圧縮する

既にメディアライブラリに大量の画像がある場合、これが最短です。過去分の一括処理（バルク最適化）ができるのがプラグインの最大の価値で、新規アップロード分の自動圧縮はおまけと考えていい。

プラグイン	特徴	向いているケース
EWWW Image Optimizer	サーバー内で処理でき、無料枠でも枚数制限がない。WebP変換も可能	枚数が多く、外部APIに送りたくない
Smush	設定が平易でUIが分かりやすい。無料版は一度に処理できる枚数に制限あり	とりあえず始めたい、枚数が少ない
ShortPixel	圧縮率が高い。月あたりの処理枚数でクレジットを消費する方式	画質を保ちつつ限界まで削りたい
Converter for Media	WebP/AVIF変換に特化。圧縮そのものより配信形式の最適化	WebP配信を入れたい

どれを選んでも、必ずバックアップを取ってから一括処理を始めてください。「劣化が気に入らないので元に戻したい」は後から効かないことがあります。復元用に原本を保持するオプションがあるプラグインでは、サーバー容量を食う代わりにそれを有効にしておくと安全です。

プラグインを入れないという選択

最適化プラグインは、アップロードのたびに画像処理を走らせます。共有サーバーだとこれがCPU制限に触れることがあり、大量アップロード時にタイムアウトの原因になります。実際、画像がアップロードできない原因の1つが画像最適化プラグインとの競合です。

枚数が少ないサイトや、これから始めるサイトなら、そもそも圧縮済みの画像を上げる運用にした方が、サーバーもプラグイン一覧も軽く保てます。

方法2: アップロード前に圧縮する

根本的にはこちらの方が筋がいい。サーバーに送るデータ量自体が減るので、アップロードも速くなります。

PCでやる場合

1. Squoosh（ブラウザで完結、Google製）に画像をドロップして品質を調整
2. ImageOptim（Mac）でフォルダごとドラッグして一括処理
3. 長辺は1600px程度あれば記事本文には十分。2560pxを超えるとWordPress側でどのみちリサイズされる

スマホでやる場合

ここが一番詰まります。iPhoneの写真アプリには一括リサイズ機能がなく、1枚ずつ編集アプリを通すのは現実的ではありません。しかもiPhoneの写真は1枚3〜6MB、Proモデルで10MBを超えることもあるので、そのままだとサーバーの upload_max_filesize に引っかかります。

SnapPress は送信時に画質を3段階（高画質/標準/軽量）から選べるので、圧縮のためだけに別アプリを経由する必要がありません。HEICのJPEG変換も同時に走ります。iPhoneから写真を上げる運用なら、サーバー側にもプラグイン側にも圧縮の仕事を持ち込まずに済みます。

WebPに変換すべきか

WordPress 5.8以降、WebPファイルはそのままアップロードして使えます。ただしJPEGから自動でWebPを生成する機能はコアに入っていません。WordPress 6.1で提案されましたが、サーバー負荷とストレージ増加を理由に見送られました。

WebP配信をしたいなら、Converter for MediaやEWWWのようなプラグインか、CloudflareなどCDN側の画像変換を使います。同じ見た目でJPEGより25〜35%小さくなるので、写真が多いサイトほど効果が出ます。

一方、既にJPEGを適切なサイズに圧縮できているなら、WebP化の追加効果は限定的です。1枚1MBの画像を放置したままWebP化しても、根本は解決しません。順番としては「サイズを適正化する」が先、「形式を変える」が後です。

どこまで圧縮すればいいのか（数値の目安）

用途	推奨サイズ	目標ファイルサイズ
記事本文中の画像	長辺1200〜1600px	100〜200KB
アイキャッチ画像	1200×630px	150KB前後
ヘッダー・ヒーロー画像	1920px幅	200〜300KB
サムネイル・アイコン	実表示サイズの2倍まで	30KB以下

厳密な正解はありません。判断基準はCore Web VitalsのLCP（最大コンテンツの描画）が2.5秒以内に収まるかどうかで、そこさえ満たせば数値を追い込む必要はない。アイキャッチのサイズ設計そのものは WordPressアイキャッチ画像のサイズは1200×630pxが基本 にまとめてあります。

圧縮したのに速くならない時に見るところ

よくあるのが、圧縮はできているのに表示が改善しないパターンです。原因は画像以外にあることが多い。

1. HTMLで過大な画像を呼んでいる — 400px幅の枠に1600pxの画像を読ませていないか。srcset が効いているかを確認する
2. LCPが画像ではない — PageSpeed Insightsで「最大コンテンツの描画」がどの要素かを見る。フォントやJavaScriptが原因なら画像をいくら削っても変わらない
3. 遅延読み込みの掛けすぎ — ファーストビューの画像に loading="lazy" が付いていると、かえってLCPが遅くなる
4. CDNを通していない — 画像が1つのサーバーから直接配信されていると、物理的な距離の分だけ遅い

まとめ

• WordPressは既にJPEGを品質82で再圧縮し、2560px超は自動リサイズしている。何もしていないわけではない
• 過去の大量画像があるならプラグインの一括最適化。それ以外はアップロード前圧縮で足りる
• WebPの自動生成はコアにない。プラグインかCDNが必要
• 目安は本文画像100〜200KB、アイキャッチ150KB前後。基準はLCP 2.5秒
• スマホの原本をそのまま上げているなら、まずそこ。他のどの対策より効果が大きい

画像の扱い全般は ワードプレス メディアライブラリ完全ガイド、アップロードが失敗する場合は WordPressで画像がアップロードできない原因8つと対処法 をどうぞ。