画像は、
小さくする前に
表示する幅から。

01 / DISPLAY FIRST

「横1200pxなら正解」ではありません。

画像ファイルのピクセル数と、ページ上の表示幅は別です。本文の横幅が600 CSS pxなら、横600pxを起点に、細部が必要な画面では横1200px程度の候補も比較します。2倍は高密度画面向けの目安で、全画像への固定ルールではありません。拡大閲覧する図は、その用途も含めて決めます。

幅と容量をどこで見る？

1. 元ファイル：Windowsはファイルの「プロパティ → 詳細」、Macはプレビューの「ツール → インスペクタを表示」でピクセル寸法を確認。ファイルの情報で容量も控えます。表示や項目名はOSで異なります。
2. WordPress：「メディア → ライブラリ」で画像を開き、ファイルサイズと寸法を確認。投稿側で選んでいる「解像度／画像サイズ」も別に見ます。
3. 表示幅：PCで画像を右クリックして「検証」を開ける場合は、選択したimgの表示サイズを確認。難しければテーマの本文幅を目安に、下書きプレビューで比較します。最大の見出し画像と本文内の小画像は別々に判断します。

02 / CHOOSE A FORMAT

形式より先に、画像の中身を見る。

形式の機能と対応状況も参照し、迷ったら写真はJPEGとWebP、細かな文字や図はPNGとWebPから比較。AVIFは対応環境で追加検討する順で十分です。無理に全画像を同じ形式へ揃えません。WordPress公式：AVIFとサーバー対応

03 / OUR CONTROLLED COMPARISON

同じ絵で、どこまで変わったか。

個人情報のない自作の合成風景画を使用。細い草・色のグラデーション・文字を含めています。実写写真の代表値ではなく、この1枚の結果です。元は2400×1600pxのPNG、1,847,788 bytes。1200×800pxへ縮小したPNGは731,142 bytesでした。

縮小だけで60.43％減。以下は、縮小後の同じ1200×800pxを各形式で保存した比較です。形式と寸法の効果を混ぜないため、削減率の基準も縮小後PNGに揃えています。

ファイル本体の実測bytes。KBは1,000 bytes換算。容量削減率＝（1−候補容量÷731,142）×100。通信量・LCPの改善率ではありません。

WebPを表示。小さい表示で違いが分からない場合は、下の実ファイルを等倍で開いて比較してください。

自分の画像に近い素材で、画質を見比べる

下の切り出しはすべて240×144pxを同じ大きさで表示します。PNGの基準と各変換後の同じ位置を比較し、読めない文字・消える細部・透明な縁を確認してください。容量は切り出す前のファイル全体の値です。必要な素材だけ開けます。

写真：赤い花の階調と花粉を見る

花びらの暗部・赤の境界・花粉の粒を比較。テーマ同梱の既存WebP（56,851 bytes）を再利用しました。すでに圧縮された素材なので、再変換で原撮影の細部は戻りません。PNG化して大きくなった基準からの削減率で、変換の必要性を判断しないでください。

元寸法1079×783px。縮小なし。JPEG品質76／WebP品質75／AVIF品質50は、同じ画質という意味ではありません。

素材：Twenty Twenty-Five同梱「Hibiscus flower」。同梱readmeのCC0記載を確認。配布元情報

操作画面：文字と細い線を見る

既存のWordPress実画面を再利用。Replaceの文字、細い罫線、その周りのにじみを比較します。文字が読めることを容量より優先。

元寸法1280×900px。縮小なし。JPEG品質76／WebP品質75／AVIF品質50は、同じ画質という意味ではありません。

透過図：輪郭・ベタ塗り・透明な縁を見る

新しい小さな自作図を使用。透明部分と半透明の影を市松模様上で比較。JPEGだけは白に合成したため、透過を保つ候補と同条件ではありません。

元寸法480×320px。縮小なし。JPEG品質76／WebP品質75／AVIF品質50は、同じ画質という意味ではありません。

この図ではWebP可逆のRGBA画素がPNG基準と完全一致しました。透過と輪郭を残したいときは、非可逆の品質を下げる前に可逆候補も比較できます。

採用基準は「必要な情報が読める・構図と透過が保てる・環境で表示できる」の順。その条件を満たした候補の容量を比較します。どの形式も、まず1枚で確認。すでに十分なら再変換しません。

別名の画像を作る具体例

Macの「プレビュー」でJPEGを作る場合（公式手順による案内）：原本を複製して開く → 「ツール → サイズを調整」→ 単位をピクセルにし、縦横比を固定・再サンプルを有効にして幅を指定 → 「ファイル → 書き出す」でJPEGを選び、画質と保存先を確認して別名保存。保存ファイルを開き直し、文字と容量を確認します。解像度のdpi値だけではなく、ピクセル寸法を見ます。サイズ調整 ／ 形式変更。今回の形式別実測はプレビューではなくPillowの結果です。

Windows・Mac共通：Squooshで1枚を変換する

ブラウザーで使えるSquoosh公式アプリで、今回の合成画像を使った操作を確認しました。公式説明では画像処理はブラウザー内で行われます。アプリ自体の通信は別に発生し得るため、非公開・機密の画像には組織の方針に合う端末内ツールを使ってください。

1. 原本の複製をアプリへ読み込みます。画像を開くのはまず1枚。
2. 右側のEditでResizeを有効にし、幅を入力。縦横比を維持し、高さも意図どおりか確認します。
3. Compressの形式からWebP等を選択。Qualityを少しずつ変え、中央の比較と表示容量を見ます。ツール間で品質値を同一視しません。
4. ダウンロードボタンから保存。端末にできたファイルの寸法・拡張子・見え方を確認し、WordPressへはそのファイルをアップロードします。

小さければ採用、ではありません。

このサンプルでは、低画質JPEGの草や文字の縁がつぶれ、JPEG・WebP・AVIFでも細かな模様に差が出ました。見え方は表示倍率や画面で変わります。比較画像を開き、同じ倍率で文字の輪郭・草・空の階調を見比べてください。品質の自動スコアだけで合格を決めていません。

画面に表示して十分な候補を選び、初回の目標容量は固定しません。「100KB以下」などを必須条件にして、読ませたい情報を壊さないことが大切です。

04 / UPLOAD, REPLACE, CHECK

WordPressでは、まず1枚だけ差し替える。

以下はブロックエディターでの流れです。独立したWordPress 7.1.2・標準テーマで、同じ合成画像のアップロードと反映を確認しました。管理画面は英語表示で、本文では対応する日本語の操作名を併記しています。バージョン・言語・テーマによりラベルや配置は異なります。クラシックエディターや画像最適化プラグインの固有画面は対象外です。

1. 戻す準備。元のファイルを端末へ保存。投稿の現在の内容を複製・下書き等で退避し、画像の名前と表示サイズも控えます。メディアの旧画像を削除しません。広く変更するなら先にバックアップと復元方法を確認。
2. 別名で候補を作る。画像編集ソフトで幅を調整し、形式・画質を選んで書き出す。例：original.pngを残し、article-1200.webpを作成。オンライン変換を使うなら公開してよい画像だけに限定し、機密画像は端末内で処理します。
3. メディアにアップロード。「メディア → 新しいメディアファイルを追加」または画像ブロックの「アップロード」へ。寸法と容量を確認し、内容に合う代替テキストを入力。装飾だけの画像は装飾として扱い、キーワードを詰め込みません。
4. 投稿の画像を置換。投稿を編集し、既存画像を選ぶ → ツールバーの「置換」→ メディアライブラリから新画像を選択。「解像度／画像サイズ」が小さすぎないか確認。横幅だけを整え、高さは自動を基本にします。
5. プレビューしてから保存。同じ場所の文字・構図をPCとスマホ幅で比較。保存後はログアウトした画面でも確認。アイキャッチ、別投稿の同じ画像、SNSの見え方は別対象なので、必要なものだけ個別に確認します。

投稿の置換は、サイト全体の画像の置換ではない。

画像ブロックを別のメディアに替えても、他の投稿やアイキャッチは自動で同じ画像になるとは限りません。逆にメディア原本の編集やプラグインの一括処理は、複数の利用先へ影響する場合があります。最初は「別ファイルのアップロード＋1ブロックの置換」が戻しやすい方法です。

05 / KEEP IT SIMPLE

プラグインが必要になるのは、作業が繰り返し増えるとき。

導入前に「変換・圧縮・サイズ生成・遅延読込・CDN」のうち既存機能と重なるものを確認します。無料枠や有料サービスへの外部送信条件も確認。一括処理の前に別環境の数枚で、画質・複数サイズ・元に戻す方法を試してください。本記事は特定プラグインの実運用比較や推奨ランキングではありません。

06 / FIND THE CAUSE

ぼける・切れる・崩れる。戻す場所を間違えない。

07 / BYTES ARE NOT SPEED

画像が軽くなっても、速くなるとは限りません。

小さくした画像が実際に配信されていなければ、転送量は減りません。逆に転送量が減っても、サーバー応答・CSS・JavaScript・フォント・遅延読込の待ち時間が残る場合があります。LCP（主要な内容が表示されるまでの指標）の対象が、変更した画像とは限りません。

1. Chrome等の開発者ツール「Network」で画像に絞り、同じページ・同じ画面幅で再読み込み。読み込まれた画像URL・寸法と、転送量／リソースサイズを区別します。キャッシュの有無も揃えます。
2. 保存した画像の容量と、実際の配信ファイルが一致するか確認。srcset・sizesがある場合は、ブラウザーが別サイズを選ぶことがあります。
3. 速度を比べる場合は同じ端末・回線・キャッシュ条件で複数回。PageSpeed Insightsのラボ測定と実ユーザーデータを分けます。1回のスコア差を改善の証明にしません。

原因が画像以外なら、WordPressが遅い原因を切り分けるへ。画像の問題を理由にサーバー移行を急ぐ必要はありません。運用上の制約まで整理できた段階でのみ、サーバーの契約・運用条件を比較します。

08 / A WAY BACK

悪くなったら、元画像を選び直す。

1. ブロックの置換を戻す：編集を保存する前なら「元に戻す」。保存後は画像ブロックの「置換」から残してある元画像を選び、元の表示サイズ・代替テキスト・キャプションも照合して保存します。
2. メディアそのものを編集した：利用中の版に「元の画像を復元」等があれば対象と影響を確認。使えなければ端末に保管した原本を別名で再アップロード。復元機能がすべての変換・削除を戻すとは限りません。WordPress公式：メディア編集
3. 一括処理・CDNを使った：停止するだけで戻ると決めつけず、導入前に保存した設定と各製品の復元手順へ。メディア削除・URL一括置換・本番DBの編集は、この確認のために行いません。

復元後はログアウト表示、PC・スマホ幅、代表的な他の利用先を確認。元画像が消えた、複数ページで壊れた、戻し方が不明なら作業を止めてバックアップの復元範囲を確認します。

1枚の完了チェック

チェックは自分の作業確認用です。入力は保存・送信しません。

0 / 5 確認済み

問題なければ同じ基準で次の画像へ。必要な画像だけを順に進めます。

確認範囲と、まだ確かめていないこと

2026年10月20日。自作風景画の比較を保持し、写真1点・既存WordPress画面・透過図1点のファイル比較を追加。Pillowによる再保存と独立WordPress 7.1.2での既存操作検証を区別しています。画像形式別のファイル容量と寸法、WordPressの派生サイズ生成、画像の差し替えと元URLへの復元、ブラウザーでの表示を確認しました。実画面は検証用環境のもので、生成した管理画面ではありません。

本番のLCP・転送量改善、実機・初心者第三者テスト、すべてのテーマ・プラグイン・サーバーでの互換性、写真一般や透過画像全般・アニメーションの最適値は未検証。追加3素材はファイル変換とブラウザー比較までで、これらをWordPressへ再取り込みした検証ではありません。合成画像の容量差を、サイト全体の速度差や収益向上に換算していません。

公式の確認先

• Squoosh：公式の動作説明 — ブラウザー内の画像処理。
• Apple：プレビューのサイズ調整 ／ 形式変更 — Macでの操作例。
• WordPress：画像ブロック — 追加・置換・解像度・表示設定。版やテーマで画面が変わります。
• WordPress：メディアの編集 — 編集と原本の扱い。
• WordPress：AVIF対応 — コアの対応とサーバー処理の条件。
• MDN：画像形式の機能・対応 — JPEG・PNG・WebP・AVIFの違い。
• web.dev：画像のパフォーマンス — 配信サイズ、画像属性、遅延読込。

公式情報と独立検証を分けて記載。編集・検証方針 ／ 訂正を連絡する