Shopify Hero-Banner Eager Loading beheben (2026)

Key Takeaways

• Shopifys image_tag-Filter wendet automatisch loading="lazy" auf Bilder nach den ersten drei Abschnitten an – dein Hero braucht explizit loading="eager".
• Füge fetchpriority="high" zum Hero-<img> hinzu, um es in der Download-Warteschlange des Browsers nach ganz vorne zu schieben.
• Für Heros mit CSS-background-image fügst du am Anfang der Hero-Section-Datei einen <link rel="preload"> für das Bild hinzu. Die URL muss exakt übereinstimmen, sonst lädt der Browser das Bild zweimal herunter.
• Der Fix gehört in sections/image-banner.liquid (oder slideshow.liquid/deine Hero-Section), nicht in theme.liquid.
• Kein Entwickler? Fudge kann diesen Fix für dich übernehmen: Beschreibe die Änderung und es bearbeitet die Section-Dateien als Entwurf, den du überprüfen und freigeben kannst.

Um ein lazy-geladenes Hero-Banner in Shopify zu reparieren, setze loading="eager" und fetchpriority="high" auf das Hero-Bild in seiner Section-Datei und füge einen Preload-Hint hinzu, falls der Hero ein CSS-Hintergrund ist. Wenn ein Audit deinen Hero mit “fetchpriority=high should be applied” oder “This img tag is above the fold and could be eagerly-loaded to improve performance.” markiert hat, sind dies genau die Liquid-Anpassungen, die das beheben.

Warum du uns vertrauen kannst

Wir haben mit Hunderten von Shopify-Marken an der Storefront-Performance gearbeitet und entwickeln Fudge, den KI-Operator für Shopify-Stores, mit einer 4.9-Bewertung im Shopify App Store. Die folgenden Muster wenden wir selbst an und empfehlen sie in Audits.

Warum wird mein Shopify-Hero-Bild lazy-geladen?

Ein paar Dinge sind häufig die Ursache:

1. Das Standardverhalten von Shopify. Wenn du ein Bild mit dem image_tag-Filter renderst und das loading-Attribut nicht setzt, wendet Shopify auf jedes Bild nach der dritten Section im Template loading="lazy" an¹. Wenn deine Hero-Section die vierte auf der Seite ist (wegen einer Announcement Bar, einer Sticky Promo oder einer App-Section darüber), wird sie standardmäßig lazy-geladen.

2. Das Theme hat loading="lazy" hardcodiert. Einige ältere Themes wenden loading="lazy" pauschal auf jedes Bild an, einschließlich des Heros.

3. Der Hero ist ein CSS-background-image. Wenn der Hero als background-image: url(...) statt als <img>-Tag gerendert wird, sieht der Browser es beim initialen Parsen nicht. Es gibt kein loading-Attribut zum Setzen und fetchpriority greift nicht.

4. Eine App oder Anpassung hat es überschrieben. Einige Apps injizieren Skripte, die bei jedem Bild eager durch lazy ersetzen, um die “Performance zu verbessern”. Das ist genau das Gegenteil von dem, was du für das LCP-Element willst.

Für das Lazy Loading von Bildern weiter unten auf der Seite, sieh dir an, wie man Bilder in Shopify lazy lädt.

Wie prüfe ich, ob mein Hero-Bild lazy-geladen wird?

Mache einen Rechtsklick auf das Hero-Bild in deiner Storefront → Untersuchen (Inspect). Schau dir das <img>-Tag im HTML an.

• loading="lazy" ist das Problem. Ersetze es durch loading="eager".
• Ohne fetchpriority behandelt der Browser es als Bild mit normaler Priorität und lädt es möglicherweise erst nach Skripten und Schriftarten. Füge fetchpriority="high" hinzu.
• Gar kein <img>-Tag bedeutet, es ist ein CSS-Hintergrundbild (background-image) – springe unten zum Preload-Abschnitt.

Lass pagespeed.web.dev über deinen Store laufen. Öffne unter Insights LCP request discovery und LCP breakdown. Wenn der Hero “lazy load not applied” oder “fetchpriority=high should be applied” anzeigt oder seine Ressourcen-Ladeverzögerung hoch ist, wird das Bild zu spät geladen.

Für weitere Speed-Fixes sieh dir an, wie man ein Shopify-Theme schneller macht.

Behebe das <img>-Tag in deiner Hero-Section

Der Hero befindet sich normalerweise in einer dieser Section-Dateien – nicht in der theme.liquid:

• sections/image-banner.liquid (Dawn-basierte Themes)
• sections/slideshow.liquid
• sections/hero.liquid oder sections/featured-hero.liquid (benutzerdefinierte Themes)

Schritt 1. Dupliziere dein Theme. Immer.

Schritt 2. Öffne die entsprechende Section-Datei im Code-Editor.

Schritt 3. Finde das <img>-Tag oder den image_tag-Filter-Aufruf. Bei älteren Themes sieht das so aus:

<img
  src="{{ section.settings.image | image_url: width: 2000 }}"
  alt="{{ section.settings.image.alt }}"
  width="2000"
  height="1000"
  loading="lazy"
/>

Schritt 4. Ändere loading="lazy" in loading="eager" und füge fetchpriority="high" hinzu:

<img
  src="{{ section.settings.image | image_url: width: 2000 }}"
  alt="{{ section.settings.image.alt }}"
  width="2000"
  height="1000"
  loading="eager"
  fetchpriority="high"
/>

Wenn dein Theme den modernen image_tag-Filter nutzt:

{{ section.settings.image
  | image_url: width: 2000
  | image_tag: loading: 'eager', fetchpriority: 'high', alt: section.settings.image.alt
}}

Schritt 5. Speichern und neu laden. Mach einen Rechtsklick auf den Hero, klicke auf Untersuchen und bestätige, dass die neuen Attribute vorhanden sind.

Die sauberere Methode: section.index

Das Hardcoden von loading="eager" funktioniert zwar, aber die Section kann verschoben werden (z. B. wenn ein Händler sie im Theme-Editor auf der Startseite nach unten zieht) und plötzlich ist sie nicht mehr das LCP-Element, wird aber immer noch eager geladen. Das flexiblere Pattern nutzt section.index:

{%- liquid
  assign loading = 'eager'
  assign fetchpriority = 'auto'
  if section.index == 1
    assign fetchpriority = 'high'
  elsif section.index > 2
    assign loading = 'lazy'
  endif
-%}

{{ section.settings.image
  | image_url: width: 2000
  | image_tag: loading: loading, fetchpriority: fetchpriority, alt: section.settings.image.alt
}}

Das bedeutet: Wenn ich die erste Section auf der Seite bin, lade mich mit hoher Priorität (fetchpriority). Wenn ich unter den ersten beiden bin, lade mich eager. Ansonsten lade mich lazy. Das ist das Pattern, das Shopify selbst für jede Bild-Section empfiehlt, die im LCP-Slot oder auch außerhalb davon landen könnte¹.

Einen CSS-background-image Hero preloaden

Wenn dein Hero als background-image: url(...) in CSS gerendert wird, weiß der Browser erst von dem Bild, wenn er dein Stylesheet geparst, es heruntergeladen und auf das Element angewendet hat. Zu diesem Zeitpunkt tickt die LCP-Uhr schon eine Weile.

Der Fix ist ein Preload-Hint. Er sagt dem Browser, dass er anfangen soll, das Bild zu fetchen, während er das HTML parst, noch bevor das Stylesheet heruntergeladen und angewendet wurde.

Füge den Hint in die Hero-Section-Datei ein, nicht in theme.liquid. Layout-Dateien können die Einstellungen einer Section nicht auslesen, also hat die theme.liquid keine Möglichkeit herauszufinden, welches Bild für den Hero ausgewählt wurde. Ein <link rel="preload"> ist im Body erlaubt, und der Browser findet ihn trotzdem früh genug im HTML.

Schritt 1. Öffne die Hero-Section-Datei, zum Beispiel sections/image-banner.liquid.

Schritt 2. Füge ganz oben im Markup der Section einen Preload hinzu, der nur gerendert wird, wenn die Section die erste auf der Seite ist:

{%- if section.index == 1 and section.settings.image -%}
  <link
    rel="preload"
    as="image"
    href="{{ section.settings.image | image_url: width: 2000 }}"
    fetchpriority="high"
  >
{%- endif -%}

Wenn du den Hint stattdessen lieber im <head> haben willst, hardcodiere die Bild-URL in der layout/theme.liquid (kopiere sie einfach von der gerenderten Seite) und aktualisiere sie, sobald sich das Hero-Bild ändert.

Die URL in deinem Preload-Tag muss exakt mit der URL übereinstimmen, die der Browser sonst anfordern würde – exakt. Gleicher width-Parameter, gleicher crop, gleiches format. Wenn sie sich auch nur um ein einziges Zeichen unterscheiden, lädt der Browser beide herunter und du hast die Sache nur verschlimmert.

Schritt 3. Wenn dein Bild je nach Viewport variiert (Mobile hat z. B. einen anderen Crop), nutze imagesrcset und imagesizes, damit der Browser das richtige Bild preloaded:

<link
  rel="preload"
  as="image"
  imagesrcset="{{ section.settings.image | image_url: width: 800 }} 800w,
               {{ section.settings.image | image_url: width: 1200 }} 1200w,
               {{ section.settings.image | image_url: width: 2000 }} 2000w"
  imagesizes="100vw"
  fetchpriority="high"
>

Schritt 4. Noch besser: Konvertiere das CSS-background-image in ein echtes <img>-Tag innerhalb der Section. Dadurch bekommst du fetchpriority, automatisches srcset und Shopifys eigenes HTTP-Header-Preload-Verhalten. CSS-Hintergründe für das LCP-Element sind ein Anti-Pattern².

Setze nicht bei jedem Bild fetchpriority="high"

fetchpriority="high" ist eine begrenzte Ressource. Wenn du fünf Bilder als ‘High Priority’ markierst, muss der Browser wählen – und er wird die anderen zum Ausgleich herabstufen. Setze es auf genau einem Bild pro Seite: dem LCP-Element.

Das Gleiche gilt für Preload-Hints. Einer pro Seite. Mehrere Preloads, die um Bandbreite konkurrieren, verlangsamen genau das, was du eigentlich beschleunigen willst.

Überprüfe den Fix

1. Untersuche das gerenderte HTML. Überprüfe, ob loading="eager" und fetchpriority="high" auf dem Hero-<img> gesetzt sind.

2. Öffne die Chrome DevTools → Netzwerk-Tab (Network) → neu laden mit deaktiviertem Cache (Disable cache). Sortiere nach Priorität (Priority). Dein Hero-Bild sollte mit der Priorität “Highest” ganz oder fast ganz oben stehen.

3. Lass pagespeed.web.dev erneut laufen. Der LCP breakdown sollte nun eine geringere Ressourcen-Ladeverzögerung aufweisen, und der LCP-Wert insgesamt sollte sinken.

4. Wenn du einen Preload hinzugefügt hast, öffne den Netzwerk-Tab und suche nach der Bild-URL. Sie sollte nur einmal auftauchen, nicht zweimal. Wenn du zwei Einträge siehst, stimmt die Preload-URL nicht mit der gerenderten Bild-URL überein – behebe diese Abweichung.

Ohne Code reparieren: Nutze Fudge

Wenn du kein Entwickler bist, kann der Store Editor von Fudge diesen Fix übernehmen. Du beschreibst die Änderung ganz einfach in eigenen Worten – Fudge bearbeitet die Section-Dateien, zeigt dir eine Vorschau im Vergleich zu deinem Live-Theme und speichert sie erst in deinem Store, wenn du zustimmst.

Kein Duplizieren des Themes und keine Liquid-Syntax.

Nutze einen Prompt wie:

„Setze in der Hero-Section auf der Startseite loading=eager und fetchpriority=high auf das Banner-Bild. Falls es ein CSS-Hintergrund ist, füge einen Preload-Hint für das Banner-Bild hinzu.“

Fudge kümmert sich sowohl um die image_tag-Bearbeitung als auch um den <link rel="preload">-Hint – derselbe Zwei-Schritte-Fix wie oben beschrieben – und zwar als Entwurf, den du vor der Veröffentlichung als Vorschau ansehen kannst, ohne dass du auch nur eine Zeile Code berühren musst. Wenn du nicht sicher bist, ob der Hero dein einziges Problem ist, bitte Fudge zuerst um ein Speed-Audit: Es listet auf, was deine Seiten verlangsamt, und erstellt für jeden Fix einen Entwurf, den du genehmigen kannst.

Häufige Stolperfallen

Der Hero ist in einer Slideshow mit mehreren Slides. Nur der erste Slide ist beim initialen Paint sichtbar. Wende Eager Loading und fetchpriority="high" nur auf das Bild des ersten Slides an – die restlichen Bilder sollten lazy geladen werden.

Der Hero variiert je nach Template. Ein Startseiten-Hero und ein Collection-Page-Hero sind unterschiedliche Sections. Wende den Fix auf beide an und behalte den Preload-Hint in der Section, die in dem jeweiligen Template ganz oben steht.

Dein Bild wird nicht als WebP ausgeliefert. Shopifys CDN liefert automatisch WebP oder AVIF aus, wenn der Browser es unterstützt – allerdings nur, wenn du über image_url oder img_url gehst. Ein rohes src="...assets/banner.jpg" erhält kein WebP. Nutze die Liquid-Filter.

Eine App überschreibt deine Änderungen. Wenn du die Section fixt, Inspect aber immer noch loading="lazy" anzeigt, manipuliert das JavaScript einer App das DOM nach dem Laden der Seite. Überprüfe deine installierten Apps auf „Performance“- oder „Bildoptimierungs“-Tools – manche davon wenden loading="lazy" rücksichtslos wieder auf alles an.

Ein Hero, der zu spät lädt und für den kein Platz reserviert wurde, verschiebt außerdem alles unter ihm. Für dieses Problem, sieh dir Cumulative Layout Shift auf Shopify an.

Wann du mit einem deutlichen Rückgang des LCP rechnen kannst

Wenn dein Hero lazy-geladen und groß war, kannst du bei einer langsamen 4G-Verbindung mit einer LCP-Verbesserung von 1 bis 3 Sekunden rechnen. Wenn er bereits eager war, aber fetchpriority fehlte, erwarte 200 bis 800 ms. Falls du außerdem ein CSS-background-image mit einem Preload-Hint fixt, addieren sich diese Verbesserungen noch dazu.

Wenn du diese Änderungen vornimmst und PageSpeed das LCP immer noch als zu langsam markiert, hat sich der Flaschenhals verlagert – renderblockierendes CSS oder JavaScript, Server-Antwortzeit oder ein Hero-Bild, das einfach zu schwer ist. Komprimiere das Bild zuerst und schau dir dann die renderblockierenden Skripte an.

FAQ