Appearance
img タグの書き方 — アクセシビリティと Core Web Vitals
今日のゴール
- 画像の書き方はアクセシビリティと Core Web Vitals の両方に直結すると知る
- alt は画像の役割にあわせて書くことを知る
- Core Web Vitals(CWV)というユーザー体験の指標があることを知る
- 画像が届く前に場所を確定させれば CLS を防げることを知る
loading="lazy"の使いどころを知る
画像の書き方は 2 つの観点に直結する
Web ページで画像はよく使われますが、書き方によって体験が大きく変わります。特に次の 2 つの観点に影響します。
- アクセシビリティ: 画像を見られない人にも情報を届けられるか
- Core Web Vitals: ページの表示速度やレイアウトの安定性
観点1: アクセシビリティ — alt 属性
alt は画像を見られないユーザーに情報を届けるための属性です。スクリーンリーダーが読み上げたり、画像の読み込みに失敗したときに代わりに表示されたりします。
alt は画像の見た目ではなく、ページ上の役割にあわせて書きます。
同じ猫の写真でも、役割が違えば alt の内容は変わります。
- お気に入りの猫の写真 →
alt="ソファでくつろぐ猫" - 猫の写真一覧へのリンク →
alt="猫の写真一覧を見る" - 背景装飾 →
alt=""
こういうときどう書く?
ケース1: テキストが含まれた画像
ロゴやバナーなど、画像の中に読めるテキストがある → そのテキストを書くalt="Green Market"
ケース2: 見出し「本日のランチ: カレーライス」直後の写真
本日のランチ: カレーライス
周辺のテキストに同じ情報がある → alt="" で二重読み上げを防ぐ
ケース3: 月別来店者数のグラフ
複雑な画像は alt だけでは伝えきれない → 短い alt + 別途詳細を記載alt="月別来店者数のグラフ。詳細は下の表を参照"
ケース4: テキスト付きボタンの中のアイコン
ボタンのテキストで意味が伝わる → アイコンは装飾と同じ扱いで alt=""
ここで紹介したのは一部のパターンです。迷ったときは W3C の alt ディシジョンツリー が参考になります。
alt 属性は必ず書く
alt 属性自体を書き忘れると、スクリーンリーダーはファイル名(「image_001.jpg」など)を読み上げてしまいます。装飾画像でも alt="" と書いて、意図的に空であることを示しましょう。
AI で alt を生成するとき
AI に画像を渡して alt を生成させることもできます。ただし同じ画像でも役割によって適切な alt は変わるので、画像だけでなくページの文脈や用途もあわせて伝えましょう。
観点2: Core Web Vitals — 表示速度とレイアウトの安定性
Core Web Vitals(コア ウェブ バイタルズ、以下 CWV)は、Google が定めた ユーザー体験を数値で測るための指標です。Google 検索の順位にも影響するため、Web サイトの品質として重視されています。
CWV には 3 つの指標があります。
| 指標 | 意味 | 何が測られるか |
|---|---|---|
| LCP(Largest Contentful Paint) | 最大コンテンツ描画 | ページで一番大きな要素(画像や見出しなど)が表示されるまでの時間 |
| CLS(Cumulative Layout Shift) | 累積レイアウトシフト | ページ読み込み中に要素がどれだけ飛ぶか |
| INP(Interaction to Next Paint) | 応答性 | ユーザーの操作に対する画面の反応の速さ |
遅い(LCP)、動く(CLS)、反応しない(INP)— どれもユーザーがストレスを感じる要因です。
CWV の中でも LCP と CLS は画像に直結 します。画像はページの最大コンテンツになりやすく(LCP)、サイズ未指定だと読み込み時にレイアウトが動きます(CLS)。画像の属性を正しく書くだけで CWV は改善できます。
width と height — レイアウトシフトを防ぐ
サイズ未指定だと、読み込み前の画像の場所はゼロです。画像が届いた瞬間に場所が生まれ、下にあるコンテンツが押し下げられます。読んでいた文章が動いたり、押そうとしたボタンがずれたりする現象 — これが CLS(レイアウトシフト) です。
❌ サイズ未指定
この文章は画像読み込み後に押し下げられる
✅ サイズ指定あり
この文章は最初から正しい位置にある
防ぐ原則は 「画像が届く前に場所を確定させる」 こと。書き方は「どう表示したいか」で決まります。
固定サイズで表示したい
表示したい幅と高さをそのまま書きます。
html
<img src="photo.jpg" alt="風景写真" width="300" height="200" />画面幅に合わせて縮めたい
次の定番 CSS と width / height 属性をセットで使うと、画像が画面幅に合わせて縮み、縦横比を保ったまま CLS も防げます。
css
img {
max-width: 100%;
height: auto;
}この CSS があると、width と height の値は 縦横比の情報 として使われます。実画像と同じ縦横比の値を書けば、表示幅が縮んでも比率が保たれるので CLS は起きません。
html
<!-- 実画像 1600×1200(4:3)-->
<img src="photo.jpg" alt="風景写真" width="800" height="600" />表示枠の比率を揃えたい
CMS やユーザー投稿など、実画像のサイズが毎回違うケースです。属性に値を書けないので、代わりに 「表示枠として決めた比率」 を CSS で固定します。画像はその枠に合わせて切り抜かれます。
css
.card-image {
width: 100%;
aspect-ratio: 16 / 9; /* 表示枠の比率 */
object-fit: cover; /* 実画像を切り抜いて枠に収める */
}どの場合でも、画像が届く前に場所(または比率)が確定しているので CLS は起きません。
loading — 画面外の画像は遅延読み込み
loading="lazy" を指定すると、画像が画面に近づいたときに初めて読み込まれます。
html
<img src="photo.jpg" alt="..." loading="lazy" width="800" height="600" />ただし、ファーストビュー(スクロールせずに見える範囲)の画像には付けないのが鉄則です。ファーストビューの画像は LCP の対象になることが多く、遅延読み込みすると逆に遅くなります。
html
<!-- ❌ ファーストビューに lazy -->
<img src="hero.jpg" alt="..." loading="lazy" width="1200" height="600" />
<!-- ✅ ファーストビューは eager(または指定なし) -->
<img src="hero.jpg" alt="..." loading="eager" width="1200" height="600" />Lighthouse で確認してみる
今日紹介した内容が実際のページでどうなっているかは、Lighthouse で確認できます。Chrome DevTools の Lighthouse タブからページを測定すると、スコアと改善提案が表示されます。
Lighthouse が測定するのは CWV だけではありません。
- Performance: CWV を含むページの表示速度
- Accessibility: alt の不足、コントラスト比の不足など
- Best Practices: HTTPS、画像の適切なサイズなど
- SEO: メタデータ、クロール可能性など
今日のレッスンで言えば、alt の書き忘れは Accessibility、width / height の指定漏れは Performance で指摘されます。
URL を入力するだけで測定できる PageSpeed Insights もあります。
まとめ
- 画像の書き方はアクセシビリティとCore Web Vitalsの両方に直結する
altは画像の役割にあわせて書く。装飾画像はalt=""。迷ったら alt ディシジョンツリー- Core Web Vitals は Google がユーザー体験を数値化した 3 指標(LCP / CLS / INP)
- 画像が届く前に場所を確定させて CLS を防ぐ(
width/heightまたは CSSaspect-ratio) loading="lazy"で画面外の画像を遅延読み込み(ファーストビューには付けない)- Lighthouse や PageSpeed Insights でアクセシビリティやパフォーマンスを確認できる