そろそろWeb画像はWebPだけでよいか

そろそろWeb画像はWebPのみの配信でよいのではないか？

このテーマについて賛成論と反対論をしてみたい。

賛成論 ​

「Web画像はもうWebPオンリーでいいんじゃないか」 の背景には、普及率、機能性の高さ、使い勝手のよさがある。

対応ブラウザシェア 96.4% ​

caniuseによると、 WebP対応ブラウザのシェアは世界で95.69%、日本国内で96.4% とある(2024年9月)。

画像はWebPしか用意しなくてもほぼすべてのユーザーに支障はない。

実際に大手企業や政府系のサイトでも、ときどきWebPしか用意していない画像に気づくことがある。このような画像は旧ブラウザでは画像が表示されないのだが、案外そのままになっている。

3〜4%の非対応ユーザの存在をどう考えるかにもよるが、一部それは無視する動きもあるようだ。

万能フォーマット ​

従来は機能性で画像フォーマットを使い分けてきたが、 WebPはWeb画像の表現的な機能をすべて備えている。

• 可逆圧縮 PNG・WebP
• 軽量な非可逆圧縮 JPEG・WebP
• 透過 PNG・GIF・WebP
• アニメーション GIF・APNG・WebP

機能面で従来フォーマットをほぼ完全に置き換えることが可能だ。

普及率No.1の次世代画像フォーマット ​

次世代画像フォーマットの対抗馬はAVIFであるが、WebPよりシェアはわずかに劣る。世界で92.64%、日本国内で93.35%である(2024年9月)。

私もまだ調査が足りていないのだが、確かにAVIFはWebPよりデータは軽量になる。しかしエンコーディングにはWebPの数倍の時間がかかるという印象である。

オンデマンドでフォーマット変換したい場合、エンコードの遅さは看過できない。

ツールの充実ぶりにもWebPは一日の長がある。そのような理由から、弊社は今のところはAVIFよりWebPを推し、AVIF対応には消極的な姿勢をとっている。

反対論 ​

「WebPオンリーはまだ早いんじゃない？」の背景には、エコシステムへの懸念、WebPの画質性向、全振りに対するリスクがある。

アプリがWebPに対応しているか ​

Web画像は今やブラウザのためだけではなく、アプリが配信手段になることもある。

すでにWebPは、OSやSDKのレベルでも広く対応フォーマットのひとつになっているが、アプリの実装がそれにシームレスに対応できるかは不明である。

供給サイドは簡単に追いつかない ​

画像データの供給する制作者やシステムの都合もある。

デザイナーなど人間が画像を用意する場合は、作業者にWebPについての知識が必要となり、ツールもそれに対応している必要がある。切り替えるには相応の準備がいる。

また、プログラムがサムネイルなどのサイズのバリエーションを自動で書き出すケースも多い。そのような仕組みの改変には長時間を要する可能性もある。

WebPはあくまで配信用フォーマット ​

WebPは画質や汎用性を犠牲にしている面がある。そもそも 配信向けに軽量化することに特化 している。

• 非可逆圧縮におけるクロマサンプリングが4:2:0固定なので境界の色味がぼやける
• 縦横の解像度が16,384ピクセルまで

現在のWebP向けのJPEGも画質は近いし、Web画像に16,384ピクセルも必要というケースはほとんどない。

しかし 配信特化の画像フォーマットがデータ保存の役割も兼ねること には、違和感がなかろうか。

本当に技術負債にならないか ​

AVIFにも触れたが、次世代画像フォーマットの候補はWebPだけではない。

ここまできて将来的にブラウザのWebP対応廃止、という未来はないと思うが、どうなるかはわからない。

ある時期の画像データのオリジナルがWebPフォーマットでしか残っていないことが、技術負債になる可能性もある。

汎用性抜群のJPEGやPNGでオリジナルデータを残し、WebPはあくまで配信用の変換先に止める方がよいかもしれない。

まとめ ​

WebPは有力であるが、デファクトスタンダードとはまだ言えないのが実情だろう。

個人的には、LPなど小規模かつ一時性の強いサイトはもうWebPオンリーでもよいと思う。

そうでないサイトについては、当面はこれまで通りJPEGやPNGで画像を用意しながら、配信用に軽量なWebPに変換する方法が無難かもしれない。

弊社ではCloudFront向けの画像WebP変換サービスを提供している。

• LightFile Proxy - AWS CloudFrontでシームレスにWebP対応・通信コスト削減

CloudFrontは画像をWebPで配信すると料金が劇的に下がる可能性がある。