Die meisten Storefront-Teams, die an AI-Sichtbarkeit arbeiten, haben sich auf eine Hälfte des Proble…
Core Web Vitals im Storefront: Wie Medien den LCP treffen
Bei den meisten Storefronts ist der Largest Contentful Paint kein JavaScript-Problem. Es ist ein einzelnes Hero-Bild, ein Produktfoto oder ein Video-Poster-Frame, das zu langsam ankommt. Wenn du die Medien-Pipeline reparierst, folgt der Core-Web-Vitals-Score meistens von selbst.
Wie der LCP wirklich gemessen wird
Largest Contentful Paint misst die Renderzeit des größten sichtbaren Elements im Viewport beim Laden der Seite, typischerweise ein Hero-Bild, ein Produktfoto über dem Fold, ein Video-Poster oder bei textlastigen Layouts ein großer Textblock. Google bewertet in drei Bändern: unter 2,5 Sekunden ist gut, 2,5 bis 4 Sekunden braucht Verbesserung, alles darüber ist schlecht. Diese Schwellenwerte gelten für Felddaten aus dem Chrome User Experience Report (CrUX), und genau die beeinflussen das Suchranking, nicht die Laborwerte aus einem lokalen Lighthouse-Lauf.
Der Unterschied ist wichtig, weil Labordaten auf einer festen Verbindung und einem festen Geräteprofil laufen. Felddaten spiegeln echte Kundinnen und Kunden auf echten Verbindungen wider, inklusive des 3G-Handys im Zugtunnel und des älteren Android-Geräts, das dein Analytics-Dashboard lieber nicht zeigen würde. Ein Storefront mit 95 Punkten in Lighthouse kann trotzdem einen 3,8-Sekunden-Feld-LCP haben, sobald diese Streuung mitgerechnet wird. Auf Kategorie- und Produktseiten im E-Commerce ist das LCP-Element in der überwiegenden Mehrheit der Fälle ein Medien-Asset, und genau darum geht es im Rest dieses Beitrags.
Warum die Medien-Auslieferung das LCP-Budget bestimmt
Sobald klar ist, dass das LCP-Element auf den meisten PDPs und PLPs ein Bild oder ein Video-Poster ist, wird aus der LCP-Frage keine Framework-Frage mehr, sondern eine Auslieferungs-Frage. Ein perfekt optimierter Nuxt- oder Next.js-Render-Baum bringt nichts, wenn die Anfrage für das Hero-Bild zu spät startet, im falschen Format ankommt oder hinter einem Drittanbieter-Skript gedrosselt wird. Den Umsatz-Zusammenhang haben wir bereits an anderer Stelle ausgeführt: wie Frontend-Performance den Umsatz treibt beschreibt die Conversion- und Absprungraten-Wirkung von Core Web Vitals im Detail. Was dort nicht behandelt wird und worum es hier geht, ist der Mechanismus: Die Medien-Auslieferung ist der Hebel, der den LCP-Wert auf einem typischen Storefront tatsächlich bewegt.
Vier Fehlerquellen erklären den größten Teil des Schadens: übergroße Quelldateien ohne responsive Varianten, ein Format-Mismatch (JPEG, wo AVIF oder WebP die Dateigröße um 30 bis 50 Prozent reduzieren würde), eine verzögerte Erkennung, weil die Browser-Engine die Bild-URL nicht früh genug findet, weil sie in clientseitigem JavaScript versteckt ist statt im initialen HTML, und Drittanbieter- oder unverwaltete CDN-Latenz, die hunderte Millisekunden addiert, bevor überhaupt das erste Byte des Bildes lädt. Keiner dieser Punkte ist ein Framework-Problem. Alle sind Probleme der Medien-Pipeline.
Die Bild-Pipeline: Formate, responsive Größen und CDN-Auslieferung
Eine Medien-Pipeline, die für LCP gebaut ist, muss vier Dinge gleichzeitig richtig machen: Format, responsive Größenanpassung, Auffindbarkeit und Caching.
Bei der Format-Wahl sollte AVIF der Standard sein, WebP der Fallback und JPEG nur die letzte Option für Randfälle. Responsive Größenanpassung bedeutet ein echtes `srcset` mit mehreren Breiten und ein korrektes `sizes`-Attribut, damit ein Smartphone ein 640px-Bild lädt und nicht dasselbe 2400px-Master-Bild wie der Desktop. Auffindbarkeit bedeutet, dass das LCP-Bild-Tag im initial serverseitig gerenderten HTML stehen muss, mit `fetchpriority="high"` markiert und niemals in `loading="lazy"` verpackt sein darf. Diesen Fehler sehen wir immer noch auf Live-Storefronts, und er allein fügt dem LCP oft eine ganze Sekunde oder mehr hinzu. Caching bedeutet, dass die eigentlichen Bytes von einem edge-gecachten Image-CDN kommen sollten, nicht von einem kalten Origin-Abruf bei jeder Anfrage.
Wenn du die tiefere Mechanik dahinter suchst, wie ein Image-CDN tatsächlich funktioniert, inklusive On-the-fly-Transformation und Edge-Caching, behandeln wir das separat im Detail: wie ein Image-CDN wirklich funktioniert. Die Kurzfassung für diesen Beitrag: Ein Image-CDN zwischen deinem Storefront und deinem Asset-Ursprung ist das, was Format-Aushandlung, responsive Größenanpassung und Edge-Auslieferung ohne eine Build-Time-Asset-Pipeline pro Gerätegröße überhaupt erst möglich macht.
Video-Auslieferung: Die Fallstricke, die den LCP brechen
Video-Hero-Sektionen sind auf Kategorie-Landingpages und Kampagnenseiten üblich, und sie bringen eine zweite Fehlerfläche mit. Wenn ein Autoplay-Video über dem Fold liegt, wird meist nicht die Videodatei, sondern das Poster-Frame zum LCP-Element, also gelten für das Poster dieselben Regeln: richtiges Format, richtige Größe, hohe Fetch-Priorität. Der Fallstrick besteht darin, das Poster als Nebensache zu behandeln, während das eigentliche Video überkonstruiert wird.
Die Videodatei selbst hat eigene Fehlerquellen: eine einzelne High-Bitrate-MP4-Datei ohne Adaptive-Bitrate-Leiter, eine Video-Player-Bibliothek, die den Main-Thread blockiert, bevor sie überhaupt mit dem Laden beginnt, und selbstgehostetes Video ohne CDN davor, wodurch jeder Storefront-Besuch zu einer frischen Origin-Anfrage wird. Video unter dem Fold sollte ausnahmslos lazy-loaded werden. Video über dem Fold braucht Adaptive-Bitrate-Streaming und eine CDN-Schicht, oder es sollte auf mobilen Verbindungen gar nicht erst automatisch abspielen, wo Datenlimits und schwankende Bandbreite eine große, unverwaltete Videodatei zu einem der teuersten Elemente einer Seite machen.
Eine Performance-Ebene statt clientseitigem Tag-Chaos
Das typische Fehlermuster ist kein Mangel an Aufwand. Es ist ein Stapel aus clientseitigen Provisorien: eine Lazy-Load-Bibliothek, ein separates Bild-Optimierungs-Plugin, ein Drittanbieter-Video-Embed und ein Personalisierungs-Skript, jedes einzeln geladen, jedes im Wettbewerb um denselben Main-Thread und dieselbe Netzwerk-Priorität, ohne dass eines vom anderen weiß. Jedes dieser Tools wurde gewählt, um ein echtes Problem zu lösen, und zusammen erzeugen sie ein neues: unkoordinierten, unvorhersehbaren LCP.
Die Alternative ist, Performance als Plattform-Ebene zu behandeln statt als clientseitige Ansammlung von Werkzeugen. Auf Composable Headless Frontend sind Medien-Auslieferung, responsive Bild-Generierung und Edge-Caching direkt in die Render- und Hosting-Ebene eingebaut, nicht nachträglich pro Projekt angeflanscht. Das ist auch die Grundannahme hinter Frontend as a Service: Storefront, Connect-Ebene und Cloud-Auslieferungsschicht arbeiten als ein gemanagtes System, sodass ein einmal gesetztes Performance-Budget für jede Seite und jede Locale gilt, statt bei jedem neuen Marketing-Skript, das sechs Monate später dazukommt, neu erkämpft werden zu müssen.
FAQ
Reicht Bild-Kompression allein, um den LCP zu fixen? Nein. Kompression reduziert die Dateigröße, behebt aber kein falsches Format, fehlende responsive Varianten oder einen verzögerten Erkennungspfad. Alle vier Faktoren, Format, Größe, Priorität und Caching, müssen gemeinsam stimmen.
Welchen LCP-Wert sollte ein E-Commerce-Storefront anpeilen? Ziel sind Felddaten unter 2,5 Sekunden als Minimum, 1,8 Sekunden auf Mobilgeräten sind ein realistisches Ziel. Laioutrs eigene Live-Frontends melden einen Median-LCP von 1,2 Sekunden in Felddaten, das zeigt, was eine sauber verwaltete Medien- und Hosting-Ebene leisten kann.
Kann ein Video jemals das LCP-Element sein, und sollte es das? Ja, wenn das Poster-Frame das größte sichtbare Element ist, bevor das Video lädt. Behandle dieses Poster genau wie ein Hero-Bild: richtiges Format, richtige Größe, hohe Fetch-Priorität, niemals lazy-loaded.
Nächste Schritte
Wenn der LCP deines Storefronts über Geräte und Märkte hinweg inkonsistent ist, ist der schnellste Weg herauszufinden, ob es ein Framework- oder ein Medien-Auslieferungs-Problem ist, ein technischer Walkthrough deiner aktuellen Pipeline. Sieh dir die Plattform-Preise an oder sprich mit uns darüber, was eine gemanagte Performance-Ebene für deinen konkreten Storefront ändern würde.