Shopify LCP Fix: Improve It Without a Theme Rebuild
⏱ 14 Min. Lesezeit
Shopify LCP Fix: So verbesserst du ihn, ohne die ganze Theme zu ersetzen
Dein LCP steht bei 4,2 Sekunden, und irgendjemand hat schon vorgeschlagen, die Theme neu zu bauen. Halt kurz inne. In den allermeisten Shopify-Shops ist nicht die Theme das Problem, sondern drei bis vier konkrete Dinge darin: ein lazy geladenes Hero-Bild, ein zu großes Bildformat, ein spät entdecktes LCP-Element und ein render-blockierendes Stylesheet. Dieser Shopify LCP Fix zeigt dir, wie du jedes davon mit gezielten Änderungen an bestehenden Theme-Dateien behebst. Kein Rebuild, kein neues Theme, kein Datenrisiko, keine verlorenen Anpassungen. Betrachte diesen Shopify LCP Fix als Checkliste: die Schritte der Reihe nach abarbeiten und aufhören, sobald die Felddaten grün werden.
Was LCP auf einem Shopify-Shop misst
Largest Contentful Paint misst die Zeit, bis das größte sichtbare Element im Viewport gerendert ist. Auf einer Shopify-Produktseite ist das fast immer das Hauptproduktbild, auf der Startseite das Hero-Banner. Der gute Schwellenwert liegt bei 2,5 Sekunden am 75. Perzentil echter Nutzer, nicht im Labor. Warum Lab-Score und Felddaten so oft auseinanderlaufen, klären wir ausführlich in unserem Beitrag zu Shopify Core Web Vitals. Hier geht es rein um die Umsetzung: wie du LCP praktisch senkst.
Google zerlegt LCP in vier Teilphasen. Diese Aufteilung ist die beste Landkarte für jeden Shopify LCP Fix, weil sie dir sagt, wo die Zeit tatsächlich verloren geht, statt blind an Bildern zu schrauben.
| LCP-Teilphase | Was auf Shopify bremst | Dein Hebel |
|---|---|---|
| Time to First Byte | Schwere Liquid-Loops, App-Logik | Theme Inspector, Caching |
| Resource Load Delay | Bild wird zu spät entdeckt | Preload + fetchpriority |
| Resource Load Duration | Zu großes Bild, falsches Format | WebP + srcset + Kompression |
| Render Delay | Render-blockierendes CSS, späte Fonts | Kritisches CSS, font-display |
Die Details zu dieser Zerlegung stehen im LCP-Optimierungsleitfaden von web.dev. Merk dir die vier Phasen, wir arbeiten sie im Rest des Artikels der Reihe nach ab.
Zuerst: Finde dein echtes LCP-Element
Jeder Shopify LCP Fix beginnt gleich. Bevor du eine Zeile Code anfasst, musst du wissen, welches Element überhaupt dein LCP ist. Rate nicht. Miss.
- Öffne die Seite in Chrome, dann DevTools, Reiter „Performance“ oder „Lighthouse“. Lighthouse markiert das LCP-Element direkt im Report.
- Prüfe die drei wichtigsten Vorlagen einzeln: Startseite, Produktseite, Kategorieseite. Das LCP-Element unterscheidet sich je Template.
- Gleiche das mit den Felddaten in der Search Console ab. Der Lab-Test zeigt die Ursache, die Felddaten zeigen, ob es echte Nutzer betrifft.
In neun von zehn Fällen ist das Ergebnis ein Bild. Genau deshalb drehen sich die ersten und wirkungsvollsten Schritte um genau dieses eine Bild.
Warum du für einen Shopify LCP Fix keine neue Theme brauchst
Ein Theme-Wechsel fühlt sich nach dem großen Schnitt an, ist aber meist der teuerste und riskanteste Weg zu einem Ziel, das ein paar Dateien entfernt liegt. LCP lebt an sehr wenigen Stellen deiner Theme:
- in der Section, die das Hero- oder Produktbild rendert,
- im Snippet, das deine
<img>-Tags erzeugt, - im
<head>vontheme.liquid, - im Basis-Stylesheet und im Font-Loading.
Ein Rebuild wirft dabei alles über Bord: deine CRO-Anpassungen, App-Integrationen, Content-Struktur und mühsam aufgebaute interne Verlinkung. Und selbst eine frische Standard-Theme wie Dawn ist ohne diese Anpassungen nicht automatisch schnell. Du würdest also das Risiko eines Umbaus tragen und am Ende dieselben vier Fixes machen müssen. Spar dir den Umweg.
Entferne loading="lazy" vom Hero-Bild und gib ihm fetchpriority="high". Diese zwei Attribute an einem einzigen Element bringen auf den meisten Shops den größten LCP-Sprung, ganz ohne neue Theme.
Schritt 1: Das Hero-Bild nicht mehr lazy laden
Der erste Shopify LCP Fix ist zugleich der wirkungsvollste. Der häufigste und teuerste Fehler auf Shopify: Das LCP-Bild hat loading="lazy". Lazy Loading verzögert den Download, bis der Browser per IntersectionObserver merkt, dass das Bild sichtbar ist. Für ein Element above the fold heißt das: unnötige Wartezeit auf genau das Bild, das deinen LCP-Wert bestimmt.
Öffne die Section oder das Snippet, das dein Hero rendert, und stelle sicher, dass das oberste Bild eager lädt:
<img
src="{{ section.settings.hero_image | image_url: width: 1200, format: 'webp' }}"
width="1200" height="675"
loading="eager"
alt="...">Die Regel ist simpel: alles above the fold eager, alles darunter lazy. Kollektionsseiten sind ein Sonderfall. Die erste Zeile Produktbilder ist sichtbar und sollte eager laden, alles ab Zeile zwei lazy. Moderne Dawn-basierte Themes lösen das oft mit einer Bedingung wie loading: forloop.index <= 4 ? 'lazy' : 'eager'. Prüfe per Rechtsklick auf das Bild und „Untersuchen“, was deine Theme tatsächlich ausgibt.
Schritt 2: fetchpriority=”high” auf das LCP-Bild
Browser vergeben Prioritäten automatisch. Bilder starten standardmäßig mit niedriger Priorität; erst wenn Chrome erkennt, dass ein Bild above the fold liegt, stuft es hoch. Diese verlorene Zeit holt man selten wieder auf. Mit fetchpriority="high" sagst du dem Browser von Anfang an, dass dieses eine Bild Vorrang hat.
<img
src="{{ section.settings.hero_image | image_url: width: 1200, format: 'webp' }}"
width="1200" height="675"
loading="eager"
fetchpriority="high"
alt="...">Shopify hat diesen Effekt im eigenen Performance-Team gemessen und den LCP von Artikelseiten allein durch fetchpriority um 0,25 bis 0,5 Sekunden gesenkt. Details dazu in Shopifys eigener Performance-Dokumentation.
fetchpriority ist in allen modernen Browsern verfügbar und wird von älteren einfach ignoriert. Du kannst es also gefahrlos setzen. Aber nur an einer Handvoll Elemente: Setzt du alles auf „high“, ist nichts mehr „high“.
Schritt 3: Das richtige Bild ausliefern, WebP und srcset via image_url
Ein priorisiertes Bild hilft wenig, wenn es ein 4-MB-JPEG in Desktop-Auflösung ist, das auf einem Handy geladen wird. Zwei Dinge lösen das: modernes Format und responsive Größen. Shopify liefert beides über den image_url-Filter.
<img
src="{{ section.settings.hero_image | image_url: width: 1200, format: 'webp' }}"
srcset="{{ section.settings.hero_image | image_url: width: 600, format: 'webp' }} 600w,
{{ section.settings.hero_image | image_url: width: 1200, format: 'webp' }} 1200w,
{{ section.settings.hero_image | image_url: width: 1800, format: 'webp' }} 1800w"
sizes="100vw"
width="1200" height="675"
loading="eager"
fetchpriority="high"
alt="...">WebP spart gegenüber JPEG bei gleicher Qualität rund 25 bis 35 Prozent Dateigröße. Das srcset sorgt dafür, dass ein Handy die 600px-Variante bekommt und nicht die 1800px-Version. Setze außerdem immer width und height, das reserviert den Platz und verhindert Layout-Shift, also CLS-Probleme als Nebeneffekt.
Der image_url-Filter gibt nur die CDN-URL aus, nicht srcset oder fetchpriority. Die schreibst du selbst ins HTML. Der neuere image_tag-Filter erzeugt srcset automatisch aus einem widths-Parameter, gibt aber (Stand 2026) kein fetchpriority aus. Für das Hero-Bild bleibst du also besser bei der manuellen Variante.
Schritt 4: Das LCP-Bild in theme.liquid preloaden
Preload ist der stärkste, aber auch gefährlichste Hebel. Er startet den Bild-Download bereits im <head>, bevor der Browser das <img> im Body überhaupt entdeckt. Für ein spät entdecktes LCP-Bild kann das mehrere Hundert Millisekunden sparen.
{%- if template.name == 'index' and section.settings.hero_image -%}
<link rel="preload" as="image"
href="{{ section.settings.hero_image | image_url: width: 1200, format: 'webp' }}"
imagesrcset="{{ section.settings.hero_image | image_url: width: 600, format: 'webp' }} 600w,
{{ section.settings.hero_image | image_url: width: 1200, format: 'webp' }} 1200w"
imagesizes="100vw"
fetchpriority="high">
{%- endif -%}Der Preload-Footgun
Preload wird nicht ohne Grund „Footgun“ genannt. Drei Regeln bewahren dich davor, dir selbst ins Bein zu schießen:
- Template-Guard. Preload nur dort, wo das Bild wirklich existiert. Ein Preload auf eine leere URL verschwendet Bandbreite und kann render-blockierende Ressourcen verdrängen.
- Richtige Größe. Preload nicht das Desktop-Bild für alle Geräte. Nutze
imagesrcsetundimagesizes, damit auf dem Handy die kleinere Variante gewinnt. - Immer messen. Preload hilft nicht überall. Miss vorher und nachher mit Lighthouse oder WebPageTest. Wenn kein Gewinn sichtbar ist, nimm es wieder raus.
Damit der Preload überhaupt an die Hero-URL kommt, muss die Bildvariable im Layout erreichbar sein. Viele lösen das über eine Theme-Einstellung, die die Hero-URL zusätzlich im <head> verfügbar macht. Zusammen mit fetchpriority und eager Loading sind das die vier Handgriffe, die auf den meisten Shops 80 Prozent des LCP-Problems erledigen. Wenn du nur eine Stunde für einen Shopify LCP Fix hast, investiere sie hier.
Du hast das Hero-Bild optimiert, aber der LCP-Wert steht immer noch im roten Bereich?
Shopify PageSpeed Audit
Wir finden das echte LCP-Element pro Template und den Grund für den roten Wert.
Speed-Audit starten →Shopify Theme-Entwicklung
Wir setzen die Theme-Fixes sauber um, ohne deine Anpassungen zu verlieren.
Theme optimieren →Technisches SEO für Shopify
Wir verbinden Speed mit den Rankings, die daraus entstehen sollen.
SEO-Basis prüfen →Schritt 5: Fonts fixen, die den Hero verzögern oder verschieben
Wenn dein LCP-Element ein Text ist, oder wenn Text neben dem Hero-Bild liegt, werden Webfonts schnell zum Problem. Ein spät geladener Font lässt den Text entweder unsichtbar flackern (FOIT) oder verschiebt ihn beim Nachladen (FOUT), und in beiden Fällen wandert dein LCP-Kandidat mit. Drei Regeln:
- font-display: swap. So rendert der Text sofort im Fallback-Font und wird ersetzt, sobald der Webfont da ist.
- Font selbst hosten und subsetten. Lade nur die Zeichen, die du brauchst (Latin, Ziffern, Satzzeichen), oft unter 30 KB, und liefere ihn über die Shopify-CDN aus.
- Nur die Above-the-fold-Weight preloaden. Ein bis zwei Schnitte, nicht die ganze Familie. Preloadest du jeden Weight, schadest du mehr, als du hilfst.
<link rel="preload" as="font" type="font/woff2"
href="{{ 'brand-regular.woff2' | asset_url }}" crossorigin>
<style>
@font-face{
font-family:'Brand';
font-display:swap;
src:url("{{ 'brand-regular.woff2' | asset_url }}") format('woff2');
}
</style>Schritt 6: Render-blockierendes CSS above the fold reduzieren
Bevor der Browser irgendetwas zeigt, muss er das CSS im <head> laden und verarbeiten. Ein einziges großes, render-blockierendes Stylesheet verzögert damit jedes Element, auch dein Hero. Bei einer typischen Feature-Theme werden 60 bis 80 Prozent des ausgelieferten CSS auf einer einzelnen Seite gar nicht genutzt.
Prüf das selbst: DevTools, „Coverage“-Tab (über das Command-Menü mit „Show Coverage“). Er zeigt zeilengenau, welches CSS nie ausgelöst wird. Der Fix läuft in zwei Schritten:
- Kritisches CSS inline stellen. Die Regeln für den sichtbaren Bereich (rund 10 bis 14 KB) direkt in den
<head>, damit der erste Paint nicht auf eine externe Datei wartet. - Den Rest deferren. Das große Stylesheet nicht mehr render-blockierend laden:
<link rel="stylesheet" href="{{ 'theme.css' | asset_url }}"
media="print" onload="this.media='all'">
<noscript>
<link rel="stylesheet" href="{{ 'theme.css' | asset_url }}">
</noscript>Der media="print"-Trick lädt das Stylesheet ohne Blockade und schaltet es nach dem Laden per onload auf all. Das <noscript>-Fallback stellt sicher, dass auch ohne JavaScript alle Styles greifen.
Schritt 7: Schweres Liquid und App-Skripte zähmen
Wenn deine Seite selbst auf schneller Verbindung träge bleibt, liegt es oft an der Time to First Byte. Shopify hat eine schnelle Infrastruktur, aber deine Theme kann sie ausbremsen, wenn Liquid pro Anfrage zu viel Arbeit macht. Typische Verursacher:
- Schleifen über
all_productsoder große Kollektionen, - Metafeld-Abfragen innerhalb von Loops,
- App-Skripte, die ihren Code global auf jeder Seite laden und mit dem Bild-Fetch konkurrieren.
Nutze den Shopify Theme Inspector (Chrome-Erweiterung), um langsame Liquid-Blöcke zu finden, und deferre nicht-kritische Skripte. Jedes Drittanbieter-Skript, das nicht für den ersten Paint gebraucht wird, gehört hinter das defer-Attribut oder hinter die erste Interaktion. Preconnecte außerdem zu den zwei, drei wichtigsten Fremd-Domains, damit deren Handshake früh passiert:
<link rel="preconnect" href="https://cdn.shopify.com">
<link rel="preconnect" href="https://fonts.example.com" crossorigin>Installiere keine „Speed-Booster“-App, um LCP zu fixen. Die meisten fügen weiteres JavaScript hinzu, das genau die Ressourcen verdrängt, die du eigentlich beschleunigen willst. Mehr Code ist selten die Lösung für ein Problem, das durch Code entstanden ist.
Häufige Fehler, die LCP hoch halten
Selbst ein sauberer Shopify LCP Fix scheitert, wenn du in eine dieser Fallen tappst. Dieselben Muster tauchen in fast jedem Audit auf, wer sie kennt, spart Wochen.
- Das falsche Element optimieren. Ohne den LCP-Kandidaten zu messen, verbesserst du vielleicht ein Bild, das gar nicht zählt.
- Das Hero-Bild lazy laden. Der teuerste Einzelfehler auf Shopify.
- Alles preloaden. Preload für zehn Ressourcen macht keine davon schnell.
- Das Desktop-Bild auf dem Handy ausliefern. Ein fehlendes
srcsetkostet auf Mobilgeräten am meisten. - Nur minifizieren. Minifizieren schrumpft ungenutztes CSS, statt es zu entfernen. Erst entfernen, dann verkleinern.
- Nur den Lab-Score jagen. Bestätige jeden Fix in den Felddaten, nicht nur in Lighthouse.
So bestätigst du, dass der Shopify LCP Fix wirkt
Miss in zwei Schritten, sonst ziehst du falsche Schlüsse:
- Sofort im Labor. Ein Lighthouse-Lauf vor und nach jeder Änderung zeigt dir, ob der Fix technisch greift. Ändere immer nur eine Sache pro Messung, sonst weißt du nicht, was gewirkt hat.
- Nach zwei bis vier Wochen im Feld. Die offizielle Bewertung basiert auf einem rollierenden 28-Tage-Fenster echter Nutzer. Erwarte in der Search Console keine sofortige Bewegung. Ein Fix, der heute live geht, zeigt sich dort erst Wochen später.
Fazit: und wann ein Rebuild doch gerechtfertigt ist
Für die allermeisten Shops ist der schnellste Weg zu einem guten LCP kein neues Theme, sondern die sieben Schritte oben, angewandt in der Reihenfolge der vier LCP-Teilphasen. So sequenziert ist ein Shopify LCP Fix ein fokussiertes Wochenende Arbeit, kein Rebuild. Hero eager laden, priorisieren, richtig ausliefern, preloaden, Fonts und CSS entschärfen, Liquid und Apps zähmen. Ein Rebuild ist erst dann sinnvoll, wenn die Theme strukturell kaputt ist: aufgeblähter Code mehrerer abgelöster Agenturen, ein veraltetes, nicht mehr wartbares Theme, oder ein Setup, in dem jede kleine Änderung neue Fehler auslöst. In diesem Fall ist der Umbau eine Investition, kein Pflaster. In allen anderen Fällen reicht ein gezielter Shopify LCP Fix.
Du hast die Schritte umgesetzt und willst wissen, was als Letztes noch bremst?
Shopify PageSpeed Audit
Wir messen pro Template und liefern die konkrete Fix-Reihenfolge für deinen Shop.
Ladezeit prüfen →Shopify Theme-Entwicklung
Wir bauen die kritischen Pfade um, oder die Theme neu, wenn es sich wirklich lohnt.
Theme angehen →Technisches SEO für Shopify
Wir sichern, dass aus schnellerem LCP auch bessere Rankings werden.
SEO-Audit holen →Shopify LCP Fix: Frequently Asked Questions
A good LCP is 2.5 seconds or less, measured at the 75th percentile of real users. Values between 2.5 and 4 seconds need improvement; above 4 seconds is poor. What counts is the field value in Search Console, not the Lighthouse lab score, which often looks kinder than the real user experience.
Mobile devices have weaker CPUs and slower networks, and Google grades mobile separately. A desktop-sized hero image loaded unfiltered onto a phone is the most common cause. A srcset serves smaller variants, and eager loading plus fetchpriority cuts the wait on that specific image. Always test mobile, not desktop Wi-Fi.
Start with fetchpriority=”high” on the hero image: it adjusts priority with no extra request and has no downside. Preload is stronger when the image is discovered late, but riskier and must be tested. In practice, eager loading plus fetchpriority delivers most of the gain, with preload adding to it.
No. The hero image is above the fold and usually the LCP element. Lazy loading delays its discovery and worsens LCP. Use loading=”eager” for everything above the fold, and lazy only for images below it. On collection pages, the first visible row of product images should also load eagerly.
No, and an app is usually counterproductive. Speed-booster apps add more JavaScript that crowds out the resources you want to speed up. The effective LCP fixes are edits to existing theme files: eager loading, fetchpriority, srcset, preload and critical CSS. None of that needs an extension.
Open the page in Chrome, run a Lighthouse audit in DevTools, and read the highlighted LCP element in the report. Check homepage, product and collection pages separately, since the element differs by template. Cross-check against the field data in Search Console before you optimise anything.
In the Lighthouse lab you see the effect immediately after deploy. The official Search Console assessment, though, is based on a rolling 28-day window of real users and only moves after two to four weeks. Use lab data for immediate confirmation and field data for the final verdict.
In most cases, no. LCP lives in a few places in the theme: the hero section, the image snippet, the theme.liquid head and the base CSS. These can be edited surgically, with no rebuild. Switching themes only pays off when the code is structurally broken and unmaintainable, otherwise you carry the risk without the benefit.
Vladyslav Kharkivskyi
