WordPressへ画像を圧縮してからアップロードしてもページ速度がほとんど変わらない主な理由は、閲覧者がその元画像ではなく、WordPressやテーマが作った別サイズ、画像最適化プラグインの再エンコード、CDN変換後のファイルを受け取ることが多いからです。まずメディアライブラリの元ファイル容量ではなく、実際のページをChrome Networkで開き、選ばれた画像URL、CSS表示寸法、intrinsic寸法、転送量、srcsetとsizesを確認します。その測定結果から寸法、形式、品質、配信を直します。
WordPressは複数の画像サイズを生成する
画像をアップロードすると、WordPressはthumbnail、medium、medium_large、largeなどの中間サイズを生成します。テーマとプラグインもadd_image_size()で追加できます。記事のImageブロックやwp_get_attachment_image()が出すHTMLにはsrcsetとsizesが付き、ブラウザーはviewport、DPR、レイアウト幅に合う候補を選びます。元画像を80KBにしても、テーマが別途作ったlarge画像が200KBなら、閲覧者の転送量は200KB側です。
「圧縮したのに効かない」をNetworkで確認する
- 未ログインの新しいブラウザープロファイルで対象ページを開く。
- DevToolsのNetworkでImgを絞り、Disable cacheを有効にして再読み込みする。
- 問題画像を選び、Request URL、Content-Type、Transferred、Resource Size、Cache、Priorityを記録する。
- Elementsでimgのsrc、srcset、sizes、width、height、loading、fetchpriorityを確認する。
- Rendered sizeとNatural sizeを比較し、必要以上に大きい候補を配信していないか見る。
- スマホ幅、DPR 1／2／3、デスクトップで選択URLと転送量が変わるか確認する。
画像CDNを使う場合、URLの幅・品質パラメーターやレスポンスヘッダーも確認します。メディアライブラリURLとNetwork URLが違えば、元ファイルを手元で圧縮するよりCDN変換設定が支配的かもしれません。キャッシュヒット時のTransferredが小さくても初回利用者のファイル自体が軽いとは限らないため、Resource Sizeと新規キャッシュの両方を見ます。
ピクセル寸法を先に最適化する
画質スライダーを下げる前に、表示に必要な最大ピクセル寸法へ縮小します。本文幅800 CSSピクセルでDPR2までを想定するなら、1600px程度の候補が一つの目安ですが、ズーム、wide/fullブロック、将来のレイアウト、トリミングを含めて設計します。6000pxの写真を800px表示するために配信すると、圧縮率が高くてもデコードメモリと処理時間が増えます。
ただし元画像を永続的に捨てると将来の再トリミングや印刷に使えません。Web配信用とマスター保管を分け、マスターは公開uploadsではなく、アクセス制御された資産管理やバックアップへ保存します。
big image thresholdを理解する
WordPressは大きな画像の幅または高さが既定の閾値を超えると、縮小版を最大利用サイズとして扱う仕組みを持ちます。big_image_size_thresholdの既定値は2560pxです。元ファイルも保管される構成がありますが、PNGなど処理差があり、版やフィルターで変わります。閾値を無効化するコードを安易に追加せず、テーマの最大表示、編集要件、ストレージ、バックアップ、サーバーメモリを確認します。
再圧縮で元の最適化が変わる
WordPressは中間サイズ作成時に画像をデコードし、GDまたはImagickでリサイズして、出力形式と品質設定で再保存します。アップロード前にJPEG品質を調整しても、その圧縮ビット列が派生画像へそのままコピーされるわけではありません。既に強く圧縮したJPEGを再度非可逆圧縮すると、容量があまり減らないのにブロックノイズや輪郭劣化が増えることがあります。元画像の品質、派生サイズの品質、CDN品質を重ね過ぎないよう、一段ごとに比較します。
WP_Image_Editorの品質
WordPressのWP_Image_Editor::set_quality()は1〜100の品質値を扱い、wp_editor_set_qualityフィルターで既定品質を変更できます。現在のAPIではMIMEタイプと寸法も判断材料にできます。しかし値100が元画像と同一や可逆を意味するわけではなく、形式とGD／Imagick実装で結果が異なります。全画像へ一律の低品質を設定せず、写真、ロゴ、スクリーンショット、文字入り図版、各寸法をサンプル検証します。
フィルターコードはテーマ変更で失わないサイト専用プラグインなどへ入れ、ステージングで新規アップロードに対する派生画像を比較します。既存画像は設定変更だけでは自動再エンコードされません。
形式をコンテンツに合わせる
- JPEG：写真に向く非可逆形式。透過は扱えず、文字や線画ではにじみやすい。
- PNG：ロゴ、UI、線画、透過に向くことがある。写真では大きくなりやすい。
- WebP：非可逆・可逆と透過に対応し、WordPress 5.8以降でアップロード対応。サーバーライブラリ対応を確認する。
- AVIF：高圧縮が期待できるが、WordPress版、GD／Imagick、ホスティング、ブラウザー、処理時間を確認する。
- SVG：ロゴやアイコンに適する場合があるが、スクリプト等を含められるためWordPress既定の許可状況と安全なサニタイズを確認する。
形式変換は必ず軽くなるわけではありません。小さなPNGロゴを非可逆WebPへ変えてにじませる、スクリーンショットをJPEGにして文字を読みにくくする例があります。代表画像を同じ表示寸法で比較し、視覚品質、透過、色、アニメーション、メタデータ、ファイルサイズを評価します。
レスポンシブ画像を正しく出力する
テーマ開発では、メディアURLを生のimgへ直書きするよりwp_get_attachment_image()へ添付IDと登録済みサイズを渡すと、WordPressが幅・高さ、srcset、sizes、読み込み最適化属性を生成できます。サイズ配列をその場で指定するより、用途名でadd_image_size()を登録し、実ファイルを生成する方が効率的です。
<?php
echo wp_get_attachment_image(
$attachment_id,
'large',
false,
array( 'alt' => $meaningful_alt_text )
);
?>テンプレートへ入れる実コードでは添付ID、alt、権限、戻り値を検証し、親テーマを直接編集しません。CSS背景画像やページビルダー独自画像はWordPressのsrcset経路を使わない場合があるため、実HTMLとNetworkで確認します。
sizesが実レイアウトと合っているか
srcsetに複数候補があっても、sizesが「画像は常に100vw」と伝えると、本文では半幅なのに大きな候補を選ぶ可能性があります。テーマの本文幅、wide/full、サイドバー、Grid、スマホ1列化に合わせてsizesを調整します。ブラウザーの候補選択はキャッシュ状況にも影響され、viewportを縮めても一度取得した大画像を使い続けることがあるため、新しい読み込みで検証します。
プラグインとCDNの役割を一つずつ確認する
画像最適化プラグインは、既存派生画像の再圧縮、WebP／AVIF生成、元画像バックアップ、遅延読み込み、CDN配信を組み合わせます。二つ以上を重ねると、二重圧縮、URL書き換え競合、削除不能、課金増、キャッシュ不整合が起きます。機能表ではなく、Networkで誰が最終ファイルを生成・配信しているかを確認し、責任を一つに寄せます。外部サービスへ画像を送る場合は個人情報、データ所在地、保存期間、削除、障害時の原本を確認します。
既存画像の再生成
画像サイズや品質を変えても、通常は今後アップロードする画像だけに反映されます。既存画像へ適用するにはWP-CLIのwp media regenerateなどでsub-sizeを再生成できますが、全メディアを処理するとCPU、メモリ、I/O、ディスク、実行時間を大きく使います。事前にデータベースとuploadsをバックアップし、ステージングで少数ID、特定サイズ、dry-run相当の確認を行い、サーバー制限とメンテナンス時間を決めます。
再生成中に既存ファイルを置き換える、使われない古い派生画像が残る、画像CDNが旧版をキャッシュする場合があります。途中失敗を記録し、成果物件数とページ表示を検証します。一括削除ツールは投稿本文、カスタムフィールド、CSS、外部参照を完全に把握できないことがあるため慎重に使います。
不要な中間サイズとストレージ
テーマやプラグインが多数のimage sizeを登録すると、1枚のアップロードから多くのファイルが生成されます。ページ転送量とは別に、uploads、バックアップ時間、inode、CDNオリジン容量が増えます。登録サイズ一覧と実際の利用箇所を調べ、不要サイズを将来分から停止します。既存ファイルの整理は参照監査とバックアップ後に行います。テーマ変更で再び必要になる可能性もあります。
LCP画像とlazy loading
ファーストビューの大きなヒーロー画像はLargest Contentful Paintになりやすく、軽量化だけでなく優先度と読み込み時期が重要です。画面外画像はlazy loadingに向きますが、LCP候補へ強制的にlazyを付けると表示開始が遅れます。WordPressコアは文脈に応じてloading、decoding、fetchpriorityを最適化する仕組みを持つため、プラグインがすべてへ同じ属性を上書きしていないか確認します。PerformanceやPageSpeed系計測で実ページを評価します。
widthとheightでレイアウト移動を防ぐ
容量が小さくても、画像のwidthとheightまたはaspect-ratioがなく、読み込み後に本文が押し下がると体験が悪化します。WordPressの添付画像APIは寸法属性を出力できます。CSSでheight:autoを使いながら縦横比を保ち、コンテナの最大幅を超えないようにします。切り抜き画像では登録サイズと実ファイル寸法を一致させます。
EXIFとプライバシー
スマートフォン写真には位置情報、撮影日時、端末情報などEXIFメタデータが含まれる場合があります。WordPressの画像処理が派生画像から一部メタデータを除く実装でも、元アップロードや特定形式、バックアップ、CDNに残る可能性があります。アップロード前のプライバシー検査、元画像の公開可否、メディア直リンクを確認します。単なる容量最適化プラグインを個人情報除去の保証として扱いません。
画質を評価する代表ケース
- 空やグラデーション：バンディング、色むら、輪郭。
- 髪、葉、布：細部のつぶれとリンギング。
- 文字入りスクリーンショット：小さい文字、細線、赤色、透過。
- ロゴ：透明縁、ブランド色、ダーク／ライト背景。
- 顔：肌の階調、目や髪、過度なシャープネス。
- スマホDPR3とデスクトップDPR1：見た目と候補選択、転送量。
管理者一人の高解像度モニターだけで判断せず、対象端末、明暗、ズーム、回線で比較します。品質値の数字ではなく、用途に必要な視覚品質と転送量の折衷を決めます。
改善の優先順位
- Networkで実配信ファイルとLCP候補を特定し、測定前の推測をやめる。
- CSS表示に対して過大なピクセル寸法と誤ったsizesを直す。
- 写真・図版に合う形式と品質を代表サンプルで選ぶ。
- WordPressの登録サイズとテンプレートを整理し、wp_get_attachment_imageを使う。
- 画像最適化プラグイン／CDNを一系統にし、キャッシュと原本復旧を設計する。
- 既存画像はバックアップと少量テスト後に再生成し、ページとストレージを検証する。
- 実機の初回表示、Core Web Vitals、アクセシビリティ、画質を再測定する。
アップロード前圧縮が無意味なのではありません。元画像がそのまま配信されるページや、uploads・バックアップ容量には効果があります。ただしWordPressサイトの表示速度では、実際に選ばれるsub-size、srcset／sizes、CDN変換、表示寸法が支配的です。元ファイルではなくNetworkの最終レスポンスを基準に最適化してください。
コメント