BLOG

  1. HOME
  2. ブログ
  3. WEB制作・デザイン
  4. コーディング(html/css/JavaScript)
  5. 次世代画像フォーマット「WebP(ウェッピー)」を実際に使ってみよう
by 漢ムラタ 漢ムラタ

次世代画像フォーマット「WebP(ウェッピー)」を実際に使ってみよう

次世代画像フォーマット「WebP(ウェッピー)」を実際に使ってみよう

今回は「jpg」や「png」「gif」などのいわゆる画像フォーマットの中でも次世代フォーマットと呼ばれている「WebP(ウェッピー)」についてのお話です。

ことの発端はGoogle Speed Insightの「改善できる項目」でたびたび目にする下記の『次世代フォーマットでの画像の配信』という記述です。

『「JPEG 2000」「JPEG XR」「WebP」などの次世代フォーマットを使えばPNGやJPEGより圧縮率が高くファイルサイズを抑えられるので、結果読み込み速度も上がるよ』というGoogle先生からのお達しです。

普段から画像に圧縮をかけてからアップをしていますが、次世代フォーマットにすることでそれより更にファイルサイズを落とせる可能性があるということですね。

フォーマットごとの対応ブラウザ状況

じゃあ実際に次世代フォーマットを試すとなると、提示されている「JPEG 2000」「JPEG XR」「WebP」の3つの中から一体どれを選べばいいのでしょうか。

使用できる絶対条件として主要ブラウザがそのフォーマットに対応していないと何の意味もないので、それぞれのブラウザごとの対応状況を「Can I use」で調べてみましょう。(2019年4月現在)

JPEG 2000

JPEG後継として規格化されたフォーマットでJPEGより画質と圧縮率が向上されているとのこと。アップル推し

しかし悲しいかな対応しているブラウザがsafariだけだったので、今後も日の目を見ることはなさそうです。

JPEG XR

XRは「eXtended Range」の略だそうです。Microsoft推し

Microsoftが推しているだけあってIEとEdgeはバッチリ対応しているものの、他のブラウザからは総スカン食らってる模様。

WebP

WebPの概要に関しては後で書くとして、対応ブラウザは以下の通り。

全てのブラウザとはいかなかったものの、「Edge」「Firefox」「Chrome」などの主要ブラウザは対応していて、「Safari」や「iOS Safari」は残念ながら対応していないものの、Androidでは古いバージョンじゃない限り問題なく使うことができます。

そもそもWebPってなに

詳しくはWikiってもらえればと思いますが、Googleが開発した新しい静止画フォーマットで、Google推しということになります。

つまり「JPEG 2000」はアップルが、「JPEG XR」はMicrosoftが、「WebP」はGoogleがそれぞれ次世代フォーマットとして推しているような感じでしょうか。

ちなみにWebPは2010年には提供が始まってたらしく「次世代」というわりにはだいぶお年を召している印象ですね。

WEBにおいて大半が占めているJPEGやPNGの代わりになるべくして作られた規格で、もちろんgifやpngのように透過処理も扱えます。

端的に言えばjpgやpngよりファイルサイズ軽いけど画質はそんな変わらんし透過もいけるぜみたいな感じです。

画質とファイルサイズ比較

早速WebPを使って、実際に画質やファイルサイズがどれくらい異なるのか調べてみましょう。

今回は

  1. 圧縮処理をかけていないオリジナルのJPEG画像
  2. 圧縮処理をかけたJPEG画像
  3. WebP画像

この3つの条件で行なってみます。
ちなみに使用する画像ファイルは「2352 × 1568px」のそれなりの大きさのものになります。

画像の圧縮

画像の圧縮ですが、今回はGoogleが提供しているWEBサービス「Squoosh」を使って圧縮します。

出力形式は「Browser JPEG」で、Qualityは「0.75」の設定で圧縮をかけます。

WebP書き出し

WebPでの書き出しはPhotoshopでは標準対応していません。プラグインを入れれば書き出すこともできますが、今回は前述の「Squoosh」でもWebPで書き出せるとのことなのでそちらを使います。

出力形式を「WebP」にして、Effortが何の設定か分からないですが「4」、Qualityは「75」としました。

画質の比較

上記で書き出した画像を横に並べてJPEGで書き出したものが以下になります。

このサイズ感だと違いは全く分からないですね。
もうちょっと拡大してみましょう。

どうでしょう・・・ぱっと見はほとんど違いが無いように見えますが、WebPは歯の辺りがちょっとボヤってるような感じがしないでもないですね。
まあそもそもここまで拡大して表示することはないでしょうし自分的には許容範囲といえるレベルではないでしょうか。

ファイルサイズの比較

ファイルサイズは以下の通りです。

  • オリジナルJPEG…3,980KB
  • 圧縮JPEG…368KB
  • WebP…251KB

オリジナルのファイルサイズが馬鹿みたいにデカいですが、圧縮をかけることで91%減の「368KB」まで落とすことができ、WebPだと更にその上をいく94%減の「251KB」まで落とすことができました。推奨するだけはありましたね。

こうしてみると圧縮もかけずに使用することがいかにページを重くするかがはっきり分かりますね。

使用できないブラウザに対する切り分け

WebPの圧縮率が優れていることが分かったので次は実際にwebで使用していきたいのですが、冒頭で説明した通りWebPは全てのブラウザが対応しているわけではありません。

なので普通に

なんて記述した場合、対応しているブラウザは問題ないですが、SafariやIEで閲覧した場合何も表示されないという事態になります。

picture要素での対応

切り分け手段としてまずpicture要素での方法があります。

こうすることでWebPに対応しているブラウザはneko.webpが、非対応ブラウザはneko_compress.jpgが読み込まれます。

でも、画像のたびに毎回picture要素を記述するのは結構面倒じゃないですか?ソースコードも長くなってしまうし。

htaccessによる自動振り分け

いちいち毎回pictureなんか書いてられるかって人はこちら。
htaccessでjpgとpng画像ファイルに対して同名のWebPファイルが同じ階層にある場合、WebPをサポートしているブラウザはそちらを自動で読み込むという処理を行ないます。

記述に関しては調べれば色々の方が例を提示してくれているんですが、自分はWordpressプラグインの「EWWW Image Optimizer」がWebP設定時に吐き出すコードをそのまま流用しました。

サーバーによっては記述の調整が必要かもしれないですが、自分は今のところどのサーバーでも問題なく動いてくれています。

この記述によって例えば

  • /assets/img/neko.jpg
  • /assets/img/neko.jpg.webp

というように「同じ階層」で「同じ名前(元の拡張子含む」のWebPファイルを設置しておけば画像が切り替わってくれます。

※Edgeの場合

書いている時に気付いたのですが上記の場合、EdgeがWebPに対応しているにも関わらずJPEGを表示します。
というのも下記のページを見ると分かるのですが、Firefox、ChromeなどはAcceptリクエストヘッダーで「image/webp」を返してくれますが、Edgeは返してくれないようです。
なので最初の条件「RewriteCond %{HTTP_ACCEPT} image/webp」の時点で除外されてしまい、それ以降処理されず普通にJPEGが返されてしまうようですね。

自分程度の知識では解決策が見つからなかったので今回はEdgeに関しては諦めることにします。

本当に読み込まれているかの確認

自動で振り分けたといっても、ぱっと見はJPEGでもWebPでもほぼ一緒なので本当に切り替わっているのか分からないですよね。

その場合は、chromeやFirefoxの開発者ツールで「ネットワーク」から確認すれば分かります。

「Network」タブを開いて、画像関連だけ知りたいので「Img」を選択してフィルターをかけます。
すると下部に画像関連のリクエストが並ぶので、その中で該当の画像の「Type」が「webp」になっていることを確認します。

webpになっていなければうまく動いていないということになります。

GulpでWebPを書き出し

サイトを構築している際に都度WebP画像を前述の「Squoosh」を使って書き出すのも面倒くさいので、Gulpを使って画像を書き出した際に自動で同じ階層にWebPを生成するようにします。

gulp-webp

今回使用するプラグインは「gulp-webp」です。

このプラグインを使うことで簡単にwebp画像を書き出してくれて、仮に元の画像が「image.jpg」だとすると、書き出されるファイルは「image.webp」となります。

ただ、前述のhtaccessによる自動振り分けをする場合これだと困ったことになります。元の拡張子を含んだ同一の名前のWebPで置き換えるようになっているからです。

試行錯誤した結果、色々端折ってはいますが以下のようになりました。
通常の画像圧縮タスクとは別のタスクとして処理しています。

タスクも分けないでもっとスマートに出来そうな気もしますが、今はこれが精一杯ということで。

最後に

現状切り分けの処理の面倒臭さや画像ファイルが2倍になってしまい煩雑になってしまう可能性もあるWebPですが、それでもこの圧縮率の高さは魅力的です。

ただ如何せんiOSでは使うことが出来ないというのは最大のネックですね・・・。
制作側としては全てのブラウザが足並み揃えてくれると非常に助かるんですけどね。

ページの先頭に戻る