Core Web Vitals mit Hyvä: LCP unter 2 Sekunden auf Mobilgeräten

Largest Contentful Paint, kurz LCP, misst, wie lange es dauert, bis das größte Element auf dem Bildschirm erscheint. In einem Magento-Shop ist das meist das Hauptproduktfoto, ein Kategoriebanner oder das Hero-Bild der Startseite.

Google bewertet einen LCP von 2,5 Sekunden oder weniger als gut. Wir zielen tiefer, auf unter 2 Sekunden mobil, denn echte Kunden auf Mittelklasse-Smartphones mit lückenhafter Verbindung sind langsamer als jeder Labortest. Dieser Beitrag erklärt, was Hyvä für den LCP leistet und was Sie trotzdem selbst tun müssen. Er basiert auf der Performance-Arbeit hinter jedem Hyvä-Shop, den wir bauen.

Was unsere Messungen zeigen

Wir haben ein sauberes Magento 2.4.9 mit Hyvä 1.5.2 mit Magentos Luma-Theme verglichen. Beide liefen auf demselben Server mit demselben Katalog, getestet mit Lighthouse 13, als Median aus drei mobilen Durchläufen.

Das entspricht einem rund 35 % schnelleren mobilen LCP für Hyvä. Die vollständige Methodik und alle Seitentypen finden Sie in unserem Hyvä-vs.-Luma-Benchmark.

Ein ehrlicher Hinweis gehört dazu: Auch ein sauberer Luma-Shop auf einem schnellen Server hinter Cloudflare im Production-Modus schneidet gut ab. Echte Luma-Shops mit Extensions und Tracking-Skripten erzielen meist deutlich niedrigere Werte. Der eigentliche Unterschied liegt darin, wie viel der Browser laden muss, nicht im Laborwert.

Warum Hyvä dem LCP hilft

Eine Luma-Seite muss rund ein halbes Megabyte JavaScript herunterladen, parsen und ausführen, bevor ein Großteil der Seite funktioniert. RequireJS lädt Module in Ketten, und der Main Thread bleibt beschäftigt, während das Bild warten muss.

Hyvä setzt stattdessen auf Alpine.js und Tailwind CSS. Mit rund 26 KB JavaScript erreicht der Browser das Hauptbild früher und hat weniger Arbeit, die damit konkurriert.

Auf echten Einsteiger-Smartphones fällt ein halbes Megabyte JavaScript stärker ins Gewicht, als das Labor zeigt. Deshalb schneidet Hyvä meist auch bei Interaction to Next Paint, kurz INP, gut ab: Weniger Skript bedeutet einen Main Thread, der bereit ist, auf Tipps zu reagieren.

Schritt eins: eine schnelle Serverantwort

Der LCP kann nicht beginnen, bevor das HTML ankommt. Braucht der Server lange für die Antwort, kann kein Frontend das wettmachen.

Unser Stack für Hyvä-Shops sieht so aus:

• Magento 2.4.9 auf PHP 8.4, im Production-Modus mit Static Content Deploy.
• Redis oder Valkey für Cache und Sessions sowie OpenSearch für die Katalogsuche.
• nginx mit einem eigenen PHP-FPM-Pool pro Shop.
• Cloudflare davor und Indexer im Modus „Nach Zeitplan“, damit Speichervorgänge im Admin die Storefront nicht ausbremsen.

Der Full-Page-Cache sorgt dafür, dass die meisten Seitenaufrufe schnell sind. Eine gecachte Kategorie- oder Produktseite wird ausgeliefert, ohne die vollständige Magento-Anwendung auszuführen. Mehr zur Wahl des Hostings finden Sie in unserem Leitfaden: beste Magento-Hosting.

Schritt zwei: das LCP-Bild richtig einsetzen

Auf den meisten Magento-Seiten ist das LCP-Element ein Bild. Vier Gewohnheiten machen den größten Unterschied.

1. Laden Sie das Hauptbild nie per Lazy Loading. Lazy Loading ist richtig für Bilder weiter unten auf der Seite, doch das erste Produktfoto oder das Hero-Bild sollte sofort geladen werden.
2. Sagen Sie dem Browser, dass es wichtig ist. Das fetchpriority="high" Attribut am Hauptbild hilft dem Browser, es vor weniger wichtigen Dateien herunterzuladen.
3. Liefern Sie die richtige Größe aus. Ein Smartphone braucht kein Foto in Desktop-Größe – nutzen Sie die skalierten Bilder, die Magento für jede Bildrolle erzeugt.
4. Verwenden Sie ein leichteres Format. Wir liefern Produkt- und Theme-Bilder als WebP aus – mehr dazu in unserem Beitrag über WebP-Bilder hinter Cloudflare.

Setzen Sie außerdem immer Breite und Höhe für Bilder. Das ändert den LCP nicht direkt, verhindert aber Layout-Verschiebungen beim Laden der Seite.

Schritt drei: die Seite vor neuem Gewicht schützen

Die meisten Hyvä-Shops sind am Launch-Tag schnell. Das Risiko kommt später, wenn nach und nach Tracking-Tags, Chat-Widgets, Bewertungs-Widgets und Marketing-Pixel hinzukommen.

Jedes Skript konkurriert mit dem Hauptbild um Bandbreite und Prozessorzeit. Wir halten uns an ein paar Regeln:

• Laden Sie Drittanbieter-Skripte erst, wenn die Seite nutzbar ist – es sei denn, sie werden für die erste Ansicht benötigt.
• Laden Sie jedes Tracking-Tool nur einmal, idealerweise über einen einzigen Tag-Manager statt über mehrere Module.
• Prüfen Sie neue Extensions auf übrig gebliebenes Luma-JavaScript, bevor sie live gehen.
• Testen Sie Start-, Kategorie- und Produktseiten nach jeder Änderung an Skripten oder Extensions erneut.

Auch Schriften zählen. Eine selbst gehostete Schriftfamilie mit wenigen Schnitten reicht meist aus und vermeidet zusätzliche Verbindungen zu anderen Servern.

Schritt vier: richtig messen

Labortests sind nur nützlich, wenn sie das Echte testen. Wir verwenden Lighthouse 13 per Kommandozeile mit Headless Chrome, nehmen den Median aus drei Durchläufen und testen die echte URL hinter dem CDN nach dem Aufwärmen des Caches.

Eine Falle hat uns Zeit gekostet: Unser nginx blockiert Bot-User-Agents, die “lighthouse” oder “headless” enthalten – das Ergebnis war ein 403-Fehler und ein wertloser Messwert. Mit einem normalen Browser-User-Agent war das Problem behoben. Alle Fallen finden Sie in wie wir die Hyvä-Geschwindigkeit mit Lighthouse testen.

Laborergebnisse sind eine Orientierung, nicht das endgültige Urteil. Für die Core Web Vitals nutzt Google Felddaten echter Besucher, wie sie in der Search Console und im Chrome UX Report erscheinen.

So sieht das in echten Shops aus

In unserem Hyvä-Demo-Shop liegen die mobilen Lighthouse-Medianwerte bei 96 für die Startseite, 90 für eine Kategorie- und 92 für eine Produktseite. Auf dem Desktop sind es 100, 100 und 98.

In einem Kundenshop – einem deutschen Händler, der in neun Länder verkauft – hob der Umstieg auf Hyvä den mobilen Lighthouse-Score einer Produktseite von 72 auf 94 und den einer Kategorieseite von 88 auf 95. Diese Zahlen stammen nach unseren Messungen von einem Staging-Build.

Für jeden Hyvä-Shop, den wir launchen, sichern wir einen mobilen Lighthouse-Performance-Score von mindestens 89 auf Start-, Kategorie- und Produktseiten zu. Das gilt auf einem für Hyvä optimierten Server und mit vorab vereinbarten Bildern und Skripten.

FAQ

Garantiert Hyvä gute Core Web Vitals?

Kein Theme kann das allein garantieren. Hyvä bietet Ihnen einen deutlich leichteren Ausgangspunkt, doch Server, Bilder und Drittanbieter-Skripte entscheiden weiterhin über das Endergebnis.

Warum ist mein Hyvä-Shop langsamer als der Benchmark?

Die üblichen Ursachen sind eine langsame Serverantwort, ein nicht optimiertes Hauptbild oder nach dem Launch hinzugefügte Skripte. Ein Magento-Audit zeigt, welche davon auf Ihren Shop zutrifft.

Ist der LCP die einzige Kennzahl, die zählt?

Nein. Auch INP und Cumulative Layout Shift gehören zu den Core Web Vitals. Unsere Core-Web-Vitals-Checkliste deckt alle drei ab.

Sie möchten auch in Ihrem eigenen Shop einen LCP unter 2 Sekunden? Werfen Sie einen Blick auf unsere Hyvä-Pakete, oder sprechen Sie mit uns über Magento-Performance-Optimierung.