背景画像は悪です。

背景画像がCore Web Vitalsを悪化させる理由と、その置き換え方法

Arjen Karel - linkedin

Last update: 2026-03-09

背景画像は悪です

私のことを知っている方や、私の講演を聞いたことがある方は、私が背景画像について話すのを聞いたことがあるかもしれません。そうでない方に向けてお伝えすると、私は背景画像が本当に大嫌いです。ここでは、なぜ私が背景画像を嫌うのか、背景画像を使用しているページを素早く見つける方法、改善するための修正方法を解説します。

最終確認：Arjen Karel（2026年3月）

Table of Contents!

背景画像は悪です
背景画像がCore Web Vitalsに悪影響を与える理由
- 実際の例を見てみましょう：
- しかし、それだけではありません！
ページ上のすべての背景画像を素早く見つける方法
背景画像を避ける方法
- 「通常の画像」の場合
- カバー画像の場合：
どうしても背景画像を残さなければならない場合

背景画像がCore Web Vitalsに悪影響を与える理由

Webページを読み込む際、すべての要素にはそれぞれのタイミングと場所があります。遅延読み込み、プリロード、非同期読み込み、スケジューリング、fetchpriorityの定義といった最新の技術を使えば、重要なリソースのほぼすべてを制御下に置くことができます。ただし、背景画像は例外です！

実際の例を見てみましょう：

WordPressのサイトを中心に、日常的にこのようなパターンをよく見かけます。通常の画像はすべて lazy loading されている一方で、一部の画像（この例ではフッターのソーシャルアイコン）が背景画像になっているケースです。何が起こるか予想できますか？

<html>
<head>
    <style>
        footer {
            /* 100vhのマージンにより、フッターは画面外（オフスクリーン）になります！ */
            margin-top: 100vh;
            >.social {
                >.facebook {background-image: url('img/facebook.jpg');}
                >.instagram {background-image: url('img/instagram.jpg');}
                >.linkedin {background-image: url('img/linkedin.jpg');}
                >.email {background-image: url('img/email.jpg');}
            }
        }
    </style>
</head>
<body>
    <!-- はい、この画像は lazy loading されています。ちょっとしたミスは起こるものです！ -->
    <img loading="lazy" src="img/hero.jpg"></img>
    <footer>
        <div class="social">
            <span class="facebook"></span>
            <span class="instagram"></span>
            <span class="linkedin"></span>
            <span class="email"></span>
        </div>
    </footer>
</body>
</html>

予想通りかもしれません。通常、ページ内で Largest Contentful Paint 要素となるはるかに重要な「hero.jpg」画像 よりも先に、画面外の背景画像がダウンロード待ちのキューに入ってしまうのです。

しかし、それだけではありません！

お伝えした通り、背景画像は悪です！なぜなら、時折発生する奇妙な優先順位の問題だけでなく、通常の画像が備えている優れた機能を背景画像は一切使えないからです！

lazy loading が使えない：背景画像には loading 属性がありません。<img> タグで動作する loading="lazy" 属性（グローバルで 94.9% のサポート率）は、背景画像には存在しません。
非同期デコードが使えない：背景画像には decoding 属性がありません
fetchpriority が使えない：背景画像には fetchpriority 属性がありません。ブラウザに対して、どの背景画像が最も重要であるかを伝えることができません。<img> タグでは、2025 Web Almanac によると、モバイルページの 17.3% がすでに LCP 画像に fetchpriority="high" を指定しています。
レスポンシブな画像ソース：背景画像用の image-set() 関数には、srcset や <picture> 要素で利用できるような機能がありません。
width 属性と height 属性が使えない：単純な width および height 属性を設定できないため、ブラウザは画像用の領域を確保できず、Cumulative Layout Shift (CLS) の原因になります。結果として CSS による回避策が必要になり、複雑さが同じであれば、コード量が多いほど常に動作は遅くなります！
alt テキストがない：背景画像には alt 属性がないため、アクセシビリティを損ない、Google 画像検索にもインデックスされません。

url() 経由で読み込まれる背景画像も、LCP の有効な候補です。背景画像の読み込みが遅いとそれが LCP となってしまいますが、最適化するための上記のようなツールは一切使えません。ブラウザは、CSS をダウンロードして解析するまで画像の存在すら把握できないからです。このリソース読み込み遅延により、Google の独自測定では、LCP の中央値が約 400ms 遅くなることが示されています。

2025 Web Almanac によると、モバイルページの 9% が依然として CSS を起点とする画像を LCP 要素として使用しています。この数値は 2022 年から変化していません。CoreDash で監視されているサイトでは、ヒーロー背景画像を <img> タグに置き換えることで、LCP の中央値が 35% 改善されました。

ページ上のすべての背景画像を素早く見つける方法

では、Webページに背景画像が使われているかどうかを調べるにはどうすればよいでしょうか？ネットワークインスペクターを開き、画像でフィルタリングし、メニューバーを右クリックしてイニシエータ（起動元）列を有効にし、イニシエータを確認することもできますが、開発者コンソールに以下のコードを貼り付ける方がはるかに簡単です。

Ctrl-Shift-I で開発者コンソールを開き、コンソールタブに移動してこのコードを貼り付けるだけです。ページ上のすべての背景画像が表示されます。

let bgimg = performance.getEntriesByType('resource')
  .filter(rs => rs.initiatorType == 'css')
  .map(rs => {
  return {
    name: rs.name,
    initiator: rs.initiatorType
  }
}) || [];

(bgimg.length > 0)?
    console.table(bgimg):
    console.log('No background images on this page!');

これにより、すべての背景画像の名前とイニシエータが綺麗にフォーマットされた表で表示されます。

背景画像を避ける方法

背景画像は簡単に避けることができます。その方法は画像自体によって異なり、大きく分けて2つのアプローチがあります。

「通常の画像」の場合

信じられないかもしれませんが、私が背景画像を見つけるケースの大部分において、画像の「背景」としての役割には何の意味もありません。ただ単に「ページのどこかに画像を表示したい」という目的のために、background-image:url() が誤用されているのです。
このような場合は、通常の画像タグを追加し、スタイルシートから背景画像の指定を削除するだけで解決します。

カバー画像の場合：

カバー画像とは、親コンテナを完全に覆う画像のことです。昔はカバー画像を実現する唯一の方法が背景画像だったため、背景画像を使うことには一応の合理性があり、今でもその習慣が残っているのだと思います。幸いなことに、現在ではより優れた選択肢があります。修正しましょう！
カバー画像の場合は、単にスタイル background-image: url(hero.jpg); background-size: cover; を削除し、同じコンテナ内に通常の画像を配置して、CSSを以下のように編集します。

<style>
.img-container {
    position: relative;
    > img {
       width: 100%;
       height: 100%;
       object-fit: cover;
       position: absolute;
       z-index: 1;
   }
}
</style>

<div class="img-container">
  <img
       height="500"
       width="300"
       decoding="async"
       loading="lazy"
       src="hero.jpg"
       srcset="hero-320w.jpg, hero-480w.jpg 1.5x"
       alt="代替テキスト"
       fetchpriority="low"
  >
</div>

これで、width、height、loading、decoding、srcset、fetchpriority、そして alt 属性を備えた適切な画像になります。ブラウザが効率的に読み込むために必要なものがすべて揃っています。

どうしても背景画像を残さなければならない場合

リピートパターンや装飾的なオーバーレイ、またはCMSの仕様上ほかに選択肢がない場合など、どうしてもCSSの背景画像が必要なこともあります。そのような状況では、ブラウザが早い段階で画像を検出できるように画像をプリロードします。

<link rel="preload" href="hero.webp" as="image" type="image/webp" fetchpriority="high">

これを <head> 内のできるだけ早い位置に配置してください。画面外 of 背景画像については、IntersectionObserver を使用して遅延読み込みさせ、ユーザーがその近くまでスクロールしたときにのみ読み込まれるようにすることができます。

変更によって実際のユーザー体験が本当に改善されたかを検証するには、RUMを導入してください。lab dataのスコアは、何が速くなるべきかを示します。実際の訪問者からのfield dataは、実際に何が速いのかを示します。

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

大規模サイトのCore Web Vitalsを通してきました。

欧州の大手メディアやEコマース基盤で50万ページ超。修正コードを書き、フィールドデータで効果を検証します。

進め方を見る