画像フォーマットの基本：PNGとJPEGの違い
今回は、画像の配信について話をしていけたらなと思うんですけど、
配信といっても、単純にユーザーやクライアントがアップロードした画像をそのまま配信したり、
その画像を動的に変換して配信するとか、いろいろありすぎるかなと思うんですけど、この辺り。
どこから話していきましょうかね。
そうですね。特に最近っていろいろありすぎるので、まずは基本的なところから少しずつ話していければなと思ってます。
そうですね。
まずその基本的なところってどこになりますかね。
まず本当に基本的なところで、PingとJPEGの話をまずしたいなと思います。
まず、PingとJPEGが一番よく使われている画像フォーマットかなと思うんですけど、
まず大きく違いがあって、Pingが可逆圧縮と呼ばれていて、JPEGが非可逆圧縮と呼ばれているものになります。
可逆圧縮は元に戻せるもの。
つまり容量は小さくなってるんだけど、元の画像、オリジナルの画像っていうのは残ってるんだよね。これがPingですと。
JPEGの非可逆圧縮っていうのは、もう画像自体が劣化してしまっている。
その代わりすごく圧縮できる。Pingとかよりすごく圧縮できるっていうのがJPEGの非可逆圧縮の特徴なんですね。
結構写真が一番よく使われているのかなと思うんですけど、画像だと。
写真だとPingとJPEGって容量が全然違くなっちゃうので、特に写真を使う場合はJPEGを基本として考えて欲しいなと思ってます。
なるほど。なんとなく僕の個人的な理解なんですけど、Pingの場合は10日を扱えるので、
10日を使いたかったらPing、その他だったらJPEGみたいな雑な理解をしてるんですけど。
それもね、昔は確かにそうだったんですけど、実はこの後話すんですけど、
WebpyとかVIFとか他の画像フォーマットも出てきてて、それらのフォーマットって全部透明も扱えるんですよ。
そうなんですね。
なので、あと実際のサービスだと、透明で白とかでなんとかなったりもするので、
透明かどうかも大事ではあるんだけど、やっぱりPingかJPEGって全然容量変わってきちゃうので、
基本的にはJPEG。
例えばロゴ画像とか、そんなに容量が食わなくて、ある程度キレイに出したい、サービス上でキレイに出したいみたいなやつはPing。
それ以外は全部JPEGっていう風に考えて欲しいかなと思ってます。
じゃあすごい雑な理解だと、UGCみたいな形で、ユーザーがアップロードする画像については、
基本的にどんだけデカい画像が来るかわからないから、とりあえずJPEGにしとくみたいな考え方もあるっちゃある?
そうですね。もちろんサービスにもよるんですけど、やっぱりユーザーが上げてくる画像ってすごくデカかったりもするので、
Pingにしちゃうともう本当にすごいデカくなっちゃう可能性があるので、
基本的には特に理由がなければ全部JPEGにするっていう風にして欲しいですかね。
なるほど。理解できました。PingとJPEGの関係性に関しては。
現代のWebにおける画像サイズの重要性
そうですね。で、大事なところがまだあって、
結構例えばImageMagickとかそういうのでJPEGとかPingとかって画像変換できたりするんですけど、
この時にクオリティっていうのを指定するんですよ。
オプションとかで指定するやつですよね。
そうですね。で、クオリティをすごい気にする人ってたまにいるんですけど、
クオリティじゃなくてまず画像サイズを現代のインターネットでは気にして欲しいんですよね。画像の綺麗さという観点では。
何でかっていうと、今のiPhoneとかが最初なんですけど、レジナディスプレーっていうので、
今って、そもそも歴史の話をした方がいいですね。
昔って1ピクセルはディスプレイの1画素だったんですよ。
なんだけど、今レジナディスプレイとかで人間の目で視認できないぐらい滑らかな画像をディスプレイ上で出したいっていうので、
今って1ピクセルで2画素とか3画素とか、そういうすごく細かいところまで1ピクセルよりも小さい画素数で表示にしてたりするんですよ。
なるほど。密度が違うんですね。
昔と全然密度が違うので、画像サイズが、ピクセル数が大きい画像じゃないと綺麗に表示できないんですよ。
そもそも潰れちゃうってことですか?
潰れちゃうっていうか、なんか粗くなっちゃうんですよね、画像が。
難しいですね。密度が高いから小さくてもいいかなと思いつつもサイズが足りないから変な感じになっちゃうんですね。
サイズが小さくしちゃうとシンプルに大きさが小さくなっちゃうんですよね。
なので、ちゃんとしたというか、一般的なサイズ感で出したければ実際のサイズよりも大きな画像を用意しないと綺麗に表示できないんですよ、今のウェブって。
なるほど。
なので、まず画像の大きさが一番大事です。画像の大きさが足りない画像はパッと見ですぐ分かっちゃいます。
さっき言ってた、冒頭で言ってたクオリティより画像サイズの方が重要って言ってた画像サイズの方は容量の方のサイズではなくてデカさの方のサイズですね。
大きさのサイズですね。
大きさのサイズですね。そこの理解が若干ミスマッチしてました。
たぶん今後ね、どっちっていうの結構出てきそうなんでそのために確認してもらった方がいいかもしれないですね。
クオリティっていうオプション、イメージマジックとかにあるクオリティのオプションはちょっと現代だと足りてないというか前提が違ってきてるってことなんですね。
この辺もちょっとね、またこの後いろいろフォローしていくんですけど、まずクオリティをすごく高くするというよりはまず画像のサイズ、大きさが足りてるのかどうかっていうのをまず最初に確認してほしくて、
クオリティは確かに下げるとその分下がるんですけど、よく見たらなんかクオリティ低そうだなっていうのはわかるぐらいなんですよ、クオリティって。
けど画像の大きさに関してはもうパッと見でこれ絶対足りてないじゃんっていうのはわかっちゃうんですよね。
なるほど。
なのでまず綺麗な画像を出したいんだったらクオリティよりもまず大きさを気にしてほしいっていうのが今のインターネットです。
その画像の大きさのサイズを適正なサイズを選ぶようにするっていう。
そうですね。
っていうのをまず大事にしてほしい。
サイズを選ぶの結構難しそうだなと思うんですけど、
そのディスプレイの密度とかによってこのぐらいのサイズが良さそうみたいなものがあるんですかね、適正サイズ的に。
基本的には2倍から3倍ぐらいがいいと思います。
必要なサイズの2倍から3倍。
ただこれもスマートフォンのディスプレイのサイズでどんどん大きくなってるので、
新しいiPhoneだと足りないとかもあり得るので、ある程度余裕を持ったサイズにしておいた方が安全ですね。
市場に出回ってるというかユーザーが使ってる端末に寄り切りなんですね。
そうですね。なのでその端末によってサイズ計算してちゃんと大きさ足りてるのかみたいなのを考えるべき。
めちゃくちゃ面倒くさいですね。
この後もいろいろ大変な話でいろいろ出てくると思うんですけど、
一番大前提としてクオリティよりまず画像の大きさが一番大事っていうのを今回一番覚えておいてほしいなと思ってるところですね。
分かりやすく劣化してしまうからですね。
そうですね。一番分かりやすく劣化するので。
正直この後画像フォーマットとかいろんな話すると思うんですけど、
正直画像フォーマット云々よりも画像の大きさが一番大事なんで、
ここが足りなかったらこの後の話何やっても無駄っていうところなんですよ。
適正なサイズ大きさで出力しろっていう話かなと思うんですけど、
逆に大きすぎたら問題とかあるんですか?
その辺もねこの後ちょっとずつ話すんですけど、
画像、要はファイルサイズが大きいと遅くなっちゃうじゃないですか。
ネットワークの通信的に。
最初にPingじゃなくてJPEG使ってくださいって言ったのもそこで、
Pingだと結構簡単にファイルサイズが大きくなっちゃうので、
適切な画像を配信するのが難しいんですよね、Pingだと。
なので最初JPEG使ってくださいって言ったのは、
やっぱりある程度ファイルサイズを軽くしつつちゃんと大きい画像を、
サイズが大きい画像を配信して欲しいから基本的にはJPEGで考えてください
って話をしたんですよね。
なるほど。要領が許す限り大きい方がいいということですね、それつまり。
まあでも基本的には2、3倍より大きくてもあんまり意味はないので、
限度はあるって感じですね。
上限の限度はあれどっていう。
そうですね。
理解しました。じゃあ一番重要なのはその画像の大きさっていうところが一番重要だよねっていうところ。
画像配信の歴史と現代の戦略
そうですね。
っていうところで次のところとしてはどういうところなんですかね。
まあこれちょっとね本当にどっから話すかなって感じなんですけど、
まず歴史的に昔の話をちょっとしていこうかなと思うんですけど、
昔ってインターネットも貧弱だったし、あとパソコンの、当時スマートフォンとかもなくて、
パソコンのディスプレイもさっき言った通り1ピクセル1画像とかで、
結構荒かったですよねディスプレイが。
あとパソコンの処理速度っていうのもあんまり速くなかったですね当時は。
なので当時のウェブサービスだとよく使われていたのは、画像をユーザーにアップロードしてもらいますと。
でアップロードされた時にイメージマジックとかを使って、
サムネイル画像っていうのを何種類かそのタイミングでアップロード時に生成する。
でその生成その時に生成したサムネイル画像を配信する。
っていうのがよく使われていたんですね。
アップロードした時点で生成してしまう方式。
そうですねそれを何種類か生成しちゃう。
決まったフォーマットを、例えば何か5個とかそういうサムネイル用のものを決まったサイズで先に生成してしまうという方法が今言ってもらったやつ。
そうですね。例えば大きいサムネイルとかちっちゃい中ぐらいのサムネイルとか、あと正方形のサムネイルとかサービスによると思うんですけど、
そういうのをアップロードされた時に全部作っちゃう。
わかりやすいですよね。
これわかりやすいし、あとやっぱりアップロードされた時って多少ユーザー待たせても許されるというか、それは時間かかるよねっていうのはある程度納得できるじゃないですか。
なんとなくその画像をアップロードしている時って編集中だったりするんでね。
何かを待つみたいないうのはユーザーにとって普通な状態でもありますもんね。
そうですね。
当時ってやっぱりそんなにマシーンのスペックが高くなかったので、画像の変換もそこそこ時間がかかる処理だったんですよ。
なのでそういう作り方をするのが一番効率が良かったんですね。
これが昔の話ですと。
じゃあ今はどうかっていうと、今ってやっぱりもうスマートフォン全盛で、スマートフォンって端末ごとに必要な画像のサイズも違うし、
あともうやっぱりiPhoneみたいにすごいデカい、デカくてしかもレティナディスプレイですごいサイズデカいの配信しないといけませんとか、
あと最近ってパソコンもレティナディスプレイみたいなの大体とかも使ってるんで、やっぱりパソコンもそれなりに大きいサイズ出さないといけないし、
本当にいろんなデバイスあるから、デバイスによって必要な画像サイズも違うし、あととにかく大きい画像を配信しないと綺麗に見えないんですよ。
クライアント側の表示する側のハードウェアが進化しすぎていて、
大きいサイズで表示しないとぼやけて見えてしまう。
適正な表示がなされないっていうようなことですよね。
そうですね。なので今だとどうするのがいいかっていうと、まずその画像アップロードされた時に大きく2通りあるかなと思っていて、
画像アップロードされた時にオリジナル画像を保存して、そのオリジナル画像から直接動的に画像変換して最適な画像を配信してしまうっていう方法と、
あとアップロードされた時に1個だけサムネイル画像生成用の別の画像を作ってあげて、それこそイメージマジックとかで作ってあげて、
そのサムネイル生成用の画像から動的に変換してあげる。
だいたいこの2通りかなと思ってるんですけど、それが多分一番効率がいいかなと思ってます。現代のインターネットサービスにおいては。
なるほど。今わからなかったのが前者と後者。前者の方は多分常に動的に違う画像を生成するみたいなことだと思うんですけど、
後者の方、1回サムネイルを変換するための中間ファイルみたいなものを生成するっていうことなんですかね。
というかサムネイル画像を作るんですけど、さっき最初に言ったサムネイル画像って結構ちっちゃいサムネイル画像を作る想定だったんですけど、
そもそも昔のサムネイル画像の作成。
そうですね。昔の方法は。今のやつはすごくでかいサムネイル画像を1個だけ作るっていうやり方で、
なんでこんなことをやるかっていうと、今って例えばそのスマートフォンの写真とかってめちゃくちゃでかいんですよ。
写真アプリとかで撮る。
そうですね。あれってすごい最近のスマートフォンのカメラって進化しすぎてて、もうめちゃくちゃでかいし、あとExif情報っていうのも大抵入ってるんですよ。
設定によってはどこで撮ったのかとか、何のスマートフォンで撮ったのかとか、ちょっと人によっては個人情報に近いような情報もExifに入ってたりするんですね。
そうですね。
なのでそのExifを消しておいた方がサービスで扱いやすかったりするんですよ。
必要ない情報は削ぎ落としておきたいですよね。
そうなんですよね。
できるように。
なので、あまりにもでかすぎる画像とか、あとExif情報を消したいとか、そういうのがあると、一回大きいんだけどサムネイル画像生成用に一回変換してちょっとちっちゃくしておいた方が扱いやすいことがあるんですよね。
なるほど。一旦情報を削ぎ落としたテンポラリーなものを作っておいて、そこから全部を変換していくっていうようなアプローチを取った方が効率がいいっていう話ですね。
そうですね。例えばS3みたいなストレージサービスに画像を保存してあげて、画像変換サービスに対してS3から画像を取ってきて変換するとするじゃないですか。
はい。
その時に毎回毎回オリジナル画像をダウンロードさせると、S3の転送量がすごい高くなる可能性があるんですよ。
うん、確かに。
けど、一回変換しておいてある程度ちっちゃくしておくっていう風にやると転送量を抑えられるので、そういった意味でも一回すごい大きいオリジナル画像が上げられるサービスだったら、一回サムネイル画像を挟んでおいた方がいいかなとは思いますね。
確かに。今聞いててそう思いますね。
一旦変換しておいた方が単純にシステムとして受け入れ可能なフォーマットにその時点でなっているので扱いやすいっていう点でかなり良さそうだなと思いますね。
逆にさっき言っていた前者のグループ全て動的にやるっていうパターンもあり得るわけじゃないですか。
そっちの場合だと、さっき言ったすげーでかいやつを毎回変換することになってしまうのですごく大変なのかなと思うんですけど、それもあり得るんですね。
それもあり得ると思っていて、というのも、やっぱりここも大前提として考えないといけなくて、最近のスマートフォンのカメラって良すぎるんですよ。性能が高すぎる。
なので、そもそもオリジナル画像いらないサービスもあると思うんですよね。
適当にユーザーが写真撮ってアップロードするだけだったら、そもそもオリジナル画像じゃなくて、ある程度変換済みの画像だけ配信できればいいっていう可能性もあるんですよ。
で、例えばそのウェブブラウザーだったらキャンバスっていう機能があるじゃないですか。
例えば画像をキャンバスで描画させて、それを画像に出力するってことも結構簡単にできるんですよ。ブラウザー上で。
ジャバスクリプトのAPIで。
そうです。
なので、例えばウェブでも一回キャンバスで描画して、もうちょっと圧縮。その時点でアップロードする前にもう圧縮しちゃう。クライアント側で。
で、それをサーバー側にアップロードするっていうアプローチも最近全然あるんですよね。
なるほど。
そのパターンの場合はクライアントを信頼するってことですよね。
そうですね。
完全にクライアント側で圧縮されているよねっていう大前提のもと、アップロードを受け入れてそれを全てで使うっていうような形なんですね。
クライアント側の実装とかをちゃんと制御していかないといけないっていう制約はありそうではありますけど、確かにあり得る。
そうですね。例えばウェブだったらキャンバスだし、AndroidとかiOSアプリもあると思うんですけど、
それぞれで圧縮してアップロードするっていう実装、それぞれで必要にはなってしまうんですけど、
ただそれさえできればサーバー側は結構簡単に保存するだけで良くなるし、
あとやっぱり最近のユーザーってWi-Fiとか繋がってないケースもあるんですよ、全然。
なるほど。アップロードに耐えれないってことですね。
そうですね。モバイル回線でアップロードしているユーザーも多いので、
そうなるとクライアントで圧縮してないと、そもそもアップロードが最後まで終わらないっていうケースもあり得るんですよね。
確かにそうですね。
なのでこの辺は本当にサービスによって状況が全然違うというか、
やっぱり2Cでスマートフォンアプリが中心ですよみたいなサービスだと、基本的にクライアントで圧縮して、
携帯電話の回線でアップロードされる前提で考えないといけないと思うので、
そういうサービスだったら最初からクライアント側で圧縮済みのものしか上げられないという前提で作っちゃうっていうのは全然ありだと思うんですよ。
この辺って本当サービスによって状況が全然違うので、
そのサービスによって適切な、例えばオリジナル画像がアップロードされる、すごい大きい画像がアップロードされるサービスだったら、
1回サムネイル画像、生成用のサムネイル画像っていうのを1回生成して挟んでおいた方がいいだろうし、
もうスマートフォンとかクライアント側でも圧縮済みのやつ上げられますよっていうんであれば、
多分そのままオリジナル画像をそのまま配信しちゃうでいいと思うし、
この辺本当にサービスによると思いますね。
サービス、プロダクトごとの特性によって、あとはユーザー層だったりとか使われる端末クライアントの種類みたいなところを加味して、
戦略考えないといけないところですね、ここちょっと技術的な。
ここは技術で解決しないといけないところなので、具体的にどうするか考えて実装する必要があるし、
あと重要なのって画像がきれいになることってないんですよ。
WebPの特性と注意点
1回圧縮しちゃったらそれよりきれいな画像って絶対出せないので、
このサムネイル画像を1回挟んだりとか、あとクライアント側で圧縮する場合は、
もう1回アップロードしちゃったりとか1回変換しちゃった画像っていうのはそれより良くなることって絶対ないので、
やっぱり十分大きい画像である必要があるし、クオリティーも下げすぎないっていう重要な必要がある。
難しいですね、ここ。未来のデバイスがどうなってるのかが分からないからこそ、
できる限りデカいやつを上げておきたいけど、現実今のネットワークの帯域とかの現実問題があるから、
どこまで抑えようかっていう話がここではされるんですね。
そうですね、その辺もちゃんと考えて、将来的なことも考えた上で十分大きい、
かつクオリティー下げない画像をちゃんと上げてほしいってところですね。
めちゃくちゃ難しいけど、めっちゃ面白いところですね、ここに関しては。
やっぱその、結構僕経験でこの画像周りいろいろやってきたんですけど、
やっぱきれいな画像を配信できると、例えば広告だったらクリック率って明らかに上がるんですよ。
ガビガビだったらちょっと嫌ですもんね。
ガビガビだったら全然クリックされない。結構ね、ダイレクトに出ますね、この辺って。
おー、なるほど。
なのでやっぱりきれいな画像、ただきれいだったらいいってわけでもなくて、
やっぱり最近ってスマートフォンで使ってるユーザーが多いから、やっぱ遅いとそれはそれでまた使われないんですよ。
ムカつきますね、表示されなかったら。
そう、だから軽いけどきれいな画像を表示するっていうのはやっぱウェブサービスにおいて今非常に重要なんですよね。
めちゃくちゃ重要ですね。
そう、ビジネスに直結するので、やっぱりここはちゃんと考えるべきところだと思ってます。
絶対考えないといけないし、しかもあれですね、日本だったらまだいいかもしれないけど、全世界で考えたらめちゃくちゃ難しいですよね、ここ。
そうですね、やっぱり世界、海外のことも考えると本当にいろいろ、これでいいんだっけっていう、きれいだったらいいだけじゃなくて、ちゃんと圧縮もしないといけないし、
この辺はJPEGじゃないWEBPとかWIFとかそういうのを使いましょうって話になってくるので、その辺はまた後で話すんですけど、そういう話になってくるかなと思ってます。
理解できました。ちょっとここからWEBPの話なんですかね、ここからは。
そうですね、まずさっき話した通り、基本的にはJPEGを使いましょうって話なんですけど、
ただJPEGってすごい古い画像フォーマットなので、今だと新しいフォーマットがいくつか出てるので、まず一番有名かな、Googleが作ったWEBPの紹介をちょっとしていきたいなと思ってます。
先に僕のWEBPの理解をちょっと話しておくんですけど、すごい雑にインターネットで綺麗な画像を配信した、しかも軽く配信したかったらWEBP使っとけみたいな、そんな理解をしてます、今。
結構そういう風に宣伝されたんですけど、WEBPはね、結構気をつけて使わないといけないことがいろいろあるので、その辺を理解してないと意外と効果ないよっていうことが結構あるので、ちょっとその辺も話していければなと思ってます。
じゃあまずですね、WEBP、実はWEBPって何種類かあって、まずロッシーとロスレスってやつがあって、ロッシーが不可逆圧縮の方で、ロスレスが可逆圧縮の方なので、実はWEBPっていわゆるJPEGとPING両方とも対応してるんですよ。
なるほど。WEBPの中に複数フォーマットがある。
WEBPの中に2つあって、ロッシーとロスレスがあって、
JPEGの代わりに使われるケースが多いんだけど、実はPINGの代わりでも使うことができます。
だから透過とか、あとアニメーションとかもサポートしてるよって。
それとは関係ないんですけど、
そうなんですね。
透過も、JPEGだと透明できないんですけど、透過も対応WEBPはしているし、あとアニメテッドWEBPってアニメーションも一応使うことができますと。
GIF的な感じですかね。
そうですね、アニメGIFを置き換えるような形ですね。
なんですけど、ロッシーとロスレス2つあるって言ったんですけど、基本的にはロッシーのほうばっかり使われてると思うので、ロスレスも少し使われてるんですけど、
基本的にWEBPって言ったらロッシーのほうを指すケースがほとんどなので、今回もロッシーのほう。
要はJPEGと同じ、不改革圧縮のほうのWEBPだと思ってもらえたらいいかなと思います。
写真をJPEGにするよりWEBPにした方がファイルの容量が小さくなることが多いので、
画像配信では非常に有効とされているんですけど、WEBPにすれば必ず小さくきれいになるわけではないので、
そこを結構知らない人多いので、ちゃんと理解してほしいなと思っています。
そうなんですね、雑に変換しておけば小さくなると思ってたんですけど。
これがWEBPの強みって何かっていうと、WEBPって高品質でかつ十分大きい画像をギュッと小さくする。
さっき言った通りiPhoneのレティナディスプレイみたいな高解像度のデバイスで、
もともときれいな画像をギュッとして出すっていうのが一番得意なフォーマットなんですよ、WEBPって。
容量を少なくできるんだけども、画像の大きさを大きくできるよってことですね。
もともと大きい画像をファイル容量小さいままきれいに見せるのが得意なんですよね、WEBPって。
なるほど。
なので、もともとクオリティがすでに低いJPEG画像をWEBPに変換しても、むしろ思ったより大きくなることもあるんですよ。
なるほど。すでに劣化しているものをWEBPにしたとしても意味ないよってことですね。
そうです。
なるほど。
なので、オリジナル画像が高品質であるっていう大前提がWEBPにはあります。
なるほど。さっきの話で言うと、クライアント側で変換してしまったものをS3だったりとかに保管しているっていうサービスがあったとして、
そのS3に保管されているサービス側から見たら、クライアントからアップロードされたオリジナル画像をWEBPに変換したとしても、
もしかしたらサイズとしては、容量としては大きくなってしまうかもしれないってことですよね。
基本的にはクオリティを下げてなければ大丈夫だと思うんですけど、
例えば、基本的にユーザーがアップロードしている画像だったら、
基本最近だったらカメラで撮ったりとかしていると思うので、
基本的には大丈夫なケースが多いと思うんですけど、
例えば外部の、例えばメディアからクロールしてきた画像とかってクオリティ待ち待ちだったりするじゃないですか。
なるほど。他のサイトがもう既に配信しているような画像。
そうですね。
そういう画像を、既に配信されている劣化済みの画像をさらにWEBPに変換したりとかすると、
意外と容量下がらないっていうのは全然ある。
なるほど。理解しました。そのパターンですね。
そうですね。なので、そこを結構気を付けて欲しいし、
あとクオリティも結構気を付けて欲しくて、WEBPはJPEGよりもクオリティ低くして使うことが推奨されていて、
例えばJPEGでクオリティ85で配信していますってなったら、
WEBPは85よりもっと全然低い70とか60とか、それはサービスによって全然あると思うんですけど、
JPEGよりもクオリティ低めにして配信すると効果が大きいですね。
WEBPは全体的に、この後も話すんですけど、全体的にちょっとぼやっとするんですよ。
最終的な成果物が。
そうですね。WEBPにするとぼやっとするんですけど、
けどそのレティナディスプレイでもともと大きい画像をちっちゃく見せてるから、ぼやっとさせてもなんかよくわかんないですよね。ちっちゃくなってるから。
なるほど。
なのでWEBPはそういう使い方をするのにすごく強いんですよ。
なのでそのクオリティをJPEGよりちょっと低めにしても、なんかぼやっとしてるけど、
まあわかりにくい。よく見ないと。よく見ないとってか拡大したらわかる。
拡大したらクオリティ低いなってわかるんだけど、拡大しないとよくわかんない。
っていうのがWEBPなんですよね。
その代わりすごく容量が縮みやすい。
そうですね。なのでそのきれい写真、基本的にきれいなオリジナル画像の写真を持っているサービスがきれいな容量が、
ファイルのサイズが小さくかつきれいで大きな画像を配信したいっていうケースだとWEBPはもうドハマリするんですよね。
一番いいユースケースですね。
それが一番いいユースケースです。
逆に写真以外の場合はどうなんですか?例えばロゴのファイルだったりとかイラストとかもそうなのかもなとは思うんですけど、
そういうのはあんまハマらないんですかね、逆に。
そう、それがね、特に一番微妙なのは、例えばテキスト、文字が書いてあるとか、あとドット絵みたいなのは結構最悪だと自分は思っていて。
なるほど。境目がはっきりしている写真、画像ってことですかね。
そう、写真だといいんですけど、なんかそのディザリングって呼ばれてるんですけど、WEBPって全体的にぼやっとするのが特徴なんですよ。
なんかちょっとなんかなんていうんですかね、フィルターかましてるみたいな。
そういうイメージ近いかもしれないですね。なのでテキストが書いてある文字が書いてあるとかドット絵みたいなはっきり境界がはっきりしてるやつだとなんかぼやっとしちゃって、
文字が読みにくいなとかドット絵とか、結構クオリティー下げちゃうと結構めちゃくちゃな画像になったりとかするんですよ、WEBPだと。
なるほど、パキッとしてるやつにあんま合わないんですね。
そうですね、なのでWEBPはハマるとこにはドハマりするんだけど、そういう明らかに合わないっていう画像もあるので、結構WEBPって曲折用なんですよね。
じゃあそういうのを扱うようなサービスプロダクトだったらWEBPあんま使わない方がいいパターンもあり得るってことなんですね。
あり得ると思いますね。一応この辺もWEBPの特徴なんですけど、WEBPってもともとGoogleが作ったんですよ。
はい。
なのでGoogleがWEBPのソースコードって公開してて、LibWEBPって呼ばれてるんですけど、実はもちろん例外はあるんですけど、ブラウザーもあとImageMagickとかも全部、
基本的に有名なソフトウェア、WEBP対応してる有名なソフトウェアって基本的に全部Googleが作ったLibWEBPで実装されてるんですね。
これもWEBPの大事な特徴の一つなんですけど、基本的に実装がLibWEBPしかないっていうのが実装の一つで、なのでWEBP、これはWEBPの仕様なのかLibWEBPの仕様なのか正直自分もよくわかってないんだけど、
WEBPの中にプリセットっていうのがあって、実は例えばドローイングとかアイコンとかテキストっていうのが実はプリセット選べるようになっていて、
設定を選べるんですね。
設定実は選べるようになっていて、例えばテキストとかアイコンってそのさっきから言ってるディザリングってやつが無効になったりするんですよ。
そのプリセットでアイコンとかテキストとか指定すると一部のモードがオフになってちょっとはっきりするみたいな。
ディザリングとかあと他にもいくつかあるんですけど、一番大きなディザリングだと思いますね。
この辺の設定がオフになるので、こういった画像を使いたい場合はそのプリセットを変えてくださいっていうのが多分WEBPの想定した使い方なんだと思うんですよ。
なんですけど、これって多分そもそもほとんどの人が知らない仕様なんですよね。
そもそも画像変換サービスでJPEGとかPINGをWEBPにするっていうことって結構できるサービスあるんですけど、
多分プリセットを指定できるサービスが果たしてあるのかっていう問題がそもそもあって。
多分見たことないと思います。
自分もちょっと見たことなくて、このプリセットを指定できるサービスがもしあれば指定すればいいんですけど、
ただ現実問題として、例えばそのユーザーが上げてきたファイルが.aかどうかってぶっちゃけわかんなくないですか。
サービスで.aしかアップロードしないよねっていうぐらいだったらわかるけども、
そういう世界観がなくて、別にいろんなものを普通にユーザーがUGCとしてアップロードできるよねみたいな感じだったら判定しようがない。
サービスにももちろんよるんですけど、やっぱり判定って基本難しいと思うので、
そういうサービスだとそもそもWebPで綺麗に画像ごとにプリセットを選ぶっていうのは多分そもそも難しいし、
ユーザーに選ばせるとしても多分ユーザーがそもそも選べないと思うし、そもそも正しく選んでくれる保証もない。
なので現実的には結構難しいと思ってます。
そうですね。ユーザーの難易度が高いですし、技術的な制約がすごいUIにまで漏れ出してるのであんまりよろしくない。
あんまりいいUIとは僕も思わないし、なのでWebPは写真以外で使うのは正直微妙と思っておいた方が良い。
要はデフォルトのプリセットがその写真に最適化されているものだから、基本的にそこから変えられないと思っておいた方が良いですね。
そういう制約があるよというのを念頭に置いておいた方がわかりやすくあるよね。
そうですね。なので基本的な写真以外は使わない方が良い。
オリジナル画像が綺麗な画像がある、基本的に綺麗な写真って思っておいた方が良いかな。
綺麗な写真を持っていればそれをWebPに変換するとすごいハマるけど、それ以外の用途だと正直あんまりハマらないって覚えておいた方が良いと思いますね。
なるほど。WebPにちょっと落とし穴的なところがあったり。
AVIFの登場とWebPとの比較
そうですね。実はまだちょっと、最近はあんまり気にしなくていいと思うんですけど、WebP一応少し落とし穴がもう少しあるので、一応それも話しておくと、
まず昔のSafari、iOSのSafariとかは対応してなかったです。もう対応して何年も経っているので、今は気にしなくていいと思うんですけど、すごい古いやつだと対応していなかったりします。
あとこっちの方が結構致命的なんですけど、古いAndroid、Android4KだとWebPに対応してるってAndroid自体言ってるんだけど、実際には対応してなくて、WebP返すと画像がぶっ壊れるみたいなのが昔あったんですよ。
この辺が結構厄介だったので、アクセプトヘッダーって言って、この後また話すかもしれないんですけど、そのクライアントがどの画像フォーマットに対応してるかを判定する方法があって、
ブラウザーはアクセプトヘッダーっていうのを介して、どういうフォーマットを今アクセプトしてるのかっていうのを教えてくれるんですよ。
で、アクセプトヘッダーの中にWebPアクセプトできますよって入ってたらそれはWebP返せるんですね。
なのでそのアクセプトヘッダーを見てWebP返せるからWebPって返すって実装って世の中一般的によくやられてる実装なんですけど、Android4Kに関してはそれやっちゃうと壊れるんですよ。
そこがね結構罠。
まあまあでもAndroid4Kだったらもう大丈夫かなっていう気はしますけどね。
もう使われてないだろうっていうのと、あと大きいのがTLSで、もともとTLSって1.0、1.1、1.2、1.3って今あって、
今は1.2以上使わないでくださいと、1.0と1.1はもう使わないでくださいってなってるんですよ。
で、今言ってるフルAndroidってTLS1.2に対応してないので、TLS1.2以上しか対応してなかったらそもそもリクエスト送れないです。
そもそも通信ができないってことですよね、エラーになるってことですよね。
なので昔はユーザーエージェント見て頑張って切り分けしたりとかしてたんですけど、今はもうやらなくていいと思います。
そこの辺の別要因で一個完成が切られたから考えなくてよくなってきた。
そうですね。結構古い記事とか見ると、多分この辺IOSで使えませんよとか古いAndroidだと壊れるんでユーザーエージェント見てくださいとか、
古い記事見ると出てくると思うんですけど、この辺りは今はもう気にしなくていいかなと思ってます。
ただ昔そういうのがあったっていうのは知っておいてもいいかなと思ってます。
歴史としてこういう若干微妙な時もあったよねっていうところ。
そうですね。
じゃあなんか今話聞いてる限りWebP使っときゃ最強みたいな話でもないなって気がしたんですけど、どうしたらいいんですかね、現代。
もう一個ね、Abifっていうのも最近、Abifって読むのかちょっとわかんないんだけど、今回ちょっとAbifって仮に読むんですけど、
最近はAbifも使えるようになってきたので、今だとAbifの方が使いやすいかなと思っていたりします。
Abifっていうのはちょっと僕は知らなかったというか、多分初めて見た気がするんですけど、どういうものなんですかね。
元々動画のフォーマットから発生してきたって聞いてるんですけど、WebPよりも扱いやすい新しい画像フォーマット、JPEGよりも圧縮しやすくて、今だったら基本的に全部のブラウザ、モダンブラウザ全部対応しているので、
最近だったらWebPよりもAbifを使っておいた方が多分楽なんですよね。さっき言ったWebPだとディザリングがちょっと強いよねとかっていうのも、
Abifだともうちょっと大人しい。ある程度どこの画像を使っても大体綺麗になるし、容量も大体縮む。
ただ正直WebPよりちょっと縮みにくいと思います。もちろん画像によって違いはあるんですけど、Abifの方が新しいから常に新しい方が良いって思ってたら、それはちょっと違う。
多分同じクオリティだったらWebPの方が小さくなりやすいと思います。
だから圧縮の加減っていうものが存在していて、どうバランスするかっていう話ですよね、そのフォーマットごとに。どこを際立たせて、どこを落としてみたいなことですよね、きっと。
WebPの方が得意な部分もあるし、Abifの方が得意な部分もあるしっていう。
自分の認識だとAbifは結構オールマイティに使える代わりにWebPほどを攻めたことはしてこないので、WebPほどがっつりは縮まないっていう感じですかね、僕の認識だと。
ただ現実的に使う分には全然Abifでいいよねみたいなところまで来てるっていう。
ただAbif一個気をつけないといけないのはエンコードが重くなりやすいっていうのがあって、例えば画像変換サービスを自前で抱えてますっていう会社だとAbif使うと変換サーバーのCPU使用率とかが上がってしまうので、それがしんどい可能性はあります。
サーバーが複数並列で必要になってきたりとか。
リソース追加しないといけないとかはあり得る。Abifに関しては結構エンコードが重いって言われてるので、画像変換サービスってCDNサービスだったりとかあと画像変換の専用のサービスSaaSっていくつか出てるので、
そういうサービス使ってるだけだったらエンコードのコストが高いとかってあんまり気にしないと思うので、そういうサービス使ってるんだったらAbifガンガン使ってもいいと思うんですけど、
画像変換サービスを自前で抱えてますみたいな会社だと何も考えずにAbif使うとちょっと負荷で死んじゃう可能性はあるかなっていうところですね。
なるほど。WebPみたいな形で考えてるとサーバーの負荷が上がりがちっていう。
上がるかもしれないですね。
なるほど。
その辺を考える必要はある。
だとしても、しかも外部の画像設定機械サービスみたいなのを使った方がコスト的にもいいよねみたいな。
コストはどうかな。そこはちゃんと計算した方がいいと思うんですけど、コストとかじゃないんですよね。また後で紹介すると思うんですけど、そういったSaaSを使った方がいいと自分は思ってるんですけど、
正直コストが安いからじゃなくて、もっと他の理由だと思いますね。そういったSaaSを使いたいのは。
なるほど。ちょっとそれは後に置いておくとして、今だったらAbif使っておけばドット絵だろうと写真だろうといい感じになるという。
ドット絵はさすがにやってみないとどうかってなるんですけど、デザイニングみたいなのも完全にゼロってわけじゃないので、そこはちょっと苦手かもしれないんですけど、Webpyほどひどいことにならないはずです、Abifの方が。
そこもサービスによりけりってことですね。
そうですね。実際に試してみてほしいですけど、ただWebpyは結構苦節用なので、そこまで苦節用ではないので、基本的にはAbifの方が今だったら難易度低めというか、結構あっさり入るんじゃないかなと思ってます。
ちなみにさっきあったWebpyの方であった古いブラウザ対応問題、Abifでないんですかね。
自分が把握してる限りはないですね。
ほう、なんかすんなり行きますね、Abifは。
そうですね。FirefoxもSafariもどのブラウザも表示できますね。古いやつはもちろん無理だけど、ただ古いやつはもう今ほとんどないと思うので。
じゃあその面でも全然問題ないってことですね、互換性に。
今だったらそうですね。
じゃあAbif使っておけばいい、とりあえず。
そうですね。今からやるんだったらWebpyを無視してAbif、JPEGとAbifとかにした方が自分はお勧めかなと思ってますね。
なるほど。じゃあちょっと次の話題としてはあれですかね、さっき言ってた画像変換サービスの話になっていくんですかね。
画像フォーマットの出し分け戦略：AcceptヘッダーとPicture要素
まずじゃあ具体的にこのAbifとかWebpy投入したいよってなった時にどう、Webアプリケーションがどうすんのって話を先にした方がいいかなと思います。
なるほど。
なのでその辺話すんですけど、さっきもちょっと話したAcceptHeaderっていうのがまず使えるですよね。
クライアント側がサポートしている画像フォーマットを返すやつですね。
そうですね。ただこれAcceptHeader常に使えばいいかっていうと、それもまたちょっと違くて、
例えばそのJSON APIとか、例えばフェッチでJSONのAPI取ってきてとかあるじゃないですか。
その時にJSON APIの時にAcceptHeaderの中にImageWebpyとか入ってないんですよ。
なるほど。
なんでかっていうと明らかに画像じゃないじゃないですか。
JSONだからってことですよね。
そう、JSON API設置してるだけだから。だからいちいちそういう時は返さないんですよね。
省略されてるっていうことですよね。
そう、省略されちゃうので。だからそのAcceptHeader、例えばそのJSON APIでAcceptHeader見て、
Webpy使えるならWebpyのURL返そうみたいなのは実装できない、そもそも。
それはブラウザ側がそういう仕様、クライアント側がそういう仕様になってるってこと?
そうですね。最初のリクエスト、最初HTML取得してくると思うんですけど、
そこのリクエストに関してはAcceptImageWebpyって入ってるので、最初のリクエストに関してはいけるんですけど、
その後のFetchとかに関しては入ってないので、例えば、昔やられた方法で言うと、
そのHTMLを取得してくるときにAcceptImageWebpyが入ってたら、例えばクッキーを付与するとか、
キャッシュをしておくみたいなことですね、データとして。
そうデータとして、なんでそんなこと昔やったかっていうと、さっきちょっと言った、
Android4Kだと動かないって問題が昔あったので、ユーザーエージェントで弾きたいんですよね。
なのでAcceptImageWebpyプラスユーザーエージェントでAndroid4Kじゃないか見て、
大丈夫だったらこの人Webpy使えますよみたいな情報をクッキーに保存しておく。
で、JSONのAPIとか他にもいろんなところでそのWebpy使えるかどうか見て、
WebpyのURLを返すみたいな実装は昔割と使われていたかなと思います。
そういう実装もあり得るんですけど、
これはこれでクッキー使うとその分リクエストの容量とか大きくなっちゃうし、
さっきも言った通り今Android4Kで使えないみたいなのって今あんまり気にしなくて良いので、
今から新規導入するってなったらあんまりやらなくていいかなと思ってます。
じゃあ実際どうやるんですかね。
で、アクセプトエッターは画像を取得してくるときは入ってるんですよ。
画像のURLだったら例えばimgタグでsrcとか書いてあったら、
そこのURLに対してリクエストを送るときはアクセプトヘッダーにイメージWebpyとか入ってるので、
例えばCDNが画像を配信してるんだったらそのCDN側でアクセプトイメージWebpyが入ったらWebpy返すとか、
アビフが入ってたらアビフ返すとか、
そのCDN側で同じURLなんだけどアクセプトヘッダーによって返す、画像フォーマット変えるってこと?
なるほど。
ちょっと動き分かりにくいかもしれないんですけど、
これができると画像のURL書き換えなくても、バックエンド側何も書き換えなくても、
勝手にCDN側で最適な画像を配信できるので、
一番簡単に導入できるのがこの方法ですね。
楽そうなんですけど、今頭の中で想像してたらちょっと気持ち悪いなと思った点が一個あって、
URLで画像を取得しに行くじゃないですか、クライアント側が、
そのときのURLの末尾に.abifとか.webpyとか入ってんじゃないかな、若干思うんですよ。
ただwebpyってURLとしてはリクエストしに行ったんだけど、
アクセプトヘッダーの方にabifって入ってるからabifを返すみたいな実装もあり得るわけですよね。
全然普通ですよ。
画像のURLってもちろんサービスによるんですけど、
結構オリジナル画像のフォーマットになってるケースって結構あると思ってるんで、
例えばJPEGで保存されてるならJPEG.JPEGって書いてあるけど、
実際にはwebpyとかabifでコンテナタイプ書いてきてるってケースは結構そういうサービス多いです、世の中に。
あるんですね。
全然あります。
なるほど。
単純にその事例を知らなくて気持ち悪いと思ってただけですね、僕が。
気持ち悪いとは思いますけど、
ただURL書き換える、バックエンド側でURL書き換えなくても全部いい感じにできるので楽ではあるんですよ。
なので結構使われてるってことですね。
わざわざ新しいフォーマット.webpyとか.abifとかにリダイレクトするわけにもいかないですもんね。
やっぱりリダイレクトしちゃうとブラウザで正しく表示できるのかって問題も出てきちゃうし、
やっぱりそのURLのままクライアントによって出し分けるっていうのが、
多分一番コストとしては低い、開発のコストとしては低いっていうところですね。
リダイレクトしてしまうとクライアントの実装次第では変な挙動になる。
変な挙動多分なる?
確かに。そのままバイナリー返しちゃった方がいいってことですね。
もちろんこれをやるにはCDN側でアクセプトヘッダーによってそもそも使うキャッシュ自体も分けないといけない。
その辺の設定とか気をつける必要はあるんですけど、
ただ画像変換サービスみたいなSaaSを使ってたら絶対こういう機能あるので、
そういうSaaSを使ってるんだったらそういう機能を有効にするだけで、
全部その辺キャッシュを分けるとかその辺も全部やってくれるので、
多分利用するだけだったらそんなに気にしなくても使える機能ではあります。
なるほど。ちなみにあともう一個ちょっと思ったのが、
そういう画像変換、CDN側が画像の変換的な、
さっきので言うとフォーマットを出し分けるみたいな機能あったりするわけじゃないですか。
WebPかAbifか、はたまたJPEGかっていう感じで出し分ける、
同じURLで出し分けるみたいなところなんですけど、
その中に割と見えるなと思うのが、
クエリパラメーターで変えるパターン、画像のサイズだったりとか、
あとはこれはもしかしたら昔かもしれないですけど、
タイプでメディアムとかそういう文字列で指定するタイプだったりとか、
そういうのってあんま今だと起きえないとか、あんまやらない方がいいんですかね。
いや、それにちょっと先行っちゃってるんですけど、
画像変換サービス、画像変換するSARSっていくつかあるんですけど、
大抵クエリパラメーターで画像のサイズとか指定したりとか、
あと画像フォーマットとか指定したら、そのサイズが返ってくるってサービスが多いんですよ。
なので、それは今でも全然使われているし、
メディアムとかそういうのは、画像変換サービスで、
例えばファストリーだったらVCLがすごく柔軟なので、
メディアムだったらこの画像サイズにしますみたいなのをVCLって設定ファイルで書けばそういうのは全然できるので、
サービスによってはそういうのも全然できるので、今でも全然使われているやり方ではあります。
じゃあそれでクライアント側で多少制御するっていうやり方も全然現代でもあると思うんですね。
現代でもあるんですけど、ちょっとその辺りやり方があるので後でまた説明したいと思います。
そこもちょっと罠があるんですよ。
なるほど、そのまだ前提があるんですね、そこまで行くまで。
その前提のところはどういうところ?
もう一個だけ、今アクセプトヘッダーで同じURLで別のフォーマット表示するって話したんですけど、
そうじゃなくて、そもそもクライアント側で画像のURLを例えば複数提示しておいて、
ブラウザー側で選ばせるっていう方法もあるんですよ。
ブラウザーが選ぶ?クライアント側が選ぶ?
クライアント側が選ぶ。
ブラウザーだったらそのピクチャータグとかSRCセットっていう属性があって、
この辺を使うとその画像、そのブラウザーが例えばWebP使えるんだったらここのURL、
でARVIS使えるんだったらこのURLとか、
あとこのディスプレイのサイズがこのディスプレイサイズだったらこのこれを使うとか、
そういうのいろいろ書けるんですよ実は。
なるほど、ブラウザーのウィンドウサイズがこれ以上だったらこれを使うみたいな。
そんな感じの設定かけて。
具体的には。
で、これ面白いのが一番後ろに普通のIMGタグ書くんですけど、
そうするとピクチャータグとか解釈できないブラウザーだったらそのIMGタグが出てくるので、
そのIMGタグにJPEGのURLを指定しておく。
そうすると解釈できない。
フォールバックとして書いておく。
なるほど。
そうするとそのピクチャータグ解釈できないとか、
あとAPとかUF使えないっていうブラウザーはその一番下のJPEGを表示してくれるので、
結構この書き方はちょっとバックエンド側の実装が少し大変にはなっちゃう。
バックエンドとかあとブラウザー、フロントエンド側。
ちょっと大変にはなっちゃうんだけど、
ディスプレイのサイズによっても変えられるので、
さっき一緒に言ったアクセプトエッターだとディスプレイサイズによって変更できないので、
ディスプレイのサイズによっても変更したいよっていうんであれば、
ピクチャータグとか使った方がいいので、
こっちの方が丁寧にいろいろできるので、
そっちを使うって手もあります。
なので基本的にはこの二択かなと思いますね今だったら。
アクセプトエッターって同じURLでフォーマット変えるか、
もしくはピクチャータグとか使って、
ブラウザー側にクライアント側で選ばせるか。
いやなんとなく今聞いて、
すごい面倒くさいことを思ったんですけど、
IMGタグがいい感じにしてくれればいいのにと思っちゃったんですけど、
そこはピクチャータグでやらないといけないんですね。
IMGタグは古いブラウザーとかでも使われてるので、
そういう拡張しちゃうと解釈できないんですよ。
なるほど。
だからそのピクチャータグのうまいところがそこで、
ピクチャータグ解釈できないんだったら、
その一番後ろのIMGタグが使われるので、
古いブラウザーで使っても安全なんですよね、
これの書き方って。
互換性を意識してピクチャータグに切り分けたんですね。
そうです。
HTMLって解釈できないタグがあっても無視するんですよ、
基本的にどのブラウザーも。
だからそういうのも古いブラウザーでも使える
記法を考えた結果こうなったんで、
結構僕はうまいなと思ってますね。
確かにエラーにならないってことですよね。
レンダリングでエラーにならないってことですね。
そうです。
タグを解釈できなかったとしても、
アンディファインドというか、
ヌルになるので問題なしってことなんですね。
ヌルっていうか、HTMLの仕様なんですよね。
仕様というか、全てのブラウザー、
基本的に壊れたHTMLでも、
解釈できるところだけ表示したりするので、
基本的にエラーにならないんですよ、HTMLって。
確かにタグ閉じてなくても勝手にタグ閉じるみたいな感じ。
そう、あるじゃないですか。
そういう風になっているので、
それをうまく利用したのがピクチャータグなんですよね。
頭いい。
ちょっと見慣れないなって思うと思うんですけど、
これは古いブラウザーでも表示できるって考えたら、
結構うまいなと自分は思ってたりします。
いいですね。
じゃあこれピクチャータグ、
使えるところだったら使っちゃった方がいいですね。
そうですね。
やっぱ丁寧に対応したいんだったら、
ピクチャータグ使うのを自分はお勧めしているし、
とりあえず楽に、
バックエンド側の実装をあんまり変えずに、
楽に入れたいって言われたら、
アクセプトエッタで切り替えるのをお勧めするし、
なので本当にここはどっち使ってもいいので、
うまく使い分けてほしいなと思っているところですね。
リリースの仕方とかに結構よりますもんね。
URL変えてしまうとめんどくさいことが、
404とか変な形になってしまうから、
URL変えたくないとか絶対運用上あり得るので。
ここの機能はURL変えるのめっちゃ大変だから嫌だとか、
あとここは結構フロントエンドでがっつり実装できるから、
丁寧にピクチャータグで丁寧に作りたいよとか、
いろいろあると思うんですよ。
なのでそこは本当に場所によって、
適切なものを選んでほしいなと思っています。
で、次ですね。
画像URL生成のベストプラクティス
さっきの話、さっきちょっと話した話なんですけど、
結構その画像変換のSARSとか使っちゃうと、
そのwithとかheightとか指定したら、
そのサイズが返ってきたりするんですよ。
クエリパラメーターとかで。
それもサービスによるんですけど、
大体クエリパラメーターで指定できます。
で、これでやっちゃう人がいるのが、
フロントエンドでピッタシの画像サイズを返しちゃう。
例えばフロントエンドで計算して、
この画像サイズ欲しいよとか、
バックエンドで伝えるとか、
もしくはフロントエンドでも計算しちゃう。
フロントエンドで計算して、
クエリパラメーターをフロントエンドで勝手に付けて送っちゃう。
っていうケース。
頑張りすぎちゃうってことですよね。
そう、本当にピッタシ。
画像変換SARS使えるから、
もうピッタシなのを毎回計算して出しちゃうってやつ。
これはね、自分は絶対やめてほしいなと思っているやり方になります。
その心。
将来、例えばその変換サービス、
その画像変換サービス移行したいとか、
あとパラメーター変えたいとか、
それこそ例えば今までWebPしか対応しなかったけど、
Abifにも対応したいとか、
なんかいろいろあるんですよ。
こういう仕様変更があるときに、
変更ができなくなる可能性があるんですね。
ガチガチに設定を詰めすぎてるからってことですね。
例えばそのWebのJavaScriptだと、
ちょっと想定しにくいかもしれないんですけど、
例えばiOSとかAndroidアプリだと
古いアプリ残り続けちゃうことあるじゃないですか。
そうですね。しかも古いiOSのバージョンだと
このバージョンまでしかアップデートできないとか
往々にありますもんね。
ありますよね。
なのでクライアント側の実装って
ずっと残っちゃうケースあるんですよ。
基本それを考慮した上で設計しないといけなさそうです。
そうですね。クライアントはそうなんです。
クライアントアプリってそうなんですよ。
なのでクライアントアプリ側で勝手に計算して
やったりとかすると、
何か変更したいってなったときに
変更できなくなる可能性があるんですね。
そうですね。
だからクライアント側でURLを計算してやっちゃうってやると
今日もサービス変更とか一切できなくなっちゃう。
っていうのが一番結構大きい理由です。
なのでフロントエンド側で計算して入れるっていうのは
やらないでほしくて、
基本的にバックエンド側で
バックエンド側が使っていいですよって言ってきたやつだけを
使うようにしてほしい。
設計上をクライアント側でやることはシンプルにすべき。
変更可能性を考慮するために
バックエンド側で自由度を高く設計したほうがいいよねっていう。
そうですね。要はフロントエンド側は
バックエンド側が返してきたURLをそのまま表示するだけ。
っていう構成にしておかないと
後々絶対問題になる。
問題になりそう。
ウェブのJavaScriptだったら大丈夫かっていうと
例えば中国で使われているブラウザーだったりとか
変な仕様で
中国国内とかのプロクシーで勝手にキャッシュして
それが配信されたりとかするケースがあって
そういうサービス、そういうブラウザー使われてると
あれこれ数年前の実装なんだけどまだ動いてるみたいなのって
全然あるんですよ。自分経験あるんですけど。
リクエストが来るんですね。古い仕様で。
古い仕様でリクエスト来るケースって全然あるんですね。世の中には。
自分めちゃくちゃ見たことあるので。
だからJavaScriptだったら変えられるとも思わないほうが良い。
やっぱりクライアントの実装っていうのはずっと残り続ける可能性がある。
なるほど。
で、あともう一個問題があって
CDNのキャッシュ効率なんですよね。
端末幅とかから自由に計算とかしちゃうと
微妙に違うURLが大量に生まれちゃうじゃないですか。
そうですね。絶対にキャッシュヒットしないですよね。
絶対にヒットしないってことはないんだけど
やっぱり携帯によって全部別の画像を変換しないといけないってなると
キャッシュヒット率も何もなくなっちゃうんですよね。
あとブラウザー、ブラウザーじゃない。
これも画像変換サービスにもよるんですけど
サービスによってはクエリパラメーターの順番が違うだけでも
別のURL扱いになって別のキャッシュ扱いになったりするケースがあるんですよ。
なんか普通に考えるとそっちの方が通常な仕様な気がしますよね。
URLのクエリパラメーター入れ替えたら
違うものになりそうな気がしますが。
これもサービスによりますね。
Nginxとかは別々になるかなと思うんですけど
例えばFastlyのVCLだったら正規化する
順番に並べるっていう関数があったりとかして
そういうのを使うと正規化できたりとかするんですけど
そういうわざわざ実装しないと基本的にはできないかなと思います。
なのでこの辺もCDNとかサービスによるんですけど
基本的にはクエリパラメーターの順番違ったら
別のURLとか別のキャッシュになるよって思っておいた方がいいと思います。
そこの効率がすごく悪いことになるから
その面でもやめておいた方がいいよね。
基本的に画像変換って重い処理なんて
そんな若すぎてやっちゃダメなんですよ。
なのでURLって極力固定して
キャッシュヒット率が高くなるような配信をしないといけない。
あと許可してない重い変換を止めにくい。
例えばすごい巨大な画像を勝手に配信するとか
すごい高いクオリティで勝手に配信するとか。
ちょっと違うかもしれないですけど
攻撃みたいなことが簡単にできちゃう。
なので基本的にやめた方が良い。
なのでこの辺はどこまでやるかなんですけど
やっぱりバックエンド側でどのサイズ使うかっていうのを完全に決めて
許可されたやつしか使わないようにする。
でバックエンド側が返してきたURLを
フロントエンドはそのまま受け取ったやつを
そのまま表示するだけにするっていうのが良くて
どの画像を使うかっていうのはブラウザーとかクライアント側に選ばせる。
さっき言ったピクチャータグとかを使って
ブラウザー側で最適なやつを選ばせるっていう風にやると
最適な画像を表示しやすくなります。
でさっきちょっと言ってたそのミディアムとかそういうのを指定するって話も
結構おすすめではあってやっぱりその
クエリパラメーターで何でもかけちゃうと自由度が高すぎるので
さっき言った攻撃みたいなのもできるはできるんですよね。
なのでミディアムだったらこの画像サイズにするとか
そういう固定しておいた方が攻撃とかしにくくなったりするので
それができるかどうかサービスによるんですけど
そういう方が扱いやすい可能性はあるので
この辺もその使ってるサービスとかによって
うまいことやるのがいいかなと思ってます。
なるほどある程度のルールを設けた方がいいってことですね。
やるとしても。
そうですねやっぱりミディアムだったらこのサイズで固定ですっていう風にして
でもそのクエリパラメーターで渡すより
クエリパラメーターでもミディアムって渡したら
勝手にその画像サイズになるとかの方が攻撃はしにくくなるだろうし
この辺も本当にサービスによって
どういう最適な管理方法っていうのを考えてほしいかなっていうところですね。
考えるべきこと多いけども
でも基本はそういった攻撃だったりとか
あとはキャッシュ効率だったりとかコスト面のところだったりを考えつつ
戦略決めた方が良さそうですね。
そうですね。それで言うとちょっとここで話しちゃうと
画像変換におけるトラブルシューティングと監視
結構罠になるのが
特に2C系のサービスってあるんですけど
1ピクセルかける何千ピクセルみたいな
もうすっごい変な画像
すっごい縦長な画像とかすっごい横長な画像みたいな
そんなことあるんですか?
そういう画像が投稿された時に
画像変換の仕方間違えてると
ものすごくデカい画像が生成されちゃったりとかするんですよ。
若干攻撃チックだけども
そういうのがユーザーに投稿されたってことですよね。
攻撃化って言うと難しいですね。
これ結構実装側のバグなので
クライアント側が普通にミスっててっていう可能性も
画像変換サービスに変な風に渡しちゃうと
ものすごいデカい画像が生成されちゃったりとかするんですよ。
こういう画像を投稿された時に。
横の部分だけ使ってみたいなことですよね。きっと。
とか使っちゃうと
それ実装によるんですけど
とかやっちゃうと
1ピクセルのところが1000倍に拡大されちゃうとか
全然あり得るんですよね。
そういうのになっちゃうと
とんでもなくデカい画像を配信されちゃって
転送料金とかそういうことになっちゃうんで
そういうことがないかどうかっていうのは
ちゃんと確認してほしいっていうのはありますね。
なので基本監視しましょうって話なんですけど
そこに関してはあれですよね。
だからクライアントを信頼せずに
バックエンドでちゃんとフィルタリングしましょうみたいな
バックエンドでフィルタリングも大事だし
あとCDNの転送料とかもちゃんと監視して
なんかすごいデカい画像が配信されてないかとか
そういうのは監視するべきですね。
そこは確かに起きえるし
なんかめんどくさそうなところではありますね。
普通の画像を扱う上でちょっとめんどくさそうではありますね。
アップロードするやつ。
そうですね。やっぱりこの辺ってすごい大事で
結構ね自分見るんですよ。
これ実装間違ってるなみたいなサービス。
例えばなんかそのブラウザーのサイズ変えたら
どんどんどんどん画像のサイズ変わって
どんどんどんどん画像生成されていくみたいな
そういうサービス自分見たことあるし
結構クライアント側で計算しちゃってたから
なんかバックエンド側で仕様変更したのに
ずっと古い仕様でリクエスト来続けちゃって
どうすんだこれみたいになってるとか
もうね散々見たことあるんですよそういうの。
なんかめちゃくちゃありそうですね。
そうめちゃくちゃ僕も見たことあるので
この辺はねやっぱちゃんと知ってないと絶対間違える
どっちでもいいでしょとかって思ってやっちゃうと
後でまずいことになるケースって結構あります。
雑に実装してしまう
実装とあと運用してしまうと後々変えられないし
時刻を見る上に多分ここら辺なんか
AIに任せて実装させると大変なことになりそうですね。
AIがどこまで分かってるか次第なんですけど
やっぱり知識ないとAIが出してきたやつ
そのまま信じちゃうとかあると思うんですけど
やっぱりこの辺知ってたら変な実装してきたら
気づくはずなんで
そんな実装したらこのケースで壊れちゃうでしょとか
ちゃんと気づいて言えばAI直してくれるから
ちゃんと自分で気づけるようにするっていうのは重要だと思ってますね。
ですよね。単純にもう鵜呑みにして
もうAIでやって最悪な結果になる前に
ちゃんと気づけないといけないので
その防波堤に人間がならないといけない知識の部分
かなりありそうだなと思いましたね。
ここに部分に関しては。
そうですね。なので本当にこの辺はね
ちゃんとみんな理解してほしいなって思ってる部分ですね。
でも画像扱うサービス多分
ほぼいろんなサービス多分あると思うので
そうですね。画像を使わないウェブサービスってほぼないと思うので
ほぼないですよね。現代においてテキストだけとかあんまないと思うので
そうなんでみんな知ってほしいなと思っていますと
全人類に聞いてほしいですね。この回は絶対に
まあちょっと大げさだけど。
じゃあそうなるとさっきちょっと話したSaaSを使うか
それとも自分たちでOSSとか使って自分たちで構築するかっていうところ
話が出てくると思うんですよ。
そうですね。変換するところですよね。
例えばそのJPEGファイルをWebPに変換したいってなったら
さっき言ったGoogleがWebPのコードを公開しているので
CWebPっていうプログラムなんですけど
CWebP使えば簡単に変換できるし
Abifも最近はいくつかライブラリーで出てたりとか
さっきも言った通りWebPは基本的にGoogleの実装しかないんだけど
AbifとかもちろんJPEGとかも複数実装があるので
どれを使うかっていうのがあるんですけど
基本的にエンコーダー出てるのでそういうのを使えば良い
例えばイメージマジックを使えばこの辺って変換できるんですよね
WebPとかAbifとかに
これもGoogleが作ってるんですけど
Webブラウザー上でスクッシュっていうサービスがあって
Webブラウザー上でいろんな画像フォーマット変換できる
っていうサービスもあって
スクッシュは結構おすすめなんですけど
これはWebアセンムリを使って
いろんな画像変換のプログラムをブラウザー上で動かしてくれるので
サーバーに送らないんですよ画像で変換できるので
その画像とりあえず手元で画像変換したいなって時はスクッシュおすすめだし
システムで使いたい点だったら
しゅうえっぴーとかイメージマジックとかそういうの使えばもちろんできるんですよね
でもじゃあこの辺使って画像変換サービス作れるのかっていうと
いくつか気をつけないといけないことがあって
まずイメージマジックについては脆弱性が定期的に出るんですよね
なのでここ気をつけないといけなくて
ただイメージマジックって本当にいろんな画像フォーマット対応してて
自分も詳しく知らないんだけど
例えばレントゲン写真でしか使われてない画像フォーマットとかもあるらしくて
そんなものに対応してるんですね
イメージマジックはそういうのも対応してるんですよ
すごい
けど別に我々使わないじゃないですか
使わないですね
そういう我々が普段使わない画像フォーマットに結構脆弱性見つかってたりするので
めんどくさい
だからポリシーっていうのが今あるので
イメージマジックで使う画像フォーマットって制限できるんですよ
なのでそのポリシーを使って
例えばJPEGとかPINGとかサービスで対応してる画像フォーマット以外
もう変換させないってやれば
大抵の脆弱性はあったとしても大抵のものは発動しないので
まずポリシーで防ぐ
あとイメージマジックやっぱり画像変換ってすごいリソース
マシンのリソース使うので
CPUとかメモリーとか一定以上使わないように
この辺もポリシーだったりとか
あとコマンドラインでも制約できると思うんですけど
そういう制限入れて
もうその暴走しないように
すごい変な画像とか上げられても
マシン丸ごと死なないようにする
っていうのが結構実サービスで投入する上で重要だったりします
あと他にも本当にいろいろあって
結構気をつけないといけないのが
ICCプロファイルっていうのがあって
色空間っていうんですけど
例えばディスプレイとか印刷とかによって
表現できる色って違いがあるんですよね
なのでICCプロファイルっていうのがあって
画像によって表現した色とかも違うので
ソフトによっても別のICCプロファイルで
いろんなのがいろんな画像出てきたりとかするんですけど
結構壊れてたりするんですよ
ICCプロファイル間違ってたりとかするんですよね
そういう画像だとうまく変換できない
変換しちゃうと変な色になったりとかするケースがある
すごい雑に言うと色のパレットが壊れてるってこと
そんな感じですね
なのでそもそも画像が壊れている
あと結構有名なのだとCMYKっていうのがあって
我々ディスプレイなので色の三原色って光の三原色で
RGBレッドグリーンブルーの3色なんですよディスプレイって
けど印刷だと絵の具の三原色になって
シアンマゼンダイエロー
プラスあと印刷だと黒があるので
キーカラーだったっけなCMYKって呼ばれてるんですけど
その印刷用途だと光の三原色じゃなくて絵の具の三原色になるので
そもそも色空間違ったりするんですよね
なんでこのCMYK画像が結構有名
結構ウェブ上で使うと結構色がくすんだりとかして変な色になることで結構有名なんですけど
こういった画像もあるんですよ
そういった画像を正しく変な色にならずに変換できるのかっていう問題がある
自前で運用した場合に
そもそもICICIプロファイル壊れている画像とかCMYKとか
そういうのを正しくできるのかって問題もあると
なんか特にここら辺はあれですかね
例えばUGCみたいな形でユーザーがアップロードする
しかもPhotoshopとか今だったら
いろんなイラストのソフトとかで書き出すときに
RGBで書き出すべきところをCMYK印刷用に
エクスポートしてしまうみたいなことをユーザーがしてしまうと
それに果たして対応できるのかっていうことですよね
それがユーザーが意図してやってたらいいんだけど
意図してないケースもあるだろうし
そもそもソフトウェアがバグってて
正しいICICIプロファイルが選択されてないってケースもあるし
本当にいろいろあるんですよ
世の中って画像を生成するソフトウェアってたくさんあるから
もう正しく実装されてる保証なんてないんですよね
クライアント側を生成物に関しては
信頼してはいけなさそうな気が若干しますよねそこに関しては
けどアップロードしたやつが変な色になってたりしたら
絶対クレームになるので
やっぱりこの辺は真面目に考えないといけないんですよね
なのでそういう壊れた画像に対してどう変換するのかとか
あとやっぱり画像変換って
やっぱり一個一個が結構重い処理になるんですよ
だけどさっき言ったキャッシュヒット率も高めやすいので
画像配信って
というかキャッシュヒット率高めてないとダメなんですよ
画像変換って
画像変換自体が重い処理だから
キャッシュヒット率を高くするように工夫しないといけないんで
そうなると逆にあんまりその画像変換って
同時に大量に来たら耐えられないケースって全然あるんですよ
それを想定してない
それをそもそも想定してないから
だからその辺のリソースの管理とかも難しいし
あとやっぱりその大量に
例えばさっき言った1ピクセルかける何千ピクセルみたいな画像を上げられた時に
メモリー食い尽くして死んじゃうとか
そういったトラブルが起こらないのかとか
そういういろいろ考えることたくさんあるんですよね
なので自前で抱えた方が安いよねっていう考えで
適当に立てちゃうとこの画像だと壊れるんだけどとか
突然障害になって全体死んじゃいましたとか
結構いろいろ起こるんですよ
気軽にできないですよね絶対
サービスの規模にもよりますけどね
サービスの規模が小っちゃいんだったら全然自前でやるのがいいと思うんですけど
サービスの規模がやっぱり大きくなってくると
自前で抱えるのだいぶ大変な仕組みにはなるし
あとクレームとか来た時にちゃんと対応できるのかっていうのもあるし
なのでそういうのを考慮に入れた上で
やっぱり画像変換のSaaSとか使うのって
やっぱこういう知見がちゃんとある会社が多いので
そこも含めてやっぱ自分たちでやった方がいいじゃんって
安易に考えると良くないというか
そこまでちゃんと考えて選択できるならいいんですけど
そこまで自分としてはそこまで考えた上で
自分たちにとって最適な方法
とにかくお金安くしたいし
自分たちにも対応できますっていうんだったら
自分たちでサービス立ててもいいと思うし
ちょっとそれはさすがに難しいし
安定運用させたいですねってなったら
SaaS使った方が多分安定運用する
安定的に稼働するだろうし
この辺は本当にサービスによって
最適なやり方が変わるかなと思ってます
なんか大体の場合において
CDNとセットで入ってるような機能な気がしてるんですよね
この画像生成周りだったりとか配信の部分は
CDNとセットで外部サービスとして提供されてる
みたいなことがありがちかなというか
それもサービスによって全然違うんですよね
画像変換しかやってないってサービスもあれば
CDNの一部それこそファストリとかクラウドフレアは
そういうサービスやってるので使えるし
でも別にCDN事業者でも画像変換の機能ないっていう
CDNも全然あるので
だしあと画像変換専業のサービスやってるって
会社もあるし本当に物によります
けど確かにやっぱ画像配信って
CDNとセットで考えないとどうしようもない
やっぱCDNのキャッシュヒット率とセットで考えないと
基本的には最適な配信はできないです
セットで考えた方がいいですよね絶対に
絶対に
ですよね
ちょっとそこを考えつつどういう戦略で
自社だったらやっていくのかみたいなところを考えないといけないというか
考えないといけない部分がめちゃくちゃ多そうだなという
部分であります
自前で持とうとすると結構考えることたくさんあるので
そこも考慮に入れた上でやらないといけないし
ただサーズ使ったら丸投げでいいのかっていうと
さっきもちょっと言った通り変な画像アップロードされた時に
すごいでかい画像を配信してしまうかもしれないから
サーズであった時も
例えばそのこの容量例えば何キロバイト以上の画像がどれぐらい配信
何回ぐらい配信されているのかとかそういうのは見ないといけないし
あとやっぱりそのでかい画像を配信してたらまずいので
なんか設定間違ってる可能性もあるのでそういうのもちゃんと見ないといけない
で自分がいつもよく言ってるのは
基本的には200キロバイト以下が好ましいです
で500キロバイト以上は論外ですと
なのでそれぐらいを目指しましょう
200キロバイトから500キロバイトぐらいまではグレーゾーンというか
っていうのを自分はよく言ってるので
500キロバイト以上のもの配信されてないのとかそういうのは見た方が良い
結構世の中的には300キロバイトぐらいが
だいたい敷地になってるケースが多いかなと思うんですけど
だいたいそれぐらいが許容範囲だと思って
調整すると良いかなと思ってます
じゃあ監視対象としてそこら辺の配信している
画像のサイズみたいなところは見ておくべき
見ておいてなんか容量大きいサイズ
容量大きい配信が増えてたらちょっとなんか設定おかしいんじゃないとか
っていうのは絶対見に行った方が良い
コストにダイレクトヒットするところだからですよね
そこに関しては
ちゃんと見ないといけないってことですね
そうですねそういうのちゃんと見て配信してほしいなと思ってます
画像配信戦略のまとめと運用
他のところとかはあったり
他のところあるかな
細かいところはあるかもしれないですが
結構話した感じですかね
結構話したんじゃないかな
結構いい時間になってきて
多分この回今までで一番長い回になってきてるなって感じなんですけど
じゃあここら辺で若干まとめつつって感じですかね
PingとかJPEGから始まって
なんとなくの理解僕の理解としては
WebP使っておきゃいいだろうっていう話かなと思ってたんですけど
Abifというような有力な広報がありつつ
ただしAbifをそのまんま使うっていうのも
そういう話でもなく
ちゃんと考えないといけないところがめちゃくちゃあるなというような感じですね
この画像を配信するのをマジでやるとしたらですよね
最近のWebサービスって基本画像使ってないところないから
基本的にはどのサービスもちゃんと考えないといけないし
AbifとかWebP使ってきゃいいんでしょみたいな感じだと良くない
やっぱりちゃんと画像のサイズからちゃんと考えないといけないし
ACLのキャッシュヒット率も大丈夫なのかっていう観点で
ちゃんとどういうふうにバックエンドとかフロントエンドを実装していくのか
っていうところもちゃんと考えないといけないし
本当に色々画像だけでも結構色々考えることはある
やっぱりあと画像変換サービスも自前で運用するとしたら
結構考えることたくさんあるから
本当にこれ自前でやるんですか
自前でやるんだったらちゃんと運用できるんですか
っていうところを考えてほしいっていうところはありますかね
だからもう本当そのサービスの特性
どうやってユーザーが使うかとかどういう環境で使うか
あとはどういうクライアント端末で使うか
みたいなところも含めてちゃんと最適なところを考えつつ
しかもこの問題が発生するのは1年後かもしれないっていうことですよね
今発生するわけではないですもんね
リリース直後は大丈夫なんだけど
なんか気づいたらあれこれやばくないってなってるケースは全然ある
ですよね
しかもその時になったら止めることもできない可能性があるってことですよね
ありますね
だから何でしょう考えすぎるに越したことはないけども
でも現実的に考えるべきところをちゃんと抑えつつ
最適なところを踏んでいきたいなっていうところですね
ちょっとまとめると
そうですね難しいかもしれないんですけど
ただ一個一個は基本というかやっぱりウェブサービス真面目にやるんだったら
覚えておかないといけないことなのでやっぱり一個一個抑えて
最適な画像を配信できるウェブサービスをみんなに作ってほしいなと
切に思っております
ありがとうございますなんかいい感じにまとめて笑いつつ
エピソードの締めくくりと今後の展望
本当にここら辺マジで
最近Viveコーディングとかで
雑に作ってリリースしてみたいなところだと絶対に踏むと思うので
ちゃんと考えないと思うので
この画像の配信をどうしようかみたいなことなんて
絶対に思わないと思うので
この辺はこの回聞いてもらって
こういうこと考えないといけないんだみたいな気づきが
ちょっとでもあったら嬉しいですよね
そうですねやっぱりそう思ってもらえたら嬉しいですね
ありがとうございます結構いい話だったなと
言いつつ今回はここまでにしたいなと思います
ヤロウヨーズのOSSでは毎回一つのOSSを取り上げて
技術的なところも深掘りしながら
結構長丁場な話もしていくような番組になっています
今後もその名の通りヤロウヨーズのOSS取り上げていけたらなと思ってますので
ぜひお聞きのプラットフォームでフォローと高評価をお願いします
またですねこんな技術についてOSSとかについて取り上げてほしいとかありましたら
コメントとかXとか後は公式サイトに載ってるお便りとかから
教えていただけると非常に嬉しいですのでよろしくお願いします
感想も非常にお待ちしている励みになりますのでよろしくお願いします
XなどでつぶやくさやにはハッシュタグヤロウヨーズのOSSつけてくださると
見つけやすくなるのでよろしくお願いします
それでは今回もありがとうございました
ありがとうございました
