diff --git a/src/content/ja/2024/media.md b/src/content/ja/2024/media.md new file mode 100644 index 00000000000..ca16fb57084 --- /dev/null +++ b/src/content/ja/2024/media.md @@ -0,0 +1,876 @@ +--- +#See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters +title: メディア +description: 2024年Web Almanacのメディアの章では、画像や動画が現在どのようにエンコード、埋め込み、スタイル設定、配信されているかを紹介します。 +hero_alt: Web Almanacのキャラクターたちが画面に映像を投影し、他のWeb Almanacキャラクターたちがポップコーンを持ってシネマの席に向かう様子を描いたヒーロー画像。 +authors: [stefanjudis, eeeps] +reviewers: [svgeesus] +editors: [MichaelLewittes] +analysts: [stefanjudis, eeeps] +translators: [ksakae1216] +stefanjudis_bio: Stefan Judisは10年前にフロントエンド開発に恋をし、ブログやニュースレターで公開して学んでいます。 +eeeps_bio: Eric PortisはCloudinaryのWebプラットフォームアドボケイトです。 +results: https://docs.google.com/spreadsheets/d/1Q2ITOe6ZMIXGKHtIxqK9XmUA1eQBX9CLQkxarQOJFCk/ +featured_quote: ウェブ上の画像はますます大きくなっています。画像ピクセル数やレイアウトの寸法のどちらを数えても、数値は上昇しています。そのため、圧縮率の向上（一部は最新の画像フォーマットの採用増加による）にもかかわらず、画像の合計バイトサイズも増加しています。 +featured_stat_1: 99.9% +featured_stat_label_1: 少なくとも1つの画像リソースをリクエストしたページの割合。 +featured_stat_2: 32% +featured_stat_label_2: 2022年以降のビデオ採用の増加率。 +featured_stat_3: 5分の1 +featured_stat_label_3: 不正確な`sizes`属性の割合。 +doi: 10.5281/zenodo.14552631 +--- + +## はじめに + +画像と動画はウェブのあらゆる場所に存在しています。しかし、これらがウェブページにエンコードされ埋め込まれる方法は驚くほど多様で複雑であり、ベストプラクティスも常に進化しています。Web Almanacは、この複雑さと私たちがそれをどのように管理しているかを確認する機会を提供し、ウェブ上のメディアの現状、これまでの進化、そして—もしかしたら—今後の方向性についての広範な視点を与えてくれます。さあ、始めましょう！ + +## 画像 + +最も一般的なメディアタイプである画像から始めましょう。画像のないウェブページを見ることはどれくらいありますか？私たちにとっては非常にまれで、もし画像がなければ、おそらくオタクな開発者のブログを見ているのでしょう。 + +1,000万以上のスキャンおよび解析されたページのうち、99.9%が少なくとも1つの画像をリクエストしたことは驚きではありません。 + +{{ figure_markup( + caption="少なくとも1つの画像リソースをリクエストしたページの割合。", + content="99.9%", + classes="big-number", + sheets_gid="186748113", + sql_file="at_least_one_image_request.sql" +) +}} + +ほとんどすべてのページが、背景画像やファビコンだけであっても、何らかの画像を提供しています。 + +1ページあたりに見つかった``要素はいくつありましたか？ + +{{ figure_markup( + image="img-elements-per-page.png", + caption="1ページあたりの``要素の数。", + description="デスクトップとモバイルでのページごとの画像要素数の分布を示す棒グラフ。両者にはほとんど違いがありません（モバイルは一貫してわずかに少ない）。10パーセンタイルでは、モバイルとデスクトップのページともに1つの画像を含み、25パーセンタイルではモバイルで5つ、デスクトップで6つ、50パーセンタイルでは13と14、75パーセンタイルでは29と32、90パーセンタイルでは56と62です。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=796561224&format=interactive", + sheets_gid="76384810", + sql_file="imgs_per_page.sql" +) +}} + +モバイルページの中央値は13個の``要素を含んでいます。そして90パーセンタイルでも、ページは「わずか」56個の``しか含んでいません。今日のウェブのビジュアル的な性質を考えると、これは妥当なようです。 + +1ページに56個の``が多いと思うなら、モバイルクローラーが2,000個以上の``要素を含むページを見つけたとは言わないほうがいいでしょう。 + +{{ figure_markup( + content="2,174", + caption="1ページあたりの最多``要素数（モバイル）。", + classes="big-number", + sheets_gid="76384810", + sql_file="imgs_per_page.sql" +) +}} + +画像は単に普及し豊富なだけではありません。ほとんどの場合、ユーザー体験の中心的な部分でもあります。それを測定する一つの方法は、ページの最大コンテンツフル描画（LCP）に画像がどれだけ関与しているかを確認することです。 + +{{ figure_markup( + content="68%", + caption="LCP要素に画像を含むモバイルページの割合。", + classes="big-number", + sheets_gid="2001439429", + sql_file="lcp_element_data.sql" +) +}} + +ウェブ上での画像の重要性を強調しすぎることは難しいです。では、私たちが扱っているものを調査してみましょう！ + +### 画像リソース + +リソース自体から始めましょう。ほとんどの画像はピクセルで構成されています（ベクター画像は一旦脇に置いておきましょう）。ウェブ上の画像は一般的に何ピクセルあるのでしょうか？ + +おそらく驚くべきことに、多くの画像はたった1ピクセルだけで構成されています！ + +#### 単一ピクセル画像 + +
+ + + + + + + + + + + + + + + + + +
クライアント1×1画像
モバイル6.4%
デスクトップ6.0%
+
{{ figure_link(caption="1ピクセルだけを含む``要素によって読み込まれたリソース。", sheets_gid="297753608", sql_file="image_1x1.sql") }}
+
+ +1×1ピクセルの画像は、キャプチャされた画像リクエストの約6%を占めています。これらはおそらく、[昨年のメディアの章](../2022/media#1画素画像に関する注意点)で発見されたトラッキングビーコンやスペーサーGIFでしょう。そして振り返ってみると、嬉しいニュースがあります：1ピクセル画像の割合は2022年から1ポイント完全に低下しています。おそらく古い習慣が徐々に[より新しく優れた代替手段](https://developer.mozilla.org/docs/Web/API/Beacon_API)に置き換えられているのでしょう。 + +### 画像の寸法 + +ここで1×1よりも大きな画像に目を向けてみましょう。それらはどれくらいの大きさだったのでしょうか？ + +{{ figure_markup( + image="image-pixel-count-distribution.png", + caption="画像ピクセル数の分布。", + description="デスクトップとモバイルでの画像あたりのピクセル数の分布を示す棒グラフですが、90パーセンタイルを除いて両者の間に実質的な違いはありません。10パーセンタイルでは、モバイル画像は0.001メガピクセル、25パーセンタイルでは0.013、50パーセンタイルでは0.058、75パーセンタイルでは0.262、そして90パーセンタイルでのモバイル画像は0.778メガピクセルを含んでいます。90パーセンタイルでのデスクトップ用の棒グラフはわずかに高く、0.85メガピクセル以上に達しています。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=71466048&format=interactive", + sheets_gid="1417829992", + sql_file="bytes_and_dimensions.sql" +) +}} + +Web Almanacのモバイルクローラーはまったく成長していないにもかかわらず（360pxの幅のビューポートで、デバイスピクセル比3xでページをレンダリング）、0.058メガピクセルの中央値の画像は、[前回調査した時](../2022/media#画像寸法)よりも約25%大きくなっています。参考までに、正方形のアスペクト比では、0.058メガピクセルは約240×240になります。 + +ほとんどのページには、中央値の画像のピクセル数の約10倍のピクセルを持つ画像が1つあります： + +{{ figure_markup( + image="largest-image-per-page.png", + caption="ページあたりの最大画像（ピクセル数別）。", + description="ピクセル数でのページごとの最大画像の分布を示す棒グラフ。モバイルの棒グラフのみにラベルが付いています。10パーセンタイルでは、モバイルページの最大画像は0.023メガピクセルを含んでいます。25パーセンタイルでは0.138メガピクセル、50パーセンタイルでは0.540メガピクセル、75パーセンタイルでは1.280、そして90パーセンタイルでは3.130メガピクセルです。最初の2つのデスクトップの棒グラフはほぼ同じですが、50パーセンタイルでは、1.25倍まで高くなり始めます。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=1868037089&format=interactive", + sheets_gid="1057576785", + sql_file="largest_image_per_page_pixels.sql" +) +}} + +正方形のアスペクト比では、0.54メガピクセルは約735×735になります。モバイルクローラーのビューポートと密度を考えると、多くのページに高密度で全幅表示される「ヒーロー」画像が1つあるのはかなり可能性が高いです。 + +それよりも大きな画像を送信しているページの50%に関しては、ほぼ確実にモバイルクローラーが実際に表示できるよりも多くのピクセルを送信しており、適切に書かれたレスポンシブ画像のマークアップでそのムダを防ぐことができたはずです。しかし、これについては後ほど詳しく説明します。 + +### 画像のアスペクト比 + +ウェブ上の画像のサイズについてある程度理解したところで、それらの形状はどうなっているのでしょうか？ + +{{ figure_markup( + image="image-orientations.png", + caption="画像の向き。", + description="デスクトップとモバイルの両方で、どの割合の画像が縦向き、横向き、正方形であるかを示す積み上げ棒グラフのペア。デスクトップの内訳は：縦向き13%、正方形33%、横向き54%。モバイルの内訳は：縦向き14%、正方形33%、横向き53%。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=774294848&format=interactive", + sheets_gid="60298066", + sql_file="portrait_landscape_square.sql" +) +}} + +ほとんどの画像は縦よりも横幅が広く、8分の1だけが横よりも縦が長く、完全に3分の1が正確に正方形です。正方形は断然、最も人気のある正確なアスペクト比です： + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
アスペクト比（幅 / 高さ）画像の割合
1:133.2%
4:33.5%
3:22.9%
2:11.8%
16:91.6%
3:41.1%
2:30.8%
5:30.5%
+
{{ figure_link(caption="上位の画像アスペクト比（モバイル）。", sheets_gid="212159042", sql_file="top_aspect_ratios.sql") }}
+
+ +このデータは2年前とほとんど変わっていません。依然としてデスクトップベースのブラウジングへの偏りを示しているようです—クリエイターは縦向きのモバイル画面を大きく美しい縦向きの画像で埋める機会を逃しています。 + +### 画像の色空間 + +特定の画像内で可能な色の範囲は、その画像の[色空間](https://wikipedia.org/wiki/Color_space)によって決まります。ウェブ上のデフォルトの色空間は[sRGB](https://wikipedia.org/wiki/SRGB)です。画像が別の色空間を使用していることを示さない限り、ブラウザはsRGBを使用します。 + +画像に明示的に色空間を割り当てる従来の方法は、[ICCプロファイル](https://wikipedia.org/wiki/ICC_profile)を画像内に埋め込むことです。データセットでクロールされたすべての画像に埋め込まれたすべてのICCプロファイルを調査しました。 + +以下がトップ10です： + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ICCプロファイルの説明sRGB系広色域画像の割合
ICCプロファイルなし✓87.7%
sRGB IEC61966-2.1✓3.8%
c2ci✓3.2%
sRGB✓1.6%
uRGB✓0.9%
Adobe RGB (1998)✓0.7%
Display P3✓0.4%
c2✓0.3%
GIMP built-in sRGB✓0.3%
Display0.3%
+
{{ figure_link(caption="トップICCプロファイル（モバイル）。", sheets_gid="644447618", sql_file="color_spaces_and_depth.sql") }}
+
+ +ウェブ上の画像の大部分は、正しいレンダリングのためにsRGBのデフォルトに依存しており、ICCプロファイルをまったく含んでいません。 + +最も一般的なICCプロファイルは、完全な公式のsRGBカラープロファイルです。このプロファイルは比較的重く、3 KBの重さがあります。したがって、トップ10のICCプロファイルの残りのほとんどは、Clinton Ingrahmの424バイトのc2ciのような「sRGB系」プロファイルで、最小限のオーバーヘッドで画像がsRGBを使用していることを明確に指定しています。 + +この10年間で、ハードウェアとソフトウェアはますますsRGBで可能な色の範囲（いわゆるsRGB[色域](https://wikipedia.org/wiki/Gamut)）の外側にある色をキャプチャして表示できるようになっています。Adobe RGB (1998)とDisplay P3は、トップ10に唯一2つの「広色域」プロファイルです。[Adobe RGB (1998)の使用率は2022年からわずかに減少しましたが、Display P3は増加し](../2022/media#fig-8)、広色域ICCプロファイルの採用は相対的に約10%増加しています。絶対的な意味では、広色域ICCプロファイルはまだ比較的まれです。ウェブ上の画像の80分の1、ICCプロファイルを持つ画像の10分の1に見つかりました。 + +ここで非常に重要な注意点は、私たちの分析ではICCプロファイルだけを調査できたということです。前述の通り、これらのプロファイルは比較的重いものです。AVIFのような最新の画像形式（そして最近近代化されたPNGのような形式）では、CICPと呼ばれる標準を使用して画像の色空間をはるかに効率的に示すことができます—これにより一般的な色空間をわずか4バイトで示すことができます。現代的なPNGエンコーダや価値のあるAVIFエンコーダは、広色域の色空間を示すためにICCの代わりにCICPを使用するのが道理にかなっています。 + +しかし、私たちの分析では、CICPを含む画像は「ICCプロファイルなし」に分類されています。したがって、ウェブ上の広色域の使用に関する私たちの計算は、総採用率の推定値ではなく、下限と見なすべきです。言い換えれば、ウェブ上の画像の少なくとも80分の1は広色域であることがわかりました。 + +## エンコード + +ここまでウェブの画像リソースがどのようにエンコードされているかを把握したところで、それらがウェブサイトにどのように埋め込まれているかについて見ていきましょう。 + +### フォーマットの採用状況 + +数十年間、ウェブ上で一般的に使用されていたビットマップフォーマットはJPG、PNG、GIFの3つだけでした。これらは今でも3つの最も一般的なフォーマットです： + +{{ figure_markup( + image="image-format-adoption-mobile.png", + caption="画像フォーマットの採用状況（モバイル）。", + description="ウェブの画像における各フォーマットのシェアを示す円グラフ。JPEGが32.4%で1位です。次にPNGが28.4%、GIFが16.8%、WebPが12%、SVGが6.4%、その他/不明が1.7%です。円グラフの非常に小さな部分にはラベルがついていませんが、ホバーするとICOが1.3%、AVIFが1.0%であることがわかります。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=424926454&format=interactive", + sheets_gid="1939630368", + sql_file="media_formats.sql" +) +}} + +しかし、変化が起きていることを嬉しく報告できます。2022年以降の使用率における最大の絶対的変化はJPEGで、2022年のすべての画像の40%から8ポイント減少して2024年には32%になりました。これは2年間で大きな減少です。 + +その差を埋めるためにどのフォーマットがより多く使用されるようになったのでしょうか？WebPは3ポイント増加し、SVGは2ポイント弱増加し、AVIFはほぼ1ポイント増加しました。最も驚くべきことに、最も古く効率の悪いフォーマットであるGIFも1ポイント増加しました。 + +そして相対的な意味では、AVIFの使用は急増しています—2年前と比べて、クロールされたページで提供されるAVIFはほぼ4倍になりました。 + +{{ figure_markup( + image="image-format-adoption-2-year-change-mobile.png", + caption="画像フォーマットの採用、2年間の変化（モバイル）。", + description="7つの画像フォーマットについて、フォーマット採用の相対的な2年間の変化を示す棒グラフ。JPEGは20%減少、PNGは1%増加、GIFは6%増加、WebPは34%増加、SVGは36%増加、ICOは17%減少、そしてAVIFは386%増加しました。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=2128858223&format=interactive", + sheets_gid="1939630368", + sql_file="media_formats.sql" +) +}} + +クローラーがJPEG XLを受け入れていれば、おそらくかなりの数のJPEG XLも見られたでしょう。残念ながら、Chromiumベースのブラウザはこのフォーマットをサポートしていません。 + +ウェブ上のJPEG、PNG、GIFのほとんどすべては、最新のフォーマットを使用したほうが良いでしょう。WebPは良いですが、AVIFとJPEG XLはさらに優れています。ウェブ上のすべての画像という巨大な船が、これらのより効率的なフォーマットへとゆっくりではあるが確実に方向転換していくのは良いことです。またSVGの使用率が上昇していることも良いことです！ + +最後に、最も古いフォーマットについて少し言及しておきましょう：「すべてのGIFを燃やせ」は1999年に良いアドバイスでしたが、今日ではさらに良いアドバイスです。開発者はこの37年前のフォーマットを置き換える方法についてTyler Stickaのアドバイスに従うべきです。 + +### バイトサイズ + +ウェブ上の典型的な画像はどれくらい重いのでしょうか？ + +{{ figure_markup( + image="distribution-of-image-byte-sizes.png", + caption="画像バイトサイズの分布。", + description="デスクトップとモバイルの両方での画像バイトサイズの分布を示す棒グラフです。モバイルの棒グラフのみにラベルが付いており、デスクトップとモバイルの数値にはほとんど違いがありません。10パーセンタイルでは0キロバイト、25パーセンタイルでは2 KB、50パーセンタイルでは12 KB、75パーセンタイルでは56 KB、そして90パーセンタイルでは177 KBとなっています。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=1659171071&format=interactive", + sheets_gid="1417829992", + sql_file="bytes_and_dimensions.sql" +) +}} + +中央値の12 KBは「そんなに重くないじゃないか！」と思わせるかもしれません。しかし、ピクセル数を見たときと同様に、ほとんどのページには多くの小さな画像と、少なくとも1つの大きな画像が含まれていることがわかりました。 + +{{ figure_markup( + image="largest-image-per-page-by-kilobytes.png", + caption="ページあたりの最大画像（キロバイト別）。", + description="キロバイトで見たページごとの最大画像の分布を示す棒グラフ。デスクトップとモバイルの両方の棒グラフが表示されていますが、モバイルの棒グラフにのみラベルが付いています。デスクトップの数値はすべて約10〜20%大きく表示されています。10パーセンタイルでは、モバイルでのページあたりの最大画像は6 KBの重さがあり、25パーセンタイルでは37 KB、50パーセンタイルでは135 KB、75パーセンタイルでは404 KB、そして90パーセンタイルでは1002 KBです。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=2122518926&format=interactive", + sheets_gid="117141741", + sql_file="largest_image_per_page_bytes.sql" +) +}} + +ほとんどのモバイルページには、135 KB以上の画像が1つあります。これは2022年以降8%の増加です。そして分布の上位に行くほど、加速しています：75パーセンタイルは10%増加し、90パーセンタイルは13%増加（ほぼ正確に1メガバイト）しています。 + +画像はより重くなり、最も重い画像はより速く重くなっています。 + +### ピクセルあたりのビット数 + +バイト数とピクセル数はそれ自体で興味深いですが、ウェブ上の画像データがどれだけ圧縮されているかを知るためには、バイト数とピクセル数を組み合わせてピクセルあたりのビット数を計算する必要があります。これにより、画像の解像度が異なる場合でも、画像の情報密度を同等に比較することができます。 + +一般的に、ウェブ上のビットマップは、チャネルごと（ピクセルごと）に8ビットの非圧縮情報としてデコードされます。したがって、透明度のないRGB画像がある場合、デコードされた非圧縮画像はピクセルあたり24ビットの重さになると予想できます。 + +可逆圧縮に関する良い経験則は、ファイルサイズが2:1の比率で縮小されるべきということです（8ビットのRGB画像の場合、ピクセルあたり12ビットになります）。1990年代の非可逆圧縮方式（JPEGやMP3）の経験則は10:1の比率（ピクセルあたり2.4ビット）でした。 + +画像の内容とエンコード設定に応じて、これらの比率は大きく異なり、MozJPEGやJpegliのような最新のJPEGエンコーダは、デフォルト設定でこの10:1の目標を上回ることが多いことに注意すべきです。 + +要約すると： + +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
ビットマップデータの種類予想される圧縮率ピクセルあたりのビット数
非圧縮RGB1:124ビット/ピクセル
可逆圧縮RGB~2:112ビット/ピクセル
1990年代の非可逆RGB~10:12.4ビット/ピクセル
+
{{ figure_link(caption="ビットマップRGBデータの典型的な圧縮率と結果として生じるピクセルあたりのビット数。" ) }}
+
+ +そこで、これらすべてを背景として、ウェブ上の画像はどのようになっているでしょうか： + +{{ figure_markup( + image="distribution-of-image-bits-per-pixel.png", + caption="画像のピクセルあたりビット数の分布。", + description="デスクトップとモバイルの両方で、画像のピクセルあたりビット数の分布を示す棒グラフ。デスクトップの棒グラフは一貫してモバイルの棒グラフよりわずかに短いですが、ラベルは付いていません。10パーセンタイルでは、ウェブの画像はモバイルでピクセルあたり0.1ビットの重さがあります。25パーセンタイルでは0.9、50パーセンタイルでは2.1、75パーセンタイルでは5.6、そして90パーセンタイルでは、モバイル画像はなんとピクセルあたり12.9ビットの重さがあります。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=400614419&format=interactive", + sheets_gid="1417829992", + sql_file="bytes_and_dimensions.sql" +) +}} + +中央値の画像はピクセルあたり2.1ビットに圧縮されており、これは1990年代の経験則よりも少し多い圧縮を表しています。これはまた、[2022年に最後にウェブの画像を調査したとき](../2022/media#fig-14)に見た圧縮率よりも8〜10%多い圧縮です。 + +圧縮をフォーマット別に分類すると、2022年と比較して2024年はすべてのフォーマットでピクセルあたりに費やされるビットが少なくなっていることが分かります—1つを除いて。 + +#### フォーマット別のピクセルあたりビット数 + +{{ figure_markup( + image="median-bits-per-pixel-by-format.png", + caption="フォーマット別の中央値ピクセルあたりビット数。", + description="いくつかの人気のある画像フォーマットについて、フォーマット別の中央値ピクセルあたりビット数を示す棒グラフ。デスクトップとモバイルの数値は類似しており、モバイルの棒グラフにのみラベルが付いています。GIFはピクセルあたり6.7ビット、PNG：3.8、JPG：2.0、AVIF：1.4、そしてWebPが最も小さくピクセルあたり1.3ビットです。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=165542730&format=interactive", + sheets_gid="1416380443", + sql_file="bytes_and_dimensions_by_format.sql" +) +}} + +[2022年と比較して](../2022/media#fig-15)、モバイルでは、中央値のPNGは約10%多く圧縮され、中央値のWebPは約7%多く圧縮され、中央値のJPEGは約3%多く圧縮されています。ここでの原因を正確に知ることは難しいですが、私たちは圧縮の増加は2つのことのより広い採用の結果であると仮説しています：より多くの価値を提供する最新のエンコーダと、すべての画像がユーザーに届く前に適切に圧縮されていることを確認する自動画像処理パイプラインです。 + +この傾向に逆らった1つのフォーマットはAVIFでした。中央値のAVIFのピクセルあたりビット数は、2022年の約1.0から2024年には約1.4ビット/ピクセルに増加しました—これは47%の増加です。面白いことに、私たちは同じ根本原因を仮説としています。現在の多様なAVIFエンコーダは、2年前のAOMの公式libavifエンコーダよりもデフォルト設定で品質を犠牲にすることが少ない、異なる品質/ファイルサイズのトレードオフを行っている可能性が高いです。 + +GIFがなぜ大幅に効率的になったのかはわかりませんが、なぜGIFが他のすべてのフォーマットよりもはるかに圧縮率が低いのかはわかります。私たちのクエリはピクセルごとであり、多くのGIFがアニメーションであるにもかかわらず、アニメーション画像を考慮していません！ + +### GIF、アニメーションとそうでないもの + +どれだけのGIFがアニメーションなのでしょうか？ + +{{ figure_markup( + content="32%", + caption="モバイルでアニメーションだったGIFの割合。", + classes="big-number", + sheets_gid="501019705", + sql_file="animated_gif_count.sql" +) +}} + +アニメーションGIFとアニメーションではないGIFを分けてみると、アニメーションではない中央値のGIFははるかに合理的に圧縮されていることがわかります： + +{{ figure_markup( + image="gif-bits-per-pixel-animated-non-animated.png", + caption="GIFのピクセルあたりビット数：アニメーションvsアニメーションなし。", + description="アニメーションGIFとアニメーションなしGIFのピクセルあたりビット数の分布を示す棒グラフ。アニメーションGIFの棒グラフはアニメーションなしGIFの棒グラフを圧倒しています。アニメーションGIFは10、25、50、75、90パーセンタイルでそれぞれ4.5、12.1、32.6、60.6、82.6ビット/ピクセルの重さがあります。アニメーションなしGIFの進行は次の通りです：0.9、1.8、3.5、5.7、9.3ビット/ピクセル。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=1948267327&format=interactive", + sheets_gid="1251617650", + sql_file="animated_gif_bpp.sql" +) +}} + +3.5ビット/ピクセルは中央値のPNGよりも少ないです！ + +特にアニメーションGIFに目を向けると：それらはどれくらいのフレーム数を持っているのでしょうか？ + +{{ figure_markup( + image="distribution-of-animated-gif-frame-counts.png", + caption="アニメーションGIFフレーム数の分布。", + description="アニメーションGIFフレーム数の分布を示す棒グラフ。このグラフはデスクトップとモバイルの両方を示していますが、モバイルの数値にのみラベルが付いています。90パーセンタイルまで棒グラフは全く同じに見えます。10パーセンタイルでは、モバイルとデスクトップの両方でGIFあたり4フレームでした。25パーセンタイルでは両方とも8フレームです。50パーセンタイルでは両方とも12フレーム、75パーセンタイルでは両方とも24フレームです。最後に、90パーセンタイルでは、デスクトップクローラーは46フレーム、モバイルクローラーは60フレームを見ました。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=230229356&format=interactive", + sheets_gid="810988388", + sql_file="animated_gif_framecount.sql" +) +}} + +一般的には：10〜20フレームで、[これは2022年からほとんど変わっていません](../2022/media#fig-18)が、最も長いGIFは特にモバイルでより長くなっています。 + +参考までに、最も多くのフレーム数を持つGIFも調査しました： + +{{ figure_markup( + content="54,028", + caption="データセット内の最高GIFフレーム数。", + classes="big-number", + sheets_gid="810988388", + sql_file="animated_gif_framecount.sql" +) +}} + +24フレーム/秒では、一通り再生するのに37分以上かかります。すべてのアニメーションGIFはおそらく現在では動画であるべきですが、これは間違いなくそうあるべきです。 + +## 埋め込み + +ウェブの画像リソースがどのようにエンコードされているかを理解したところで、それらがウェブサイトにどのように埋め込まれているかについて何が言えるでしょうか？ + +### 遅延読み込み + +ウェブサイトに画像が埋め込まれる方法における最近の最大の変化は、遅延読み込みの急速な採用でした。遅延読み込みは2020年に導入され、[わずか2年後にはほぼ4分の1のウェブサイトで採用されました](../2022/media#レイジーローディング)。その上昇は続き、現在ではすべてのウェブサイトの完全に3分の1で使用されています： + +{{ figure_markup( + image="adoption-of-img-loading-lazy.png", + caption="遅延読み込み（``）の採用状況。", + description="モバイルとデスクトップの両方で、時間の経過に伴うネイティブ遅延読み込みを使用しているページの割合を示す折れ線グラフ。線は互いにかなり近く、2022年6月のわずか25%未満から2024年6月のわずか35%未満まで、ほぼ直線的に上昇しています（多少の波がありますが）。どの1か月でも最も急な上昇は最後にあり、そこに鋭い小さな上昇があります。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=1997305111&format=interactive", + sheets_gid="228292115", + sql_file="lazy_loading_adoption_over_time.sql" +) +}} + +そして、昨年と同様に、遅延読み込みを少し使いすぎているようです： + +{{ figure_markup( + content="9.5%", + caption="モバイルでネイティブ遅延読み込みを使用しているLCP対象の``要素の割合。", + classes="big-number", + sheets_gid="2001439429", + sql_file="lcp_element_data.sql" +) +}} + +LCP要素を遅延読み込みすることは、[ページを大幅に遅くするアンチパターン](https://web.dev/articles/lcp-lazy-loading)です。LCP対象の``の10個に1個近くが遅延読み込みされていることは落胆させられますが、過去2年間でわずかに改善されていることを報告できることは嬉しいことです。違反サイトの割合は2022年から0.3パーセントポイント減少しています。 + +### `alt` テキスト + +``要素で埋め込まれる画像は、内容を持つべきものです。つまり、単なる装飾ではなく、意味のあるものを含むべきです。WCAG要件とHTML仕様の両方によれば、ほとんどの場合、``要素には代替テキストが必要であり、その代替テキストは`alt`属性によって提供されるべきです。 + +{{ figure_markup( + content="55%", + caption="空でない`alt`属性を持つ画像の割合。", + classes="big-number", + sheets_gid="694600230", + sql_file="image_alt.sql" +) +}} + +残念ながら、``要素の45パーセントには`alt`テキストがありません。さらに悪いことに、[今年のアクセシビリティの章からの詳細な分析](./accessibility#画像)によると、`alt`テキストを持つ``の多くも、その属性にはファイル名や他の意味のない短い文字列しか含まれていないため、それほどアクセシブルではありません。 + +2022年以降、`alt`テキストの導入は1パーセントポイント増加していますが、私たちはさらに—そしてそうしなければなりません—改善できます。 + +### `srcset` + +遅延読み込みの前に、ウェブ上の``要素に起きた最大の変化は、「レスポンシブイメージ」のための機能セットで、これによって画像がレスポンシブデザイン内に適合するように調整できるようになりました。2014年に最初にリリースされた`srcset`属性、`sizes`属性、``要素は現在10年の歴史を持っています。私たちはこれらをどれくらいの頻度で、どれくらい上手に使用しているでしょうか？ + +まず、`srcset`属性から見ていきましょう。これによって作成者は、コンテキストに応じてブラウザに選択肢となるリソースのメニューを提供できます。 + +{{ figure_markup( + content="42%", + caption="モバイルで`srcset`属性を使用しているページの割合。", + classes="big-number", + sheets_gid="2067327124", + sql_file="image_srcset_sizes.sql" +) +}} + +[前回確認した時、この数字は34%でした](../2022/media#srcset)—2年間で8パーセントポイントの増加は重要であり、勇気づけられます。 + +`srcset`属性により、作成者は2つの記述子のいずれかを使用してリソースを記述できます。`x`記述子はリソースの密度を指定し、ブラウザがユーザーの画面密度に応じて異なるリソースを選択できるようにします。`w`記述子はブラウザにリソースの幅をピクセル単位で提供します。`sizes`属性と組み合わせて使用すると、`w`記述子によりブラウザは可変レイアウト幅と可変画面密度の両方に適したリソースを選択できます。 + +{{ figure_markup( + image="srcset-descriptor-usage.png", + caption="`srcset`記述子の使用状況。", + description="`x`記述子と`w`記述子を使用している`srcset`の割合を示す棒グラフで、モバイルとデスクトップの両方を示しています。`x`記述子はデスクトップとモバイルの両方で`srcset`の15%で使用されています。`w`記述子は4倍多く使用されており、デスクトップでは64%、モバイルでは62%の頻度で使用されています。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=1554380054&format=interactive", + sheets_gid="1810212061", + sql_file="image_srcset_descriptor.sql" +) +}} + +`x`記述子が最初に出荷され、理解しやすいものですが、`w`記述子はより強力です。`w`記述子がより一般的であることを見るのは勇気づけられます。そして、`x`記述子の採用は2022年からほとんど増加していませんが、[`w`記述子の使用はまだ成長し続けています](../2022/media#fig-23)—`w`記述子の採用はモバイルで4パーセントポイント、デスクトップで6パーセントポイント増加しています。 + +### `sizes` + +先ほど、`w`記述子は`sizes`属性と組み合わせて使用すべきだと述べました。では、私たちは`sizes`をどれくらい上手に使用しているでしょうか？あまり上手ではありません！ + +`sizes`属性は、画像の最終的なレイアウト幅についてブラウザへのヒントとなるもので、通常はビューポート幅に対する相対値です。`sizes`属性は明示的にヒントであることが意図されているため、多少の不正確さは問題なく、むしろ予想されています。 + +しかし、`sizes`属性が少し以上に不正確である場合、リソース選択に影響を与える可能性があり、実際の画像のレイアウト幅が大きく異なる場合でも、ブラウザが`sizes`幅に合わせて画像を読み込む原因となります。 + +では、私たちの`sizes`はどれくらい正確でしょうか？ + +{{ figure_markup( + image="distribution-of-img-sizes-errors.png", + caption="``エラーの分布。", + description="デスクトップとモバイルの両方での`sizes`属性の相対的なエラーの分布を示す棒グラフ。最初はすべてゼロで、10パーセンタイルと25パーセンタイルではデスクトップとモバイルの両方で0%です。50パーセンタイルではデスクトップで43%、モバイルで16%、75パーセンタイルではそれぞれ168%と94%、そして90パーセンタイルではデスクトップで360%、モバイルで179%となっています。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=16669482&format=interactive", + sheets_gid="776888472", + sql_file="image_srcset_sizes_per_image_accuracy_impact.sql" +) +}} + +多くの`sizes`属性は完全に正確ですが、中央値の`sizes`属性はモバイルで16%、デスクトップで43%大きすぎます。この機能のヒント的な性質を考えると問題ないかもしれませんが、ご覧のように、75パーセンタイルと90パーセンタイルはかなり悪い状況です。最も懸念されるのは、[これらの数値がすべて過去2年間で大幅に悪化している](../2022/media#fig-24)ことで、デスクトップの中央値の`sizes`は2年前よりも2倍以上不正確になっています。 + +こうした不正確さの影響はどれほどでしょうか？ + +{{ figure_markup( + content="20%", + caption="デスクトップで`srcset`選択に影響を与えるほど不正確だった`sizes`属性の割合。モバイルでは14%です。", + classes="big-number", + sheets_gid="1503721277", + sql_file="image_srcset_sizes_accuracy_pct.sql" +) +}} + +デスクトップでは、デフォルトの`sizes`値（`100vw`）と画像の実際のレイアウト幅の差がモバイルよりも大きくなる可能性が高く、5つに1つの`sizes`属性が不正確すぎて、ブラウザが`srcset`から最適ではないリソースを選択する原因となっています。これらのエラーは積み重なります。 + +{{ figure_markup( + image="excess-kilobytes-loaded-per-page-due-to-inaccurate-sizes.png", + caption="不正確な`sizes`によってページごとに読み込まれる余分なキロバイト。", + description="不正確な`sizes`属性によってページごとに無駄に読み込まれるキロバイトの分布を示す棒グラフ。最初はゼロばかりです。10パーセンタイル、25パーセンタイル、50パーセンタイルでは、モバイルとデスクトップの両方でゼロキロバイトです。75パーセンタイルでは、デスクトップクローラーは179キロバイト、モバイルでは55キロバイトの無駄を検出し、90パーセンタイルでは、デスクトップでは920キロバイト、モバイルでは400キロバイトでした。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=736387424&format=interactive", + sheets_gid="252030871", + sql_file="image_sizes_per_page_accuracy_impact.sql" +) +}} + +私たちの推定では、`w`記述子を使用するデスクトップページの4分の1が、不正確な`sizes`属性のために180KB以上の無駄な画像データを読み込んでいます。つまり、`srcset`にはより良い、より小さなリソースがあるにもかかわらず、`sizes`属性が非常に誤っているため、ブラウザはそれを選択しません。`w`記述子を使用するデスクトップページの最も悪い10%は、不良な`sizes`属性のために約1メガバイトの余分な画像データを読み込んでいます。 + +これはかなり問題ですが、さらに悪いことに、これらの数字はすべて、わずか2年前と比較して約2倍悪化しています。状況は悪く、さらに悪化しています。 + + + +開発者が追求すべき2つの解決策があります。 + +LCP対象および他の重要な画像については、開発者は`sizes`属性を修正する必要があります。`sizes`を監査および修正するための最良のツールはRespImageLintで、これは他の多くのレスポンシブ画像の問題も修正するのに役立ちます。 + +ビューポート外（below-the-fold）や重要でない画像については、作成者は`sizes="auto"`を採用し始めるべきです。この値は遅延読み込みと組み合わせてのみ使用できますが、ブラウザに``の実際のレイアウトサイズを`sizes`値として使用するよう指示し、使用される値が完全に正確であることを保証します。 + +遅延読み込み画像の自動`sizes`は現在Chromeでのみ実装されていますが、SafariとFirefoxの両方がそれをサポートする意向を表明しています。彼らがすぐにそれを実装し、開発者が（フォールバック値を伴って）今すぐそれを展開し始めることを期待しています。 + +### `` + +2014年に最後に登場したレスポンシブイメージ機能は``要素でした。`srcset`がブラウザに選択肢となるリソースのメニューを提供するのに対し、``要素は作者が主導権を握り、どの子``要素からリソースを読み込むかについての明示的なコンテキスト適応型の指示をブラウザに与えることができます。 + +``要素は`srcset`よりもはるかに少なく使用されています： + +{{ figure_markup( + content="9.3%", + caption="``要素を使用しているモバイルページの割合。", + classes="big-number", + sheets_gid="1095160660", + sql_file="picture_distribution.sql" +) +}} + +この数字は2022年から1.5パーセントポイント以上増加していますが、``を使用する1ページに対して`srcset`を使用するページが4ページ以上あるという事実は、``のユースケースがより限定的であるか、``の導入がより困難であるか、あるいはその両方であることを示唆しています。 + +人々は``をどのような目的で使用しているのでしょうか？ + +``要素は、作者にリソースを切り替える2つの方法を提供します。タイプ切り替えにより、作者は最先端の画像フォーマットをサポートするブラウザに提供し、他のすべてのブラウザにはフォールバックフォーマットを提供することができます。メディア切り替えはアートディレクションを容易にし、作者がメディア条件に基づいて``間を切り替えることを可能にします。 + +{{ figure_markup( + image="picture-feature-usage.png", + caption="``機能の使用状況。", + description="`picture`要素と組み合わせて、`source`要素上で`media`属性と`type`属性を使用しているページの割合を示す棒グラフ。`media`はモバイルでは`picture`要素の40%、デスクトップでは37%で使用されています。`type`はモバイルとデスクトップの両方で`picture`要素の46%で使用されています（ただし、モバイルの棒グラフはわずかに大きくなっています）。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=68600519&format=interactive", + sheets_gid="1248341599", + sql_file="picture_switching.sql" +) +}} + +2022年から`media`属性の使用は3パーセントポイント減少していますが、`type`切り替えの使用は3パーセントポイント増加しています。この増加は、次世代画像フォーマット、特にまだ普遍的なブラウザサポートを享受していないJPEG XLの人気の高まりと関連している可能性が高いです。 + +## レイアウト + +私たちはすでに[ウェブの画像リソースがどのようなサイズであるか](#画像の寸法)を見てきました。しかし、ユーザーに表示される前に、埋め込まれた画像はレイアウト内に配置され、場合によっては押しつぶされたり引き伸ばされたりして適合させる必要があります。 + + + +### レイアウト幅 + +まず次の質問から始めましょう：ウェブの画像はページに描画されるとどれくらいの幅になるのでしょうか？ + +{{ figure_markup( + image="distribution-of-img-layout-widths.png", + caption="``レイアウト幅の分布。", + description="デスクトップとモバイルの両方での画像要素レイアウト幅の分布を示す棒グラフ。一般的に、デスクトップの幅はより大きく、25パーセンタイルではモバイルと同等です。10パーセンタイルでは、デスクトップのレイアウト幅は31 CSSピクセルで、モバイルは21 CSSピクセルです。25パーセンタイルでは、モバイルとデスクトップの両方とも81 CSSピクセルで同等です。50パーセンタイルでは、デスクトップは216 CSSピクセル、モバイルは158 CSSピクセルです。75パーセンタイルでは、デスクトップは345、モバイルは300です。そして最後に90パーセンタイルでは、デスクトップは600 CSSピクセル、モバイルは340 CSSピクセルです。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=991739101&format=interactive", + sheets_gid="1727223276", + sql_file="image_layout_widths.sql" +) +}} + +ウェブ上のほとんどの画像はレイアウト内ではかなり小さくなっています。興味深いことに、[モバイルのレイアウトサイズの大部分は2022年からほとんど変わっていませんが、デスクトップのレイアウトサイズの上位半分はすべて約8%増加しています](../2022/media#sizes)。 + +しかし、レイアウトサイズの大多数が小さい一方で、ほとんどのページには少なくとも1つのかなり大きな``があります。 + +{{ figure_markup( + image="widest-img-per-page-layout-width.png", + caption="ページあたりの最も幅広い``（レイアウト幅別）。", + description="デスクトップとモバイルの両方で、ページごとの最も幅広い画像レイアウト幅の分布を示す棒グラフ。10パーセンタイルでは、デスクトップクローラーは149 CSSピクセル、モバイルクローラーは101ピクセルを観測しました。25パーセンタイルの幅はデスクトップで330ピクセル、モバイルで280ピクセルでした。50パーセンタイルの数値は680ピクセルと330ピクセル、75パーセンタイルでは1,350ピクセルと360ピクセル、そして90パーセンタイルではデスクトップで1,905ピクセル、モバイルで392ピクセルという高い数値を示しました。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=764338367&format=interactive", + sheets_gid="1022961650", + sql_file="largest_image_per_page_layout.sql" +) +}} + +すべてのモバイルページの半分には、ビューポートのほぼ全体を占める画像が少なくとも1つあります。上位の方では、モバイルレイアウトは画像がそれ以上のスペースを占めないようにうまく抑制しています。分布がモバイルクローラーのビューポート幅（360px）にすぐに近づき、それをわずかに超えるだけであることがわかります。 + +これに対してデスクトップのレイアウト幅は、まったく頭打ちになっていません。それらは拡大し続け、75パーセンタイルでフルビューポート幅（1360px）に達し、90パーセンタイルではそれを大きく超えています。同様に興味深いのは、デスクトップでの25、50、75パーセンタイルのレイアウトサイズが[2年前よりも大きくなっている](../2022/media#fig-30)一方で、分布の端はほとんど変わっていないことです。大きなヒーロー画像はさらに大きくなっています。 + +### 内在的 vs 外在的サイジング + +ウェブの画像はどのようにしてこれらのレイアウトサイズになるのでしょうか？CSSで画像をスケーリングする方法はたくさんありますが、実際にCSSでスケーリングされている画像はどれくらいあるのでしょうか？ + +画像は、すべての["置換要素"](https://developer.mozilla.org/docs/Web/CSS/Replaced_element)と同様に、[内在的サイズ](https://developer.mozilla.org/docs/Glossary/Intrinsic_Size)を持っています。デフォルトでは—密度を制御する`srcset`やレイアウト幅を制御するCSSルールがない場合—ウェブ上の画像は1xの密度で表示されます。640×480の画像を``に配置すると、デフォルトではその``は幅640 CSSピクセルでレイアウトされます。 + +作者は画像の高さ、幅、またはその両方に外在的サイジングを適用することができます。画像が一方の次元で外在的にサイズ設定されている場合（例えば、`width: 100%;`ルールによる）、しかしもう一方の次元では内在的サイズのままである場合（`height: auto;`または何もルールがない）、内在的なアスペクト比を使用して比例的にスケーリングされます。 + +さらに複雑なことに、いくつかのCSSルールは、内在的な次元が何らかの制約に違反しない限り、``要素を内在的な次元に基づいてサイズ設定します。例えば、`max-width: 100%;`ルールを持つ``要素は、内在的サイズが``要素のコンテナのサイズよりも大きい場合を除いて、内在的にサイズ設定されます。その場合は、外在的に縮小されて適合します。 + +これらの説明を踏まえて、ウェブの``要素がレイアウトのためにどのようにサイズ設定されているかを見てみましょう： + +{{ figure_markup( + image="intrinsic-and-extrinsic-image-sizing-mobile.png", + caption="内在的および外在的な画像サイジング（モバイル）。", + description="幅と高さが内在的サイジングと外在的サイジングのどちらに基づいて決定されるかを示す積み上げ棒グラフ。（今のところ）謎の第三のカテゴリーもあります：両方。高さと幅の間の内在的、外在的、および両方の分布はかなり異なります。高さについては、画像の55%が内在的にサイズ設定され、36%が外在的、残りの9%が両方に該当します。幅については、わずか7%の画像が内在的にサイズ設定され、70%が外在的です。残りの22%は両方です。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=771165914&format=interactive", + sheets_gid="224799521", + sql_file="image_sizing_extrinsic_intrinsic.sql" +) +}} + +大多数の画像は外在的な幅と内在的な高さを持っています。幅の「両方」カテゴリ—`max-width`または`min-width`のサイジング制約を持つ画像を表す—もかなり人気があります。画像を内在的な幅のままにしておくことははるかに人気が低く、[2022年](../2022/media#fig-31)よりもわずかに人気が低くなっています。 + +### `height`, `width`属性と累積レイアウトシフト + +内在的な寸法に依存するレイアウトサイズを持つ``は、[累積レイアウトシフト（CLS）](https://web.dev/articles/cls)を引き起こすリスクがあります。本質的に、そのような画像はレイアウトが2回行われるリスクがあります—1回目はページのDOMとCSSが処理された時点で、そして2回目は最終的に読み込みが完了し、内在的な寸法が判明した時点です。 + +先ほど見たように、特定の幅に合わせて画像を外在的にスケーリングしながら、高さ（およびアスペクト比）を内在的なままにしておくことは非常に一般的です。このようなレイアウトシフトの蔓延を防ぐために、[作者は``要素に`width`と`height`属性を設定すべきです](https://developer.mozilla.org/docs/Learn/Performance/Multimedia#rendering_strategy_preventing_jank_when_loading_images)。これによりブラウザは埋め込みリソースが読み込まれる前にレイアウトスペースを確保できます。 + +{{ figure_markup( + content="32%", + caption="モバイルで`height`と`width`属性の両方が設定されている``要素の割合。", + classes="big-number", + sheets_gid="36830123", + sql_file="img_with_dimensions.sql" +) +}} + +`height`と`width`の使用は[2022年から4パーセントポイント増加しており](../2022/media#fig-32)、これは良いことです。しかし、これらの属性はまだ画像の3分の1にしか使用されておらず、まだ長い道のりがあることを意味しています。 + +## 配信 + +最後に、画像がネットワーク上でどのように配信されているかを見てみましょう。 + +### クロスドメイン画像ホスト + +埋め込まれた文書とは異なるドメインから配信されている画像はどれくらいあるのでしょうか？増加する多数派です： + +{{ figure_markup( + image="image-hosts-same-vs-cross-domain.png", + caption="画像ホスト：同一ドメイン vs クロスドメイン。", + description="ルートHTMLページと同じドメインから配信された画像と、異なる（クロス）ドメインから配信された画像の数を示す棒グラフで、2022年と2024年の両方のデスクトップとモバイルの内訳を比較しています。モバイルでは、クロスドメイン/同一ドメインの割合は2022年の55%/45%から、2024年には62%/38%になりました—つまり、クロスドメイン画像のシェアは約7パーセントポイント増加しました。デスクトップでは、2022年の53%/47%から2024年には62%/38%になり、クロスドメイン画像ホスティングが9パーセントポイント増加しました。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQCSP87WE9bhFjIICxcrpIEGQlz3xBq33-ODZ8e91XSLUbLvAZjk25GhOdDtFIZCzPcS-VrSygr7pmz/pubchart?oid=595767399&format=interactive", + sheets_gid="817041542", + sql_file="img_xdomain.sql" +) +}} + +ここでのさまざまな潜在的な原因を解きほぐすのは難しいですが、私たちは画像を正しく扱うことがいかに難しいかが一つの要因であるという仮説を立てています。これによりチームは[画像CDN](https://web.dev/image-cdns/)を採用するようになり、画像の最適化と配信をサービスとして提供しています。 + +これで、ウェブ上の画像の現状についての全体像が得られました。次に、2024年のウェブ上の動画について見ていきましょう。 + +## 動画 + +`