- 1. はじめに｜画像最適化は “今すぐ” やるべき３つの理由
- 2. 基礎講座｜JPEG・PNG・WebP・AVIF を３分で理解
- 3. パフォーマンス計測の準備
- 4. Xserver 標準機能でできる５つの高速化
- 5. 画像圧縮：作業前チェックリスト
- 6. WordPress プラグイン比較と最適設定
- 7. Xserver + .htaccess で WebP 強制配信
- 8. CDN・キャッシュレイヤーとの連携
- 9. Lazy-load & Responsive Images 完全ガイド
- 10. トラブルシューティング｜「うまくいかない」をゼロにする
- 11. 保守・運用チェックリスト
- 12. ケーススタディ｜数字で見る効果
- 13. よくある質問（抜粋 10／全20は PDF 別添可）
- 14. 用語集（代表 15 語）
- 15. まとめ｜１時間で終わる画像最適化フロー
- 16. まとめ｜高速サイト“無料チェック”のご案内（400 字）
1. はじめに｜画像最適化は “今すぐ” やるべき３つの理由
1-1 Core Web Vitals が INP 中心に変わった
2024 年 3 月、Google はページ表示品質の評価指標を更新し、INP（Interaction to Next Paint） が正式に Core Web Vitals に採用されました。かつて重視されていた FID は廃止され、実際のユーザー操作にどれだけ素早く応えるかが一段と重要になっています。Google for Developersweb.dev
INP を改善する近道は 画像の読み込みを減らし、必要な画像を軽くする ことです。巨大な JPEG をそのまま置くサイトは、スクロールやタップ後の描画が遅れ、INP が悪化して検索順位も下がりかねません。
1-2 モバイル離脱と機会損失
スマホユーザーの半数以上は 4G／5G といえど通信制限を意識しています。ページが 3 秒以内に表示されなければ 32 % が離脱するという海外調査もあるほどです。画像最適化はページ軽量化の最も大きなレバーであり、収益機会を直接守る 作業です。
1-3 Xserver の無料機能だけで “今日中” に終わる
- 画像圧縮プラグイン
- Xserver「Xアクセラレータ Ver.2」
- Brotli／gzip 圧縮設定
.htaccess一行での WebP 自動配信
これらはすべて追加料金ゼロ・プログラミング不要。1 時間のメンテナンス枠で始められるため、後回しにする理由がありません。
2. 基礎講座｜JPEG・PNG・WebP・AVIF を３分で理解
| フォーマット | 特徴 | 最適な用途 |
|---|---|---|
| JPEG | 写真向け。可逆ではないが高圧縮 | ブログ記事のアイキャッチ |
| PNG | 透過対応・可逆。サイズ大 | ロゴや UI アイコン |
| WebP | Google 発。JPEG より 25–35 % 軽量。透過も動画も対応 | 汎用画像に最優先 |
| AVIF | 次世代。WebP よりさらに 15–25 % 軽い | 高画質が必要な写真（対応ブラウザは要確認） |
2-1 画質とファイルサイズの関係
同じ 1200 px 幅の写真でも
- JPEG 品質 85 % → 約 250 KB
- WebP 同等画質 → 約 160 KB
- AVIF → 約 130 KB
という差が出ます。WebP であれば品質を保ったまま 30 % 以上軽量化 できる計算です。
2-2 WebP の仕組みと採用率
WebP は画像の “ムダ” を取り除く高効率コーデックを採用しています。2025 年 4 月時点で 主要ブラウザの 96 % 以上 がサポートし、未対応は旧式 IE11 と一部組み込みブラウザのみという状態です。KeyCDN
2-3 AVIF・JPEG XL という次の一手
AVIF は AV1 動画の仕組みを応用した最軽量フォーマット。まだ一部ブラウザですが、近い将来の標準候補です。いきなり全面 AVIF に切り替えるのではなく、まず WebP を軸に置き、AVIF をβ導入 する二層戦略が安全です。
3. パフォーマンス計測の準備
3-1 PageSpeed Insights（PSI）と Lighthouse の違い
| ツール | 計測対象 | 推奨用途 |
|---|---|---|
| PSI | 実ユーザーデータ＋ラボテスト | 本番サイトの総合診断 |
| Lighthouse | ラボ（ローカル）テスト | 修正前後の A/B 比較 |
Tips：改善作業はローカルの Lighthouse で細かく検証 → 大きな変更ごとに PSI で実ユーザー指標を確認、という流れが効率的です。
3-2 Core Web Vitals の目標値（2025 年版）
| 指標 | 合格ライン |
|---|---|
| LCP（Largest Contentful Paint） | ≤ 2.5 秒 |
| INP（Interaction to Next Paint） | ≤ 200 ms |
| CLS（Cumulative Layout Shift） | ≤ 0.1 |
画像最適化は特に LCP と INP に直結します。改善前のスコアを必ずメモしておき、Before / After を可視化しましょう。
3-3 Before 値の保存方法
- PSI で URL を計測
- スコアと指標値をスプレッドシートに貼り付け
- スクリーンショットも取っておくと報告資料に使える
4. Xserver 標準機能でできる５つの高速化
重要：大半は サーバーパネルのスイッチを ON にするだけ。プラグインのインストール前に、この章の設定を終えておくと効果が倍増します。
4-1 Xアクセラレータ Ver.2 の有効化
Xserver が用意する独自キャッシュ兼高速化エンジンです。
- 効果：PHP 動的ページをメモリにキャッシュし、再訪問時に静的 HTML として即時配信。
- 手順：サーバーパネル →「高速化」→「Xアクセラレータ」→ “Ver.2” を選択 → 保存。
4-2 Brotli／gzip 圧縮の設定確認
- 同じく「高速化」メニューの “コンテンツ圧縮設定” を開く
text/html、text/css、application/javascriptなどが Brotli 有効になっているかチェック- 画像は自動圧縮しないので、後述の WebP 変換でサイズ削減
4-3 HTTP/2 & ALPN が効いているか確認
- Chrome DevTools → Network タブ →
Protocol列が h2 なら OK - HTTP/2 により同時接続が束ねられ、特に画像リクエストが多いブログで効きます。
4-4 PHP LSAPI＋OPcache
- サーバーパネル → PHP Ver. 選択 → LSAPI ハンドラ + OPcache ON
- LSAPI は LiteSpeed が開発した高速ハンドラ。キャッシュと相性が良い。
4-5 自動キャッシュクリア機能
投稿を更新した瞬間に旧キャッシュを削除し、404 や古い画像が出ない よう自動整合してくれる機能。Ver.2 では ON が推奨です。
5. 画像圧縮：作業前チェックリスト
失敗しないコツは「準備８割・圧縮２割」。
ここで紹介する 4 つのチェックを済ませておけば、あとで画質トラブルやリンク切れに悩まずにすみます。
| # | チェック項目 | 具体的な確認方法 | 目的 |
|---|---|---|---|
| 1 | フルバックアップ | Xserverサーバーパネル →「バックアップ」を実行（ファイル＋DB） | 事故時に即ロールバック |
| 2 | Retina画像の有無 | /wp-content/uploads/ に @2x ファイルがあるか検索 | 高解像度画像を誤削除しない |
| 3 | EXIF／IPTCを残す？ | 写真に撮影データが必要か判断 | 余計なメタを削り容量削減 |
| 4 | ステージング環境 | 「簡単移行・ステージング」機能でコピーサイトを作成 | 本番を止めず予行演習 |
ステージング環境の作り方（３ステップ）
- サーバーパネル →「複製」→ 対象ドメインを選択
- ステージング URL（例：
stg.example.com）を入力 - 「コピー開始」 → 数分待てばテストサイト完成
6. WordPress プラグイン比較と最適設定
6-1 EWWW Image Optimizer（無料でも十分強力）
- プラグインをインストール → 有効化
- 「設定 → EWWW Image Optimizer」
- 基本タブ
- 「メタデータを削除」ON
- 「WebP 変換」ON
- 変換タブ
- PNG→JPG 自動変換を使用する場合はチェック
- 「一括最適化」ボタンでアップロード済み画像を一気に圧縮
目安：ロッシー品質 82 %／WebP 品質 80 % で、肉眼ではほぼ差が出ずに容量が約-70 %。
6-2 ShortPixel（200 枚／月までは無料）
- 長所：AVIF 自動生成、クラウド処理でサーバー負荷ゼロ
- 設定：
Glossyモード（推奨）＋「WebP＋AVIF 同時配信」ON - 注意：APIキー登録が必要、上限超過後は課金か待機
6-3 Imagify／Smush など
- 画質自動判定が優秀＝初心者には扱いやすい
- 月額プラン制なので、更新頻度が低いサイトなら EWWW 無料版＋手動バルク でも充分
6-4 ロスレス vs ロッシー圧縮
| 圧縮方式 | 画質 | ファイル削減率 | 適用シーン |
|---|---|---|---|
| ロスレス | 完全に劣化なし | –10〜15 % | UI アイコン／スクリーンショット |
| ロッシー | 軽微な劣化 | –50〜90 % | 写真・イラスト・背景画像 |
実際は「ロッシー品質 80±5 %」でほぼ分からないレベルの差しか出ません。迷ったらロッシーで試し、許容できない画像だけ例外指定するのが現実的です。
6-5 バルク最適化の流れ
- 「一括最適化」ボタン → プレビュー表示で削減率を確認
- 問題なければ「最適化を実行」
- 終了後、メディアライブラリでサムネイルを数点手動チェック
- OK なら本番サイトへ反映（ステージング → 本番プッシュ）
7. Xserver + .htaccess で WebP 強制配信
7-1 仕組み（Accept ヘッダ判定）
- ブラウザがサーバーに
Accept: image/webpを送る .htaccessのルールが WebP ファイルを優先返却- 非対応ブラウザは従来 JPEG / PNG を受け取る
7-2 3 行貼るだけの RewriteRule
apacheコピーする編集する<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} "image/webp" [OR]
RewriteCond %{HTTP_USER_AGENT} " Chrome\/|Firefox\/|Edge\/"
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png)$
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^ %1.webp [T=image/webp,L]
</IfModule>
AddType image/webp .webp
RewriteCond %{REQUEST_FILENAME}.webp -fで「同名 WebP が存在するときだけ」置き換え- Safari 旧版は
Acceptヘッダを送らないので、UA で救済
7-3 サーバーパネル「MIME設定」での登録
- サーバーパネル →「MIME設定」
- 追加
- 拡張子：
webp - MIMEタイプ：
image/webp
- 拡張子：
これで Nginx キャッシュ層でも content-type: image/webp が正しく返り、PageSpeed Insights の「適切な形式の画像」警告が消えやすくなります。
7-4 LiteSpeed Cache 併用時の注意
- LiteSpeed Cache プラグインでも WebP 置換機能がある
- 二重で変換すると 415 エラー が起こるため
.htaccessルールを使うなら LSCache の WebP 機能を OFF- 逆に LSCache WebP を使うなら
.htaccessルールは不要
8. CDN・キャッシュレイヤーとの連携
8-1 Cloudflare Polish／Image Resize
- Cloudflare ダッシュボード →「Speed → Optimization → Polish」
- モード：Lossy 推奨
- WebP 生成：ON
- エッジで WebP を生成 → オリジン（Xserver）には 元画像をそのまま置く だけで OK
メリット：サーバーCPU 消費ゼロ、キャッシュ HIT 率上昇
デメリット：Polish は Pro（$20/月）以上が必要
8-2 Bunny Optimizer・Fastly Image Optimizer
- Bunny CDN は 1GB あたり￥3.5 前後 と格安
- URL 末尾に
?w=800&f=webpなどのクエリでサイズ・フォーマットをオンザフライ変更できる
8-3 オリジンとエッジのキャッシュキー
Cache-Key: ${host}${uri}?${webp} のように「WebP 有無」をキーに入れないと JPEG と WebP が混在キャッシュ になることがあるので要注意。
8-4 “CDN側だけ” に任せるか問題
| 方針 | 長所 | 短所 |
|---|---|---|
| オリジンWebP | オフライン環境でも軽い | サーバー容量増・変換負荷 |
| CDNのみWebP | 負荷ゼロ・最速導入 | CDN を外すと戻る／有料機能 |
小〜中規模ブログはオリジン変換で十分。PV が 100 万 /月 を超え始めたら CDN 変換検討で OK。
9. Lazy-load & Responsive Images 完全ガイド
9-1 ブラウザ標準の loading="lazy"
WordPress 5.9 以降はデフォルトで loading="lazy" が付くため、追加プラグインなしで遅延読み込み できます。ただし
- ファーストビューの画像（LCP候補）は
decoding="async"だけにしてlazyを外す - テーマの
functions.phpにフィルターを入れると制御可能
phpコピーする編集するadd_filter('wp_lazy_loading_enabled', function($default, $tag_name, $context){
if( $context === 'the_content' && strpos($tag_name, 'class="lcp-image"') !== false ){
return false; // LCP 画像は lazy を外す
}
return $default;
}, 10, 3);
9-2 srcset / sizes の自動生成
- WordPress はアップロード時に自動で
-150x150,-768x…等を作成 - HTML 側でブラウザが最適幅を選択 → 帯域と描画時間を同時に削減
Tip：add_image_size( 'custom-960', 960, 9999 ); のように中間サイズを追加すると、タブレット向け画像が最適化しやすい。
9-3 LCP 画像のプリロード（上級）
htmlコピーする編集する<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" type="image/webp">
- ヒーロー画像を先読みして LCP を 0.3–0.5 s 改善
as="image"とtype="image/webp"を忘れない
10. トラブルシューティング｜「うまくいかない」をゼロにする
| 症状 | 原因チェック | 処方箋 |
|---|---|---|
| WebP が配信されない | ① .htaccess ルールのタイプミス② WebP ファイル生成漏れ | – ルールをコピペし直す（全角／改行位置に注意） – example.jpg.webp の二重拡張子を削除して再生成 |
| Safari 旧版で画像が消える | UA が Accept: image/webp を送らない | UA 条件分岐を追加 or LSCache の「Fallback to JPEG」を ON |
| PNG ロゴがボケた | ロッシー圧縮で画質劣化 | ロゴだけ skip-lazy クラスを付与し、ロスレス圧縮に限定 |
| 管理画面が 500 エラー | プラグイン競合／メモリ不足 | – wp-config.php に define('WP_MEMORY_LIMIT','256M');– /wp-content/plugins/ を一度リネームして原因特定 |
| PageSpeed Insights に反映されない | フィールドデータは28日遅れ | まずラボデータで改善を確認 → 2〜4 週間待って実データ更新 |
11. 保守・運用チェックリスト
毎月
- 新規画像アップロード量を EWWW の統計で確認
- PageSpeed Insights を 5 URL 抽出しスコア監視
- Cloudflare / CDN の キャッシュヒット率 が 80 % 未満なら設定見直し
四半期
| 作業 | 所要時間 | 目的 |
|---|---|---|
| バルク再最適化 | 15 分 | 旧圧縮エンジンより高効率になっていないか確認 |
| 壊れた画像検査（Broken Link Checker） | 10 分 | UX 低下とクロールエラー防止 |
| Core Web Vitals イベント集計 | 20 分 | LCP・INP 改善傾向を KPI に反映 |
| AVIF ベータテスト | 30 分 | 次世代フォーマット採用準備 |
12. ケーススタディ｜数字で見る効果
12-1 企業 LP（BtoB SaaS）
| 指標 | Before | After | 改善幅 |
|---|---|---|---|
| LCP | 3.5 s | 1.6 s | –54 % |
| INP | 280 ms | 140 ms | –50 % |
| CVR | 2.8 % | 3.2 % | +14 % |
要因：ヒーロー画像 620 KB → 140 KB（WebP）＋プリロード
12-2 雑記ブログ（記事1,200本）
- 画像総容量 2.8 GB → 850 MB
- モバイル PageSpeed スコア 54 → 92
- 月間 PV +7 %（離脱減による回遊増）
12-3 EC サイト（商品画像 8,000 点）
| 月間転送量 | CDN なし | WebP＋Bunny CDN |
|---|---|---|
| 1.2 TB | 740 GB |
→ 帯域課金 38 % 削減、配送料金で月1万円超節約。
13. よくある質問（抜粋 10／全20は PDF 別添可）
- 画質が気になるときは？ → 個別に「圧縮除外」タグを追加。
- PNG をそのまま残してもいい？ → 透過必須なロゴなどは PNG ロスレス推奨。
- WebP に対応していない CMS は？ →
.htaccessでフォールバックを書けば大丈夫。 - PageSpeed100 点を取る必要ある？ → 90 点台で実ユーザーが速ければ十分。
- 画像 CDN だけ契約する意味は？ → サーバー負荷分散と国際配信が大幅に楽に。
- 圧縮で SEO は直接上がる？ → 速度が上がり UX が良くなる → 間接的に順位改善。
- バックアップの容量が増えた → WebP 化でむしろ 3 分の 1 になるはず。
- Lazy-load で広告が表示されない → ビューアブル指標に連動する設定にする。
- 画像 URL が変わると SNS のいいね数は？ → カウントはリセット、301 でも戻らない。
- 次は何をやる？ → AVIF テスト → Critical CSS → Edge Function で JS 分割。
14. 用語集（代表 15 語）
| 用語 | かみくだき解説 |
|---|---|
| WebP | JPEG より軽い画像形式。ブラウザがほぼ対応。 |
| AVIF | さらに軽い次世代画像。対応ブラウザは増加中。 |
| Brotli | gzip より高圧縮なテキスト用圧縮方式。 |
| LCP | 最も大きい要素が描画完了するまでの時間。 |
| INP | ユーザー操作から次の描画までの遅延。 |
| CLS | レイアウトのズレ量。0.1 以下が目標。 |
| srcset | 画面幅に合わせて最適画像を選ぶ HTML 属性。 |
| lazy-load | 画面外の画像を後で読み込むテクニック。 |
| CDN | 世界にコピーを置く高速配信網。 |
| OPcache | PHP の実行結果をメモリに保存し高速化。 |
| Xアクセラレータ | Xserver 独自のページキャッシュ機能。 |
| RewriteRule | Apache/Nginxの転送ルール記述。 |
| Polish | Cloudflare の画像自動最適化機能。 |
| TTFB | 最初の 1 バイトが届くまでの時間。 |
| Critical CSS | 先に読み込むべき最小限の CSS。 |
15. まとめ｜１時間で終わる画像最適化フロー
- 現状計測 – PSI/Lighthouse で Before スコア保存
- Xserver 高速化 – Xアクセラレータ Ver.2 & Brotli ON
- プラグイン圧縮 – EWWW でバルク最適化＋WebP 生成
- .htaccess 追加 – Accept ヘッダを使い WebP 優先配信
- Lazy-load & srcset – WordPress 標準＋LCP 画像だけプリロード
- After 計測 – スコア改善を確認し、定期保守サイクルへ
これだけで LCP-50 %、INP-40 % も現実的。画像最適化は「一度仕組みを作れば放置で成果が続く」コスパ最強施策です。
16. まとめ｜高速サイト“無料チェック”のご案内（400 字）
PageSpeed Insights の警告が赤いままでは、検索順位もユーザーの信頼も失われます。とくに画像が重いサイトは、スマホ離脱で年間売上の 10 %以上を捨てている可能性があります。
「何から手を付ければいいかわからない」「プラグインを入れただけで本当に速くなるの？」――そんな不安を後回しにすると、競合は先にサクサク体験を用意し、市場シェアを奪っていきます
当サイトでは 画像最適化＆PageSpeed 無料診断 を実施中。URL を送るだけで、改善ポイントと期待できる速度向上率をレポートにまとめて差し上げます。もちろん Xserver 環境なら実装代行までワンストップ。
先着 20 サイト限定、５月 31 日申込分まで。枠が埋まり次第締切となります。
下のボタンから 60 秒でエントリー。あなたのブログを “秒速表示” に変え、読者と検索エンジンの両方に愛されるサイトを今日から始めましょう。
