Core Web Vitals のための画像最適化
画像が Core Web Vitals にどう影響するか、そしてその最適化方法を学ぶ

画像は Core Web Vitals にどのような影響を与えるのか?
画像はウェブサイトの視覚的な魅力を高める上で重要な役割を果たしますが、読み込み速度にも大きな 影響を与える可能性があります。Core Web Vitals は、Google がウェブサイトの user experience を測定するために使用する 一連の指標であり、画像の最適化は良いスコアを達成するための重要な 要素です。この記事では、Core Web Vitals のために画像を最適化し、ウェブサイトの読み込み速度を改善する 方法について説明します。
Core Web Vitals を理解する

画像の最適化について詳しく説明する前に、Core Web Vitals について簡単に確認しましょう。これらはウェブページの読み込み速度、 インタラクティブ性、視覚的安定性を測定するユーザー中心の指標です。3つの主要な指標は以下の通りです:
Largest Contentful Paint (LCP):ページ上で最も大きな要素の読み込み速度を測定します。
First Input Delay (FID): ページがインタラクティブになるまでの 時間を測定します。
Cumulative Layout Shift (CLS):ページの視覚的安定性を測定します。
画像はどの Core Web Vitals に影響するのか?
画像がすべての Core Web Vitals に影響を与えうることを知ると驚くかもしれません。画像が レンダリング中の遅いタイミングでダウンロードキューに入れられた場合や、単純にサイズが大きすぎる場合、通常は高い LCP スコアにつながります。画像のサイズが設定されていない場合や、読み込みフェーズ中に変更される場合、CLS スコアにも影響を与える可能性があります。 そして最後に、画像のデコードがメインスレッドの作業を占有しすぎると、INP にも影響を与える可能性があります。詳しく 見ていきましょう:
Largest Contentful Paint
Core Web Vitals の1つである Largest Contentful Paint (LCP) は、ページ上で最も大きな 要素(画像や動画など)がユーザーに 表示されるまでの時間を測定します。画像のキューイングが遅すぎたり、読み込みに時間がかかりすぎると、ページの LCP スコアが大幅に 低下する可能性があります。
Cumulative Layout Shift
もう1つの Core Web Vital は Cumulative Layout Shift (CLS) で、ページの読み込み中にコンテンツが どれだけ移動するかを測定します。画像が 適切なサイズに設定されていない場合や、ページの読み込み後に挿入された場合、他の要素が 移動し、レイアウトシフトが発生する可能性があります。
First Input Delay と INP
最後に、画像は3つ目の Core Web Vital である INP にも影響を与える可能性があります。これはユーザーがページを操作してから 視覚的に応答するまでの時間を測定します。デコードが必要な 大きな画像が多すぎると、ページがユーザーの操作に応答するまでに時間がかかり、 INP スコアが悪化する可能性があります。
ステップ1:速度のために HTML の画像要素を最適化する

Src 属性
画像の URL を指定します。このプロパティは、ブラウザに画像の場所を伝えるため、不可欠です。
Width と height 属性
画像の幅と高さをピクセル単位で指定します。これらのプロパティは、画像コンテナのサイズと 画像がその中にどのように収まるかを定義するため、ページ上で画像を正しく レンダリングするために重要です。
Alt 属性
画像が表示できない場合の代替テキストを指定します。これはアクセシビリティの観点で重要であり、 視覚障害のあるユーザーが画像の内容を 理解するのに役立ちます。また、検索エンジンが画像の内容を理解するために alt テキストを使用するため、 SEO の観点でも重要です。
Loading 属性(lazy loading)
ブラウザが画像をどのように読み込むかを指定します(lazy、eager、または auto)。このプロパティは ページパフォーマンスの向上に重要であり、画像を 非同期で必要なときにのみ読み込むことを可能にします。
Srcset 属性
Sizes 属性
Decoding 属性
Fetchpriority 属性
fetchpriority 属性は、ページ上の他のリソースに対するリソースのフェッチ優先度を指定します。 priority 属性には3つの値のいずれかを設定できます: "high"、"medium"、または "low"。高い優先度のリソースは、中程度または低い 優先度のリソースよりも先に読み込まれます。中程度の優先度のリソースは、 低い優先度のリソースよりも先に読み込まれます。同じ優先度のリソースは、 HTML に出現する順序で読み込まれます。
ステップ2:画像ができるだけ早くダウンロードキューに入るようにする
HTML を最適化した後の次のステップは、画像のスケジューリングを確認することです。多くの場合、 LCP 指標に関して画像の最大のボトルネックは、スケジューリングの遅延です。ブラウザがレンダリングプロセスの早い段階で LCP 要素をダウンロードする機会があれば、画像はできるだけ早くブラウザに利用可能になり、 ブラウザはレンダリングプロセスの早い段階でその要素の描画を開始できます。
シンプルですよね?では、画像をできるだけ早くダウンロードキューに入れるにはどうすればよいでしょうか。
LCP 要素をプリロードする
早期ダウンロードを確実にする最も効果的な方法は、画像をプリロードすることです。画像のプリロードは、 <head> 要素の先頭にシンプルなタグを追加するだけで実現できます。例:
<link rel="preload" as="image" href="image.jpg"> このシンプルなタグは、まもなく "image.jpg" が必要になることをブラウザに伝え、ブラウザは 即座にこのファイルのダウンロードを開始します。
LCP 要素を eager load する
高い fetchpriority を使用する
何らかの理由で LCP 要素をプリロードできない場合は、少なくとも要素の fetchpriority 属性を high に設定してください。これにより、ブラウザに画像がページにとって重要であることを伝え、ブラウザは 高い優先度でダウンロードを行います。fetchpriority="high" の使用は通常、 画像のプリロードほど効率的ではないことに注意してください!
JavaScript ベースの lazy loading を避ける
ステップ3:画像ができるだけ速くダウンロードされるようにする
3番目にすべきことは、本来あるべきサイズより大きい画像に貴重なネットワークリソースを無駄にしていないか確認することです。 レスポンシブ画像の使用、圧縮の適用、そして新しくより高速な画像フォーマットの使用によりこれを実現できます
レスポンシブ画像
画像圧縮
新しくより高速な画像フォーマット

画像はウェブページ上で最もサイズの大きいリソースの1つであることが多く、最適化されていない場合、 ページの読み込み速度を大幅に低下させる可能性があります。WebP や AVIF フォーマットなどの新しくより高速な 画像フォーマットは、品質を犠牲にすることなく画像のファイルサイズを削減するのに役立ちます。これにより、 より迅速に読み込むことができ、ページの読み込み速度を改善できます。
ステップ4:レイアウトシフトを排除する!
読み込み中にサイズが変わる画像はレイアウトシフトを引き起こします。それほどシンプルなことです。 画像がレイアウトシフトを引き起こす主な理由は3つあります(実際にはもっと多くの理由がありますが、 これらの3つが最も一般的です)
1. 画像サイズの未指定
2. スタイリングの問題
通常、画像がビューポートより大きくならないようにするために、シンプルな CSS のテクニックが使われます
img{
max-width:100%; height:auto;
} これは優れたテクニックであり、使用すべきです。しかし残念ながら、レイアウトシフトを引き起こす このテクニックのバリエーションを頻繁に見かけます。例えば、 width:auto を追加する場合:
img{
max-width:100%; height:auto;
width:auto;
} これにより、すべての画像が auto の width と height でレンダリングされます。これは通常、画像がダウンロードされる前にブラウザが 画像を 0x0px でレンダリングすることを意味します
3. プレースホルダー
一部の JavaScript ベースの lazy loading スクリプトはプレースホルダーを使用します。前述の max-width:100% と height:auto のような CSS テクニックを使用している場合、正方形のプレースホルダーの auto height は 画像の height 属性と一致しません。基本的に、画像はまず正方形のプレースホルダーで 720x720 でレンダリングされ、 最終的な画像がダウンロードされると 720x180 でレンダリングされます
<img
src="1x1placeholder.png"
data-src="hero.png"
width="720"
height="180"
style="height:auto;max-width:100%"
> ステップ5:メインスレッドを保護する
次に確認すべきことは、同時に多くの画像がメインスレッドでデコードされないようにすることです。 通常これは問題になりませんが、商品一覧ページ(時には 500枚もの画像がリソースを奪い合うことがあります!)で何度も見かけたことがあります。
コツは、すべての画像に decoding="async" を追加して、これらの画像が別の スレッドでデコードされるようにすることです。また、ファーストビュー外および非表示の画像に loading="lazy" を追加して、 これほど多くの画像が一度にデコードされることを避けるようにしましょう。
ステップ6:各画像に適切な戦略を選択する!
LCP 要素の画像戦略
LCP 要素は通常、最も重要なビジュアル要素です。そのため、これを本当に優先する必要があります。"
- ページの head の早い段階で次の コードを使用して画像をプリロードします:
<link rel="preload" as="image" href="path-to-img.png"> loading="eager"を設定するか loading 属性を省略して、この画像を lazy load しないようブラウザに伝えますfetchpriority="high"を使用して、 この画像を高い優先度でダウンロードするようブラウザにヒントを与えます(画像をプリロードしている場合、この部分はスキップできます)- この要素は非常に重要であるため、メインスレッドでデコードしたいので
decoding="sync"を設定します
ロゴやその他の表示領域内(非 LCP)画像の画像戦略
表示領域内の画像はページ読み込み中にかなり早くロードされるべきですが、できれば LCP 要素の後にロードされるべきです。 LCP 要素をプリロードすることで、これらの表示領域内の画像に自然で正しいダウンロード順序を 与えることができます。
loading="eager"を設定するか loading 属性を省略して、この画像を lazy load しないようブラウザに伝えます- この要素はメインスレッド外で安全にデコードできるため、
decoding="async"を設定します!
ファーストビュー外の画像の画像戦略
ファーストビュー外のすべての画像は lazy load されるべきです。それほどシンプルです!例外はありません!
loading="lazy"を設定して、 この画像を lazy load するようブラウザに伝えます- この要素はメインスレッド外で安全にデコードできるため、
decoding="async"を設定します!
背景画像を避ける
背景画像を使用している場合は、再検討が必要です。背景画像は lazy load できず、 decoding プロパティを制御できず、fetchpriority も設定できません。背景画像は通常 レスポンシブではないため、多くの帯域幅を消費する可能性があります。しかし最も重要なのは、背景画像は通常 ブラウザが CSS ファイルをダウンロードした後に発見されることです。これは画像のダウンロードをトリガーする 適切なタイミングであることはほとんどありません!
通常の画像タグと CSS の object-fit:cover を組み合わせることで、通常の画像を 背景画像のように動作させることができます!
Make decisions with Data.
You cannot optimize what you do not measure. Install the CoreDash pixel and capture 100% of user experiences.
- 100% Capture
- Data Driven
- Easy Install

