WordPress 7.1が、2026年8月19日にリリースされる。
今回もブロックエディタの改善や管理画面の変更、開発者向けAPIの拡張など、多数のアップデートが含まれる。
しかし、その中にひとつ、WordPressの画像処理を根本から変える変更がある。
画像のリサイズや圧縮、フォーマット変換を、Webサーバーではなくブラウザ側で処理するようになる。
そのために使われる技術が、WebAssembly（WASM）だ。
WordPressといえばPHPで動くCMSの代表格である。
そのWordPressが、これまでPHPとサーバー側の画像ライブラリに任せていた仕事を、WASMを使ってユーザーのPCへ移そうとしている。
これは単なる高速化ではない。
レンタルサーバーの負荷を減らし、画像アップロード時の失敗を減らし、さらにWebサイトを訪れるユーザーへ配信する画像そのものまで軽量化する。
WordPress 7.1では、画像処理の常識がかなり変わる。
これまで画像処理はサーバーの仕事だった
WordPressへ大きな画像をアップロードすると、その画像がそのまま保存されるだけではない。
テーマなどで利用するために複数サイズの画像が生成され、必要に応じて画像の回転や縮小、フォーマット変換なども行われる。
これまで、その仕事を担当していたのはWebサーバーだった。
WordPressがPHPからGDやImagickなどの画像処理ライブラリを呼び出し、アップロードされた画像を加工する。
普通に使っているだけなら意識することはない。
しかし、巨大な画像をアップロードした途端に処理が失敗した経験があるWordPressユーザーもいるだろう。
画像処理には、それなりのCPUとメモリが必要になる。
特に多数のユーザーが同じサーバーを共有するレンタルサーバーでは、PHPが利用できるメモリ量にも制限がある。
スマートフォンやデジタルカメラの高画素化によって、画像ファイルは巨大になった。
WordPress側では「大きすぎる画像」を自動縮小する仕組みなども導入されてきたが、その縮小作業自体をサーバーが行う以上、処理負荷がなくなるわけではない。
WordPress 7.1は、この構造そのものを変える。
画像処理をブラウザへ持ってきた
WordPress 7.1では、対応するブラウザを利用している場合、画像処理をユーザーのブラウザ側で実行する。
使われるのは「wasm-vips」。
高速な画像処理ライブラリとして知られるlibvipsを、WebAssemblyとしてブラウザ上で動作させる仕組みだ。
WordPress公式のDeveloper Noteによれば、ブラウザ側で行える処理には、
- 画像圧縮
- リサイズ
- クロップ
- JPEG、PNG、WebP、AVIF、GIFなどのフォーマット変換
- EXIF情報に基づく回転
- サムネイル生成
などが含まれる。
しかも処理はWeb Worker上で実行される。
つまり、重い画像処理をJavaScriptのメインスレッドで走らせ、WordPressの編集画面を固めてしまうような単純な実装ではない。
画像を選択すると、ブラウザの中でWASMによる画像処理が行われる。
そして加工済みの画像や各サイズのサムネイルがサーバーへ送られる。
これまで、
画像 → サーバー → PHP＋GD/Imagickで加工
だったものが、
画像 → ブラウザ＋WASMで加工 → サーバー
へ変わるわけだ。
サーバーから見れば、かなりありがたい話である。
レンタルサーバーには特に恩恵が大きい
WordPressは世界中で利用されている。
そして、その多くが巨大な専用サーバーで動いているわけではない。
一般的なレンタルサーバーや共有ホスティングで動作しているWordPressは膨大な数にのぼる。
共有サーバーでは、ひとつの物理サーバーや仮想環境上で多数のWebサイトが動いている。
そこで誰かが巨大な画像をアップロードするたびに、PHPがGDやImagickを使って複数サイズの画像を生成する。
これはホスティング事業者からすれば純粋な計算コストだ。
WordPress 7.1では、その仕事のかなりの部分を投稿者のPCへ渡せる。
画像をアップロードした本人のCPUとメモリを使って画像を処理し、Webサーバーは完成したファイルを受け取って保存する。
WordPress公式も、今回の変更によるメリットとして「Reduced server load」を明確に挙げている。
さらにPHPのメモリ制限による画像処理失敗も避けられる。
画像処理がブラウザのメモリ空間で行われるためだ。
WordPressを大量に収容しているレンタルサーバーほど、この効果は積み重なる。
1回の画像処理で節約できるCPU時間は小さくても、何万、何十万というWordPressサイトを抱える環境なら話は別だ。
WASMが、レンタルサーバー会社のCPUを救う。
なかなか面白い使われ方である。
ユーザーにも「画像が軽くなる」という直接的なメリット
もちろん、得をするのはサーバー会社だけではない。
WordPress公式によれば、今回採用されたlibvipsによるJPEG出力は、GDやImagickより効率的に圧縮でき、MozJPEGに近いエンコードによってJPEG画像を約15％小さくできるとしている。
15％は馬鹿にならない。
Webページのデータ量の中で、画像が占める割合は大きい。
記事中に写真を何枚も掲載するサイトなら、画像が15％軽くなるだけでもページ全体の転送量に効いてくる。
これまでWordPressの画像軽量化といえば、プラグインに頼るケースも多かった。
画像圧縮プラグインを導入する。
WebPへ変換する。
CDN側で画像を最適化する。
あるいは、アップロード前にユーザー自身が画像を縮小する。
Webサイトの高速化を意識する管理者なら当たり前に行ってきた作業だが、普通のWordPressユーザーがそこまで考えているとは限らない。
スマートフォンで撮影した巨大な写真を、そのままWordPressへ放り込む。
そんな使い方も珍しくない。
そしてPageSpeed Insightsを実行して、
「画像の配信を改善してください」
などと怒られる。
WordPressでは昔から見慣れた光景だ。
7.1だけですべての画像最適化問題が消えるわけではない。
LCP画像の扱いや表示サイズ、遅延読み込みなど、Webパフォーマンスには別の要素も存在する。
しかし、
「ユーザーが何も考えず巨大な画像をアップロードしたため、サイトまで巨大になった」
という事故は減らせる。
WordPress本体が、画像最適化の仕事を一段引き受けるようになるからだ。
WebPやAVIFもブラウザ側で扱える
さらに面白いのがフォーマット変換だ。
WordPress 7.1のクライアント側画像処理は、JPEGやPNGだけではなくWebPやAVIFにも対応する。
既存のWordPressフィルター「image_editor_output_format」もブラウザ側で尊重されるため、JPEGからWebPへの自動変換といった処理も可能になる。
AVIFについても、サーバー側のPHP画像ライブラリがAVIFに対応していなくても、ブラウザ側で処理できるケースがある。
さらにHEIC/HEIF画像にも対応する。
iPhoneで撮影したHEIC画像をブラウザでデコードし、Web向けJPEGへ変換してアップロードできる。
これまで画像形式への対応状況は、レンタルサーバーにインストールされているGDやImagick、そのバージョンやビルド構成にも左右されていた。
クライアント側処理なら、その差をかなり吸収できる。
同じWordPressなのに、契約しているサーバーによって画像処理能力が違う。
そんな問題も少しずつ小さくなっていく。
対応しない環境では、これまで通り動く
もちろん、いきなり全ユーザーの画像処理がWASMへ切り替わるわけではない。
WordPress 7.1のフル機能を利用できるのは、現時点では主にChromium系ブラウザだ。
公式情報ではChrome 137以降、Edge 137以降がフルサポート対象となる。
FirefoxやSafariでは必要なDocument-Isolation-Policyが利用できないため、基本的には従来のサーバー側画像処理へフォールバックする。
さらに端末のメモリが2GB以下、CPUコアが不足している、低速回線を利用している、といった場合にもWASM処理は利用されない。
つまりWordPressは、
使える環境ならブラウザで処理する。無理なら今まで通りサーバーで処理する。
という非常に現実的な実装を選んでいる。
ユーザーが設定画面でWASMを理解する必要もない。
対応環境では勝手に使われ、対応していなければ従来方式へ戻る。
この「存在を意識させない」という設計こそ、今回の変更で興味深いところでもある。
WASMは、こういう場所へ向かっていた
WebAssemblyが登場したころ、大きな期待が寄せられた。
JavaScriptを置き換える。
ブラウザ上でネイティブアプリ並みの巨大アプリケーションが動く。
Dockerコンテナに代わる実行環境になる。
そんな未来も語られた。
2026年現在、その予言がすべて実現したとは言い難い。
JavaScriptは今日も元気に動いているし、Dockerも倒れていない。
しかしWASMは消えたわけではない。
SQLiteをブラウザで動かす。
AIモデルをローカル実行する。
サーバーレス環境の軽量なサンドボックスとして利用する。
そして今度は、WordPressが画像処理エンジンをブラウザへ持ってくるためにWASMを使い始めた。
世界中のWebサイトを支えるWordPressで、ユーザーがその存在を意識することもなくWASMが動く。
派手ではない。
しかし、これはWebAssemblyという技術が「実用品」になったことを象徴する出来事なのかもしれない。
かつて期待されたように、WASMがJavaScriptを倒す日は来なかった。
その代わり、
「サーバーでやる必要のない重い仕事を、ブラウザへ持ってくる」
という、ずっと現実的な仕事を始めている。
WordPress 7.1の画像処理は、その分かりやすい実例だ。
WASMは世界をひっくり返す主役にはならなかった。
だが気がつけば、世界で最も使われているCMSの裏側で、黙々と画像を圧縮するところまで来ている。
案外、こういう技術の方が長生きするのかもしれない。
参照
