【HTML】imgタグがCore Web Vitalsに与える影響と計測方法

はじめに

こんにちは、株式会社TOKOSのユウマです。
今回は、HTMLのimgタグがCore Web Vitalsにどのような影響を与えるのかを解説します。
また、Chrome DevToolsを使った計測と改善の方法も併せて紹介します。

対象読者

• HTMLのimgタグがパフォーマンスへ与える影響を知りたい方
• Core Web Vitalsの改善方法を具体的に学びたい方

Core Web Vitalsとは

Core Web Vitalsは、Googleがウェブページのユーザー体験を測定するために定めた指標のセットです。
公式ドキュメントでは、次のように定義されています。

ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標です。

ページの使い心地を以下の3つの観点で数値化したものと言えます。

Core Web Vitalsが重要な理由

Core Web Vitalsが重要な理由は2つあります。

1つ目はUX（ユーザー体験）の向上です。
読み込みが遅かったり表示がずれたりするページは、ユーザーにストレスを与えます。
Core Web Vitalsを改善することは、UX（ユーザー体験）が良くなることに直結します。

2つ目はSEO（検索エンジン最適化）への影響です。
SEOとは、検索結果で自分のサイトをより上位に表示させるための取り組みのことです。
GoogleはCore Web Vitalsを検索順位の判断材料の1つにしていますが、その影響はそれほど大きくありません。

Core Web Vitals と Google 検索（Google Search Central）

Core Web Vitals は、実際のユーザー エクスペリエンスを測定する一連の指標です。Google 検索と Core Web Vitals の詳細をご確認ください。

developers.google.com

3つの指標

Core Web Vitalsは、LCP・INP・CLSの3つの指標で構成されています。
それぞれLargest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shiftの略です。

ユウマ

ビューポートとは、ブラウザのウィンドウに現在表示されている領域のことです。
スマホなら画面全体、PCならウィンドウ内の表示エリアにあたります。

Web Vitals：LCP・INP・CLS の詳細解説（Google web.dev）

サイトの健全性を示す基本的な指標

web.dev

画像とCore Web Vitalsの関係

ページの表示速度は、表示するデータ量に大きく左右されます。
LCPの対象になる要素の多くは画像であり、画像の読み込みが表示速度のボトルネックになりやすいです。
そのため、画像の扱い方はページのパフォーマンスを左右する重要なポイントになります。

画像のデータ量そのものを減らすアプローチ（圧縮や次世代フォーマットの採用）もありますが、本記事ではHTMLのimgタグの書き方による改善に焦点を当てます。
属性を適切に指定するだけでも、LCPやCLSは改善できます。

ユウマ

画像のデータ量そのものを減らすアプローチについては、補足情報で簡単に触れています😎

画像が関わる指標：LCPとCLS

Core Web Vitalsの3つの指標のうち、画像と深く関わるのはLCPとCLSの2つです。
INP（応答速度）はユーザー操作への反応を測る指標であり、画像の読み込みとは直接関係しません。

LCPは、ビューポート内でもっとも大きいコンテンツが表示されるまでの時間を測ります。
ページのメインビジュアルのような大きな画像はLCPの対象になりやすく、データ量が大きかったり読み込み開始が遅れたりするとスコアが悪化します。

CLSは、ページ表示中に発生するレイアウトシフトを数値化する指標です。
レイアウトシフトとは、すでに表示されていた要素の位置が後から変わってしまう現象のことです。イメージしやすいよう、後述の動画で具体例も確認できます。

たとえば画像の表示サイズが読み込み前に確定していないと、画像の表示と同時に周囲のコンテンツが押し下げられ、レイアウトシフトが発生してCLSが悪化します。

CLSのスコアは、要素が「どれだけの範囲に」「どれだけの距離」ずれたかで算出されます。

レイアウトシフトスコア ＝ 影響率 × 距離率

• 影響率: ずれた要素が移動前と移動後に占める領域の和集合 ÷ ビューポートの面積
• 距離率: 要素が移動した距離 ÷ ビューポートの長辺の長さ

たとえば、ビューポートの50%を占める要素が高さの25%分だけ下にずれた場合を考えます。
移動前（上半分）と移動後（25%下にずれた位置）を合わせた領域はビューポートの75%になるため、影響率は0.75です。
距離率は0.25なので、スコアは0.75 × 0.25 = 0.1875となります。

まずはimgタグの属性を理解する

改善方法を説明する前に、土台となるimgタグの属性を整理しておきます。
ここで取り上げるのは、loading・width/height・fetchpriorityの3つです。
いずれも前章で見たLCPとCLSに関わる属性で、このあとの改善はこれらの指定がベースになります。

loading属性

loading属性は、画像をいつ読み込むかをブラウザに伝えます。

<!-- デフォルト（eagerと同じ動作） -->
<img src="hero.jpg" alt="メインビジュアル" />
 
<!-- 遅延読み込み -->
<img src="gallery.jpg" alt="ギャラリー" loading="lazy" />

loading="lazy"を付けると、画面外の画像は初期リクエストに含まれなくなります。
ユーザーがスクロールして画像に近づいたタイミングで読み込みが始まります。

width・height属性

widthとheightは、画像の幅と高さをブラウザに伝える属性です。
ブラウザはこの値からアスペクト比（縦横の比率）を計算し、画像の読み込み前にスペースを確保します。

<img src="photo.jpg" alt="写真" width="1600" height="1200" />

widthとheightには、画像ファイルの幅と高さをそのまま書きます。

たとえば1600×1200の画像なら、width="800"height="600"やwidth="4"height="3"と書いても縦横比は同じになります。ブラウザはこの比率だけを見ているため数値自体はどれでも構いませんが、実際のファイル寸法（width="1600"height="1200"）をそのまま書いておくのが確実です。
CSSで表示サイズを変えるときも、HTMLのwidth/heightは実際の寸法のままにしておきます。
そのうえで、見た目のサイズはmax-width: 100%やheight: autoで調整するのが一般的な書き方です。
縦横比はCSSのaspect-ratioプロパティでも指定できます。ただ、HTMLはwidth/heightだけで済み、CSSの読み込みを待たずにブラウザが表示スペースを確保できます。そのため、まずはwidth/heightを指定しておくのが基本です。

ただし、width/heightでできるのは、あくまで1枚の画像の表示スペースを確保することだけです。
画面サイズや解像度に応じて画像ファイル自体を切り替えるには、srcset/sizes属性を使います。これらは、表示環境に合わせて最適な画像を出し分けるための属性です（詳しくは補足情報で触れます）。

fetchpriority属性

fetchpriority属性は、リソースを読み込む優先度をブラウザに伝える属性です。
特にimgタグでは、LCPの対象となるファーストビュー画像の読み込み開始を早められます。

ファーストビューとは、ページを開いてスクロールする前に見えている範囲のことです。
下の動画で、ファーストビューとスクロールしないと見えない領域の違いを確認できます。

省略した場合はautoになります。

<!-- LCP候補のメインビジュアル -->
<img src="hero.jpg" alt="メインビジュアル" width="1600" height="1200" fetchpriority="high" />

loading属性と似ているように見えますが、役割が異なります。
loading属性は「いつ読み込むか」を、fetchpriority属性は「読み込みの優先度」をブラウザに伝えます。

なお、fetchpriority属性は比較的新しい属性ですが、対応していないブラウザでは単に無視されるため、安全に導入できます。

fetchpriority 属性の解説（Google web.dev）

Fetch Priority API は、ブラウザに対するリソースの相対的な優先度を示します。これにより、読み込みを最適化し、ウェブに関する主な指標を改善できます。

web.dev

ユウマ

属性の指定は簡単ですが、付け忘れるとCore Web Vitalsに影響します。次のセクションで具体的に見ていきましょう。

imgタグ使用時のCore Web Vitalsの問題点

imgタグの書き方によって、Core Web Vitalsがどのように悪化するかを確認します。

問題のあるコード例

以下は、width・height・loading・fetchpriorityのいずれも指定していない例です。

<img src="photo.jpg" alt="写真" />

このコードには3つの問題があります。

問題点1: CLSの悪化（width・heightの未指定）

widthとheightがないと、ブラウザは画像の読み込みが完了するまでサイズを把握できません。
読み込みが完了した瞬間にスペースが確保され、周囲のコンテンツが押し下げられます。
これがレイアウトシフトです。テキストを読んでいる途中で画像が読み込まれ、内容が下にずれる様子を確認できます。

問題点2: LCPの悪化（loading属性の最適化不足）

loading属性を指定しないと、画面外の画像も含めてすべての画像が、最初のリクエストでまとめて読み込まれます。

たとえば画像が10枚あるページで、ファーストビューに2枚しか見えていなくても、残り8枚を含めた10枚すべてのダウンロードが最初から一斉に始まります。
ここで問題になるのが、回線で一度に運べるデータ量には限りがあるという点です。

1本の道路を一度に通れる車の数が決まっているのと同じで、画面外の画像まで一度に取得しようとすると道が混み合います。

その結果、本来すぐに表示したいファーストビューの画像が優先されず、読み込みが遅れてLCPスコアが悪化します。
このようにダウンロードする画像が増えると、リクエスト数（ブラウザがサーバーに画像を取りにいく回数）と転送量（ダウンロードされる画像データの合計サイズ）が増えていきます。これらの指標は、あとのDevToolsでの計測で確認していきます。

逆に、ファーストビューの画像にloading="lazy"を付けてしまうとブラウザが「まだ見えていないので後回しにしてよい」と判断し、表示が遅くなります。
ページのメインビジュアルのような大きな画像はLCPの対象になりやすく、loading="lazy"を付けることで読み込みが遅れ、LCPスコアが悪化します。

問題点3: LCPの悪化（fetchpriority属性の未指定）

画像にはデフォルトで「低」の優先度が割り当てられます。
ブラウザはレイアウト計算のあとにビューポート内の画像を検出し、そこで優先度を「高」に引き上げる仕組みです。

そのため、loading="eager"を指定した画像でも、レイアウト計算の完了を待つ分読み込みが遅れがちです。
LCPの対象となるファーストビュー画像ほど、この遅れが表示速度に影響します。

fetchpriority="high"を付与すると、ブラウザは最初から高い優先度で画像を取得します。
レイアウト計算の完了を待たずに読み込みが始まるため、LCPの改善に直接つながります。

使い分けの目安はシンプルです。

• ファーストビューのLCP候補画像 → loading="eager"（または省略）＋ fetchpriority="high"
• 画面外の画像 → loading="lazy"

DevToolsを使った計測と改善方法

Chrome DevToolsを使い、imgタグの属性がCore Web Vitalsにどう影響するかを確認します。
本記事ではCLSスコア、loading属性の効果を示す転送量・リクエスト数の変化、fetchpriority属性の効果を示す読み込み優先度の3つを計測します。

DevToolsの準備

1. Chromeで対象ページを開き、開発者ツール（F12）を開く
2. PerformanceタブでDisable cacheにチェック（比較条件を揃えるため）
3. PerformanceのスロットリングでSlow 3Gを選択

スロットリングとは、DevTools上で通信速度を意図的に遅くし低速な回線環境を再現する機能です。
Slow 3Gを選ぶと、低速回線での読み込みを疑似体験できます。

下記のように設定できていれば準備完了です。

CLSの改善（レイアウトシフトの計測）

Performanceタブを開き、記録（Record）を開始してからページを再読み込みします。
読み込みが落ち着いたら記録を停止し、CLSの値を確認します。

width・heightがない場合

レイアウトシフトが発生し、CLSスコアが0.08になっています。
0.08は「良好」（0.1以下）の範囲内ですが、画像の枚数や表示サイズ、回線速度などの条件によってはこの値が0.1を超え、基準を下回るリスクがあります。
width/heightを指定することで、こうした条件に左右されずレイアウトシフトを未然に防げます。

width・heightがある場合

アスペクト比に沿った領域が事前に確保されるため、レイアウトシフトは発生せず0になっています。

改善方法

画像のファイル寸法に合わせてwidthとheightを指定します。

<img src="photo.jpg" alt="写真" width="1600" height="1200" />

widthとheightを付与した結果、レイアウトシフトが解消されました。

LCPの改善（転送量・リクエスト数の計測）

Networkタブを開き、Imgフィルタを選択します。
画像のリクエスト件数（requests）と転送量（transferred）を確認します。

loading="lazy"がない場合

初期リクエストでページ内のすべての画像が読み込まれています。

loading="lazy"がある場合

画面外の画像はまだリクエストされていないため、リクエスト数と転送量が減少しています。
スクロールすると、画像に近づいたタイミングでリクエストが発生します。

スクロールに応じてリクエスト数と転送量が増えていくのが確認できます。
ユーザーがページ下部までスクロールした場合、最終的な合計転送量は同じになります。
差が出るのは初期読み込みのタイミングです。

改善方法

画面外の画像にloading="lazy"を付与し、ファーストビューの画像にはloading="eager"（または省略）を使います。

<!-- ファーストビュー -->
<img src="hero.jpg" alt="メインビジュアル" width="1600" height="1200" loading="eager" />
 
<!-- 画面外 -->
<img src="gallery.jpg" alt="ギャラリー" width="1200" height="800" loading="lazy" />

LCPの改善（読み込み優先度の計測）

NetworkタブのPriority列で、各リソースの読み込み優先度を確認できます。
Priority列はデフォルトでは非表示のため、列ヘッダーを右クリックして表示されるメニューからPriorityを選び、有効化します。

有効化すると、各画像がHigh/Lowどちらの優先度で読み込まれているかを一覧で確認できます。

fetchpriority="high"がない場合

LCP候補のファーストビュー画像（Typeがjpegの最初の行、240kB）はHighになっていますが、表示時間（Time）は741msかかっています。
これは、ブラウザが最初はLowでリクエストを開始し、レイアウト計算のあとにビューポート内の画像を検出してHighへ引き上げているためです。
優先度が引き上げられるまでの待ち時間分、取得開始が遅れます。

fetchpriority="high"がある場合

ファーストビュー画像にfetchpriority="high"を付与すると、リクエストが最初からHighで開始されます。
レイアウト計算の完了を待たないため、同じ画像の表示時間が436msに短縮されました。

改善方法

LCPの候補となるファーストビュー画像にfetchpriority="high"を付与します。

<img src="hero.jpg" alt="メインビジュアル" width="1600" height="1200" fetchpriority="high" />

改善後のコード

これまでの内容をまとめると、最終的な書き方は以下のパターンが基本になります。

<!-- ファーストビューの画像（LCP候補） -->
<img src="hero.jpg" alt="メインビジュアル" width="1600" height="1200" loading="eager" fetchpriority="high" />
 
<!-- 画面外の画像 -->
<img src="gallery.jpg" alt="ギャラリー写真" width="1200" height="800" loading="lazy" />

img {
  max-width: 100%;
  height: auto;
}

CSSのmax-width: 100%とheight: autoにより、画面幅に応じてレスポンシブに表示されます。
HTMLのwidth/heightはアスペクト比の伝達に使われるため、表示崩れは起きません。

ユウマ

Before/Afterを数値で比較すると、改善の効果が実感できます。ぜひ皆さんのサイトでも試してみてください。

補足情報

本記事では3属性の指定を中心に解説しましたが、画像のパフォーマンス改善には、あわせて知っておくと役立つ情報もあります。

• レスポンシブ画像: srcset/sizes属性や<picture>要素で、画面サイズや解像度に応じて画像を出し分ける。なおloading="lazy"の画像にsizes="auto"を指定すると、ブラウザが実際の表示幅から最適なソースを自動で選び、sizesの手動指定が不要になります。Chrome 126以降、Firefox 150〈2026年4月〉でサポートされています。
• 画像フォーマットの最適化: WebP/AVIFなどの次世代フォーマットを採用し、ファイルサイズを削減する
• フレームワークによる自動化: Next.jsのnext/imageなどのコンポーネントは、loading・width/height・fetchpriorityの指定やsrcsetの生成を自動で行う

遅延読み込み画像の sizes="auto" 対応（Google web.dev）

2026 年 4 月に安定版とベータ版のウェブブラウザに導入された興味深い機能をご紹介します。

web.dev

レスポンシブ画像とWebPの具体的な使い方については、以下の記事で詳しく解説しています。

WebP！srcset！picture！Retina対応！HTMLで画像を最適化して表示する

HTMLで画像を最適化して表示する方法を解説。WebPフォーマットの活用、srcset属性によるレスポンシブイメージ、pictureタグでのRetina対応など、画像の最適化テクニックを紹介します。

また、本記事ではPerformanceタブとNetworkタブで個別の指標を計測しましたが、Lighthouseを使うとCore Web Vitals全体のスコアをまとめて確認できます。
属性以外の要因も含めて改善ポイントを洗い出したいときに便利です。

使い方は簡単で、DevToolsのLighthouseタブを開き、対象カテゴリ（Performanceなど）を選んで「Analyze page load」ボタンを押すだけです。

数十秒待つとレポートが生成され、LCP・CLSのスコアと具体的な改善提案が一覧表示されます。

おわりに

この記事では、imgタグがCore Web Vitalsに与える影響と、DevToolsを使った計測・改善方法を紹介しました。

• Core Web VitalsはUXとSEOの両面で重要な指標
• width/heightの指定でCLSを防止し、レイアウトの安定性を確保できる
• loading属性の適切な使い分けで、初期読み込みを軽量化しLCPを最適化できる
• fetchpriority="high"でLCP候補画像の取得優先度を引き上げ、表示開始を早められる
• DevToolsのPerformanceタブでCLS、Networkタブで転送量や優先度を確認できる

属性を1つ追加するだけでもCore Web Vitalsの数値は変わります。
ぜひ皆さんのサイトでも計測しながら、少しずつ改善を進めてみてください。