【WordPress】WebP形式の画像は'-pass 10 -m6'でエンコードするとかなり画質が上がる
2022年頭ごろから一部の個人サイトが挑戦している、WEB 画像の JPEG → WebP 形式への完全移行について徒然に書かせてもらいます。
ブラウザ側の対応状況が大幅改善したWebP形式
WebP とは、Google が開発した WEB 向けのオープンな画像フォーマット。
同画質の JPEG よりファイルサイズを軽量化できると謳われる WebP ですが、かつては非対応ブラウザが多く、特に <picture> タグ登場以前は環境ごとに JPEG と出し分ける手間などから、採用は一定以上の開発力があるサイトに留まっていました。
が、ここにきてブラウザ側の対応状況が大幅に改善。
かつては Internet Explorer や Apple の Safari がなかなか対応しないため全面採用は難しかったのですが、2020年秋に iOS 版 Safari 14 / Mac 版 Safari（Big Sur 以降）が相次ぎ対応。
さらに2022年6月には Internet Explorer のサポートが切れたことで、現役主要ブラウザが概ね WebP 対応となったこと、また、実利用ベースでもすでに95～97%以上が WebP 対応ブラウザからのアクセスとみられることから、一部個人サイトでは思い切って画像配信を WebP 形式のみに完全移行したところも出てきている状況です。
その一方、かつて WebP を採用していた大手サイトが、いつの間にか（少なくとも WEB 版では）JPEG 形式に切り戻していたりするなど、情勢は流動的。
すでに、WebP 形式以上の軽量化が期待される次世代フォーマット「AVIF」のブラウザサポートが広がりつつある中で、趨勢として WebP は微妙な立ち位置に置かれつつあるようにも見えます。
とはいえ、WordPress 5.8 以降で WebP が正式サポートされたことや、現役主要ブラウザのほぼ全てが WebP 対応していることから、WebP 形式への切り替えのハードルは大幅に低下。
WordPress のプラグインやレスポンシブイメージの自動生成機能の助けを借りることでサーバー側の対応もかなり楽になっていることから、小規模サイト運営者視点では「現実的な選択肢」として WebP 形式の魅力がアップしている状況のようです。
WebPの画質は悪い？
で、その WebP 形式ですが、実はかなり昔に Mozilla から「JPEG と大差ない」との調査結果を食らったことがあります。
日本語版 Wikipedia の「WebP」に関するページでも、上の記事を念頭に、
非可逆圧縮では、2013年10月に行われたMozillaの比較調査で、同一品質におけるファイルサイズが旧来のJPEGと大して変わらないという結果となった[10]。
https://ja.wikipedia.org/wiki/WebP
などと良からぬ記述がなされている始末。
この調査結果自体はかなり昔のものなので、それについて今、どうこう言うつもりもありませんが、2022年現在の僕の使用感として、「WebP の非可逆圧縮性能はエンコード時の設定次第でかなり改善する」という話を、面倒なので特に証跡も揃えずに書かせてもらいます。
WebPは '-pass 10 -m6' で圧縮すると高画質に
どのフォーマットでもエンコード時の設定で画質が変わるのは当たり前ですが、特に WebP では大幅に画質を改善できる設定として、
「cwebp の '-pass 10 -m6' オプションを試してほしい」
という話を伝えたくてですね。
初期値と比べてモスキートノイズが大幅に改善するので、WebP の画質が悪いと感じている方には、ぜひこれを試してみて欲しい、というのがこの記事の趣旨になります。
なお、WebP エンコーダー「cwebp」の '-pass' の初期値は6、'-m' の初期値は4です。
MSE/PSNR や SSIM を使った厳密な画質評価は他紙に譲りますが、このオプションを指定した場合、（少なくとも人間の視覚基準での）画質とファイルサイズの両面で、（僕の印象としては）JPEG を使う意味が分からないくらいの改善がみられるように感じます。
一方で、'-pass' と '-m' を増やすとエンコード時間も大幅に伸びてしまい、これがかなり頭の痛い問題となるシーンも想定されます。
というのは、画素数やサーバーの処理能力にもよるものの、標準的な WEB 画像を先のオプション付きで cwebp で圧縮した場合、1枚あたり1～数秒を要するため、多くのレスポンシブイメージを自動生成する最近のサーバーサイドとの親和性が悪く、そのあたりも WebP の導入が進まない理由の1つとなっているような気がして気がして。JPEG は兎にも角にも速いんですよねぇ。
WebP形式への完全切り替えはアリか？
とはいえ、サーバー側での生成負荷が気にならない規模・構成・ワークフローなら、画質・ファイルサイズ・対応ブラウザの多さの3つがすでに並び立っている次世代画像フォーマット、というのは貴重な存在ですので、完全切り替えするなら WebP かな、とは思える状況なのも事実。
ただ、サイトのマスター画像の形式まで WebP に切り替えるか、と聞かれればそこまではしない、というのもまた事実です。
というのは、WEB サイトにとって「画像形式の永続性」は極めて重要であり、JPEG の社会的安定性の優秀さが尋常ではないからです。
また、大量の画像を扱う現代では、画質を多少諦めてでもエンコード負荷・デコード負荷を重視するケースが少なくないことや、モバイルネットワークの通信品質（速度・遅延）が大幅に向上したこと、そして WebP 発表時には存在しなかった「mozjpeg」の存在など、WebP が発表された2010年当時とは時代背景が大きく変わりました。
そのほかにも、エンコード負荷・デコード負荷・ファイルサイズ・速さ・画質・インラインイメージと画像形式の出し分けなどの総合的なバランスから、結果、大手ほど JPEG を使った実用解が採用されているケースが少なくないようにも感じます。
今回は、別件の道すがらで WebP を少し触ってみただけのため深掘り検証はしていませんが、興味のある方は諸所勘案の上、WebP 周りを調査してみると面白いかもしれません。
それにしても、<picture> タグで画像を出し分けしなくても、WebP 形式1本でほとんどのユーザーをカバーできる時代になった、というのは隔世の感があります。
エンコード負荷を気にせず、画像形式の出し分けをするなら、WebP より AVIF が選ばれそうなのでアレなんですけどね。
2022年7月現在、WebP は AVIF より一歩先に「上がり」に到達しつつある技術といえます。
現在の HTML では <picture> タグで画像を出し分けできるため、画像形式の変更の重大性は昔ほどではなくなりました。
ひょっとすると、今年・来年あたりは個人サイトの画像形式が大きく動き出す頃合いなのかもしれません。
関連情報：
