Hintergrundbilder sind böse

Hintergrundbilder sind böse

Wer mich kennt oder mich schon mal sprechen gehört hat, hat mich vielleicht schon über Hintergrundbilder reden hören. Für alle anderen: Ich mag Hintergrundbilder wirklich überhaupt nicht. Hier erfährst du, warum ich Hintergrundbilder ablehne, wie du Seiten mit Hintergrundbildern schnell findest und wie du sie behebst.

Zuletzt geprü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 seinen Platz und seine Zeit. Mit modernen Techniken wie Deferring, Preloading, asynchronem Laden, Scheduling oder fetchpriority haben wir fast alle kritischen Ressourcen im Griff. Außer Hintergrundbilder! 

Schau dir dieses Praxisbeispiel an:

Dieses Muster sehe ich täglich, vor allem auf WordPress-Websites: Alle normalen Bilder werden lazy geladen, und einige Bilder (in diesem Fall die Social-Icons im Footer) sind Hintergrundbilder. Kannst du erraten, was passiert?

<html>
<head>
    <style>
        footer {
            /* Ein Margin von 100 vh schiebt den Footer aus dem Viewport! */
            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 lazy geladen – 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>

Du ahnst es wahrscheinlich schon: Die Offscreen-Hintergrundbilder landen vor dem viel wichtigeren Bild „hero.jpg“ in der Download-Warteschlange. Dabei ist meistens genau dieses Bild das Largest Contentful Paint-Element der Seite.

Aber das ist noch nicht alles!

Wie gesagt: Hintergrundbilder sind böse. Denn abgesehen von der seltsamen Priorität, die sie manchmal bekommen, fehlen Hintergrundbildern all die nützlichen Features normaler Bilder.

• Kein Lazy Loading: Für Hintergrundbilder gibt es kein loading-Attribut. Das loading="lazy"-Attribut von <img>-Tags (mit 94,9% weltweiter Unterstützung) existiert für Hintergründe schlicht nicht.
• Kein asynchrones Decoding: Für Hintergrundbilder gibt es kein decoding-Attribut
• Keine fetchpriority: Für Hintergrundbilder gibt es kein fetchpriority-Attribut. Du kannst dem Browser nicht mitteilen, welches Hintergrundbild am wichtigsten ist. Bei <img>-Tags nutzen 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 bietet längst nicht dieselben Möglichkeiten wie srcset und das <picture>-Element.
• Kein width- und height-Attribut. Weil du die einfachen Attribute width und height nicht setzen kannst, kann der Browser keinen Platz für das Bild reservieren. Das führt zu Layout Shift (CLS). Am Ende greifst du zu CSS-Workarounds – und mehr Code ist bei gleicher Komplexität immer langsamer als weniger Code!
• Kein alt-Text: Hintergrundbilder haben kein alt-Attribut. Das schadet der Barrierefreiheit, und Google Bilder kann sie nicht indexieren.

Hintergrundbilder, die über url() geladen werden, sind gültige LCP-Kandidaten. Ein langsames Hintergrundbild wird zu deinem LCP – aber du hast keines 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. Dieser Resource Load Delay erhöht den medianen LCP laut Googles eigenen Messungen um rund 400 ms.

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

Alle Hintergrundbilder auf einer Seite schnell finden

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!');

Das zeigt dir eine sauber formatierte Tabelle mit allen Namen der Hintergrundbilder und ihren Initiatoren.

Wie du Hintergrundbilder vermeidest

Hintergrundbilder lassen sich leicht vermeiden. Wie das geht, hängt vom jeweiligen Bild ab. Es gibt im Wesentlichen 2 Methoden.

Bei „normalen Bildern“

Du wirst es kaum glauben, aber in den meisten Fällen, in denen ich Hintergrundbilder finde, hat der Hintergrund-Teil überhaupt keinen Zweck. Die Bilder „müssen einfach irgendwo auf der Seite stehen“, und dafür wird background-image:url() missbraucht.
Wenn das so ist, füge einfach ein normales Image-Tag ein und entferne das Hintergrundbild aus dem Stylesheet.

Bei Cover-Bildern:

Cover-Bilder sind Bilder, die einen übergeordneten Container vollständig abdecken. Hintergrundbilder dafür zu nutzen, war früher durchaus verständlich: Lange Zeit war das die einzige Möglichkeit für Cover-Bilder, und viele bleiben einfach bei dem, was sie kennen. Glücklicherweise gibt es heute bessere Optionen. Beheben wir das also!
Bei Cover-Bildern entfernst du einfach das Styling   background-image: url(hero.jpg); background-size: cover;, setzt ein normales Bild in denselben Container und passt das CSS so an:

<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 hast du ein vollwertiges Bild mit den Attributen width, height, loading, decoding, srcset, fetchpriority und alt. Alles, was der Browser braucht, um es effizient zu laden.

Wann du ein Hintergrundbild behalten musst

Manchmal geht es nicht ohne CSS-Hintergrundbild: sich wiederholende Muster, dekorative Overlays oder Fälle, in denen das CMS keine andere Option bietet. In diesen Situationen lädst du das Bild per Preload vor, damit der Browser es frühzeitig entdeckt:

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

Platziere das so früh wie möglich im <head>. Offscreen-Hintergrundbilder kannst du per IntersectionObserver verzögern, sodass sie erst geladen werden, wenn der Nutzer in ihre Nähe scrollt.

Um zu überprüfen, ob deine Änderungen die echte User Experience verbessern, richte Real User Monitoring ein. Lab-Scores zeigen dir, was schneller sein sollte. Field data von echten Besuchern zeigt dir, was es tatsächlich ist.