WordPressの画像表示を最適化するために画像圧縮プラグイン「EWWW Image Optimizer」を導入しました

これは、WordPressの画像が多すぎる問題に「画像をWebP化」で挑んだ備忘録（EWWW導入〜画像が消えるトラブル解決まで）です。
WordPressでは記事数・画像数が増えると、どんどん「不安」も増していきます。当サイトも記事が7,000件近くになり、ファイル容量や表示速度が気になってきました。画像は基本的に幅640pxでリサイズしてJPG中心にしていたので、「そこまで重くないはず」と思っていました。
それでも、リサイズを忘れて大きいまま投稿した画像もありますし、最近はWebPで劇的に軽くする事例も増えています。
そこで、画像をWebP化するための対策を調べて実行しました。

画像をWebP化することで表示が早くなる

WebPとは（ざっくり解説）

WebP（ウェッピー）は、Googleが開発した「画像を軽くできる新しめの画像形式」です。見た目の画質をあまり落とさずに、JPGやPNGよりファイルサイズを小さくできるのが大きな特徴です。

なぜWebPが効くのか
・画像のデータ量が減る → ページの読み込みが速くなりやすい
・転送量が減る → モバイル回線の閲覧にもやさしい
・画像が多いサイトほど効果が出やすい（記事数が多いブログ、商品画像が多いECなど）

JPG/PNGとの違い（イメージ）
・JPG：写真向き。古くからある。容量はやや大きめになりがち
・PNG：透過できる。図やロゴ向き。容量は大きくなりやすい
・WebP：写真も図もいける。容量を小さくしやすい（ただし設定や配信方法がポイント）

注意点（ここが実務では大事）
WebPは「WebPに変換しただけ」では効果が出ません。実際の表示でWebPを配信できて初めて軽くなります。
そのためWebP対応は次の2段階で考えると整理しやすいです。

1 生成：WebPファイルを作る（例：xxx.jpg.webp を作成）
2 配信：対応ブラウザにWebPを返す（例：.htaccessで自動出し分け）

この記事では、この2段階を意識しながら、EWWW導入からトラブル解決までの実例を紹介します。

WordPressではプラグインでwebp化できます

そこで今回、WordPressの画像をWebPで配信する仕組みを本格的に整えました。
結果としてはうまくいったのですが、途中で「画像が消える」というトラブルもありました。

同じ悩みを持つWEB担当者の方の参考になるよう、検討から実践までを備忘録としてまとめます。

結論（先に要点）
・WebP化は「画像ファイルを作る」と「配信でWebPを返す」の2段階
・EWWW Image Optimizer でWebP生成はできる
・画像が見えない原因はEWWWそのものではなく、遅延読み込み（lazyload）とその周辺の相性だった
・最終的に .htaccess のWebP配信設定を整えて、ChromeのNetworkで Content-Type: image/webp を確認して完了

画像をWebPで表示する方法を比較検討

目的はシンプルです。

・サーバー容量を増やしたくない
・表示速度の不安を減らしたい
・できれば既存の大量画像もまとめて対応したい

ただし、WordPressのWebP対応は「やり方が複数あって混乱しやすい」と感じました。

大きく分けると次の2タイプがあります。

案A：EWWW Image Optimizer

• 特徴: 画像の「圧縮（ファイルサイズ削減）」と「WebP変換」の両方ができる老舗。

• デメリット: 高性能な圧縮機能を使うには有料プランへの誘導がある。また、サーバーへの負荷が比較的高め。

• 判定: 画像そのものを小さくする「圧縮」も同時にしたいならアリですが、設定が少し複雑で難易度が高めです。

案B：Converter for Media（旧 WebP Express）

• 特徴: 「WebPへの変換と配信」に特化したプラグイン。

• メリット:

  • 無料: 基本機能が無料で優秀。

  • 元データを汚さない: 元のJPG画像は触らず、別フォルダにWebP版を作成して配信する仕組みなので、いつでも元に戻せる安心感があります。

  • エックスサーバーと相性が良い: サーバーの設定（.htaccess）をうまく書き換えて高速配信してくれます。

• 判定: リスクを最小限に抑えたいならB案が適しています。

私の場合は別サイトで案A（EWWW）を使いたいという理由もあったため、学習と実験も兼ねて、当サイトでもEWWWを採用することにしました。

プラグイン比較の結果：EWWWを選択した理由

今回選んだのは EWWW Image Optimizer です。

EWWW Image Optimizer

より小さな画像、より速いサイト、より幸せな訪問者。ロケット工学の学位を必要としない、包括的な画像最適化です。

ja.wordpress.org

選択理由
・老舗で情報が多い
・圧縮もWebPも対応できる
・既存画像の一括処理ができる

注意点（先に知っておくと安心）
・高性能な圧縮は有料プラン誘導がある
・画像数が多いと処理時間が長い
・設定項目が多く、周辺機能（遅延読み込み等）との相性が出ることがある

実際にやった手順（導入から一括処理まで）

ここからは実際の流れです。

EWWWを入れて設定

・EWWW Image Optimizer をインストール
・WebP変換を有効化
・画像サイズ制限（Max Image Dimensions）を設定

今回のサイトでは画像幅640px運用なので、基本は
・Max Width = 640
・Max Height = 0（高さは制限しない）
にしました。

縦長画像で高さが1000px以上になるケースがあるため、高さを固定してしまうと意図しない縮小が起きやすいからです。
「幅だけ制限」は運用として事故が少ないです。

一括最適化を開始

画像数が多いサイトでは、ここが最大の山場です。

・total images が数万単位になる
・進捗がゆっくりに見える
・サーバー負荷の影響も受ける

私の環境でもかなり時間がかかりました。（処理時間は約６時間でした）
この時点で大事なのは、「途中で止めたくなる気持ち」を抑えて淡々と進めることです。

トラブル発生：記事の画像が見えない

一括処理を進めている途中から、記事の画像が表示されなくなりました。
編集画面では見えるのに、公開ページで見えないという症状です。

HTMLを確認すると、画像タグがこうなっていました。

・src が base64 のプレースホルダー（透明PNGなど）
・本来の画像URLは data-src に入っている

つまり「遅延読み込み（lazyload）」の形式になっていました。

この状態で、何らかの理由で遅延読み込みのJavaScriptが動かないと、画像は永久にプレースホルダーのままになります。
結果として「画像が消えたように見える」状態になります。

原因の切り分け：EWWWが悪いのか、遅延読み込みが悪いのか

ここは落ち着いて切り分けました。

やったこと
・Cocoon側の遅延読み込みをオフ
・EWWW側の遅延読み込みも停止
・エックスサーバー側のキャッシュ削除
・エックスサーバー側の高速化機能（JS遅延など）を必要に応じてオフ

結果として、遅延読み込みを止めると画像が表示されました。

このことから分かったのは、
「WebP化そのもの」ではなく、
「遅延読み込み周辺の挙動」が原因だった
という点です。

つまり、WebP化は進めてよいが、遅延読み込みは慎重に扱う必要がある、ということです。

最終対応：「.htaccess」 を調整してWebP配信を完成させる

EWWWで WebPファイル（.jpg.webp）が生成されていることは確認できました。
例　https://…/xxxx.jpg.webp が存在する

次は、対応ブラウザに対してWebPを返す設定です。
この配信切り替えは .htaccess で行いました。

ポイントは次の考え方です。

・ブラウザが WebPに対応しているときだけ WebPを返す
・元の jpg は残す（非対応ブラウザ用の保険）
・uploads配下の画像だけを対象にして安全性を上げる
・キャッシュの誤配信を避けるため Vary: Accept を付ける

この調整を入れたことで、HTMLは .jpg のままでも、実際にはWebPが返るようになります。

「.htaccess」の記述方法について

.htaccess の要点

目的
・WebP対応ブラウザだけに WebP を返す
・元のJPG/PNGは残して、非対応ブラウザには従来どおり返す
・対象を uploads 配下に限定して事故を防ぐ
・キャッシュ誤配信を防ぐため Vary: Accept を付ける

ポイントになる構造
1 WebPに対応しているか判定
・条件：HTTPヘッダ「Accept」に image/webp が含まれるときだけ

2 対象を限定
・対象パス：/wp-content/uploads/ 配下だけ（テーマ画像などは除外）
・対象拡張子：jpg / jpeg / png（必要ならgifも）

3 WebPファイルが存在する場合だけ切り替え
・「元画像 + .webp」が存在するときだけリライトする
例
・元画像：/wp-content/uploads/YYYY/MM/xxxx.jpg
・WebP： /wp-content/uploads/YYYY/MM/xxxx.jpg.webp
この WebP が存在する場合のみ、内部的に WebP を返す

4 内部リライト（URLは変えず中身だけ差し替え）
・ブラウザのURLは .jpg のまま
・サーバーが返す実体は .jpg.webp にする（内部処理）

5 ヘッダ（キャッシュ事故防止）
・画像レスポンスに Vary: Accept を付ける
これがないと「WebP非対応の人にWebPが配られる」などの事故が起きやすい

6 MIMEタイプ（念のため）
・.webp を image/webp として扱う設定を入れる（すでにある場合は不要）

「.htaccess」のサンプル（雰囲気だけ）
・<IfModule …>
・RewriteEngine …
・RewriteCond %{HTTP_ACCEPT} …[webp…] ・RewriteCond %{REQUEST_URI} …[/wp-content/uploads/…] ・RewriteCond %{REQUEST_FILENAME} …[jpg/png…] ・RewriteCond %{REQUEST_FILENAME}…[.webp exists…] ・RewriteRule … [….webp … T=image/webp …] ・Header append Vary Accept …
・AddType image/webp .webp

補足
・この方式は「HTMLを書き換えない」ので、見た目は .jpg のままでも、Networkで Content-Type: image/webp になっていれば成功です
・確認は シークレット + F12(Network) で Content-Type を見ます

最終確認：シークレット + F12(Network) で「Content-Type」を見る

「本当にWebPで配信されているか」はHTMLを見ても確定できません。
なぜなら、.htaccess方式はHTMLを書き換えず、サーバーが返す中身だけをWebPに差し替えるからです。

そこで最後は ブラウザのシークレットウィンドウで確認しました。

確認手順
1 シークレットウィンドウで該当記事を開く（キャッシュの影響を減らす）
2 F12で開発者ツールを開く
3 Network を開く
4 Img を選んで画像リクエストだけ表示
5 対象画像をクリック
6 Response Headers の Content-Type を確認

ここが
Content-Type: image/webp
になっていれば、WebP配信は完成です。

実際に私の環境でも Content-Type: image/webp を確認でき、これで完了と判断しました。

エックスサーバーの高速化設定を見直し

エックスサーバーはWordPressの高速化に関して最適化されています。しかし、今回の設定では「遅延読み込み」で問題が起きたため、慎重に設定をしなおすことにしました。

画像最適化については、今回設置したプラグインでwebp化ができているのでオフのままにします。
画像遅延読み込みとJavaScript遅延読み込みについては、当面の間はオフのままで運用するつもりです。

まとめ：同じ悩みのWEB担当者に伝えたいこと

WordPressで記事数・画像数が増えてくると、画像最適化は避けて通れません。
WebP化は効果が大きい一方で、トラブルも「WebPそのもの」ではなく周辺の高速化機能（遅延読み込み・キャッシュ・JS最適化）で起きがちです。

今回の学びを短くまとめるとこうです。

・WebPは「生成」と「配信」を分けて考えると整理しやすい
・画像が消えたら、まず lazyload のdata-src形式になっていないか確認
・まずは遅延読み込みを止めて表示が戻るかで原因を絞る
・最後はシークレット + Networkで Content-Type を見て確定する

今後の運用メモ（私の方針）
・WebP配信は維持
・遅延読み込みは、導入するなら段階的に（いきなり全部ONにしない）
・高速化設定は「体感が速い」より「事故らない」を優先

同じように「画像が多すぎて不安」になった方の参考になれば幸いです。