Core Web Vitals in Shopware-Shops: 51 Startseiten im Labor gemessen
Wir haben die Startseiten von 51 Shopware-6-Shops unter gleichen Bedingungen geladen — mobil, mit gedrosseltem Netz und Prozessor, je dreimal. Der erste Inhalt erschien im Median nach 2,9 Sekunden, das größte Element erst nach 9,6. Die Server antworteten schnell; gebremst haben Bilder, Slider und Banner.
Ergebnis
9,6 s
Median des Largest Contentful Paint über 51 Startseiten im gedrosselten Mobil-Labor. Der erste Inhalt erschien nach 2,9 Sekunden; dazwischen lagen im Median 6,6 Sekunden, in denen vor allem Bilder, Slider und Banner nachluden. Die Server antworteten im Median nach 0,12 Sekunden.
Ladezeit ist eines der Themen, bei denen fast jeder eine Meinung und kaum jemand eine Messung hat. Shopware gilt mal als schwerfällig, mal als schnell genug. Wir wollten wissen, wie sich echte Shopware-Shops verhalten, wenn man sie unter gleichen Bedingungen lädt — und was den Unterschied macht.
So haben wir gemessen
Für 35 Produktsuchen, von Angelzubehör bis Wanderschuhe, haben wir die organischen Google-Treffer gesammelt und Preisvergleiche und Marktplätze aussortiert. Unter den übrigen Shops haben wir die mit Shopware 6 herausgesucht: Sie verraten sich im HTML durch Merkmale der Storefront, etwa die Pfade für Theme-Dateien. Es blieben 51.
Jede Startseite haben wir dreimal in einem frischen Browser ohne Cache geladen, als Mobilgerät mit gedrosseltem Netz und Prozessor. Diese Einstellung entspricht der Voreinstellung „langsames 4G“ der Chrome-Entwicklerwerkzeuge. Je Shop zählt der Median der drei Läufe. Die Läufe lagen eng beieinander: Im Median wichen sie beim LCP um 60 Millisekunden voneinander ab.
Ergebnis: schneller Anfang, spätes Hauptbild
| Kennzahl | Median | mittlere Hälfte der Shops |
|---|---|---|
| erster Inhalt (FCP) | 2,9 s | 2,5 bis 4,2 s |
| größtes Element (LCP) | 9,6 s | 6,4 bis 21,9 s |
| Layoutverschiebung (CLS) | 0,05 | 0,00 bis 0,32 |
| Blockierzeit nach dem ersten Inhalt | 223 ms | 105 bis 557 ms |
| übertragene Daten | 3,9 MB | 2,1 bis 5,3 MB |
| davon Bilder | 2,2 MB | 1,0 bis 3,7 MB |
| davon JavaScript | 0,9 MB | 0,6 bis 1,2 MB |
| Serverantwort, ungedrosselt | 0,12 s | 0,07 bis 0,21 s |
Auffällig ist der Abstand zwischen den ersten beiden Zeilen. Die meisten Shops zeigten nach knapp drei Sekunden etwas an — Kopfzeile, Navigation, Text. Das größte Element folgte im Median erst 6,6 Sekunden später, bei 30 der 51 Shops lagen mehr als fünf Sekunden dazwischen.
Nur sechs Startseiten erreichten den LCP in unter vier Sekunden, eine davon in unter 2,5. Bei 29 Shops blieb die Layoutverschiebung bei höchstens 0,1, bei 15 lag sie über 0,25.
Befund 1: Der Server war selten das Problem
Ungedrosselt abgerufen, lieferten 34 von 48 Servern den Anfang der Seite in höchstens 0,2 Sekunden. Zwischen dieser Antwortzeit und dem LCP im Labor fanden wir keinen Zusammenhang (Rangkorrelation 0,01). Das heißt nicht, dass Serverzeit egal ist — aber bei diesen Shops lag der Unterschied woanders.
Befund 2: Das größte Element ist meist ein Bild in einer Bühne
Im vierten Lauf haben wir festgehalten, welches Element der Browser als größtes meldete:
| größtes Element | Shops | LCP-Median |
|---|---|---|
| Bild, Video oder Text in einem Slider | 26 | 10,9 s |
| einzelnes Bild oder Video | 17 | 9,4 s |
| Textblock | 5 | 8,2 s |
| Cookie-Banner | 3 | 14,1 s |
Bei der Hälfte der Shops war es ein Slider auf der Startseite. Slider laden oft mehrere große Bilder gleichzeitig und werden erst per JavaScript zusammengesetzt, bevor das erste Bild erscheint. Dass bei drei Shops der Cookie-Banner das größte Element war, zeigt eine Eigenheit der Kennzahl: Gemessen wird das größte sichtbare Element, nicht das wichtigste.
Befund 3: Bildgewicht trennt die Shops
Sortiert man die Shops nach der Datenmenge ihrer Bilder, wird der Unterschied deutlich:
| Drittel nach Bildgewicht | Bilder (Median) | LCP-Median |
|---|---|---|
| leichtestes Drittel | 0,6 MB | 6,7 s |
| mittleres Drittel | 2,2 MB | 10,1 s |
| schwerstes Drittel | 4,4 MB | 23,5 s |
Die Rangkorrelation zwischen Bildgewicht und LCP lag bei 0,55, zwischen JavaScript-Menge und LCP bei 0,21. Mehr JavaScript ging dagegen mit mehr Blockierzeit einher: im leichtesten Drittel 112 Millisekunden, im schwersten 317. Ursache und Wirkung lassen sich aus diesen Zahlen nicht trennen — Shops mit großen Bildern haben oft auch mehr von allem anderen.
Was wir daraus ableiten
Die sechs schnellsten Startseiten der Stichprobe hatten kaum schnellere Server (Median 0,09 statt 0,12 Sekunden), aber deutlich weniger Gewicht: 1,0 statt 2,5 Megabyte Bilder und 1,7 statt 4,2 Megabyte insgesamt. Auch drei von ihnen zeigen einen Slider — er muss also nicht langsam sein, wenn die Bilder darin klein sind. Wer die eigene Startseite verbessern will, beginnt deshalb mit einer Frage: Welches Element ist das größte, und wie schnell ist es da?
Wie ein einzelner Artikel im Warenkorb den Seitencache aushebelt, haben wir in Ein Artikel im Warenkorb kostet den Cache gemessen. Wie wir Ladezeit bei neuen Websites von Anfang an mitplanen, beschreibt unsere Seite zum Webdesign.
Wie wir solche Messungen in eine Optimierung übersetzen — Feld und Labor getrennt —, beschreibt unsere Performance-Optimierung.
Wie Felddaten und Labor zusammenhängen und wie man die Werte für den eigenen Shop liest, steht in Core Web Vitals im Onlineshop messen und lesen.