Core Web Vitals のための画像最適化

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

Arjen Karel - linkedin

Last update: 2026-03-27

画像は 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 の画像要素を最適化する

画像を最適化する際にまず確認すべきことは、すべての画像の HTML コードです。画像はシンプルであり、ブラウザはシンプルなタスクを得意としています。そのため、トリックやクレバーなソリューションは避け、プレーンな HTML の画像タグ <img> を使用し、画像を高速化するために利用可能なすべてのオプションを活用しましょう！

Src 属性

画像の URL を指定します。このプロパティは、ブラウザに画像の場所を伝えるため、不可欠です。

Width と height 属性

画像の幅と高さをピクセル単位で指定します。これらのプロパティは、画像コンテナのサイズと画像がその中にどのように収まるかを定義するため、ページ上で画像を正しくレンダリングするために重要です。

Alt 属性

画像が表示できない場合の代替テキストを指定します。これはアクセシビリティの観点で重要であり、視覚障害のあるユーザーが画像の内容を理解するのに役立ちます。また、検索エンジンが画像の内容を理解するために alt テキストを使用するため、 SEO の観点でも重要です。

Loading 属性（lazy loading）

ブラウザが画像をどのように読み込むかを指定します（lazy、eager、または auto）。このプロパティはページパフォーマンスの向上に重要であり、画像を非同期で必要なときにのみ読み込むことを可能にします。

Srcset 属性

画像ソースとそのサイズのカンマ区切りリストを指定し、ブラウザがデバイスの画面サイズと解像度に基づいて最適な画像ソースを選択できるようにします。このプロパティはレスポンシブデザインに重要であり、デバイスに関係なくユーザーが最高の画像品質を得られることを保証します。

Sizes 属性

ビューポートサイズに基づいて使用する画像ソースのサイズを指定します。このプロパティは srcset と連携して、異なるデバイスや画面サイズで正しい画像サイズが読み込まれるようにし、ページ全体のパフォーマンスを向上させます。

Decoding 属性

ブラウザが画像をどのようにデコードするかを指定します（async、sync、または auto）。このプロパティもページパフォーマンスの向上に重要であり、ブラウザが残りのページのレンダリングよりも画像のデコードを優先または後回しにすることを可能にします。

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 する

LCP 要素の lazy loading は常に避けるべきです。LCP 要素を lazy load する場合、JavaScript ベースの lazy loading は特にページスピードに悪影響を与えます！JavaScript ベースの lazy loading は、スクリプトが <img> タグを書き換えることに依存しています。通常、img には data-src 属性があり、 JavaScript によって src 属性に書き換えられます。これには2つの問題があります

1. ブラウザのプリロードスキャナーは data-src 属性を認識しないため、要素の早期ダウンロードをプロアクティブにトリガーしません。

2. JavaScript ベースの lazy loading は、JavaScript が読み込まれて実行されるのを待つ必要があります。これは通常、レンダリングプロセスの比較的遅い段階で発生します。これにより、画像のさらなる遅延が生じます。

この問題を完全に回避するために、LCP 要素は常に eager load されるようにしましょう。'eager' はすべての画像のデフォルトであるため、画像が lazy load されていないことを確認するだけで十分です。ネイティブの 'loading="lazy" 属性' を削除するか、最適化プラグインを使用している場合は、画像の lazy loading をスキップする方法についてドキュメントを確認してください！

高い fetchpriority を使用する

何らかの理由で LCP 要素をプリロードできない場合は、少なくとも要素の fetchpriority 属性を high に設定してください。これにより、ブラウザに画像がページにとって重要であることを伝え、ブラウザは高い優先度でダウンロードを行います。fetchpriority="high" の使用は通常、画像のプリロードほど効率的ではないことに注意してください！

JavaScript ベースの lazy loading を避ける

1. ブラウザのプリロードスキャナーは data-src 属性を認識しないため、要素の早期ダウンロードをプロアクティブにトリガーしません。

ステップ3：画像ができるだけ速くダウンロードされるようにする

3番目にすべきことは、本来あるべきサイズより大きい画像に貴重なネットワークリソースを無駄にしていないか確認することです。レスポンシブ画像の使用、圧縮の適用、そして新しくより高速な画像フォーマットの使用によりこれを実現できます

レスポンシブ画像

LCP に関する最も一般的な問題の1つは、1920x1200px のフルサイズのデスクトップ「ヒーロー画像」を、約 360x225 で画像をレンダリングするモバイルデバイスに送信することです。これは画像が本来あるべきサイズの約28倍大きいことを意味します（もちろん、高い DPI で画像を送信することもできますが、その場合でもフルサイズの画像は7倍大きくなります）！

そこでレスポンシブ画像の出番です！レスポンシブ画像は、異なるビューポートに異なるバージョンの画像を送信します。これにより、モバイルブラウザには小さい画像を、タブレットにはやや大きい画像を、デスクトップにはフルサイズの画像を送信し、不要なバイトが送信されないようにできます！

画像圧縮

画像圧縮を使用すると、視覚的な品質をほぼ維持しながらファイルサイズを削減できます。冗長または不要なデータを排除するさまざまな技術が含まれます。最新の CMS システムの多くは、画像がライブラリにアップロードされる際に画像圧縮を適用します。ただし、ライブラリをバイパスしたり、独自のカスタムソリューションを使用したりする場合は、画像が適切な圧縮レベルであることを常に確認してください！

新しくより高速な画像フォーマット

画像はウェブページ上で最もサイズの大きいリソースの1つであることが多く、最適化されていない場合、ページの読み込み速度を大幅に低下させる可能性があります。WebP や AVIF フォーマットなどの新しくより高速な画像フォーマットは、品質を犠牲にすることなく画像のファイルサイズを削減するのに役立ちます。これにより、より迅速に読み込むことができ、ページの読み込み速度を改善できます。

ステップ4：レイアウトシフトを排除する！

読み込み中にサイズが変わる画像はレイアウトシフトを引き起こします。それほどシンプルなことです。画像がレイアウトシフトを引き起こす主な理由は3つあります（実際にはもっと多くの理由がありますが、これらの3つが最も一般的です）

1. 画像サイズの未指定

画像サイズとは、画像の width 属性と height 属性のことです。width または height 属性が設定されていない場合、ブラウザはレンダリング中に画像のためにどれだけのスペースを確保すべきか分からず、未指定の寸法に対して0ピクセルを確保します。

つまり、width と height が設定されていない画像は 0x0ピクセルでレンダリングされ、画像が読み込まれてデコードされた後、ブラウザは画像に正しいスペースを使用するためにレイアウトを再計算します。

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 を組み合わせることで、通常の画像を背景画像のように動作させることができます！