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

「最近、サイトの表示が重たい気がする…」そんな悩みはありませんか？記事が増えるにつれて画像も蓄積し、どうしても読み込みが遅くなってしまいがちです。そこで今回は、画像を「WebP」という最新形式に変換し、ファイルサイズをギュッと縮小してサイトを高速化する作戦を実行しました。
難しい作業はプラグインにお任せ。WordPressを使って既存の大量画像を​​一気に軽くする手順と、途中で直面した「画像が消える！？」というトラブルの解決法までを分かりやすくレポートします。サイトの重さに悩む担当者の方はぜひ参考にしてください。

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

WebPとは（ざっくり解説）

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

特に効果が高いのが「PNGで保存してしまった写真データ」などで、WebP化によってファイルサイズが1/10以下になるケースも珍しくありません。JPGの場合でも、平均して2〜3割のサイズダウンが見込めますし、1200ピクセル以上の大きな画像では半分くらいのサイズになることもあります。

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

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

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

1 生成：jpgから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」です。

EWWW Image Optimizer

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

ja.wordpress.org

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

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

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

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

EWWWを入れて設定

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

今回のサイトでは画像幅640px運用なので、基本は
・Max Width = 0
・Max Height = 0
にしました。
※0にするのは数値での制限をしないということです

理由はいくつかあります。左右640ピクセルにした画像が多いのですが、過去の記事では意図しないサイズのものも混在しています。また縦長画像で高さが1000px以上になるケースがあるため、高さを固定してしまうと意図しない縮小が起きやすいからです。

一括最適化を開始

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つまり、WebP化は進めてよいが、遅延読み込みは慎重に扱う必要がある、ということです。WordPressでは「遅延読み込み」を行う複数のサービスがあるため、あちこちで遅延読み込みをさせると動作が不安定になります。
これは、PCに複数のウイルスソフトを入れて動作がおかしくなる現象と似てますね。ここではいったんすべての遅延読み込みを停止しました。（のちほど徐々にどの遅延読み込みを使うべきか検証します）

最終対応：「.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 を確認できました。これでwebp化とその表示に関する処理は完了です。

ここからはさらに高速化のチューニングです

ここからは、さらなる表示の高速化をめざしたチューニングです。いったん、オフにしていた遅延処理も状況に応じて復活させていきます。このことで、webp化された画像とともにサイト表示の高速化を狙います。

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

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

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

CocoonのLazy Loadを有効にする

その後、高速化についての微調整をしたところ、CocoonのLazy Loadを有効にすると効果がありました。

なお、最終的に除外の設定に６行追加したのがポイントです。

logo
carousel
slide
main-visual
eye-catch
wp-post-image

logoやeye-catchなどは遅延読み込みさせないほうがよいということです。とくにトップページに限っては、カルーセルを使っているため、carouselを遅延読み込みをさせないほうがよいということがわかりました。

Cocoonの事前読み込みを削減する

なお、Cocoonにはいろんな機能が実装されています。そのひとつが事前読み込み設定です。これはフォントや外部のリソースを事前に読み込んでおくことで、人間がみたときに遅延が減るということです。

しかし、読む必要がないリソースまで事前読み込みすることによって、WEBサイトの初期表示速度を遅くしています。

そこで、不要だと思われるリソースを削除して、以下のように５つに削減しました。

残したリソース配下の５つです。

fonts.googleapis.com
fonts.gstatic.com
ajax.googleapis.com
cdnjs.cloudflare.com
cdn.jsdelivr.net

これで最小限度の事前読み込みになったのではないかと思います。

PageSpeed Insights（ページスピードインサイト）の結果

これらの設定が終わった段階で、「PageSpeed Insights」でトップページや投稿ページの表示速度評価をしました。

PageSpeed Insights

pagespeed.web.dev

 

FCPがこれまで6秒程度だったのが2.9秒に高速化できました。

体感的な表示速度はかなり高速化しています。トータルのパフォーマンス評価が72になり、これまでよりは格段によくなりました。トップページだけでなく個別投稿ページの測定もだいたい同じような感じでした。

なので総合的な高速化の成績はまずまず良好になったのではないかと思います。

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

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

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

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

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

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