画像WebP 化でサイト高速化のつもりが、思わぬ落とし穴にハマる
画像のWebP化でサイト高速化を狙ったものの、WP-Optimize ではうまくいかず削除した途端に WordPress の挙動が不安定になり、WebP も正しく配信されないという想定外のトラブルが発生しました。本記事では、その原因となった“不完全アンインストール”の正体と、実際に行った解決手順を詳しく書き残します。
PageSpeed Insights でパフォーマンス測定
Google が提供している無料の速度計測ツール「PageSpeed Insights」で当サイトをチェックすると、結果は次のようになった。
- 携帯電話：パフォーマンス77（画像上）
- デスクトップ：パフォーマンス95（画像下）
モバイルの数値は悪くはないものの、最適化の余地はある。そして PageSpeed Insights からは、画像に対して次のような指摘も出ていた。
最新の画像形式（WebP、AVIF）を使用するか、画像の圧縮率を高くすると、この画像のダウンロード サイズが改善する可能性があります。
画像WebP 化プラグイン、WP-Optimize を入れてみる
WordPress には、アップロードした画像を WebP 化して軽量化してくれるプラグインがいくつもある。中でも WP-Optimize は、
- 画像圧縮
- データベース最適化
- キャッシュ
- HTML/CSS/JS の圧縮
など、多機能で人気が高いようだ。
そこで WP-Optimize を導入してみたところ、キャッシュ機能は問題なく動作。しかし肝心の 画像の WebP 変換については、
- 自動変換を有効にしても反応せず、手動変換のみしか動かない
- 既存画像の WebP 変換は非常に遅い
- 表示される画像が WebP ではなく 元画像（PNG） のまま
という状態だった。
画像が 元の PNG のまま表示されていることに、実はしばらく気づかなかった。
基本的にこのあたりの仕組みはよく分かっていないので、「WebP に変換したはずだから、きっと大丈夫でしょ」と、根拠のない思い込みで完全に放置していたのである。
しかし後日になって段々と気になり始め、「レスポンスヘッダで、表示中の画像が本当に WebP なのかを確認する」という、今さらすぎる基礎知識をようやく習得。おそるおそるレスポンスヘッダを確認してみたところ——
content-type: image/webp ではなく
content-type: image/png
……はい、完全に OUT！
そこでようやく、「WebP 表示が全然できてなーい！」と気づいたわけである。
WebP Converter for Media も試してみる
そこで、WP-Optimize の画像圧縮機能をOFFにし、代わりにこちらも有名な画像軽量化プラグイン WebP Converter for Media を導入した。
しかしこちらも、
- アップロード画像の自動 WebP 化はやはり動かない
- WebP の自動表示も切り替わらない
という状況で、やはり望む成果は出なかった。
とはいえ、既存画像の変換スピードは非常に速いため、このプラグインは残し、WP-Optimize は 無効化 → 削除 することに。
—— そして、ここから本当のトラブルが始まった。
ポチップ
WP-Optimize の削除で起きたエラーと、完全削除までの全手順
■発端：WP-Optimize 削除後、WordPress の挙動がおかしい
（Xserver 利用／WordPress）
WP-Optimize をインストール後に無効化 → 削除を行ったものの、しばらくして サイト表示が重くなる不具合 が発生。しかも、このサイトだけでなく、同じサーバーで運用している他のサイト にも症状が波及した。
Xserver のWebサイトトラブル診断で確認すると、以下の警告が表示される。
「使用中のバージョンで動作未確認」
「Webサイトに問題が見つかりました」
さらに WordPress 側では、メディア関連ページを開くたびに次の PHP 警告が発生していた。
PHP Warning: Undefined array key “extension”
（wp-optimize/webp/class-wp-optimize-webp-images.php）
本来であれば、プラグインは 無効化 → 削除 すれば影響が完全に消えるはず。しかし、WP-Optimize 削除後も WordPress が不安定なままという異常な状態が続いた。
そして、FTP で確認すると、 /wp-content/plugins/ 内には wp-optimize フォルダが存在しなかった。
つまりフォルダは削除されているが、動作は停止してない“形だけの削除”状態だった。
■ つまり、実際に起きていたこと
●原因：プラグイン「WP-Optimize」の不完全無効化・不完全アンインストール
WordPress ダッシュボードで「無効化 → 削除」を行ったにもかかわらず、
- 内部設定やフックだけが “有効化されたまま”残留
- プラグイン本体フォルダはサーバー上に存在しない
という、通常では起こらない状態になっていた。
その結果、WordPress は 存在しないファイルを読み込もうとして PHP 警告を出し続けていた。
このため、
- Xserver の Webサイトトラブル診断でもエラー扱い
- WordPress のメディア周りで不自然な挙動
- サイト全体の動作が重くなる
といった症状が連鎖的に発生していた。
■ なぜ「不完全アンインストール」が起きたのか？
Webで情報を調べたところ、WordPress プラグインは “無効化→削除” を行っても、wp_options テーブル内の設定（オプション）が自動では消えず、そのまま残留してしまうことがある、と WordPress.org のフォーラムや StackExchange でもたびたび指摘されています。
今回のケースのような「不完全アンインストール」が起こりやすい原因としては、以下が代表的です。
● 不完全アンインストールの主な原因
- Xserver 側の書き込み制御で、ファイル削除が中断されることがある
- ラグインのインストール／削除処理の途中でタイムアウトする
- WP-Optimize 側が PHP バージョンに完全対応していないタイミングだった
- プラグインの初期化・削除に必要な通信が途中で切れる
- WordPress 内部の transients / options が壊れたまま残留する
参考になるWeb ページ（一般論としての資料）
■ 今回のケースに最も当てはまる事象
WP-Optimize の WebP 機能部分（class-wp-optimize-webp-images.php）だけが設定として残存 し、
- プラグイン本体は削除されている
- だが WordPress が「まだ有効なプラグイン」として処理し続けた
- 結果、存在しないフォルダ・ファイルを読み込もうとして Undefined array key エラーが発生
という流れが最も自然に説明できる。
つまり、WP-Optimize の WebP 関連の内部処理が壊れたまま、WordPress の内部に“ゴミ”として残り続けたことが原因。
これにより、削除後も WordPress 全体の挙動が乱れ、他プラグインにも悪影響を与える「不完全アンインストール」が発生していたと考えられます。
■ 問題を整理するために実施した調査
① サーバー側：プラグインフォルダを確認
まず FTP で以下のディレクトリを確認。
/wp-content/plugins/
（wp-optimize フォルダなし）
→ 不完全アンインストール確定。
プラグイン本体がないのに、WordPress 側で“有効化の名残”だけ残っている可能性が高い。
② WordPress 側：データベースを調査
サイトのDB 名が不明、さらにphpMyAdmin の接続情報を完全に忘れていたので、wp-config.php 内の表記を確認し、
- DB 名
- DB ユーザー
- パスワード
を再取得してログイン。
そこで wp_options テーブルを検索しました。
検索条件
- option_name LIKE ‘%optimize%’ → ヒットなし（＝WP-Optimize の設定項目は消えている）
- option_name LIKE ‘%wpo%’ → “WP-Optimize の残骸”と思われる項目がヒット
- option_name LIKE ‘%webp%’ → WebP Converter for Media が作った画像情報が大量にヒット
特に WP-Optimize の残骸と思われる項目は。
_transient_timeout_wpo_minify_get_cached_files
_transient_wpo_minify_get_cached_files
_transient_timeout_wpo_get_current_db_size
_transient_wpo_get_current_db_size
→ プラグイン本体は無いのに、transients（WP の一時キャッシュ情報）だけが残っている状態。
③ エラーの原因をほぼ確定
- プラグイン本体は存在しない
- しかし WordPress は「有効化されている」と誤認したまま
- DB 内に一部設定・transients が残存
- WebP 関連のファイルを読み込もうとして PHP 警告が発生
これは “不完全アンインストール”の典型的なパターンと一致。
■ 解決手順（実際に行った操作）
手順1）phpMyAdmin で active_plugins を修正
WordPress の有効化プラグイン一覧は
wp_options → option_name = active_plugins に格納されている。
ここから wp-optimize の1行だけ削除。
→ 「存在しないプラグインを読み込もうとする状態」が解消。
手順2）WP-Optimize の残骸 transients を確認
wpo% で検索して、minify 関連のキャッシュ残骸が存在することを確認。
transients は WordPress が自動削除するため、基本的に放置で問題なし。
（必要なら削除しても良い）
手順3）uploads / WebP 画像の確認
uploads/年/月/ 内には WebP Converter for Media が生成したWebP画像が多数あったが、WP-Optimize とは無関係。
→ 削除不要。
※WebP が表示されない問題は別要因。
手順4）Xserver のサイト診断が全サイトで正常に戻る
wp-optimize の“誤った有効化状態”を解除した直後、同アカウント内の他ドメインに出ていた診断エラーも全て消失。
おそらく、
- 同アカウント内のサイトで発生している PHP 警告
- それを Xserver の診断ツールが横断的に拾っている可能性
といった理由で、1サイトのエラーが他サイトにも影響していたように見える。
（※仕様を断定はできませんが、実際にこの挙動が起きた）
■ 残っている問題：WebP が表示されない
WebP Converter for Media は、
- 手動変換 → 正常
- 自動変換 → 動作しない
- 変換済み WebP の表示 → されない
という状態。
→ .htaccess の rewrite 設定が壊れている／優先順位がおかしい可能性 などを調査する必要あり。
（これは別途対応予定）
■まとめ（要点）
- WP-Optimize を削除した結果、「プラグイン本体が無いのに有効化されたまま」という壊れ方をした
- DB には一部設定だけが残り、PHP が「存在しないファイル」を読みに行って警告発生
- Xserver の診断ツールがアカウント単位でエラーを拾っている可能性があり、他サイトまで巻き込まれた
- phpMyAdmin で active_plugins を手動編集 → 問題解決
- FTP 側はフォルダ残骸なし
- DB の transients は残っても害なし（自動で消える）
