EWWW Image Optimizer 使い方｜中小企業のサイト表示速度を改善する設定手順

「画像が重くてサイトが遅い、でも何から手を付ければいいか分からない」——中堅企業の発信担当者から、よくいただくご相談です。結論から言うと、EWWW Image Optimizerは「インストール→ウィザード→3タブ調整→Bulk Optimize→WebP配信→効果測定」の6ステップで使いこなせます。無料モードのままでも、JPEG/PNGの自動圧縮とWebP変換まで担えるのが強みです。本記事では、前提条件・初期設定・推奨タブ設定・一括最適化・サーバー別WebP配信・NG例・PageSpeed Insightsでの効果測定を順に整理します。画像最適化を「半年後に効いてくる蓄積資産」として運用したい担当者の方に、お役に立てれば嬉しく思います。

EWWW Image Optimizerとは｜中小企業がまず押さえる全体像

EWWW Image Optimizerとは、WordPressにアップロードした画像を自動で圧縮し、サイトの表示速度を改善する無料プラグインのことです。例えばJPEGやPNGを入れた瞬間にファイルサイズを軽くし、WebP形式への変換まで担います。中堅企業の発信担当者にとって、画像加工の専門知識がなくても画質を保ったまま容量を抑えられる、定番の選択肢と言えます。

プラグインが担う3つの役割（圧縮・リサイズ・WebP変換）

EWWW Image Optimizerが担う役割は、圧縮・リサイズ・WebP変換の3つに整理できます。まず圧縮は、画質をほぼ落とさずにファイルサイズだけを削るロスレス圧縮が基本です。次にリサイズは、アップロード時に最大幅を超える画像を自動で縮小し、元データの肥大化を防ぎます。

WebP変換とは、Googleが推奨する次世代画像形式へ自動で書き換える機能のことです。例えば同じ写真でもJPEGに比べて25〜35%ほど軽くなる傾向があり、表示速度の体感差が大きく出ます（参考: Google web.dev / WebP）。

私が運用するハッシンラボ Premiumのサイトでも、画像を多用するコラム記事のLCPがWebP導入後に明確に改善しました。@shige も「画像を軽くすると、サーバー負担と表示速度の両方が変わる」と動画で解説しており、現場感覚と一致します。

無料版と有料版（Easy IO・API）の違い

EWWW Image Optimizerには無料モードと、有料のEasy IO（画像CDN）・APIプランがあります。中堅企業の自社サイト規模であれば、無料モードで十分実用に耐えます。Easy IOは月数万PV超のメディアサイトで、画像をCDN経由で配信したい場合に検討する位置づけです。

APIプランは、画質を維持したまま強めに圧縮したい高画質写真サイト向けです。判断軸は「画像枚数」「月間PV」「画質要件」の3つ。迷ったら、無料モードで運用を半年回してから、必要に応じて段階的に有料機能を足す進め方が安全です。

ほかの画像最適化プラグインとの位置づけ

画像最適化系プラグインには、Smush・Imagify・ShortPixelなどの選択肢が並びます。EWWW Image Optimizerの強みは、無料モードでもサーバー内処理ができる点です。Smushの無料版は外部API経由が中心で、月間処理枚数に制限があります。

中堅企業のサイトで「まず一つ入れる」段階なら、EWWW Image Optimizerは堅実な選択です。サイト規模が大きくなった段階で、Easy IOへの移行か、CDN+別プラグインの組み合わせに切り替える設計が現実的と言えます。

導入前に確認したい3つの前提条件

EWWW Image Optimizerは便利ですが、入れる前に押さえたい前提が3つあります。PHPバージョン・他プラグイン競合・バックアップの3点です。中堅企業のサイトでは更新が止まっているケースも多く、ここを飛ばすと表示崩れや、復元不能な圧縮事故につながります。

PHP7.4以上・WordPress最新版が動いているか

EWWW Image Optimizerは、WordPress公式プラグインページ上でPHP7.4以上を推奨しています（参考: WordPress.org / EWWW Image Optimizer）。古いPHPでも動く場合はありますが、サポート対象外になると将来のセキュリティ更新が止まります。

確認手順はシンプルです。WordPress管理画面の「ツール → サイトヘルス → 情報 → サーバー」を開けば、現在のPHPバージョンが表示されます。7.4未満であれば、まずレンタルサーバーの管理画面からPHPを上げる作業が先です。WordPress本体も最新メジャーバージョンに揃えておくと安心です。

画像系・キャッシュ系プラグインとの競合チェック

すでにSmushやImagify、Autoptimize、W3 Total Cache等を入れている場合、競合に注意が必要です。画像最適化系は原則1つに絞ります。複数併用すると二重圧縮で画質が荒れたり、メタデータが消えて差し替え時に困る事態に陥ります。

キャッシュ系プラグインは併用できますが、WebP配信の方式が重なるとうまく表示されない事例が出てきます。導入順序は「キャッシュ系設定 → EWWW Image Optimizer設定 → キャッシュクリア → 表示確認」の流れが安全です。

更新前のバックアップ（UpdraftPlus等）とロールバック手順

Bulk Optimize前のバックアップは必須です。私の運用では、UpdraftPlusで「wp-content/uploads」配下をフルコピーしてから作業に入る手順を固定しています。@リオのブログカレッジ も同様の手順を動画で紹介しており、業界標準のフローと捉えてよさそうです。

ロールバック先のストレージはGoogle Drive・Dropbox等、サイト本体と別の場所に置きます。万一サーバー側の障害が起きても、バックアップが同じ場所に消える事態を避けられます。

インストールから初期設定までの基本手順

EWWW Image Optimizerの導入は、プラグイン検索から有効化までで完了します。初期設定はウィザード形式で進みますが、選び方を先に言語化しておくと迷いません。中堅企業の発信担当者でも10分前後で終わる流れを、画面の進行順で整理します。

プラグイン新規追加から有効化までのクリック手順

WordPress管理画面の「プラグイン → 新規追加」を開き、検索窓に「EWWW Image Optimizer」と入力します。開発元「Exactly WWW」と表示されるものが正規版です。「今すぐインストール」→「有効化」の2クリックで導入は完了します。

有効化直後、自動でウィザード画面に遷移します。遷移しない場合は「設定 → EWWW Image Optimizer」から手動で起動できます。インストール時点で他のプラグインが警告を出した場合は、その段階で一度停止して原因を切り分けます。

ウィザードでの推奨選択（サイトを高速化／無料モード）

ウィザードでは、「サイトを高速化」と「無料モード」を選ぶ流れが実務的に推奨されます。@さっとが@WordPressブログ×副業 と @リオのブログカレッジ も、それぞれ動画で同じ選択を勧めています。私のサイトも初期は無料モードで運用を回しており、不便を感じる場面はほぼ出ていません。

その後の質問では「メタデータの削除」「遅延読み込み（Lazy Load）」「WebP変換」の有無を聞かれます。メタデータ削除はオン、Lazy LoadはWordPress本体機能と重複するためオフ、WebP変換はオンが扱いやすい初期値です。

初期設定後にチェックする3つの管理画面

ウィザード終了後、必ず3つの管理画面を順に確認します。「設定 → EWWW Image Optimizer」「メディア → 一括最適化」「メディア → ライブラリ」の3つです。設定画面で各タブの初期値を見て、Bulk Optimize画面で対象枚数を把握し、ライブラリで個別画像の最適化状態を確認します。

ここで「EWWW Image Optimizer」列がライブラリ画面に追加されていれば、画像ごとの圧縮状況が一覧で見えるようになります。運用後の効果測定でも役立つ画面です。

推奨設定｜基本・変換・リサイズの3タブの埋め方

EWWW Image Optimizerの設定画面は項目が多く、初見では迷いやすい構成です。中堅企業のサイト運用では、基本・変換・リサイズの3タブを押さえれば実用上のチューニングが整います。それぞれ「触る項目」と「触らない項目」を分け、最短で安全側に倒します。

基本タブ：メタデータ削除・遅延読み込みのON/OFF判断

基本タブの要点は3つあります。メタデータ削除はオン、遅延読み込みはオフ（WordPress本体機能を使う）、画像最適化の品質はJPEG 82・PNG 9前後が無難な初期値です。メタデータとは、撮影時のカメラ情報や位置情報等のことです。例えばスマホで撮った画像には位置情報が含まれることがあり、公開時のプライバシー観点でも削除は理にかなっています。

品質値は数字が大きいほど画質を残す代わりに容量も残ります。JPEG 82は人の目で違いが分かりにくい水準で、ファイルサイズも十分軽くなります。82未満まで下げると、写真の肌色やグラデーション部分でムラが目立ち始めるため避けます。

変換タブ：JPEG⇄PNG自動変換は原則オフにする理由

変換タブで最も注意すべきは、JPEG⇄PNG自動変換は原則オフという点です。@ゆかチャンネル と @40JUMPUP! も同様の運用を動画で説明しています。私の現場でも、ロゴPNG（透過あり）が自動でJPEG化され、白背景に変わってしまった事故が過去にありました。

透過情報はJPEGに変換した瞬間に失われ、復元できません。ロゴ・アイコン・スクリーンショット等を扱うサイトでは、変換タブの全項目をオフにしておくのが安全側です。WebP変換は変換タブとは別管理で、こちらはオンのままで問題ありません。

リサイズタブ：最大幅2048pxを目安にする根拠と注意点

リサイズタブでは、最大幅2048px・最大高2048pxを初期値に置きます。一般的なPCディスプレイの解像度（フルHDで横1920px、4K表示でも横3840px）を踏まえ、原寸表示する用途以外は2048pxで十分な品質を保てます。

注意点は、リサイズが「元画像そのもの」を縮小する設定だという点です。一度リサイズすると元の高解像度版は失われます。撮影オリジナルを別フォルダで保管してからアップロードするか、リサイズ機能をオフにして手動で行うかの二択になります。

既存画像を一括最適化する（Bulk Optimize）の進め方

プラグイン導入後にアップロードする画像は自動で圧縮されますが、過去画像はBulk Optimize（一括最適化）で個別に処理します。中堅企業のメディアサイトでは数千枚たまっているケースもあり、ここで一度きれいに整理すると、表示速度の改善が体感できます。

Bulk Optimize実行前のバックアップ取得手順

Bulk Optimize前のバックアップは絶対条件です。私は「UpdraftPlusでuploads配下フルバックアップ→Google Driveへ転送→転送完了確認」の3ステップを固定運用にしています。@リオのブログカレッジ と @webサイトチャンネル も、それぞれ動画でバックアップの重要性に触れています。

復元用データを保持する設定（管理画面の「画像をバックアップ」相当の項目）も併せてオンにします。これにより、プラグイン側の「画像の復元」機能で個別ロールバックが可能になります。サーバー側スナップショットがある場合はそれも併用すると、二重の安全網が張れます。

実行画面の見方と途中停止・再開の方法

Bulk Optimize画面では、対象枚数と推定処理時間が事前に表示されます。「最適化を開始」ボタン押下後はリアルタイムで進捗が動き、ブラウザを閉じても処理は継続します。途中停止したい場合は「最適化を停止」ボタン、再開は同じ画面の「最適化を再開」で続きから処理されます。

サーバーのタイムアウト設定で処理が止まることもあります。途中で止まった場合は再開ボタンを押せば残り分から処理が走るため、強制終了で焦る必要はありません。

サーバー負荷を抑える夜間バッチ運用のコツ

数千枚規模のBulk Optimizeは、夜間バッチ＋途中停止前提で進めるのが現実的です。@リオのブログカレッジ と @webサイトチャンネル も、サーバー負荷の観点で同様の運用を勧めています。アクセスのピーク時間帯（昼休み・夜のゴールデンタイム等）を避け、深夜0時〜早朝5時の時間帯にバッチ実行する設計が安全です。

共有サーバー（さくらインターネット・エックスサーバー・ロリポップ等）を使っている場合、CPU使用率上限に引っかかるとサイト自体が一時的に重くなります。500枚〜1000枚程度に区切って数日に分散する運用も視野に入れます。

WebP配信の設定｜Apache・Nginx・Cloudflare別の進め方

WebPとはJPEG・PNGより容量が小さい次世代画像形式のことです。例えばGoogleが2010年に発表した形式で、Chrome・Safari・Firefox等の主要ブラウザがすでに対応しています（参考: Google web.dev / WebP）。EWWW Image OptimizerはWebPへの変換と配信の両方を担えますが、配信の仕組みはサーバー環境で分岐します。中堅企業がよく使うApache・Nginx・Cloudflareの3パターンを整理します。

Apache環境：.htaccessでのリライト設定とテスト方法

Apache環境では、EWWW Image Optimizerが.htaccessへ自動でリライトルールを書き込む方式が標準です。@リオのブログカレッジ と @shige も動画で同様の手順を解説しています。設定画面の「WebP配信方法」で「Apacheリライトを挿入」を選ぶと、必要なコードブロックが自動生成されます。

テストは管理画面内の「PNG/JPGテスト」ボタンで完結します。緑色の「WebP」と表示されれば配信成功、赤色なら.htaccessへの書き込み権限不足か、サーバー側でリライトモジュールが無効化されている可能性が高いです。レンタルサーバーの管理画面でmod_rewrite有効化を確認します。

Nginx環境：設定ファイル書き換えとSSL対応の注意点

Nginx環境では.htaccessが効かないため、Nginxの設定ファイル（nginx.conf または個別のserverブロック）に手動でルールを追記する手順になります。EWWW Image Optimizer設定画面に推奨コードが表示されるので、サーバー管理者がコピーして適用する流れです。

SSL対応サイトでは、httpsブロック側にもルールを反映させる必要があります。VPS運用なら自社で対応できますが、マネージドホスティングを使っている場合は提供事業者側のサポートに依頼するケースが多いです。

Cloudflare利用時：Polish機能との二重圧縮を避ける設定

Cloudflareを併用する場合、Polish機能（Lossy/Lossless）はオフに揃えます。@リオのブログカレッジ と @shige も同様の注意点を動画で扱っています。Polishとは、Cloudflare側で画像を自動圧縮・WebP変換する機能のことです。例えばEWWW Image Optimizer側でWebP変換した画像を、さらにCloudflare側で再変換すると二重圧縮になり、画質劣化や表示崩れが起きます。

Cloudflareの管理画面で「Speed → Optimization → Polish」を「Off」、「WebP」も連動してオフにします。CDN経由の高速化はキャッシュ機能側に任せ、画像最適化はEWWW Image Optimizerに一元化する設計が、運用上も管理しやすい形です。

中小企業がやりがちなNG設定と運用ルール

EWWW Image Optimizerは便利な反面、設定を間違えると画質劣化や復元不能の事故が起きます。中堅企業の現場でよく見る5つのNG設定を先に潰しておくと、長期運用で困りません。月1回の見直しと、担当者交代時の引き継ぎテンプレも合わせて整えます。

可逆圧縮を切って強圧縮にしすぎる

JPEG品質値を70未満まで下げる設定は避けます。圧縮率を上げれば容量は減りますが、写真のグラデーション部分でブロックノイズが目立ち始めます。JPEG 82・PNG 9前後を初期値にし、サイト全体のトーンを確認してから微調整する手順が安全です。

JPEG⇄PNG自動変換をオンにして透過が消える

変換タブの自動変換オンは事故の温床です。透過PNG（ロゴ・アイコン）が白背景JPEGに置き換わり、サイト全体のデザインが崩れます。基本姿勢は「変換タブは全項目オフ」で運用します。

リサイズ上限を設定せず元画像が肥大化する

リサイズタブで最大幅・最大高を未設定のままアップロードすると、撮影オリジナル（横6000px等）がそのまま入り、サーバー容量を圧迫します。2048px前後の上限値を置くと、容量と画質のバランスが整います。

Cloudflare Polishと二重圧縮で画像が荒れる

CloudflareのPolish機能とEWWWのWebP配信が両方オンだと、画像が二重に変換されて荒れます。CDNを使うなら、画像最適化の責任範囲をEWWW側に一元化する設計に揃えます。

Bulk Optimize後にバックアップを削除して戻せなくなる

Bulk Optimize完了後にバックアップを消すと、後から画質劣化が見つかっても戻せません。最低3か月はuploadsバックアップを保管する運用ルールに固定します。担当者交代時の引き継ぎ書類にも、この保管期間を明記しておきます。

導入後の効果測定｜PageSpeed Insightsで何を見るか

画像圧縮の効果は、感覚ではなく数値で確認します。中堅企業の発信担当者がまず使いやすいのはGoogle PageSpeed Insightsです（参考: PageSpeed Insights）。LCPと画像関連の指摘項目を月1回チェックする運用に落とすと、改善サイクルが定着します。

LCP（Largest Contentful Paint）の前後比較

LCPとは、ページ内で最も大きな要素が表示されるまでの時間のことです。例えばトップ画像やヒーロー画像が読み込まれる時点を計測する指標で、2.5秒以下が「良好」と判定されます（参考: web.dev / LCP）。

EWWW Image Optimizer導入前後で、同じURLのLCPを比較記録します。私のサイトでは、Bulk Optimize完了後にLCPが0.8秒前後改善する事例が出ています。数字で動きが見えると、社内報告にも使える資料になります。

「次世代フォーマットでの画像配信」項目の解消確認

PageSpeed Insightsの「改善できる項目」内に、「次世代フォーマットでの画像配信」という指摘が出ているケースがあります。WebP配信設定が正しく効いていれば、Bulk Optimize完了後にこの項目が消えるか、対象画像数が大幅に減ります。

消えていない場合は、配信設定（.htaccess書き換え・Cloudflare Polishのオフ等）のどこかでつまずいています。設定画面の「PNG/JPGテスト」を再実行して、緑色のWebP表示が出るかを確認します。

月次レポートに残す3指標と判断基準

月次レポートには、LCP・「次世代フォーマット」指摘の有無・画像総容量の3指標を残します。Googleスプレッドシートで月次に1行ずつ追記する運用が、軽くて続けやすい形です。3か月続けると、サイト改善のトレンドが線で見えてきます。

画像最適化は蓄積型発信の基盤づくりと言えます。記事を書き続けても、表示速度が遅ければユーザーは戻ってきません。地味な作業ですが、半年・1年の単位で資産化していく仕事です。詳しくはハッシンラボ Premium のサイト表示速度改善ガイドもあわせてご覧ください。

よくある質問（FAQ）

Q1. EWWW Image Optimizerは無料のままで十分ですか？

中堅企業の自社サイト規模（月数十枚〜数百枚の画像追加）であれば、無料モードで運用上の不便はほぼ出ません。CDN経由の大規模配信や、AVIFなど次世代形式まで踏み込む場合に有料Easy IOやAPI契約を検討する順序が現実的です。まず半年〜1年は無料モードで運用を回し、サイト規模の伸びに応じて段階的に判断する進め方をおすすめします。

Q2. 他の画像圧縮プラグインと併用しても問題ありませんか？

原則として画像最適化系プラグインは1つに絞ります。Smush・Imagify・ShortPixel等と併用すると、二重圧縮で画質が荒れたり、メタデータが消えて画像差し替え時に困るケースが出てきます。乗り換える場合は、旧プラグインを停止・削除してからEWWW Image Optimizerの設定を確定する順序で進めます。

Q3. Bulk Optimizeで画像が劣化したら元に戻せますか？

EWWW Image Optimizerには「画像の復元」機能がありますが、復元用データを保持する設定がオンになっていることが前提です。実行前にUpdraftPlus等でuploadsフォルダのバックアップを別ストレージに取っておく運用が安全です。サーバー側スナップショットがある場合は併用すると、二重の安全網になります。

Q4. Cloudflareを使っているのですが、設定を変える必要はありますか？

CloudflareのPolish機能（Lossy/Lossless）をオンにしている場合、EWWW Image OptimizerのWebP配信と二重圧縮になり、かえって画質が落ちることがあります。EWWWでWebP配信する方針に決めたら、CloudflareのPolishは「Off」に揃える設定が推奨です。詳しくはハッシンラボ Premium のCloudflare運用ガイドも参考になります。

Q5. 中小企業の発信担当者は、月にどのくらい運用工数を取れば回せますか？

初期設定とBulk Optimizeの初回実施で2〜3時間、その後は月1回30分のPageSpeed Insights確認＋四半期1回の設定見直しで十分回せます。属人化を避けるため、設定スクリーンショットを共有フォルダに残す運用にしておくと、担当者交代時の引き継ぎも軽くなります。

Q6. WebP対応していない古いブラウザのユーザーには画像が表示されませんか？

EWWW Image Optimizerのリライト設定は、ブラウザ側のWebP対応状況を判定し、未対応ブラウザには元のJPEG/PNGを返す仕組みです。例えばIE11等の旧ブラウザでも画像表示が崩れる心配はありません。フォールバックの仕組みが標準で組み込まれているため、安心して導入できます。

まとめ｜画像最適化は「蓄積型発信の基盤」として運用する

EWWW Image Optimizerは、中堅企業のWordPressサイトで表示速度を改善する定番の打ち手です。本記事で整理した6ステップ（前提確認→初期設定→3タブ調整→Bulk Optimize→WebP配信→効果測定）に沿って進めれば、画像加工の専門知識がなくても安全に運用を回せます。

画像最適化は派手な施策ではありませんが、蓄積型発信の土台として効いてきます。記事を書き続ける一方で、表示速度が遅ければ読者は戻ってきません。月1回30分のPageSpeed Insights確認を組み込むだけでも、半年後・1年後の資産化に大きく寄与します。SEO・GEO・コンテンツ運用の全体像についてはハッシンラボ Premium のSEO運用カリキュラムも合わせてご覧ください。

中堅企業の発信担当者が一人で抱え込みがちな領域だからこそ、運用ルールをチーム共有資産として残す設計が大切と捉えています。設定スクリーンショット・月次レポート・引き継ぎテンプレを揃え、担当者交代があっても止まらない仕組みに整えていきましょう。

この記事の著者

飯塚 昭博

Akihiro Iitsuka

コントリ株式会社 代表取締役

青山学院大学卒業後、自動車会社にて年間180億円規模の設備調達を担当。中小企業経営者の想いに触れる中でその価値を伝えることに使命を感じ、2023年独立。経営者インタビューメディア「コントリ」を運営し、100社以上の経営者を取材。SEO・AI活用・発信設計を通じて中小企業の「伝わる発信」を支援している。

comtri.jp
ハッシンラボ
note