サイトアイコン cocone engineering

WebP対応について

はじめに

はじめまして。ココネのサーバーエンジニアのJです。
皆さんは次世代画像フォーマット、WebPをサービスに取り入れたことがありますか?
WebP対応の際に、気をつけてほしいポイントについて話したいと思います。

WebP(ウェッピー)とは?

pngやjpgのような画像フォーマットの一種です。
Google社が2010年に開発したもので、次世代といっても、もう14年もたつ技術になります。
一般的には、既存フォーマットより画質をあまり落とさず、容量を25%〜35%程度減らすことができると言われています。
圧縮率については、画像の内容にもよりますが、私の経験だと70%減ってる時もたまにあったりとか…
なので、画像表示が多いサービスなら、積極的に取り入れたほうが良いかと思います。
画面表示までの時間が体感できる程短縮でき、その結果SEO対策としても有効な手段になります。

さっそく本題に入りたいと思います。

気をつけたいポイント1 対応ブラウザ(端末)に注意

WebP画像に対応していないブラウザ(バージョン)が存在します。


https://caniuse.com/webp
上記のサイトから各ブラウザのWebP対応状況が確認できます。(が非対応)
Can I use…によると96.59%のユーザーがWebP対応ブラウザを使用中、逆に言えば3.41%のユーザーが未対応のブラウザを使っているようです。

最新のパソコン、スマホの普及率が高い日本国内に限定すれば、対応ブラウザをお持ちでないお客様は減ると思いますが、それでも1~2%程度はいると想定した方が良いでしょう。

例えば、iPhoneだとiOS13.7は未対応ブラウザ(端末)になりますが、
2019年9月に発売された、iPhone11をiOSアップデートしてなければ、未対応端末になります。古いと言えば古いのですが、4年半前に発売された端末なのでまだまだ使っている人が周りにいてもおかしくないでしょう。

こういったお客様を捨てることができますか?2%という数字は無視できないと思います。

どう対策していくのか

基本的には「WebP表示ができるブラウザはそのままWebP画像を表示、できないブラウザはjpgなどの既存画像を表示する」で問題ないと思います。

やり方はいろいろあると思いますが、簡単に実践できる方法を1つ紹介します。
画像を表示している箇所は数箇所、数百箇所ありますが、真面目にそれぞれに分岐を入れる等の対応ではキリがありません。大元の部分に対応を入れて対応もテストも簡単にできるようにしたいものです。

まずは、WebPに対応しているブラウザかどうかをどうやって判定するのか?
幸いなことに、ブラウザ種類やバージョンで判定することはしなくて問題ありません。



対応ブラウザだと、リクエストヘッダーに「image/webp」という文字を乗せてくれるのがルールになっています。
なので、これで簡単に判定が可能です。

次は、WebPを返すかjpgを返すかの処理ですが、nginxなどのサーバーの設定で簡単にできます。
nginxではrewriteという機能があり、特定のURLに対して、指定コンテンツを返すように設定が可能です。これを使って以下のようなシナリオを想定します。

①基本的にリクエストはWebPにする(画像のURLを.webpにする)
②リクエストが来たら、nginxでWebPのリクエストか、WebP未対応ブラウザかを判定し、jpgを返すようにrewriteする

すでにお気づきの方もいるかと思いますが、このシナリオには前提条件があります。
・サーバーにwebpとjpg画像は両方存在する
・画像のファイル名にルールがある

例えば、
jpg画像:test_image.jpg
WebP画像:test_image.jpg.webp
のように、WebP画像は既存画像の後ろに「.wepb」をつけるなどのルールです。

そしたら、nginxでのrewrite処理の際に、正規表現を取り入れて簡単に対応が可能になります。

redirectではなくrewriteなので、無駄なリダイレクトが発生しないのもメリットになります。


非対応ブラウザであるIE11でテストした時の通信ですが、WebPをリクエストしたにもかかわらず、サーバーでうまく処理ができていてjpgで返してくれた時のレスポンスです。実際に画像表示も問題ありませんでした!

二つの画像保持について

画像をwebpとjpg両方のフォーマットで管理することは、少々面倒ではあります。
画像を何かのツールでexportしているのであれば、追加でWebP画像もexportする必要が出てきます。

画像はサムネイルが必要だったりで、画面によって表示時の大きさが異なることも多いのではないでしょうか?その場合は、原本画像をinputし、複数の大きさ違いの画像がoutputされるシステムがすでに構築されていることもよくあるパターンかと思います。
もし、そのようなシステムがすでにあるのであれば、追加でWebPの画像もoutputするように改修を行うと、管理の手間も増えずに自動化できると思います。

気をつけたいポイント2 画像変換時のメタデータ

私の場合、ImageMagickというライブラリで原本画像から、サイズ違いの画像とWebP画像を変換していました。ただ、安易に対応すると画像の色味が変わってしまう問題がありました。

それが、原本画像と変換後の画像を交互に切り替えながら比較してみないと、わからないレベルの違いであるため、気づくことも難しい問題になります。

メタデータの中にはICCプロファイルという情報がありますが、ICCプロファイルは画像のRGB情報と絡みがありますので、変わったりなくなったりすると、色味も変わってきます。なので、ICCプロファイルだけは引き継ぐ必要があります。
※画像生成方法によってはICCプロファイルは存在しないこともあります。

ImageMagickですと画像変換する際に、適切なオプションを与えないと基本的にはメタデータは引き継がれません。

最後に

本記事では、画像について話していますが、私自身も画像データそのものに対する知識はあんまり高くなく、経験ベースで述べさせていただきました。

皆様のお役に立つ記事になっていたら嬉しく思います。

ココネエンジニアリングでは一緒に働く仲間を募集中です。

ご興味のある方は、ぜひこちらのエンジニア採用サイトをご覧ください。

→ココネエンジニアリング株式会社エンジニアの求人一覧

 

 

モバイルバージョンを終了