Das Wichtigste in Kürze
- Shopifys
image_tag-Filter wendet bei Bildern nach den ersten drei Sektionen automatischloading="lazy"an – für dein Hero-Bild mussloading="eager"explizit gesetzt werden.- Füge
fetchpriority="high"zum Hero-<img>hinzu, um es in der Download-Warteschlange des Browsers ganz nach vorne zu schieben.- Für Heros mit CSS-
background-imagesolltest du ein<link rel="preload">-Tag im<head>dertheme.liquidhinzufügen. Die URL muss exakt übereinstimmen, sonst lädt der Browser das Bild zweimal herunter.- Der Fix gehört in
sections/image-banner.liquid(oderslideshow.liquid/ deine Hero-Sektion), nicht in dietheme.liquidselbst – mit Ausnahme des Preload-Hints.- Kein Entwickler? Der einfachste und sicherste Weg für diesen Fix ist Fudge. Beschreibe die Änderung in einfachen Worten und die App bearbeitet die Sektionsdateien für dich – kein Liquid, keine Theme-Duplizierung, kein Risiko, etwas kaputt zu machen.
Wenn dir ein Lighthouse- oder PageSpeed Insights-Audit gerade gesagt hat, dass dein Hero-Bild per Lazy Loading geladen wird – oder dass das LCP-Element zu spät vorgeladen wurde – bist du hier genau richtig. Dieser Guide zeigt dir die genauen Liquid-Anpassungen, damit dein Hero-Bild sofort lädt, inklusive fetchpriority und einem Preload-Hint, wo nötig.
Warum du uns vertrauen kannst
Wir haben mit Hunderten von Shopify-Brands an ihrer Storefront-Performance gearbeitet und Fudge entwickelt – einen KI-Storefront-Editor mit einer Bewertung von 4.8 im Shopify App Store. Die untenstehenden Methoden wenden wir selbst an und empfehlen sie in unseren Audits.
Warum dein Hero-Bild lazy-loaded ist
Ein paar Dinge verursachen das typischerweise:
1. Shopifys Standardverhalten. Wenn du ein Bild mit dem image_tag-Filter renderst und das loading-Attribut nicht setzt, wendet Shopify loading="lazy" auf jedes Bild an, das nach dem dritten Abschnitt im Template kommt1. Wenn dein Hero-Abschnitt der vierte auf der Seite ist (wegen einer Announcement-Bar, einer Sticky-Promo oder einem App-Abschnitt darüber), wird er standardmäßig lazy-loaded.
2. Das Theme hat loading="lazy" hardcodiert. Einige ältere Themes wenden loading="lazy" unterschiedslos auf jedes Bild an, einschließlich des Heros.
3. Der Hero ist ein CSS background-image. Wenn der Hero anstelle eines <img>-Tags als background-image: url(...) gerendert wird, sieht der Browser ihn beim initialen Parsen nicht. Es gibt kein loading-Attribut, das man setzen kann, und fetchpriority wird nicht angewendet.
4. Eine App oder Anpassung hat es überschrieben. Einige Apps injizieren Skripte, die bei jedem Bild ein eager gegen lazy austauschen, um “die Performance zu verbessern”. Das ist genau das Gegenteil von dem, was du für dein LCP-Element willst.
So diagnostizierst du es
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 durchloading="eager".- Wenn es kein
fetchpriority-Attribut gibt, wird das Bild im Vergleich zu anderen Ressourcen depriorisiert. Fügefetchpriority="high"hinzu. - Gar kein
<img>-Tag bedeutet, dass es sich um ein CSS-background-imagehandelt – springe unten zum Preload-Abschnitt.
Lass pagespeed.web.dev über deinen Store laufen. Unter der Diagnose zeigt der Eintrag “Largest Contentful Paint-Element”, welches Element gemessen wird. Wenn es dein Hero ist und der Wert bei “Load Delay” (Ladeverzögerung) hoch ist, wird das Bild zu spät abgerufen.
Verwandt: Shopify-Theme schneller machen.
Das <img>-Tag in deiner Hero-Section fixen
Der Hero befindet sich normalerweise in einer dieser Section-Dateien – nicht in der theme.liquid:
sections/image-banner.liquid(Dawn-basierte Themes)sections/slideshow.liquidsections/hero.liquidodersections/featured-hero.liquid(Custom 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 Aufruf des image_tag-Filters. 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" zu 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 vergewissere dich, dass die neuen Attribute vorhanden sind.
Das sauberere Pattern: section.index
loading="eager" hardzucodieren funktioniert zwar, aber es kann passieren, dass die Section verschoben wird (ein Händler zieht sie im Theme-Editor auf der Startseite nach unten) und plötzlich ist sie nicht mehr das LCP-Element, lädt aber weiterhin eager. Das portable Pattern nutzt dafür 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 in den ersten drei bin, lade mich eager. Ansonsten lade mich lazy. Das ist das Pattern, das Shopify selbst für jede Bilder-Section empfiehlt, die im LCP-Slot landen könnte oder eben auch nicht1.
Einen CSS background-image Hero preloaden
Wenn dein Hero als background-image: url(...) im CSS gerendert wird, weiß der Browser nichts von dem Bild, bis er dein Stylesheet geparst, das Bild heruntergeladen und auf das Element angewendet hat. Bis dahin tickt die LCP-Uhr munter weiter.
Der Fix ist ein Preload-Hint im <head> deiner theme.liquid. Er sagt dem Browser, dass das Bild sofort abgerufen werden soll, noch bevor das CSS überhaupt geparst wird.
Schritt 1. Öffne layout/theme.liquid.
Schritt 2. Füge innerhalb des <head>-Blocks einen bedingten Preload hinzu, der nur auf der Seite feuert, auf der sich der Hero befindet (meistens die Startseite):
{%- if template.name == 'index' -%}
{%- assign hero_section = sections['image-banner'] -%}
{%- if hero_section.settings.image -%}
<link
rel="preload"
as="image"
href="{{ hero_section.settings.image | image_url: width: 2000 }}"
fetchpriority="high"
>
{%- endif -%}
{%- endif -%}
Die URL in deinem Preload-Tag muss exakt mit der URL übereinstimmen, die der Browser ansonsten anfordern würde. Gleicher
width-Parameter, gleichercrop, gleichesformat. Wenn sie sich auch nur um ein einziges Zeichen unterscheiden, lädt der Browser beide herunter und du hast die Situation eher verschlimmert.
Schritt 3. Wenn sich dein Bild je nach Viewport ändert (Mobilgeräte erhalten einen anderen Zuschnitt), verwende imagesrcset und imagesizes, damit der Browser auch das richtige Bild preloaded:
<link
rel="preload"
as="image"
imagesrcset="{{ hero_section.settings.image | image_url: width: 800 }} 800w,
{{ hero_section.settings.image | image_url: width: 1200 }} 1200w,
{{ hero_section.settings.image | image_url: width: 2000 }} 2000w"
imagesizes="100vw"
fetchpriority="high"
>
Schritt 4. Noch besser: Wandle das CSS-background-image innerhalb der Section in ein echtes <img>-Tag um. Dann bekommst du fetchpriority, automatisches srcset und das eigene Preload-Verhalten von Shopifys HTTP-Headern. CSS-Hintergründe für das LCP-Element sind nämlich ein Anti-Pattern2.
Setze nicht bei jedem Bild fetchpriority="high"
fetchpriority="high" ist eine begrenzte Ressource. Wenn du fünf Bilder mit hoher Priorität markierst, muss der Browser wählen – und er wird die anderen nach hinten reihen, um dies auszugleichen. Wende es auf genau ein Bild pro Seite an: das LCP-Element.
Das Gleiche gilt für Preload-Hints. Einen pro Seite. Mehrere Preloads, die um Bandbreite wetteifern, verlangsamen genau den Aspekt, den du eigentlich beschleunigen willst.
Den Fix überprüfen
1. Untersuche (Inspect) das gerenderte HTML. Stelle sicher, dass loading="eager" und fetchpriority="high" auf dem Hero-<img> vorhanden sind.
2. Öffne die Chrome DevTools → Network-Tab (Netzwerk) → Seite neu laden mit deaktiviertem Cache. Sortiere nach Priorität (Priority). Dein Hero-Bild sollte ganz oben oder fast ganz oben mit der Priorität “Highest” stehen.
3. Checke die Seite erneut mit pagespeed.web.dev. Die Diagnose “Largest Contentful Paint-Element” sollte einen geringeren Load Delay anzeigen. Der gesamte LCP-Wert sollte sinken, oft um 500-2000 ms bei einer langsamen Mobilverbindung.
4. Wenn du einen Preload hinzugefügt hast, öffne den Network-Tab und suche nach der Bild-URL. Sie darf nur einmal auftauchen, nicht zweimal. Wenn du zwei Einträge siehst, stimmt die Preload-URL nicht mit der gerenderten Bild-URL überein – korrigiere diese Abweichung.
Keine Lust, Liquid zu bearbeiten?
Der gesamte bisherige Ablauf geht davon aus, dass du es dir zutraust, eine Section-Datei zu öffnen und ein Tag zu ändern. Wenn du das lieber vermeiden möchtest, übernimmt Fudge das über einen einfachen Prompt für dich. Etwa so:
“Setze in der Hero-Section auf der Startseite
loading=eagerundfetchpriority=highfür das Banner-Bild. Wenn es sich um einen CSS-Hintergrund handelt, füge einen Preload-Hint in der theme.liquid für das Index-Template hinzu.”
Fudge generiert die exakte Code-Änderung, zeigt dir eine Vorschau im Live-Theme an und speichert erst in deinem Store, wenn du es absegnest. Kein Theme duplizieren, keine Liquid-Syntax erlernen.
Häufige Stolpersteine
Der Hero ist in einer Slideshow mit mehreren Slides. Nur der erste Slide ist beim Initial Paint sichtbar. Wende Eager Loading und fetchpriority="high" nur auf das Bild des ersten Slides an – den Rest lädst du per Lazy Load.
Der Hero ändert sich je nach Template. Ein Homepage-Hero und ein Collection-Page-Hero sind unterschiedliche Sections. Wende den Fix auf beide an und grenze deine Preload-Hints mit if template.name == 'index' usw. ein.
Dein Bild wird nicht als WebP ausgeliefert. Das CDN von Shopify liefert automatisch WebP aus, wenn der Browser es unterstützt – aber nur, wenn du image_url oder img_url nutzt. Ein reines src="...assets/banner.jpg" wird nicht zu WebP. Nutze die Liquid-Filter.
Eine App überschreibt deine Änderungen. Wenn du die Section anpasst, im Inspect aber immer noch loading="lazy" steht, verändert das JavaScript einer App das DOM nach dem Laden der Seite. Prüfe deine installierten Apps auf “Performance”- oder “Bildoptimierungs”-Tools – manche davon wenden loading="lazy" wahllos auf alles an.
Verwandt: Lazy Load für Bilder in Shopify.
Verwandt: Bilder komprimieren in Shopify.
Verwandt: Render-Blocking Scripts in Shopify beheben.
Verwandt: Cumulative Layout Shift in Shopify - ein Hero, der spät und ohne reservierten Platz lädt, verschiebt alles darunter.
Wann man mit einer spürbaren Reduzierung des LCP rechnen kann
Wenn dein Hero-Image lazy-loaded und groß war, erwarte eine LCP-Verbesserung von 1-3 Sekunden bei langsamem 4G. Wenn es bereits eager war, aber fetchpriority fehlte, erwarte 200-800 ms. Wenn du außerdem ein CSS-Background-Image mit einem Preload-Hint behebst, kommt dieser Gewinn noch obendrauf.
Wenn du diese Änderungen vornimmst und PageSpeed den LCP immer noch als langsam markiert, hat sich der Flaschenhals woandershin verlagert – zu render-blockierendem CSS oder JavaScript, der Server-Antwortzeit oder einem Hero-Image, das einfach zu groß ist. Komprimiere zuerst das Bild und sieh dir dann die Skripte an.
FAQ
Shopifys image_tag-Filter wendet loading="lazy" auf Bilder nach der dritten Section im Template an. Wenn dein Hero die 4. Section ist (z. B. nach der Announcement-Bar, einer Sticky-Promo, einer App-Section), wird es lazy-loaded. Das ist ein gutes Standardverhalten für Non-LCP-Bilder, aber schädlich für das Hero-Image — setze explizit loading="eager".
Nein. Verwende loading="eager" nur für das LCP-Element — normalerweise ein einziges Hero-Image. Andere Above-the-fold-Bilder (Logo, Nav-Icons, sekundäre Banner) sind klein genug, dass Lazy-Loading vs. Eager-Loading den LCP nicht nennenswert beeinflusst. Auch bei fetchpriority="high" gilt die Regel: nur bei einem Bild pro Seite.
Nein — das Gegenteil ist der Fall. fetchpriority="high" ist ein relatives Signal. Wenn mehrere Bilder als 'high' markiert sind, depriorisiert der Browser als Ausgleich das eigentliche LCP-Element. Setze es auf genau ein Bild (das LCP-Element) pro Seite. Dasselbe gilt für Preload-Hints — einer pro Seite.
Die theme.liquid ist der übliche Ort, da das <link rel="preload"> im <head> stehen muss und die theme.liquid jede Seite umschließt. Einige Sections unterstützen einen {% layout 'theme' %} Injection-Point, die meisten jedoch nicht. Wenn du die theme.liquid nicht direkt bearbeiten kannst, kann Fudge die Änderung sicher durchführen, ohne dass du den Code anfassen musst.
Auf drei Arten: (1) Rechtsklick auf das Hero-Image → Untersuchen (Inspect) → bestätigen, dass loading="eager" und fetchpriority="high" im <img>-Tag stehen, (2) Chrome DevTools → Network-Tab → neu laden → nach Priorität sortieren → das Hero sollte 'Highest' sein, und (3) PageSpeed Insights erneut ausführen — der LCP "Load Delay" sollte sinken und der LCP-Score insgesamt besser werden.
Footnotes
-
Offizieller Shopify-Leitfaden zum
image_tag-Filter und densection.index-Standardwerten: Announcing new Liquid features for better web performance. ↩ ↩2 -
Web.devs Empfehlung zur Vermeidung von CSS
background-imagebei LCP-Elementen: siehe Optimizing images for performance on Shopify. ↩