Hintergrundbilder sind böse

Warum Hintergrundbilder Ihren Core Web Vitals schaden und wie Sie sie ersetzen können

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-09

Hintergrundbilder sind böse

Diejenigen von Ihnen, die mich kennen oder mich schon einmal sprechen gehört haben, haben mich vielleicht schon über Hintergrundbilder reden hören. Für diejenigen, die das nicht getan haben: Ich mag Hintergrundbilder wirklich überhaupt nicht. Hier erfahren Sie, warum ich Hintergrundbilder nicht mag, wie Sie Seiten mit Hintergrundbildern schnell finden und wie Sie sie beheben können.

Zuletzt überprüft von Arjen Karel im März 2026

Warum Hintergrundbilder schlecht für die Core Web Vitals sind

Beim Laden einer Webseite hat jedes Element seine Zeit und seinen Platz. Mit einigen modernen Techniken wie Deferring, Preloading, asynchronem Laden, Scheduling, dem Definieren der fetchpriority usw. usw. können wir alle kritischen Ressourcen ziemlich gut unter Kontrolle bekommen. Außer Hintergrundbilder! 

Betrachten Sie dieses Praxisbeispiel:

Täglich sehe ich dieses Muster, meistens auf WordPress-Seiten. Alle normalen Bilder werden per Lazy Loading geladen und einige Bilder (in diesem Fall die Social-Icons im Footer) sind Hintergrundbilder. Können Sie erraten, was passiert?

<html>
<head>
    <style>
        footer {
            /* ein margin von 100vh macht den Footer off-screen! */
            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>
    <!-- ja, dieses Bild wird per Lazy Loading geladen, denn kleine Fehler passieren! -->
    <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>

Sie haben es vielleicht erraten: Die Offscreen-Hintergrundbilder werden vor dem viel wichtigeren 'hero.jpg'-Bild in die Warteschlange für den Download gestellt, welches normalerweise das Largest Contentful Paint-Element auf der Seite sein wird.

Aber das ist noch nicht alles!

Wie ich schon sagte, Hintergrundbilder sind böse! Das liegt daran, dass Hintergrundbildern, abgesehen von der seltsamen Priorität, die sie manchmal erhalten, die coolen Features fehlen, die normale Bilder haben!

  • Kein Lazy Loading: Es gibt kein loading-Attribut für Hintergrundbilder. Das loading="lazy"-Attribut, das bei <img>-Tags funktioniert (mit 94,9 % weltweiter Unterstützung), existiert für Hintergründe einfach nicht.
  • Kein asynchrones Decoding: Es gibt kein decoding-Attribut für Hintergrundbilder.
  • Keine fetchpriority: Es gibt kein fetchpriority-Attribut für Hintergrundbilder. Sie können dem Browser nicht mitteilen, welches Hintergrundbild am wichtigsten ist. Bei <img>-Tags verwenden laut dem Web Almanac 2025 bereits 17,3 % der mobilen Seiten fetchpriority="high" für ihr LCP-Bild.
  • Responsive Bildquellen: Die image-set()-Funktion für Hintergrundbilder hat nicht die gleichen Funktionen, die Sie mit srcset und dem <picture>-Element erhalten.
  • Kein width- und height-Attribut. Da das einfache width- und height-Attribut nicht festgelegt werden kann, kann der Browser keinen Platz für das Bild reservieren, was Cumulative Layout Shift (CLS) verursacht. Am Ende verwenden Sie CSS-Workarounds, und mehr Code ist bei gleicher Komplexität immer langsamer als weniger Code!
  • Kein alt-Text: Hintergrundbilder haben kein alt-Attribut, was der Barrierefreiheit schadet und bedeutet, dass Google Bilder sie nicht indexieren kann.

Hintergrundbilder, die über url() geladen werden, sind gültige LCP-Kandidaten. Ein langsames Hintergrundbild wird als Ihr LCP angezeigt, aber Sie haben keine der oben genannten Tools, um es zu optimieren. Der Browser muss zuerst das CSS herunterladen und parsen, bevor er überhaupt weiß, dass das Bild existiert. Dieses Resource Load Delay erhöht den medianen LCP laut Googles eigenen Messungen um etwa 400 ms.

Laut dem Web Almanac 2025 verwenden immer noch 9 % der mobilen Seiten ein CSS-initiiertes Bild als LCP-Element. Diese Zahl hat sich seit 2022 nicht verändert. Auf von CoreDash überwachten Seiten verbesserte das Ersetzen eines Hero-Hintergrundbilds durch ein <img>-Tag den medianen LCP um 35 %.

Alle Hintergrundbilder auf einer Seite schnell finden

Wie finden wir also heraus, ob eine Webseite Hintergrundbilder enthält? Nun, Sie könnten den Netzwerk-Inspektor überprüfen, nach Bildern filtern, mit der rechten Maustaste auf die Menüleiste klicken, die Initiator-Spalten aktivieren und den Initiator überprüfen, aber es ist viel einfacher, diesen Code in die Dev-Konsole einzufügen.

Öffnen Sie einfach die Dev-Konsole mit Strg-Umschalt-I, navigieren Sie zum Konsolen-Tab und fügen Sie diesen Code ein. Er zeigt Ihnen alle Hintergrundbilder auf der Seite.
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('Keine Hintergrundbilder auf dieser Seite!');

Dies zeigt Ihnen eine sauber formatierte Tabelle mit allen Namen der Hintergrundbilder und den Initiatoren.

Wie man Hintergrundbilder vermeidet

Hintergrundbilder sind leicht vermeidbar. Wie das geht, hängt vom Bild selbst ab. Es gibt grob gesagt 2 Methoden.

Im Fall von 'normalen Bildern'

Sie würden es nicht glauben, wenn ich es Ihnen sage, aber in der Mehrheit der Fälle, in denen ich Hintergrundbilder finde, hat der Hintergrundteil des Bildes nicht einmal einen Zweck. Die Bilder 'müssen nur irgendwo auf der Seite sein' und background-image:url() wird für diesen Zweck missbraucht.
Wenn dies der Fall ist, fügen Sie einfach ein normales Image-Tag hinzu und entfernen Sie das Hintergrundbild aus dem Stylesheet.

Im Fall von Cover-Bildern:

Cover-Bilder sind Bilder, die einen übergeordneten Container vollständig abdecken. Die Verwendung von Hintergrundbildern als Cover-Bilder macht irgendwie Sinn, da dies vor langer Zeit die einzige Möglichkeit war, Cover-Bilder zu erhalten, und ich schätze, die Leute bleiben einfach bei dem, was sie kennen. Glücklicherweise stehen uns bessere Optionen zur Verfügung. Also lassen Sie uns das beheben!
Im Fall von Cover-Bildern entfernen Sie einfach das Styling   background-image: url(hero.jpg); background-size: cover; und platzieren Sie ein normales Bild in demselben Container und passen das CSS so an, dass es wie folgt aussieht:

<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="alt text"
       fetchpriority="low"
  >
</div>

Jetzt haben Sie ein richtiges Bild mit width, height, loading, decoding, srcset, fetchpriority und alt-Attributen. Alles, was der Browser benötigt, um es effizient zu laden.

Wenn Sie ein Hintergrundbild behalten müssen

Manchmal benötigen Sie ein CSS-Hintergrundbild: sich wiederholende Muster, dekorative Overlays oder Fälle, in denen das CMS Ihnen keine andere Möglichkeit lässt. In diesen Situationen sollten Sie das Bild per Preload vorladen, damit der Browser es frühzeitig entdeckt:

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

Platzieren Sie dies so früh wie möglich im <head>. Für Offscreen-Hintergrundbilder können Sie diese mit einem IntersectionObserver aufschieben (defer), sodass sie erst geladen werden, wenn der Nutzer in ihre Nähe scrollt.

Um zu überprüfen, ob Ihre Änderungen die echte User Experience (UX) tatsächlich verbessern, richten Sie Real User Monitoring ein. Labordaten sagen Ihnen, was schneller sein sollte. Felddaten von echten Besuchern sagen Ihnen, was es tatsächlich ist.

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.

Performance degrades unless you guard it.

I do not just fix the metrics. I set up the monitoring, the budgets, and the processes so your team keeps them green after I leave.

Start the Engagement
Hintergrundbilder sind böseCore Web Vitals Hintergrundbilder sind böse