ウェブサイトの画像最適化

画像の最適化は、WordPressのパフォーマンスにおいて最も「やりがいのある」側面のひとつです。同じページ構成とテーマでも、画像のサイズ、寸法、フォーマット、配信が適切であれば、読み込みエクスペリエンスはすぐに改善されます。

しかし、画像の最適化は、技術的に難しいからではなく、情報が断片的であるため、混乱を招く最も簡単な方法でもある：
いくつかの記事を読み、“圧縮”、“WebP/AVIF”、“遅延読み込み ”を知り、プラグインの紹介を見て、“毎月無料！毎月100クレジット”、“無料20MB”、“画像1枚につき1クレジット ”と書いてあったが、読めば読むほど混乱する--。無料でいいの？料金の引き方は？同じこと」を誤解していませんか？そして最も重要なことは実際に効果があったのか、なかったのか。

この記事の目的は3つしかない：

1. 実行ファイルを渡すロードマップ(まず何をすべきか、次に何をすべきか）。
2. 目指すオプションを明確にする（無料／有料の違いは何か、それぞれどのような人に適しているか）。
3. よくある落とし穴を前もって書き出しておく（そうすれば、終了後にトラブルシューティングのために探し回る必要がなくなる）

1.結論：WordPressに備わっているものと備わっていないもの

まずWordPressのコアがすでに何をしているのかを把握しなければ、2つのうちの1つをやってしまいがちだ：

• 本来なら享受できるはずの “自由な能力 ”を使わず、何度も車輪を作るために時間を費やし、お金を払う。
• 私は、WordPressが「すべての古い画像を自動的にWebP/AVIFに変換する」と思っていたが、そうではないことがわかった！

WordPressのコアには、これらの主要な機能が組み込まれています：

• レスポンシブ画像（srcset/sizes）: WordPress 4.4では、コアは srcset とともに sizesまた、アップロード時に生成されるマルチサイズの画像を利用し、ブラウザが画面の状況に応じてより適切なリソースを選択してロードできるようにする。
• ネイティブの遅延ロード: WordPress 5.5以降では、HTML標準を使用して、デフォルトで画像のネイティブレイジーローディングが可能です。 loading 属性の実装。
• WebPのアップロードをサポート: WordPress 5.8以降では、JPEG/PNGのようなWebPをアップロードして使用することができます（ホスティング環境がWebPに対応している場合に限ります）。
• AVIFのアップロードをサポート: WordPress 6.5以降では、JPEG/PNGのようなAVIFをアップロードして使用することができます（ホスティング環境のサポートにも依存します）。

しかし、注意してほしい：
“「アップロード／使用への対応」≠「自動変換／自動配信」。
つまり、すでにWP 6.5を使っていても、メディアライブラリにあるJPG/PNGが勝手にWebP/AVIFになることはありません！--この部分は通常、プラグインやサービスでパッチを当てる必要があります。

2.ロードマップ：5つのステップによる画像の最適化

何をするのか、なぜするのか、予選通過のために何をすべきか、そして典型的なピットとは何か。

2.1 まず「サイズ」を正しくする（最も見落とされがちだが、最もやりがいがある）

多くの放送局が遅いのは、圧縮が行われていないからではない。表示領域から大きくはみ出した大きな画像をダウンロードした。：
例えば、ページの幅が実際には900pxしかないのに、訪問者に元の3000pxの画像をダウンロードするように頼んだ場合、ブラウザは「ダウンロードしてから縮小する」だけです。これは帯域幅を浪費し、デコード時間を増加させ、最初の画面を遅くします。

ワードプレス4.4以上レスポンシブ・イメージ・メカニズム（srcset/sizes)はまさにこの問題に対処するために設計されている。

パスとしてカウントされることを行う：

• 携帯電話でページを開く場合、ダウンロードした画像のサイズはデスクトップよりもかなり小さくなるはずです。
• 同じ画像を異なるデバイスで異なるリソースサイズで読み込む（元の画像を常にダウンロードする代わりに）

よくある落とし穴

• ダイアグラムをCSSの背景画像として扱うテーマやビルダーがあります。 srcsetその結果、大きな写真が出来上がった。
• 外部リンクされたイメージベッド、サードパーティのイメージブロックを使用し、メディアライブラリによって生成されたマルチサイズシステムをバイパスすることもできる。

---

2.2 圧縮（KBを下げたが、品質は “つぶさない”）

圧縮の核心は、「小さければ小さいほど良い」ではなく、「肉眼ではほとんど違いは見えないが、体積の減少は明らか」である。

ルールは以下の通り：

• 写真／ライブショット（人物、商品、風景）非可逆圧縮優先（最大ゲイン）
• インターフェイスのスクリーンショット／文字が多い画像曖昧なテキストを避けるために、圧縮はより控えめにすべきである。
• ロゴ/アイコンプライオリティSVGまたは目立たないロスレス（ロスレスはエッジがぼやけやすい）

パスとしてカウントされることを行う：

• ほとんどのページで画像サイズを大幅に縮小
• 目に見えるノイズ、エッジの濁り、カラーブロックの切れ、不鮮明なテキストはない

---

2.3 WebP / AVIF (フォーマット戦略:等精細のためにより小さく)

ワードプレスはすでにアップロードをサポートしている ウェブP（5.8）対AVIF（6.5）。
しかし、次世代フォーマットを本当に機能させるには、通常2つのことを解決しなければならない：

1. 過去のメディアライブラリを一括変換する方法(そうでなければ、“後でアップロードされた新しい画像 ”に最適化されているだけです。）
2. コピーを生成するか、オリジナル画像を置き換えるか(これは危険な流域です。後でPlus WebPの「オリジナル画像の置換と削除」に焦点を当てます)

おすすめの書き方

• WebP: 一般的にデフォルトが望ましい（より安定した互換性）
• AVIF: さらなる圧縮の方向性で、大きな画像、ファーストスクリーンの大きな画像、アルバム画像に適しています。環境サポートへの依存）

---

2.4 レイジーローディングは正しく使うべき（一律ではない）

ワードプレス5.5以降デフォルトの遅延ロード写真
これにより、初期レンダリング時の帯域幅使用量が削減される：

• “画面外リソース ”の遅延ロード”
• 最初の画面の最も重要な大きな画像（多くの場合、最初の画面の重要な画像）は、遅延ロードには適さないことが多い。

---

2.5 デリバリーレイヤー: CDN / イメージ CDN

圧縮、サイジング、フォーマットは、「フィットする小さいファイル」という問題を解決する。
しかし、画像が常にソースから離れた場所から引き出される場合、ネットワークの遅延は依然として体験に大きな影響を与えます。そこで、「配信レイヤー」ソリューション（CDN/Image CDN）の登場です。

代表的な2つの方向性：

• クラウドフレア：Cloudflareドキュメントポーランドの圧縮方式（lossless/lossy/WebP）が紹介されている。 format=auto WebP/AVIFフォーマット可。
• ジェットパックサイトアクセラレータ：Jetpackドキュメント画像を最適化し、静的リソースとともにネットワークを通じて配信することを説明する。

画像の最適化は、より小さく、より適切なものにする責任がある。CDNは、より近く、より安定した

3.選択：主要2ルートのみ

画像最適化で最もよくある失敗は、「プラグインがない」ことではなく、「プラグインが多すぎて処理が重複してしまう」ことだ：
Aは圧縮し、Bは圧縮し、AはWebP/AVIFに変換し、Bは変換し、AはURLを変更し、Bは書き換えている。

ルール

取るべき道はひとつしかない。すべて無料のローカルか、3つのうちのクラウド圧縮だ。

• ルートA（すべて無料ローカル）：プラスWebPまたはAVIF + EWWWイメージオプティマイザ(または1つだけ）
• ルートB（クラウド圧縮トリプルオプション）：ShortPixel / Imagify / TinyPNG

---

3.1 ルートA：完全無料ローカル（プラスWebPまたはAVIFまたはEWWWW）

このルートの特徴は以下の通りだ：

• サードパーティの “月ごと/枚ごと ”の圧縮サービスに依存することはありません（ただし、一部の機能はオプションサービスとして提供される場合があります）。
• コスト：バッチ処理はCPU/IOではサーバーに負荷がかかり、「戦略とリスク」にもっと注意を払う必要がある。“

3.1.1 プラスWebPまたはAVIF核心は “生成/置換 ”であり、伝統的な “圧縮ツール ”ではない。”

• フルボリュームの画像を生成する場合：元の画像ファイルIDはWebP/AVIFで上書きされ、元のファイルは削除され、コンテンツ内のURLは置き換えられます。。
• プラグインはWP-CLIコマンドを提供し、思い出させる：WP-CLIは、多くのファイルがある場合、より信頼性があります。

つまり、「静かにWebPを生成してくれる」のではなく資産移動(特に “元の画像を置き換えて削除する ”オプションをオンにした場合）。

2つのモデルの違い

モード1：オリジナル画像を保持＋WebP/AVIFコピーを生成（より安定）

• 長所：互換性の問題が発生した場合のフォールバックが容易
• コスト：ディスク使用量が増える（オリジナル画像＋新フォーマット＋マルチサイズサムネイル）

モード2：元の画像を置き換えて削除する（よりアグレッシブ）

• 長所：ディスクの拡張速度が速くならない。
• リスク：「アセットを変更する＋参照を変更する」ことになり、互換性の問題のトラブルシューティングにコストがかかる（特に、外部システムやテーマのロジックが元のファイル名／パス／フォーマットに依存している場合）。

プラスWebPまたはAVIFの典型的な落とし穴

1. ライブラリ全体を入れ替えた後、一部のページ画像が異常に表示される。
   その理由は通常、画像が「壊れている」のではなく、URLの置換、キャッシュ、サムネイルポリシーなどの連鎖のどこかが正しくないからです。
2. サムネイルの数が多ければ多いほど、変更の範囲は大きくなる
   WordPressで画像をアップロードすると、複数のサイズが生成されます。テーマやプラグインによって、さらにサイズが追加されることもあります。テーマやプラグインによって、さらにサイズが追加されることもあります。完全な置き換えは、非常に大きなファイルのコレクションを変更する可能性があることを意味します。
3. フォーマットの移行を行うだけでは、ボリュームが常に最小になるとは限りません。
   一般的にWebP/AVIFの方が小さいが、それでも「サイズ戦略」と「圧縮戦略」は重要だ。PlusWebPを「1クリック速い」と考えてはいけない。

---

3.1.2 EWWWイメージオプティマイザー自由な局所圧縮の代表

EWWWのプラグインページはとても良い位置にある：

• さまざまなツール（jpegtran、optipng、pngout、pngquant、gifsicle、cwebpなど）を使ってサーバー上で最適化できます。
• また、高圧縮やCPUの節約が必要な場合は、CPUを消費する処理をサーバーにオフロードすることもできます（オプション）。

ルートAでEWWWはどのような役割を果たすべきか？

もしPlus WebPを「フォーマットの移行／置き換え戦略」として使うのであれば、EWWWの方が適している：

• 圧縮と体積の最適化(特にJPG/PNGなどの一次ソースの軽量化）
• 履歴メディアライブラリの一括最適化(URLの差し替え」よりも「ボリュームの削減」を狙う）

EWWWの典型的なピット

1. バッチ最適化中のサーバー負荷の上昇
   ローカル圧縮はCPU/IOを食うので、解決策は「使うな」ではなく、「バッチ、低ピーク、必要ならオフロード/クラウドオプション」だ。
2. “「WebP が生成される」とは、フロントエンドが WebP を生成していることを意味しません。
   多くのプラグインがこのような誤解に苦しんでいる。生成と配信戦略（リライト、ピクチャータグ、キャッシュヒットなど）は別のものだ。
3. 他のプラグインで同じことを繰り返す
   Aを選択する場合は、ShortPixel/Imagify/TinyPNGタイプのクラウド圧縮をオーバーレイしないようにし、Bを選択する場合は、Plus WebP置換ロジックをオンにしないようにする。基本原則：最後まで一つのルート。

---

3.2 ルートB：クラウド圧縮トリプルチョイス（ShortPixel / Imagify / TinyPNG）

このルートは、「サーバーリソースを節約したい、より少ない労力でバッチ処理を行いたい、クレジット/ボリュームごとの課金を受け入れたい」という人に適している。
しかし、クラウド圧縮に関する最も誤解を招きやすい点は、以下の通りだ：フリークレジットは「フリーシート」ほど単純ではない！..サムネイルサイズの数、WebP/AVIFを生成するかどうか、再圧縮を繰り返すかどうかは、消費量に大きく影響する。

以下では、無料／有料で何が起こっているのか、クレジットはどのように差し引かれるのか、どのような落とし穴に足を踏み入れやすいのか、どのようなサイトタイプが適切なのかを説明する。

---

3.2.1 ショートピクセル100クレジット/月無料だが、クレジットはサムネイルとWebP/AVIF拡大で消費される。

無料／有料で何が起きているのか

ShortPixelプラグインの説明にはこう明記されている：

• 毎月100クレジット無料
• また、“エクストラ無制限マンスリー・クレジット ”もあります（プラグインのページに対応する価格の情報があります）。
• 有効期限のないワンタイムクレジットパック」（初回価格情報付き）としても利用可能

ヒント

• 無料：軽いサイトやテスト用に毎月一定額のクレジットを提供
• 使い捨てパック：大規模なメディア・ライブラリーを持つサイトで、在庫を一度に整理したい場合に適している（一度購入すれば使い切ることができ、通常期限はない）。
• 月額/無制限：継続的に画像を更新し、長期的に安定した最適化を行うサイトに適しています。

ShortPixel公式のKBは、「ワンタイム・パックと月額無制限の比較」でも次のように説明している。明示的説明月額無制限は、CDNの固定割り当てで無制限のクレジットを提供する月払い（または年払い）です。1回限りのクレジットは有効期限がないため、オンデマンドの使用量をよりコントロールできます。

結論：ShortPixelのクレジットはどのように計算されますか？

ShortPixel公式ドキュメント KB 非常にストレートに語る：

• WordPressは画像をアップロードすると複数のサムネイルを生成します；
• サムネイルの最適化が1クレジットとしてカウントされます。；
• WebPまたはAVIFを生成する場合はオリジナル画像とサムネイルの各WebP/AVIFバージョンは、追加クレジットを消費します。；
• クレジットの消費を減らすために、特定のサムネイルを最適化から除外することができます。

クレジット例：

例えば、1枚の画像をアップロードし、テーマ/プラグインが8枚のサムネイルを生成するとします：

• 元画像＋サムネイルのみを最適化：1（元画像）＋8（サムネイル）＝9クレジット
• WebP/AVIFも生成したい場合：上記9つの次世代バージョンを1つずつ追加 → +9クレジット。
  つまり、あなたが「1枚の写真」だと思っているものは、実際には「2桁のクレジット」に近いものを消費しているかもしれないのだ。

だから“「無料100クレジット」は「無料100画像」とは異なります。

ショートピクセルのよくある落とし穴

1. 無料100クレジットがすぐになくなる
   根本的な原因：多くのサムネイル＋WebP/AVIFを生成するための余分なクレジット。
   提案：

• サイトのサムネイル数をまず評価する
• 不要なサムネイルサイズを除外する（実際に使用されるサイズのみを最適化する）
• 試行錯誤を繰り返さないために、大量に実行する前に圧縮戦略を決定する。

2. 他のコンバーター・プラグインを同時にスタックする
   PlusのWebP置換とShortPixelの次世代タグの生成/挿入がある場合、ロジックが積み重なり、トラブルシューティングが難しくなります。ルートBでは、ShortPixelに単独でやらせます。
3. インストールすれば「フォアグラウンドでWebP/AVIF」になると思っていた。“
   ShortPixelプラグインのページWebP/AVIFを変換し、次世代画像を（タグ付けなどで）フロントページに追加できることに言及。
   しかし、それでも結果を検証することは重要である。

---

3.2.2 イマジファイ無料: 20MB/月; “オリジナル画像サイズ+サムネイル数 ”に応じてクォータが差し引かれます。

自由な量と位置

イマジファイ公式価格ページ文章は明快だ：無料アカウント 月額20MBクォータ。
プラグインのページには、WebP/AVIFの圧縮、リサイズ、変換ができることも明記されている。

ノルマはどのように控除されるのか？

Imagify 公式ドキュメント “「ノルマの使用率はどのように計算されるのか？”は、控除のメカニズムを非常に明確に説明している：

• サムネイルの数が消費に影響例えば、10個のサムネイルサイズがある場合、1個の画像を最適化すると11個の画像（オリジナル＋10個のサムネイル）を最適化することになり、これらはすべてクォータの消費に貢献します。
• 原稿の大きさによる控除例えば、100KBの画像をImagifyに送る場合、100KBがクォータから差し引かれます。
• 圧縮レベルを変更して最適化し直すと、またクォータが消費されます。。
• 同じAPI Keyを複数のサイトに使用できますが、クォータはそれらのサイト間で共有されます。

これがイマジファイの “核となる理解の仕方 ”である：
送信した分だけ差し引かれ、サムネイルが多ければ多いほど差し引かれ、押し直しを繰り返せば差し引かれる。

読みやすいImagifyクォータの例

オリジナル画像800KBをアップロードし、サイトが8つのサムネイルを生成したとします。

• Imagifyは “オリジナル画像＋8つのサムネイル ”を含むように最適化するため（すべてのサムネイルを最適化する場合）、この1つの操作で “これらすべてのファイルを合わせたオリジナルサイズ ”に近いクォータを消費することになる。
  20MBの減りが早い」と感じるサイトがあるのはそのためです。Imagifyが十分でないのではなく、一度にアップロードする画像が多すぎ、サムネイルが多すぎ、圧縮レベルを何度も試しているのでしょう。

イマジファイのよくある落とし穴

1. 無料 20MB “完全なサイト履歴インベントリ ”を行うには十分ではない”
   20MBは通常、軽いアップデートのテストに適しています。メディアライブラリがすでに大きい場合は、1回限りのパージでアップグレードが必要になる可能性があります。
2. 圧縮レベルの調整を繰り返すと、クォータ消費が重複する。
   イマジファイは次のように明言している。再最適化は、再びクォータを消費します。
   このページで “戦略 ”を明確にすることをお勧めする：

• 圧縮レベルとルック＆フィールを決定するために、少数の画像から始める
• 戦略を決定し、一括して実行する
  フルライブラリーで試行錯誤を繰り返さない

3. 複数のサイトがAPI Keyを共有するため、クォータが “不可解に低い”。”
   複数のステーションで同じAPI Keyを使用する場合、クォータは共有されます。
   そのため、チームや複数のステーションを使用するシナリオでは、予算をコントロールできない事態を避けるため、どのステーションを共有し、どのステーションを個別に使用するかを明確にするのがベストだ。

---

3.2.3 タイニーPNG(Tiny Compress Images): 500クレジット/月無料。WebP/AVIFに切り替えると「1サイズにつき1クレジット差し引かれる」。“

無料クレジットとその課金の考え方

TinyPNGのWordPressプラグインページがすべてを物語っている：

• 毎月500クレジットが無料
• 一般的なWordPressのインストール “で、あなたはおそらく圧縮することができます 約100枚/月
• ただし、AVIFまたはWebP変換が有効になっている場合：画像サイズごとに追加クレジットを消費だから、おそらく圧縮して変換するしかない。 約50枚/月(サムネイルサイズの数によって異なります）。

一方、Tinify社（TinyPNG/TinyJPGの開発元）も、同社のサイトで発表している。 API価格ページ説明: 登録すると、毎月500回の圧縮が無料で受けられます。その後は、圧縮に成功した回数で課金され、強制加入はありません。

TinyPNGがどのように理解されているかを一文で要約する：
サムネイルサイズが多いほど、またWebP/AVIFがオンになっているほど、クレジットの消費は速くなります。

見やすいTinyPNGのクレジット例

あなたのサイトが各画像に8つのサムネイルサイズを生成するとします：

• 圧縮のみ：オリジナル＋サムネイル8枚→9クレジット必要
• WebP/AVIF変換がオンになっている場合：1サイズにつき1単位追加→おそらくほぼ2倍！
  これは、プラグインページの説明に対応しています。スイッチをオンにすると、無料額がおよそ「100枚/月」から「50枚/月」に変わります。

TinyPNG よくある落とし穴

1. 500クレジット＝500画像
   そうではありません。画像サイズ/バリアント」によって消費されます。プラグインのページには、「コンバージョンでは、画像サイズごとにさらに1クレジットが差し引かれます」と明確に警告されています。
2. テーマ／eコマース・プラグインのサイズが多すぎて、無料クレジットが大幅に減少している。
   サイズが多ければ多いほど、クレジットの拡大や消費が容易になる。
3. 変換を有効にした後、クレジットが突然使われなくなったことに気づく。
   バグではなく、課金の仕組みだ。
   戦略のアドバイス

• もし無料フェーズが主に圧縮と軽量化のために使用されるのであれば、圧縮のみで開始し、サイト構造が安定し、本当に次世代が必要だと確信したときに変換をオンにすることができます。

4.サブシナリオの推奨：異なるタイプのサイトをどう選ぶか

また、WordPress、コンテンツサイト、eコマースサイト、ポートフォリオ、会員制サイトには、画像に対する「ツボ」がありません。

4.1 コンテンツサイト／ブログ（記事画像が多く、更新頻度は中程度）

優先順位の高い提言

1. サイジング戦略（ステップ1）
2. コンプレッション（ステップ2）
3. WebP (ステップ3)

より適切なルートだ：

• 保存希望：ルートBトリプルチョイス（ShortPixel / Imagify / TinyPNG）
• 無料にしたい場合：ルートA（プラスWebP＋EWWW）、ただしリスクを見極めるために「保守的モード（元画像を削除しない）」から始めることをお勧めします。

典型的なピットだ：

• 記事ページの最初の画像が非常に大きい。最初の画面が遅くなる

4.2 Eコマース/商品サイト（サムネイル多数、画像バリエーション多数、安定性優先）

Eコマースは、最も可能性の高い問題は、“圧縮効果がよくない ”ではなく、“サイズの一部を最適化すると、サムネイルが欠落し、正しいではありませんが、フロントコンポーネントは、画像を取得することはできません ”です。

優先順位の高い提言

1. 安定性を第一に：保守的な圧縮戦略、すぐにライブラリーの完全入れ替えを行わない
2. サムネイルサイズの評価：eコマーステーマは通常、より多くのサイズを生成し、クレジットの消費を増幅させる（ShortPixel/TinyPNGは特に顕著）。
3. バッチ前の小規模バリデーション（非常に重要）

より適切なルートだ：

• ルートBは、より手間がかからない傾向がある：ShortPixel/Imagify/TinyPNGはすべてバッチ処理が可能であり、ノルマの仕組みを理解し、事前にコストを評価することが重要である。
• ルートAは問題ありませんが、Plus WebPの「IDを上書き／元の画像を削除／URLを置き換える」動作にはより注意が必要です：これは資産の移行であり、いきなり全体を置き換えるのはお勧めできません。

4.3 ポートフォリオ／写真ステーション（単一画質に敏感、大きな画像、閲覧に対する要求が高い）

優先順位の高い提言

1. サイズ戦略（表示領域のコントロール）
2. 圧縮戦略（細部をつぶすより大きい方がいい）
3. WebP/AVIF（全体像のシーンゲインは明らかだが、ビューを検証する）

より適切なルートだ：

• イマジファイ元画像のサイズ “に応じてノルマを差し引く、この種のサイトは ”予算制御可能“（あなたは、各大画像の控除額を知っている）を行うのは簡単ですが、繰り返し抑圧を避けることができます。
• ショートピクセルサムネイルサイズがそれほど大きくない場合は、クレジットも非常に直感的ですが、+next-genで多くのサイズを生成する場合、クレジットの消費は拡大するので、計画的に行う必要があります。

5.ノルマと請求の比較：「無料では十分でない」ことを視野に入れる

どちらがお得で、無料期間はどれくらいですか？

5.1 3つのチャージバック・モデル

• ショートピクセル単位オリジナル画像＋サムネイル数」に応じてクレジットが加算され、対応するバージョンのWebP/AVIFが生成されるたびにクレジットが加算されます。
• イマジファイ(MB枠)サムネイルが多ければ多いほど減算され、再プレスするとまた減算されます。
• タイニーPNG単位WebP/AVIF 変換を有効にすると、画像サイズごとに追加クレジットが差し引かれます。

5.2 迅速な推定方法

このように見積もることができる：

1. 適当に「よくアップロードしている元画像」を探して、その大きさを確認する（例：300KB / 1MB / 3MB）。
2. あなたのサイトが生成するサムネイルサイズの数に応じて（例：5 / 10 / 20）
3. WebP/AVIFを生成するかどうかを決める（はい/いいえ）

そして、次のような「暗算」を使って消費を理解する：

• ショートピクセルWebP/AVIFを生成する場合、≈は再び2倍になります（次世代バージョンもクレジットを取るため）。
• イマジファイ各画像≒(オリジナルサイズ＋各サムネイルサイズ)減算; 圧縮レベルを変更し、再圧縮するとまた減算される！
• タイニーPNG: 500クレジットは無料です。もしあなたのサイトが画像ごとに多くのサイズを生成し、コンバージョンを有効にした場合、無料クレジット数は大幅に減少します（プラグインのページでは、「～100クレジット/月」対「～50クレジット/月」と視覚的に予想されます）。

6.リスクアラート

リスク1：複数のプラグインに同じことを繰り返させない

最も一般的な “災害の原因 ”だ。”

• ルートA：プラスWebPまたはAVIF + EWWWW(労働力を2つに分ける、コンバージョンとデリバリーを同時に行わない、あるいはどちらか一方だけを設置する）。
• ルートB：ShortPixel / Imagify / TinyPNG 3つ選ぶ(圧縮と次世代機について1つ選択)

リスク2：プラスWebPの「IDの上書き／元画像の削除／URLの置換」は資産移行である。

と強調した：プラスWebP 説明には、完全生成はオリジナルの画像IDを上書きし、オリジナルファイルを削除し、コンテンツURLを置き換える、と明記されている。
つまり、「いつでも引き出せる小さな設定」ではなく、資産レベルの変更ということだ。

提案された戦略はこうだ：

• まずは小規模テスト（数十人から数百人）
• フロントエンドの表示、サムネイル、キャッシュの更新がすべて正常に機能していることを確認する。
• 完全なライブラリ処理を再考

リスク3：クラウド圧縮の「無料クレジット」の実質的な消費量は、サムネイル数と次世代セレクションに依存する。

• ショートピクセルサムネイルと次世代はクレジットに大きく影響する。
• タイニーPNGWebP/AVIF を有効にすると、画像サイズごとにクレジットが加算されます。
• イマジファイ元画像のサイズに応じて控除され、より多くのサムネイルがより控除され、重圧が控除を繰り返します！

リスク4：「WebP/AVIFが生成された」は「WebP/AVIFがフロントオフィスから配信された」を意味しない“

変換後に「速くならない」と感じる人が多いが、根本的な原因はフロントエンドがJPG/PNGのまま（キャッシュ/ライト/タグ/ブラウザネゴシエーションなど、どのリングも正しくない）。

7.実行後、それが有効になったことを確認する方法

非常にシンプルな4つの検証ポイント

1. 同じページが2回目にリフレッシュされ、より安定して速く読み込まれるかどうか。(キャッシュし、機能するかどうかの物理的な感覚を最適化する）。
2. 携帯電話とデスクトップで読み込まれる画像のサイズは大きく異なるか？(レスポンシブ） srcset/サイズ (効くかどうかは別として）
3. いくつかの画像をスポットチェック：WebPまたはAVIFファイル/リソースが存在するかどうか(このサイトは実際に 次世代）
4. いくつかの画像をサンプルにする：拡大して、目に見えて濁っていないか、文字がぼやけていないかなどを確認する。(圧縮質量は過大ではない）

この4つすべてが一致すれば、選んだルートは走破されたことになる。次へ。 CDN “デリバリーレイヤー”全体がより安定する。

8.提言

1. まずルートを選ぶ：

• できるだけ自由であろうとする。: Plus WebP または AVIF + EWWW (またはどちらか1つだけ)
• サーバーリソースを節約したい。: ShortPixel / Imagify / TinyPNG トリプルチョイス

2. まず小規模なテストを行う（数ダース）
3. バッチする前に問題がないことを確認すること
4. デリバリーの安定性をさらに向上させる必要がある：読む CDN 加速度

一般的な問題

1.いくつのプラグインをインストールしなければなりませんか？全部インストールできますか？

ルートは1つに絞ること。

• ルートA: プラス WebP または AVIF + EWWW Image Optimizer (またはそのうちの1つ)
• ルートB：ShortPixel / Imagify / TinyPNG
  同じステーションで同時に複数のプラグインに「圧縮／WebP／AVIF転送／URL変更／配信書き換え」をさせるのは、ますますカオスになる可能性が高いが、チェックも最も難しい。

2.WordPressはすでにWebP/AVIFをサポートしていませんか？それでもプラグインが必要ですか？

分離する必要がある：
“「アップロード／使用への対応」≠「自動変換／自動配信」。
WordPress 6.5は、古いJPG/PNGを自動的にWebP/AVIFに一括変換したり、「ブラウザの機能とフォールバックごとにAVIF/WebPをエクスポートする」リンクを自動的に完全には行ってくれません。通常、過去のメディアライブラリに対応するプラグインやサービスが必要です。

3.画像の最適化で最も「やりがいのある」ステップとは？

通常は まず「サイズ」を正しくする（srcset/sizes）。。
多くのサイトが遅いのは、圧縮していないからではなく、900pxのページしか表示しないのに3000pxの画像をダウンロードさせるからだ。圧縮はKBを節約できるが、“間違ったサイズ ”は無駄に数倍のデータをダウンロードさせることになる。

4.元の画像ではなく、「小さい方」を読み込んでいることを確認するにはどうしたらいいですか？

2つの現象を見てみよう：

• 携帯電話でページを開くと、ダウンロードした画像のサイズがデスクトップに比べて明らかに小さい。
• 同じ画像を異なるデバイスで異なるリソースサイズで読み込む
  オリジナルの画像がいつまでもダウンロードされる場合、よくある原因は、テーマ/ビルダーが画像をCSSの背景画像またはカスタム出力として扱い、メディアライブラリのsrcsetによるマルチサイジングをバイパスしてしまうことです。

5. “WebP/AVIF生成 ”とは、フロントエンドがWebP/AVIFを生成しなければならないという意味ですか？

平等ではない。
フロントエンドが実際にWebP/AVIFを配信するかどうかは、書き換え、画像タグ付けポリシー、キャッシュヒット、有効なブラウザネゴシエーションなどに依存します。終了したら、必ず「リソースタイプについていくつかの画像をスポットチェック」してください。

6.プラス WebPやAVIFの何がそんなに危険ですか？ワンクリックでライブラリ全体を実行できますか？

そのリスクポイントは「圧縮」ではない。資産移動レベルの変化：

• 完全生成は、オリジナルの画像ファイルIDを上書きし、オリジナルファイルを削除し、コンテンツ内のURLを置き換えることができる。
  なぜいきなりライブラリ全体を入れ替えるのはお勧めできない。まずは小規模（数十～数百）でテストし、バックアップをとってから、フルライブラリ処理を検討する。

7.PlusWebPの2つのモードのうち、オリジナル画像を維持するモードと、オリジナル画像を置き換えて削除するモードの選択は？

わかりやすい：

• モード1：オリジナル画像を保持＋WebP/AVIFコピーを生成（より安定）ロールバックには便利だが、ディスクが増える（元画像＋新フォーマット＋マルチサイズサムネイル）。
• モード2：元の画像を置き換えて削除する（よりアグレッシブ）ディスクは肥大化しにくいが、“アセット変更＋リファレンス変更 ”となり、互換性問題のトラブルシューティングにコストがかかる。
  サイトが複雑であればあるほど（eコマース／マルチプラグイン／マルチサイズ）、より安定したモデルから始めることをお勧めします。

8.EWWW Image Optimizerの無料ローカル圧縮で十分ですか？サーバーを圧迫しませんか？

EWWWはどちらかというと “ローカル・コンプレッサー ”で、CPU/IOを食べる。
バッチ最適化中に負荷が上昇するのはよくあることで、これは「うまくいかない」という意味ではなく、バッチ、低ピーク、必要であればオフロード／クラウドオプションといった戦略が適切であることを意味する。
もし節約をお考えなら、あるいはサーバーのリソースが不足しているなら、ルートBの方がサーバーに優しい。

9.ShortPixelの100クレジット/月の無料クレジット、数枚の写真でなくなった気がするのはなぜ？

につき クレジットは「写真の枚数」ではない。“次世代機は次世代機でサムネイルが拡大される：

• オリジナル画像＋すべてのサムネイルがクレジットとしてカウントされる
• WebP/AVIFが生成された場合、対応するバージョンごとに追加クレジットが消費される。
  つまり、あなたが「1枚の画像」だと思っているものは、実際には「2桁のクレジット」に近いものを消費している可能性がある。

10.Imagifyの月額20MBが無料ですが、これもすぐになくなってしまうのはなぜですか？

Imagifyはむしろ “トラフィックパック ”に近い：

• 送ってくれた通りだ。オリジナル・ファイル・サイズノルマ控除
• サムネイルが多いほど消費量も増える
• 再最適化のために圧縮レベルを変更すると、再びクォータを消費します。
• 同一API Key マルチサイト共有、クォータ共有
  つまり、「20MBがもうすぐなくなる」というのは、画像が大きすぎたり、サムネイルが多すぎたり、試行錯誤を繰り返していることが原因であることが多い。

11.TinyPNGは500クレジット/月で無料ですが、なぜプラグインでは100クレジット/月程度と表示され、WebP/AVIFでは50クレジット/月と表示されるのですか？

TinyPNGのクレジットも “size/variant ”で大きくなっているからだ：

• 通常のWordPressのインストールでは、おそらく月に100枚程度圧縮される。
• AVIFまたはWebP変換を有効にする：画像サイズごとに追加クレジットを消費そのため、（サムネイルサイズの数にもよりますが）おそらく月に50枚程度の画像しか圧縮・変換できないでしょう。
  つまり、500クレジット≠500画像というわけだ。

12.サムネイルは何枚ありますか？なぜそんなに重要なのですか？

WordPressでは、画像をアップロードすると複数のサイズが生成されます。テーマやプラグイン（特にeコマース）では、さらに多くのサイズが追加されることがあります。
クラウド圧縮のクレジット／クォータは通常「オリジナル＋サムネイルを一緒に」なので、サムネイルが多ければ多いほど、無料で使えるクレジットは少なくなる。

13.遅延ロードは常に速いのですか？なぜ遅延ロードは遅くなると言う人がいるのですか？

遅延ロードは「画面外のリソース」に適している。
最も重要な大きな画像の最初の画面も遅延ロードされている場合は、最初の画面のエクスペリエンスを遅くすることがあります。 WordPressの5.5は、デフォルトの遅延ロードは問題ありませんが、 “ワンサイズがすべてに適合 ”しないので。

14.ルートAまたはBで旅行していますが、CDN/ピクチャーCDNはいつ必要ですか？

圧縮、サイジング、フォーマットは、「フィットする小さいファイル」という問題を解決する；
CDNは、より近く、より安定的な製品を提供するという問題を解決します。。
画像がソースサイトから遠く離れた場所から取得され、レイテンシーが大きくなる場合、CDN/画像をCDN（Cloudflare Polish / Jetpack Site Acceleratorなど）で補う方が、全体的に安定します。 WordPress CDN アクセラレーション。

15.完成したとき、「それが本当に機能する」ことを確認する最も簡単な方法は？

最も時間効率の良い検証方法：

• 同じページが2回目にリフレッシュされ、より安定して速く読み込まれるかどうか。
• 携帯電話とデスクトップで読み込まれる画像のサイズが明らかに違う（srcset/sizesが関係しているのか）。
• いくつかの画像をスポットチェック：WebPまたはAVIFファイル/リソースが存在するかどうか
• いくつかの画像をサンプルにする：拡大して、目に見えて濁っていないか、文字がぼやけていないかなどを確認する。