WordPressで写真をアップロードしたとき、裏側では何が起きているか。サーバー上のPHPが元画像を読み込み、縮小版を何種類か書き出し、必要なら形式を変換している。撮ったままの大きな写真を何十枚もまとめて投げ込むと、この処理が重くて途中で止まる。更新担当が自分で写真を載せている中小企業のサイトでは、よくある詰まりどころだ。

今月中旬に公開が予定されているWordPressの次の版では、この画像処理の担当がサーバーからブラウザに移る。開発チームの解説によると、圧縮、リサイズ、形式変換、回転、サムネイル生成までを、操作している人の手元のブラウザで済ませる仕組みだという。

画像処理のエンジンがブラウザの中で動く

使われているのはwasm-vipsと呼ばれるもので、画像処理ライブラリのlibvipsをWebAssemblyに変換し、ブラウザ上で動かせるようにしたものだ。処理はWeb Workerに逃がしてあるため、変換の最中でも編集画面の操作が固まりにくい。

副次的な効果として、書き出される画像そのものも変わる。libvipsが生成するJPEGは、これまで使われてきたGDやImagickによるものよりおよそ15パーセント小さくなるとされている。サーバーに入っている画像ライブラリの違いで書き出し結果が微妙に変わっていたのが、どの環境でも同じ出力に揃う点も見逃せない。共用サーバーを使う案件が多いほど、この均一さはありがたい。サーバーごとの環境差を吸収するために、書き出し品質の設定を案件別に調整していた人には、手間が一つ減る話でもある。

iPhoneの写真やアニメーションGIFの扱いも変わる

分かりやすいのはHEICへの対応だろう。iPhoneの標準的な写真形式だが、これまではサーバー側の対応状況次第でアップロードできないことがあった。新しい仕組みではブラウザ内でデコードしてJPEGに変換し、元のファイルは別途保持される。

AVIFは10ビットや12ビットといった高階調の元データまで通り、UltraHDRのJPEGはゲインマップを保ったまま各サイズが書き出される。透過のないアニメーションGIFはMP4やWebMの動画に変換され、エディタ側では自動再生とループが効く動画ブロックの派生として挿入される。見た目は元のGIFのままで、ファイルだけが軽くなる形だ。

条件を満たさない環境では今までどおりになる

気になるのは、対応していない環境で何が起きるかという点だが、ここは素直な作りになっている。条件を満たさない場合は従来どおりサーバー側で処理され、切り替えは自動で、画面上の見え方も変わらず、エラーも出ない。判定には端末のメモリ量やCPUのコア数、通信速度、CSPでblobが許可されているかどうかが使われる。

ブラウザ側の条件はやや厳しめだ。SharedArrayBufferを使う都合でDocument-Isolation-Policyに対応したChromium系のブラウザが必要で、FirefoxとSafariは当面サーバー側処理に回る。ただしHEICのデコードだけはSafariでも動く。サイト側で機能ごと止めたい場合はwp_client_side_media_processing_enabledフィルターをfalseにすればよく、big_image_size_thresholdやjpeg_qualityといった既存のフィルターもそのまま効くとされている。

制作の現場から見て効いてくるところ

実務でありがたいのは、PHPのメモリ上限に起因するアップロード失敗が減ることだ。画像処理はメモリを食う工程で、共用サーバーの上限に当たって管理画面が真っ白になる相談は今でも珍しくない。その負荷がブラウザ側に移るなら、サーバーの構成を触らずに回避できる場面が増える。手元のパソコンは近年それなりに性能が上がっているので、重い工程を任せる先としては悪くない。

アップロードの粘り強さも上がっている。サイズ違いの書き出しごとにリクエストが分かれ、失敗すれば間隔を空けて自動で再試行する。回線が切れれば一時停止し、つながれば再開する。進捗も画面に出て、読み上げソフトにも伝わる作りだ。出先からスマートフォンで写真を上げる担当者がいるサイトほど、この差は体感しやすいだろう。

正式な公開は今月中旬の予定になっている。普段どおりの写真の投げ方を検証環境でひととおり試し、いつも使っている画像形式が想定どおりに変換されるかを見ておくと、切り替わったあとに慌てずに済む。