現在、合計転送サイズの点で画像はウェブで最も大きなアセットとなっています。 ページあたりのリクエスト数などがあります。ウェブページの合計転送サイズの中央値はおよそ 2022 年 6 月時点では 2 MB で、画像だけでその半分近くを占めています。大げさではなく 画像リクエストの最適化が、パフォーマンスの最適化において最大の効果を発揮する可能性があると述べています。
後ほど、レスポンシブな画像が、あらゆる状況で 1 つの画像を提供することで生じている問題に対処するために、どのように進化してきたかを学びます。 このセクションでは、画像に関連する主なパフォーマンス指標とその改善方法について説明します。
イメージ リクエストの延期
画像リクエストをできるだけ小さく効率的にするさまざまな方法を学習しようとしていますが、
二度と生まれないものです。さっそく、この道のりに皆様が取り入れることができる、最も影響力のある変化についてお伝えしたいと思います。
loading="lazy" 属性: 画像アセットをユーザーに配信します。
<img src="image.jpg" loading="lazy" alt="…">
この属性を使用すると、画像のリクエストはユーザーのビューポートに近くなるまで行われず、最初のリクエストから延期されます。 そして、これらのリクエストをクリティカル レンダリング パスから削除することを検討します。
実際にはシンプルですが、この属性を使用すると、パフォーマンスに大きなプラスの影響（例: ユーザーのビューポートはリクエストされないため、ユーザーがまったく表示されない画像に帯域幅が浪費されることはありません。
ただし、こうしたリクエストを遅らせると、ブラウザのプロセスが高度に最適化されて
できるだけ早い段階で実行しますloading="lazy" がレイアウト上部の img 要素で使用されている場合（つまり、その可能性が高い）
画像がユーザーのビューポートに表示されるように設定してあるため、これらの画像はエンドユーザーにとって非常に遅く感じられる可能性があります。
取得優先度
loading 属性は、デベロッパーがウェブブラウザの機能をより強力にするための大規模なウェブ標準の取り組みの一例です。
リクエストの優先度を判断できます
ブラウザとブラウザについて優先度を取得するための基本的なアプローチ:
たとえば、ドキュメントの <head> 内にある外部 CSS ファイルに対するリクエストは、レンダリングをブロックするには十分に重要であるとみなされますが、外部 CSS ファイルのリクエストは、
</body> のすぐ上にある外部 JavaScript ファイルは、レンダリングが完了するまで遅延します。<img> の loading 属性の値が「lazy」の場合、
関連付けられた画像のリクエストは、画像がユーザーに表示されるとブラウザが判断するまで延期されます。それ以外の場合、イメージには
ページ上の他の画像と同じ優先度になります。
fetchpriority 属性は、
デベロッパーがアセットの優先度をきめ細かく制御し、リソースにフラグを設定可能
「high」としてと「低」リソースに対して優先度を設定できます。fetchpriority のユースケースは loading と同様です。
属性よりもはるかに広範ですたとえば、ユーザー インタラクション後にのみ表示される画像には fetchpriority="low" を使用できます。
（その画像がユーザーのビューポート内にあるかどうかに関係なく）ページの他の場所に表示される画像を優先します。または、fetchpriority="high"
を使用して、ページがレンダリングされるとすぐにビューポートに表示されるように画像に優先順位を付けます。
fetchpriority は、ブラウザの動作を根本的に変更しないという点で loading と異なります。ブラウザには指示しない
特定のアセットを他のアセットより先に読み込むように指示することで、アセットのリクエストに関する判断に必要なコンテキストを提供できます。
画像の影響を測定する
画像アセットを最適化する場合、一般に、全体の移行よりも、実感したパフォーマンスの方が重要で、測定は困難 なります。
Web Vitals は、ユーザーのエクスペリエンスを向上させるための、測定可能で実用的な指標とガイダンスを提供します。ウェブエクスペリエンスのエクスペリエンスを 向上させることです ウェブサーバーからの応答時間が遅い、レンダリングの問題、インタラクティビティが遅延するなどの問題です。Core Web Vitals は、これらの目標の一部であり、 ユーザーが個々のページを直接目にするエクスペリエンス（複数の技術的な測定値を総合し、ユーザー エクスペリエンスの速さを判定します。
Cumulative Layout Shift
Cumulative Layout Shift（CLS）は視覚的な安定性の尺度です。これは、発生した費用がどれだけ アセットが読み込まれてページがレンダリングされると、ページのコンテンツのレイアウトが変化します。かなりの金額を費やした人 ページが「ジャンプ」したことが原因で、長いテキストの中で自分のスペースが失われたユーザーの割合遅延したウェブフォントや画像のソースが インタラクティブ要素がポインタから突然移動した場合などです。CLS の高さはせいぜいわずらわしく、 最悪のユーザーエラー - 「キャンセル」以前「確認」のボタンが表示されていたスペースに移動するボタンをクリックするだけです。
読み込みに時間がかかり、レイアウト内で占有できるスペースも大きいため、画像が原因であるのは 確認できます
最近のブラウザにおける比較的最近の変更により、画像による高い CLS スコアを避けるのは、想像するよりも簡単です。
数年前からフロントエンドに取り組んできているなら、<img> の width 属性と height 属性に馴染みがあるでしょう。
CSS が普及する前は、画像のサイズを制御する唯一の方法でした。
<img src="image.jpg" height="200" width="400" alt="…">
これらの属性は、スタイルに関する問題とマークアップを分離するために、特にレスポンシブ デザインでは使用されていませんでした
ウェブデザインでは、CSS で割合に基づくサイズを指定する必要がありました。初期のレスポンシブ ウェブ デザインでは、「
未使用の width 属性と height 属性"これは一般的なアドバイスであり、CSS で指定した値である max-width: 100% と
height: auto — オーバーライドします。
<img src="image.jpg" alt="…">
img {
max-width: 100%;
height: auto;
}
前の例と同様に height 属性と width 属性を削除したことで、ブラウザが判断するための唯一のメソッドとなりました。
この場合の画像の高さは、ソースをリクエストしてパースし、
スタイルシート適用後にレイアウト内で占有するスペースの幅。このプロセスの多くはページの
新たに計算された高さにより追加のレイアウト シフトが発生します。
2019 年以降、width 属性と height 属性を異なる方法で処理するようにブラウザの動作が更新されました。これらの値の値を使用する代わりに、
属性を使用して、レイアウト内の img 要素の固定のピクセルベース サイズを指定します。これらの属性は、
画像のアスペクト比。ただし、構文は同じです。最新のブラウザでは、これらの値を互いに分割して、
ページのレンダリング前に img 要素に固有のアスペクト比を決定して、レイアウトのレンダリング時に画像が占めるスペースを確保します。
原則として、<img> では必ず height 属性と width 属性を使用し、その値は画像ソースの本質的なサイズと一致する必要があります。
HTML 属性の高さをオーバーライドするために、max-width: 100% とともに height: auto が指定されていることを確認してください。
<img src="image.jpg" height="200" width="400" alt="…">
img {
max-width: 100%;
height: auto;
}
<img> 要素で width 属性と height 属性を使用すると、画像による CLS スコアが高くなりません。
重要な点として、この方法は、長年確立されているブラウザの動作、すなわち任意のブラウザに依存しているため、この方法にデメリットはありません。
基本的な CSS をサポートしている場合、通常どおりに動作し、マークアップの height 属性と width 属性はスタイルによってオーバーライドされます。
width 属性と height 属性を使用すると、画像に必要なレイアウト スペースを確保して、CLS の問題を効果的に回避できます。
空白や低品質のプレースホルダが表示され、
画像が転送されてレンダリングされるのを待つことも
理想的ではありません測定可能で認識可能な問題を
軽減するためにできることはあります
画像の読み込みが遅い場合の影響を軽減できます。完全にレンダリングされた画像をより迅速にユーザーに表示するには、転送サイズを小さくするしか方法がありません。
Largest Contentful Paint
Largest Contentful Paint（LCP）は、ユーザーのビューポートに表示される最大の「contentful」要素（ コンテンツ要素の中で、視認可能なページ内で最も多くを占める割合を占めています。一見すると限定的すぎるように思えるかもしれませんが、 要素は、ユーザーの観点からは、ページの大部分がレンダリングされた時点を表す実用的なプロキシとして機能します。LCP は 測定するものです
DOMContentLoaded や window.onload イベントなどの指標は、現在のページがいつ読み込まれるかを判断する場合に役立ちます
が技術的に完了したものの、必ずしもそのページにおけるユーザーの体験に対応しているわけではありません。要素のレンダリングで若干の遅延が発生する
これらの指標のいずれかで考慮されますが、現実世界のユーザーにはまったく検出されない可能性があります。
LCP が長いと、ユーザーのページ（現在のビューポート内で最も重要なコンテンツ）の第一印象が変わります。
発生しません
LCP によって捕捉されるユーザーの認識は、ユーザー エクスペリエンスに直接影響します。昨年 Vodafone が実施したテスト は、LCP が 31% 改善したことで売上が 8% 増加（それだけでも大きな成果）につながるだけでなく、総ユーザー数に占める割合は 見込み顧客になった訪問者の数（「見込み顧客から見込み顧客の割合」）、ユーザー数が 11% 向上 （「カートから訪問率」）。
ウェブページの 70% 以上で、最初のページの最大要素が
ビューポートには、独立した <img> 要素、または背景画像を持つ要素として、画像が関係します。つまり
ページの 70%LCP スコアは画像のパフォーマンスに基づいています。なぜなら、それほど想像力は必要ありません。大きな、注目を集める
スクロールせずに見える範囲に
配置される可能性が非常に高いです
LCP による遅延を回避するには、まず、loading="lazy" を「スクロールせずに見える範囲」で指定しないようにします。画像、
ページのレンダリングが完了するまでリクエストを遅らせると、LCP スコアに著しく悪影響が及ぶ可能性があります。
次に、fetchpriority="high" を使用して、この画像の転送がページ上の他の画像よりも優先されるようにブラウザに通知できます。
これらのルールを正直に念頭に置き、ページの LCP スコアを向上させるために最も重要なことは、 転送とレンダリングにかかった時間ですそのためには、画像ソースを可能な限り小さく、効率的に その品質を犠牲にすることなく可能な限り ブラウジング環境に適したものになります
まとめ
画像アセットは（帯域幅）- 必要な他のすべてのアセットの転送から解放される帯域幅。 渡します。画像が、周囲のページの視聴中と再生後に、認識されるパフォーマンスの面で重大な問題を引き起こす レンダリングされました。つまり、画像アセットにはダメージを与えるということです。
大変なことかもしれませんが、「ウェブは画像の数が少ない方がよい」パフォーマンスのみで言えば間違いありませんが ユーザーに多大な失望を 与えることになります画像はウェブに不可欠な要素です。画像の自由度を高く保ち、 コンテンツを作成することです
このコースの残りの部分では、Google の画像アセットに使用されているテクノロジーと、画像アセットと 品質を損なうことなく、パフォーマンスに悪影響を及ぼしません。