WordPress 7.1で画像処理がブラウザ側へ、ブログの画像アップロードはどう変わる？

WordPress 7.1では、画像をアップロードするときの「裏側」が大きく変わります。対応するブラウザでは、画像の圧縮やリサイズ、回転、サムネイル生成などをレンタルサーバーへ任せるのではなく、記事を書いている側のブラウザで処理できるようになります。

普通にブログを書いているだけなら、新しい設定方法を覚える必要はありません。対応できる環境ではブラウザ処理を使い、条件を満たさなければ従来のサーバー処理へ自動的に戻る仕組みだからです。

一方で、「画像アップロードが必ず速くなる」「画像圧縮プラグインが全部不要になる」と理解すると少し違います。WordPress 7.1のClient-Side Media Processingは、サーバーのCPUやメモリ負荷を減らしつつ、画像処理環境をそろえやすくすることが大きな狙いです。

2026年8月19日6時時点：WordPress 7.1の公式リリース日は8月19日です。公式のRelease Day Processでは8月19日23:10 UTCから公開予定とされており、日本時間では8月20日8:10ごろに当たります。

WordPress 7.1では画像処理をブラウザ側でできるようになる

WordPress 7.1には「Client-Side Media Processing」が導入されます。対応ブラウザでは、画像の圧縮、リサイズ、形式変換、回転、サムネイル生成などをWebAssemblyを利用してブラウザ内で処理します。

これまでWordPressへ画像をアップロードすると、まず元画像をサーバーへ送り、サーバー側のPHPとGDまたはImagickが複数サイズの画像生成や回転、大きすぎる画像の縮小などを担当するのが基本でした。

7.1では、条件を満たす環境なら記事を書いているPCなどで画像を加工し、元画像と生成済みの各サイズをサーバーへ送ります。サーバーは完成したファイルを保存する側へ役割が寄るイメージです。

従来の画像処理とWordPress 7.1は何が違う？

違いを大づかみにすると、画像をアップロードした後にサムネイルなどを作る場所が「サーバー中心」から「対応環境ではブラウザ中心」へ変わります。

比較	従来の基本動作	WordPress 7.1の対応環境
画像加工	サーバー側	ブラウザ側
サムネイル生成	GD・Imagickなど	ブラウザ内のlibvips
生成画像の送信	元画像を送信後、サーバーで生成	元画像と生成した各サイズを送信
非対応環境	サーバー処理	従来のサーバー処理へ自動で戻る

利用者から見ると操作方法そのものを変える機能ではなく、「画像を選んでアップロードする」という流れは基本的に同じです。処理を担当する場所が変わる、と考えると分かりやすいでしょう。

ブログ運営ではサーバーのCPU・メモリ負荷を減らせるのが大きい

一般的なブログ運営で分かりやすいメリットは、画像処理の負担をサーバーから投稿者の端末へ移せることです。WordPress公式は、大きな画像を処理するときに起こるPHPのメモリ上限による失敗を避けやすくなり、サーバーのCPUとメモリ負荷も減らせると説明しています。

スマートフォンやデジタルカメラの高解像度写真をそのままアップロードすることが多いサイトでは、画像生成時の負荷が問題になることがあります。共有レンタルサーバーでも、画像を追加した瞬間だけ処理が集中する場面を減らせるのは分かりやすい恩恵です。

また、ブラウザ側ではlibvipsを利用するため、サーバーにGDとImagickのどちらが入っているかといった環境差の影響を受けにくくなります。公式資料では、生成したJPEGについてGDやImagickより約15％小さくなる例も示されています。

ただし、この約15％はすべての画像が一律に15％軽くなるという意味ではありません。画像形式や内容、設定によって結果は変わるため、「WordPress 7.1にすれば画像容量が必ず15％減る」とは考えない方がよいでしょう。

画像アップロード時の通信量が減る機能ではない

Client-Side Media Processingという名前から「ブラウザで圧縮してから送るなら、アップロードも軽くなる」と考えたくなりますが、ここは少し注意が必要です。

従来方式では基本的に元画像をサーバーへ送り、各サイズの画像はサーバー内で生成します。クライアント側処理では、元画像に加えてブラウザで生成した各サイズも個別にアップロードします。

WordPress公式も、アップロード時に通信する総データ量は従来方式より増えると説明しています。つまり、この機能の中心的なメリットは「アップロード通信量の節約」ではなく、「画像加工に使っていたサーバーのCPUとメモリを節約すること」です。

生成される画像自体はより効率よく圧縮できるため、読者へ配信するときの画像容量を抑えられる可能性があります。「投稿するときの通信」と「読者が画像を見るときの通信」は分けて考える必要があります。

Chrome・Edge以外では従来方式へ自動で戻る

WordPress 7.1公開前の公式Dev Noteでは、フルのクライアント側画像処理はDocument-Isolation-Policyを利用できるChromium系ブラウザが対象です。ChromeとEdgeはバージョン137以降が対応として案内されています。

FirefoxやSafariでは、フルの画像処理パイプラインは標準では使わず、従来のサーバー側処理へ自動的に戻ります。処理方法を利用者が毎回選ぶ必要はなく、非対応だから画像がアップロードできなくなるわけでもありません。

ブラウザだけでなく、端末のメモリやCPU、通信状態なども確認されます。低メモリ端末や低速回線など、ブラウザ側で処理するのが適さない状況では自動的にサーバー処理へフォールバックします。

そのため、普段Safariでブログを更新している人がWordPress 7.1へ上げたからといって、新機能を使うためだけにブラウザを変更する必要はありません。まずは今までどおり使い、画像アップロードで問題がないかを見る程度で十分です。

iPhoneのHEICやAVIFも扱いやすくなる

画像形式の対応が広がることもWordPress 7.1の特徴です。HEIC画像は対応環境でブラウザがデコードし、Webで使いやすいJPEGへ変換してアップロードできます。元のHEICは関連ファイルとして保持されます。

ただし、HEICのデコード対応はブラウザとOSの組み合わせに左右されます。WordPress公式はChromium系ではmacOSやHEVC対応Windows、SafariではmacOSでのHEICデコードなど、環境条件があることを案内しています。

AVIFについても、ブラウザ側で処理できればサーバー側の画像ライブラリがAVIFに対応していない環境でもアップロードできる範囲が広がります。写真を扱うブログでは、レンタルサーバーの画像処理ライブラリだけに左右されにくくなるのがポイントです。

なお、アニメーションGIFにはさらに特殊な処理があり、不透明なGIFをMP4またはWebMの動画へ変換して表示データを減らす仕組みも含まれます。透明GIFや一部のブロック内に置いたGIFなどは対象外で、ブラウザが必要な機能に対応していない場合は元のGIFがそのままアップロードされます。

WordPress 7.1で画像最適化プラグインは不要になる？

WordPress 7.1へ更新しただけで、画像関連プラグインが一律に不要になるとは言えません。今回の変更は、画像をアップロードするときのリサイズや圧縮、形式変換、サムネイル生成をブラウザ側でも行えるようにするものです。

画像最適化プラグインには、CDNからの配信、過去にアップロードした画像の一括最適化、遅延読み込み、WebP・AVIF配信の制御、ウォーターマークなど、WordPress本体のアップロード処理とは別の役割を持つものがあります。

WordPress公式では、CDN同期、ウォーターマーク、カスタムメタデータなどで使われる既存の処理フックも引き続き動くよう配慮されています。ただし、プラグイン開発者にはクライアント側処理とサーバー側処理の両方で確認するよう求めています。

利用者側では、「7.1だから画像プラグインを削除する」のではなく、そのプラグインを何のために入れているか確認するのが先です。単純なアップロード時圧縮だけが目的なのか、CDNや既存画像の最適化まで使っているのかで判断は変わります。

WordPress 7.1へ更新したら確認したい画像アップロード

アップデート後は、特殊な検証よりも自分が普段扱っている画像を実際にアップロードしてみるのが分かりやすい確認方法です。

1. 普段記事で使うJPEGをアップロードし、画像ブロックへ正常に表示されるか確認する
2. 透過PNGを使うサイトなら、背景の透明部分が崩れていないか確認する
3. 大きな写真を扱うなら、高解像度画像でもアップロードとサムネイル生成が完了するか確認する
4. iPhone写真をPCへ取り込んでHEICのまま使うなら、HEIC画像の登録と表示を確認する
5. WebPやAVIFを直接使っているなら、普段の形式でもアップロードと公開表示を確認する

画像圧縮、CDN、ウォーターマークなどのプラグインを使っている場合は、メディアライブラリへ登録できたことだけでなく、プラグイン側の処理まで完了しているかも確認します。

リリース候補版を事前に試す場合は、本番サイトではなくステージングやテスト環境を使います。WordPress 7.1 RC4の公式案内でも、開発版を本番・重要サイトへ入れず、テスト環境で評価するよう案内されています。

WordPress 7.1の画像処理についてよくある質問

まとめ：画像処理を「サーバーだけに任せない」WordPressへ

WordPress 7.1のClient-Side Media Processingは、ブログの画像投稿画面を大きく作り替える機能ではありません。対応できる端末では画像加工をブラウザへ分担し、難しい環境なら従来のサーバー処理へ戻す、という裏側の改善です。

一般的なブログ運営者にとっては、サーバーのCPU・メモリ負荷を減らせること、大きな画像を扱いやすくなること、HEICやAVIFなどの画像形式を扱える範囲が広がることが注目点です。一方で、アップロード時の通信量は減るとは限らず、画像最適化プラグインの役割もすべて置き換えるわけではありません。

更新後は仕組みを細かく追うより、JPEG、大きな写真、HEICなど自分が普段使う画像を1枚ずつ試して、いつもの記事投稿が問題なくできるか確認するのが実用的です。

参考にした公式情報

• Client-Side Media Processing in WordPress 7.1
• Call for Testing: client-side media processing
• WordPress 7.1 Field Guide
• WordPress 7.1 Release Candidate 4
• WordPress 7.1 Release Day Process