Core Web Vitals ist ein schlechter Name für eine gute Idee. Die Metriken messen drei Dinge, die ein Käufer unmittelbar erlebt — wie lange es dauert, bis die Seite fertig aussieht, wie lange, bis sie auf eine Berührung reagiert, und ob sie sich unter seinem Finger bewegt. Google berichtet sie in Millisekunden, also ausgerechnet in der Einheit, mit der sich am schwersten ein Budget bewilligen lässt.
Das hier ist die Übersetzung. Drei Metriken, was jede einzelne Sie kostet, und der Magento-typische Grund, warum sie in der Regel durchfällt.
Nutzen Sie Felddaten, keine Labordaten. Der Core-Web-Vitals-Bericht der Search Console zeigt, was echte Besucher auf echten Geräten über ein rollierendes 28-Tage-Fenster erlebt haben. Ein Lighthouse-Lauf auf Ihrem Laptop zeigt, was ein simulierter Besucher ein einziges Mal erlebt hat.
LCP: Wie lange, bis die Seite fertig aussieht
Largest Contentful Paint misst, wann das größte sichtbare Element — meist ein Hero-Bild oder ein Produktfoto — fertig gerendert ist. Googles Schwelle liegt bei 2,5 Sekunden für eine gute Erfahrung; ab 4 Sekunden gilt sie als schlecht.
Kaufmännisch gesehen entscheidet LCP darüber, ob ein Besucher aus einer bezahlten Anzeige Ihr Produkt überhaupt zu sehen bekommt. Wer auf dem Smartphone im Mobilfunknetz eine Shopping-Anzeige antippt, hat eine kurze und schonungslose Aufmerksamkeitsspanne; ein Shop, der vier Sekunden braucht, um ein Produktbild zu zeigen, bezahlt für Klicks, die er nicht in Umsatz verwandelt. Wenn Sie bezahlte Kundengewinnung betreiben, ist LCP zuerst eine Kennzahl für Media-Effizienz und erst danach eine technische.
Die üblichen Magento-Ursachen
- Eine langsame Time to First Byte (TTFB). Cache Misses im Full-Page-Cache, eine zu klein dimensionierte Datenbank oder eine Varnish-Konfiguration, die nicht mehr zu Ihrer URL-Struktur passt. Nichts im Frontend kann eine langsame Server-Antwortzeit verbergen.
- Nicht optimierte Katalogbilder. Produktfotos, die in Druckauflösung hochgeladen und erst im Browser skaliert werden. Magentos Bildverarbeitung hilft, rettet Sie aber nicht vor einer 4 MB großen Ausgangsdatei.
- Render-blocking CSS und JavaScript. Lumas Standard-Bundle blockiert den ersten Paint; genauso fast jedes Drittanbieter-Skript, das im Head landet.
- Webfonts ohne font-display: swap. Der Text ist da, fertig, unsichtbar — und wartet auf eine Schriftdatei.
Die Reihenfolge zählt. Bilder zu optimieren, während der Server 1,8 Sekunden zum Antworten braucht, poliert die falsche Stelle. Messen Sie zuerst die TTFB; liegt sie über rund 600 ms, ist das Ihr Projekt.
INP: Wie lange, bis die Seite reagiert
Interaction to Next Paint misst die Verzögerung zwischen dem Antippen durch einen Käufer und der sichtbaren Reaktion der Seite. Gut ist unter 200 Millisekunden; alles jenseits von 500 ms gilt als schlecht und fühlt sich für einen Kunden an, als sei die Seite kaputt.
INP ist die Metrik, die Sie Warenkörbe kostet, nicht Sitzungen. Sie ist genau dort am schlechtesten, wo es am meisten wehtut: bei der Swatch-Auswahl an einem konfigurierbaren Produkt, bei Mengenänderungen im Mini-Warenkorb, bei Filterklicks auf einer Kategorieseite und beim Schritt zur Versandart im Checkout. Wer einen Größen-Swatch zweimal antippt, weil beim ersten Mal nichts passiert ist, hat gerade eine doppelte Position in Ihrem Warenkorb erzeugt — oder, häufiger, die Seite verlassen.
Die üblichen Magento-Ursachen
- Knockout.js-Re-Rendering unter Luma. Mini-Warenkorb und Checkout sind die schwersten Knockout-Bereiche des Themes — deshalb reagieren sie am langsamsten.
- Tag Manager und Personalisierungs-Skripte von Drittanbietern, die lange Tasks auf dem Main Thread ausführen, während der Käufer die Seite benutzen möchte.
- Layered Navigation, die bei jedem Filterklick die ganze Seite neu lädt, statt sie an Ort und Stelle zu aktualisieren.
- Chat- und Bewertungs-Widgets, die beim Laden initialisieren statt bei der ersten Interaktion.
INP ist die Metrik, deren Ursache am ehesten etwas Gekauftes ist und nicht etwas Selbstgebautes. Prüfen Sie die Drittanbieter-Skripte, bevor Sie das Theme anfassen.
CLS: Ob sich die Seite unter dem Finger bewegt
Cumulative Layout Shift misst unerwartete Bewegung — Inhalte, die springen, weil Bilder, Banner oder Widgets zu spät nachladen. Gut ist ein Wert unter 0,1.
CLS kostet Sie auf zwei Arten, eine offensichtliche und eine weniger offensichtliche. Die offensichtliche sind Fehlklicks: Ein Käufer tippt auf In den Warenkorb, darüber lädt ein Werbebanner nach — und er hat etwas anderes getroffen. Die subtile ist Vertrauen. Eine Seite, die beim Laden herumzuckt, wirkt unprofessionell, und beim ersten Besuch arbeitet dieser Eindruck messbar gegen Ihre Conversion Rate.
Die üblichen Magento-Ursachen
- Bilder ohne width- und height-Attribute, sodass der Browser keinen Platz reservieren kann, bevor die Datei ankommt.
- CMS-Blöcke und Werbebanner, die im sichtbaren Bereich eingefügt werden, nachdem der erste Paint längst erfolgt ist.
- Cookie- und Consent-Banner, die die Seite nach unten schieben, statt sich darüberzulegen.
- Drittanbieter-Widgets — Bewertungen, Trust-Badges, Chat —, die in Container ohne reservierte Höhe geladen werden. Das gibt es fast überall und ist fast immer trivial zu beheben.
CLS ist von den drei Metriken die günstigste Korrektur und bleibt am häufigsten unerledigt, weil es sich nicht wie ein Performance-Problem anfühlt. Meist sind es ein paar Dutzend Zeilen CSS, die Boxen reservieren, die von Anfang an hätten reserviert sein müssen.
Wie Sie priorisieren, wenn alle drei durchfallen
Sie fallen selten gleich stark durch, und sie verdienen nicht gleich viel Aufmerksamkeit. Unsere Reihenfolge:
- CLS zuerst. Am günstigsten zu beheben, am schnellsten zu prüfen, und es beseitigt reinen Schaden — es gibt keinen Zielkonflikt abzuwägen.
- LCP als Zweites, beginnend mit TTFB und den Bildern. Hier versickert Ihr Budget für die Kundengewinnung.
- INP zuletzt, weil es am schwersten ist und am ehesten verlangt, etwas zu entfernen, das ein Stakeholder mag.
Segmentieren Sie nach Template, bevor Sie anfangen. Bei den meisten Magento-Shops, die wir auditieren, besteht die Startseite und die Kategorieseiten fallen durch — und die nötige Arbeit ist jeweils eine andere. Seitenweite Durchschnittswerte verdecken genau das Problem, für das Sie tatsächlich bezahlen.
Wie das in der Praxis aussieht
Als wir Careshops Magento-Shop übernommen haben, lautete die geschilderte Beschwerde wie üblich: Die Seite fühle sich langsam an. Die eigentlichen Ursachen verteilten sich auf alle drei Metriken und den Server dahinter. Die obige Abfolge ist keine theoretische Sortierung; sie ist die Reihenfolge, die ohne einen Neubau der Storefront Ergebnisse gebracht hat.
Ist der verbleibende Abstand nach dieser Arbeit immer noch groß, wird daraus eine Frontend-Frage — dazu haben wir einen mit Kosten hinterlegten Leitfaden geschrieben: die Wahl zwischen Hyvä, einer PWA und dem Verbleib auf Luma. Fangen Sie nicht dort an. Fangen Sie mit der Messung an.
Ein ehrliches Ziel setzen
Einem perfekten Lighthouse-Score hinterherzujagen ist eine schlechte Verwendung des Entwicklungsbudgets. Googles Ranking-Signal ist eine Bewertung nach bestanden oder nicht bestanden, gemessen am 75. Perzentil echter Besuche — die Mehrheit der echten Sitzungen muss gut sein, auf den Templates, die zählen. Das ist auf Magento erreichbar, ohne irgendetwas neu zu bauen.
Setzen Sie das Ziel also so: Kategorie- und Produkt-Templates bestehen alle drei Metriken in den Felddaten auf Mobilgeräten, durchgehend über ein volles 28-Tage-Fenster. An diesem Ziel lässt sich ein Entwicklungsteam messen, und ein Finanzteam versteht es. Ein Wert von 100, auf dem Desktop gemessen, ist beides nicht.
Genau darauf sind unsere Mandate zur PageSpeed-Optimierung ausgerichtet, und für Kataloge im Einzelhandel ist es meist die technische Arbeit mit der höchsten Rendite in einem Jahr.
Häufige Fragen
Wirken sich Core Web Vitals wirklich auf das Google-Ranking aus?
Sie sind ein bestätigtes Ranking-Signal, aber ein vergleichsweise schwaches — Relevanz und Inhaltsqualität wiegen schwerer. Das stärkere kaufmännische Argument ist die Conversion: Dieselbe Langsamkeit, die die Bewertung nicht besteht, kostet Sie Umsatz, ganz gleich, was sie mit Ihrer Position macht.
Warum widerspricht die Search Console meinem Lighthouse-Score?
Sie messen Unterschiedliches. Lighthouse ist ein Labortest auf einem simulierten Gerät; die Search Console berichtet Felddaten echter Chrome-Nutzer über ein rollierendes 28-Tage-Fenster. Die Felddaten sind das, was Google verwendet, und das, was Ihre tatsächlichen Kunden erleben. Rechnen Sie mit Abweichungen und vertrauen Sie den Felddaten.
Wie lange dauert es nach einer Korrektur, bis sich die Zahlen bewegen?
Das Felddaten-Fenster umfasst 28 Tage. Eine heute ausgerollte Korrektur ist deshalb erst nach vier Wochen vollständig sichtbar, und der Trend ist erst nach sechs belastbar. Beurteilen Sie die Arbeit im ersten Monat noch nicht — und machen Sie sie erst recht nicht rückgängig.
Welche Metrik sollte ein Magento-Shop zuerst angehen?
Fast immer CLS. Die Behebung ist am günstigsten, die Prüfung am schnellsten, und meist läuft es darauf hinaus, Platz für Bilder und Drittanbieter-Widgets zu reservieren. CLS ist außerdem die Metrik, die am häufigsten im roten Bereich bleibt, weil sie sich nicht wie ein Geschwindigkeitsproblem anfühlt.
Können wir die Core Web Vitals mit dem Standard-Luma-Theme bestehen?
Ja. Es erfordert disziplinierte Arbeit — ein Audit der Extensions, verzögertes JavaScript, eine Bild-Pipeline, Cache- und Server-Tuning —, aber eine bestandene Bewertung auf Luma ist für die meisten Kataloge ein realistisches Ziel. Eine Theme-Migration hebt die Obergrenze; sie ist nicht der Eintrittspreis.
Finden Sie heraus, was Ihre Core Web Vitals Sie kosten
Wir prüfen Ihre Felddaten nach Template, ermitteln, welche der drei Metriken den Schaden anrichtet, und sagen Ihnen, was eine Behebung erfordern würde — mit Ihrem Bestand an Extensions als Teil der Rechnung, nicht als Annahme. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.