#42「Webにおける画像を改めて考える」

今年はWebブラウザで画像が初めて表示できるようになってちょうど30年！Webにおける画像の現状と制作者ができることを改めて確認しましょう。

※ オフラインのため、音声ファイルを再生できません。ネットワーク状況をご確認の上、再度アクセスしてください。

加藤

皆さん、こんにちは！ミツエーリンクスの加藤です！

佐竹

佐竹です！

加藤

はい。それでは今回もミツエーテックラジオをはじめていきたいと思います。ミツエーテックラジオは、株式会社ミツエーリンクスのスタッフが、Webデザイン、Webフロントエンドなどの、Web技術に関するニュースやツールをシェアするポッドキャストです。

早速ですが今日はWebサイトにおける画像について少し話してみようかなと思います。

佐竹

画像ですか。そういえば画像って今年Webで使えるようになって30周年ですよね。

加藤

はい、そうなんです。最近だとAVIFのブラウザサポートが結構充実してきていたり、web.devにLearn Imagesという学習リソースが公開されたりとか、画像についての動きが結構あって、前々から何となく話をしてみようかなと思っていたんですよね。

佐竹

なるほど。過去にも「次世代画像フォーマットとは？」というエピソードを公開していましたよね。

加藤

はい、そうですね。そのエピソードを公開したのは2年ちょっと前くらいなんですけど、WebPとかAVIFについての特徴を簡単に説明しているので、良ければそちらも合わせて聞いてみてください！

加藤

ではまずは、画像についての現状の確認をしようということで、少し前の情報になってしまうんですけど、2022年の9月に公開されたWeb Almanacから、いろいろ情報を共有していこうかなと思います。

佐竹

はい。Web Almanacは、HTTP Archiveが集めている統計データとトレンドに、Webコミュニティの専門知識が組み合わされたWebの状態に関する年次レポートです。

加藤

はい。補足ありがとうございます。まず最初に、Webページで画像がどれくらい使われているかというところを見ていきたいんですけど、Web Almanacに「Page Weight」っていう章がありまして、そこにWebページが読み込むファイルの総容量について書かれているところがありました。突然ですが、佐竹さん、HTMLやCSSなどすべてのリソースの合計の中央値ってどのくらいだと思いますか？

佐竹

えーどのくらいでしょう。社内だとLighthouseを使ってパフォーマンス計測する際の基準値は2MBにしていますよね。

加藤

あー目の付け所がいいですね。実はWeb Almanacで報告されている中央値っていうのがPC向けだと2,019KBという結果が出てました。なので社内の基準値とだいたい同じくらいですね。で、そのうち画像の容量がどれくらいだったかというと、中央値が1,026KBだったので、ファイル総容量の約半分くらいを画像が占めているっていう感じですね。あとは、99.9%のページにおいて何かしら1つの画像に対するリクエストが発生しているっていうことでした。

佐竹

背景画像とかを含めると、画像を使用していないページってほとんど見かけないですよね。

加藤

うん、そうですね。あとさらにいうと、Core Web Vitalsの一つであるLargest Contentful Paint、これはページ内で一番大きな表示領域を持つ要素が表示されるまでの時間を計測する表示パフォーマンスの指標ですけども、このLCPの対象になる要素が画像であるページっていうのが70%にも及ぶらしいです。

佐竹

なるほど。会社のロゴみたいな小さい画像だけじゃなくって、表示領域が大きい画像も多く使われているということですよね。

加藤

うん、そういうことですね。つづいて「Media」のページには、画像に特化した集計の結果が書いてあったので、ここからは、そこからいくつか取り上げて話したいと思います。

佐竹

はい。

加藤

まず、使われている画像のファイル形式についてですけど、JPEGが40%、PNGが28.2%、GIFが15.9%、WebPが8.9%、SVGが4.7%という感じでした。

佐竹

うーん、SNSとかだとカメラで撮った写真をそのままのフォーマットでアップするっていうことが多いので、まぁJPEGの使用率が多くなるのはわかりますね。

加藤

はい。あとは気になるAVIFですけど、AVIFは総計の0.22%のページでしか使われていなかったという報告がされています。

佐竹

まだブラウザのサポートが十分ではなかったからなのか、結構少ないですね。

加藤

そうですね、私も意外と少ないなと思いました。AVIFはChromeだとバージョン85、Firefoxだとバージョン93からサポートされているので、picture要素を使って読み込んでいるサイトがけっこう多いのかなーとか思ってたんですけど、意外と少なかったですね。ただAVIF単体の使用率を昨年比でみてみると、400%ほど増えているらしいです。

佐竹

え、400%も増えてるんですか！？なんか、すごい増えてますね！

加藤

そうなんですよね。さらに言うとあのーSafariでも昨年2022年の9月に公開されたバージョン 16から使えるようになったので、今年はもっと増えるんじゃないかなーと思います。

佐竹

じゃあ、あとはMicrosoft Edgeがいつごろサポートするかがポイントですね。サポート開始を待つか、それとも待たずしてpicture要素と一緒に使い始めてみて、サポートされたらpicture要素からimg要素に切り替えるとか、その辺はEdgeの動向をみつつ、運用を考慮して決めたいところですよね。

加藤

はい、そうですね。ほかにも、Web Almanacには興味深いデータがたくさんあるんですけど、いったんここまでの話を踏まえて、私たちWeb制作者はどういうことを考えるべきかってところを話したいんですけど、何か佐竹さんありますか？

佐竹

そうですね。やっぱり画像の合計の転送サイズとページあたりのリクエスト数の両方において、画像がWebページの最大の資産になっているっていうところが、ここまで話してみてわかったので、表示パフォーマンスへの影響ですかね？

加藤

うん、たしかにユーザー目線で見ると、たとえばメインビジュアルの画像の読み込みが極端に遅かったりすると、なんかページ全体でちょっと遅いなーって感じてしまうことはありますね。

佐竹

そうですね。あと気にかけたいのは、通信量が増えればその分二酸化炭素の排出が増えるっていうことですよね。

加藤

あーたしかに、サステナビリティにも影響がありますね。ちなみにWeb Almanacにもサステナビリティのページがあって、そのなかで炭素排出量についても言及されていました。実際に二酸化炭素が排出されるのはデータ転送だけが理由ではないんですけど、データ転送に着目して見ると画像による排出っていうのがやっぱり特に多いみたいですね。

佐竹

そうすると画像自体を最適化してファイル容量を減らしたり、無駄に大きな画像を読み込んだりしないように画像の読み込み方を最適化するっていうことは、できるだけ実践したいですよね。

加藤

画像自体の最適化っていうのは、ざっくりいえばファイル形式を適切な形式に変えたり、ロッシー圧縮だったりロスレス圧縮を組み合わせてファイルの容量を減らすっていうことかなと思うんですけど、その読み込み方を最適化するっていうのはどういうイメージですか？

佐竹

そうですね。例えばページ読み込み直後のリクエストをできるだけ小さく、効率的にする方法だと遅延読み込みがありますよね。具体的に言うとimg要素に対してloading属性にlazyという値をつけるんですけど、それを設定するとビューポートに画像が近づくまで、画像のリクエストを遅らせるっていう事ができるようになるんですね。

加藤

遅延読み込みは楽に対応できる上に効果が大きいのでいいですよね。

佐竹

はい。ただ、あくまでloading属性にlazyの値をつけるのは、初期表示で見えない画像に対してのみで、初期表示で見える画像にまでこの属性を設定してしまうとLCPが下がる要因にもなってしまうので、そこはちょっと注意が必要ですね。

加藤

はい、まさにおっしゃる通りで、えーとWeb Almanacに「Lazy-loading」の章があるんですけど、その中でLCPの対象要素に対して遅延読み込みを設定しているページが9.8%もあるという結果が出てました。

佐竹

あー結構多いんですね…。こういう属性って何かしらのツールで自動的についてしまう場合もあると思うので、ちょっと気を付けたいですよね。

加藤

確かにそうですね。ちなみにloading属性以外だとどうですか？

佐竹

そうですね。Core Web VitalsのCumulative Layout Shiftを減らすために画像のアスペクト比をimg要素のwidthとheightに設定するとかも割と取り組みやすいですかね。

加藤

はい。一応簡単にCumulative Layout Shiftを説明しておくと、略してCLSと呼ばれている指標で、画像とかのコンテンツが遅れて描画されることによって起きるコンテンツのガタつきの量を計測する指標ですね。

佐竹

はい。最近だとwidthとheight属性を付与するのにVSCodeのEmmet記法を使ったり、node.jsを使って自動で付与するような処理をしたり、あと社内だと指定した幅と高さが実際の画像のサイズとあっているかどうかをチェックするためのツールっていうのが開発されてましたよね。

加藤

はい、そうですね。あのー画像って途中で差し替えられてサイズが変わったりするんですけど、画像は差し替えても属性の値を更新し忘れた、ってことは起こりやすそうですよね。ちなみにwidthとheight属性に関するデータも、あのWeb Almanacにあったんですけど、widthとheightが指定されているimg要素の量っていうのが全体の28%ということでした。

佐竹

あー思ってたよりちょっと少ないかな。CLSの値が高いと、遅延していた画像が急に表示されて、見ていた箇所を見失ったり、あと押そうと思っていたボタンが移動して別のボタンを押してしまったりとか、UXを悪くしてしまうので、設定は入っていて欲しいですね。

加藤

はい、そうですね。ちなみにChromeのバージョン112に搭載される予定のLighthouse バージョン10でスコアの重みづけが変わるんですけど、CLSはこれまで最大15点だったのが25点まで増えるみたいですね。

佐竹

あ、ということは、よりいっそうCLSが重要視されるってことですよね？

加藤

はい、そうだと思います。ここまで話してきたloading属性とかwidthやheight属性は割と基本的な対応に含まれると思うんですけど、そういう基本的なところを着実に対応していくことがやっぱり改めて大事かなと思いました。

加藤

はい。ちょっと今回Web Almanacの話が中心になったんですけど、なんか佐竹さんから話したかったことってありますか？

佐竹

そうですね。えっと冒頭で加藤さんが紹介されていたweb.devのLearn Imagesで、srcsetとかsizes属性だったり、source要素を使って画像を適切に配信するためのヒントなんかも書かれていたので、その辺も話してみたかったですね。

加藤

うん。なんかさすがに30周年というだけあって、画像1つとってもいろいろと考えることがあってやっぱ大変ですね…！引き続き注目していきつつ、なにかまた大きな動きがあれば、フロントエンドブログとかテックラジオでご紹介したいと思います！

加藤

最後に、ミツエーリンクスではスマートなコミュニケーションをデザインしたいUIデザイナー、UI開発者を募集しています。採用サイトではオンライン説明会やオンライン面接なども行っていますのでチェックしてみてください。

また、このPodcastはApple Podcast、Google Podcast、Amazon Music、Spotify、YouTubeで配信していますので、お好みのプラットフォームでフォローいただけると、最新のエピソードをすぐ視聴できます！こちらもぜひご活用ください。「#ミツエーテックラジオ」でご意見、ご感想、こんなこと話してほしいというリクエストなどもお待ちしております。それでは今日はこの辺で！ありがとうございましたー！

佐竹

ありがとうございました！