Die Felddaten, nach denen ein Shop bewertet wird, entstehen über ein rollierendes Fenster von 28 Tagen. Wer am 20. November etwas repariert, sieht die Wirkung frühestens Mitte Dezember, also nach dem Aktionswochenende. Das ist der eigentliche Grund, warum die Messung in den September gehört und nicht in den November.

Der zweite Grund ist praktischer Natur. Eine langsame Kategorieseite fällt bei dreißig gleichzeitigen Besuchern nicht auf und bei dreitausend sofort. Was im Herbst wie ein Schönheitsfehler aussieht, ist am Aktionstag eine Abbruchquelle, und dann fehlt die Zeit für sauberes Arbeiten.

Diese Prüfliste ist auf einen Vormittag ausgelegt. Sie führt von der Messung über die drei häufigsten Bremsen bis zur Reihenfolge der Behebung, und jeder Punkt hat ein Abnahmekriterium, an dem sich ablesen lässt, ob er erledigt ist oder nicht.

• Aufwand: ein Vormittag für die Messung, danach gezielte Eingriffe
• Datenquelle: Felddaten aus echten Aufrufen, nicht der Laborwert eines Einzeltests
• Bewertungsgrundlage: das 75. Perzentil, nicht der Durchschnitt
• Reaktionszeit: bis zu vier Wochen, bis eine Verbesserung in den Felddaten steht
• Reihenfolge: Serverantwort, dann größtes Element, dann fremde Skripte, dann Layoutsprünge
• Getrennt prüfen: mobil und Desktop werden separat bewertet

Warum die Messung im September stattfindet

Zwischen einer Änderung im Shop und ihrer Sichtbarkeit in den Felddaten liegen Wochen, nicht Stunden. Der Grund ist die Art der Erhebung: Es werden echte Aufrufe echter Besucher über einen längeren Zeitraum zusammengefasst. Ein einzelner guter Tag verschwindet in diesem Durchschnitt.

Daraus folgt ein harter Termin. Wer will, dass die verbesserten Werte am Aktionstag in den Daten stehen, muss spätestens Ende Oktober fertig sein. Rechnet man Analyse, Umsetzung und Test dazu, ist September der letzte bequeme Zeitpunkt.

Und es gibt einen dritten Grund, der nichts mit Suchmaschinen zu tun hat: Im September kann man einen Fehler machen, ohne dass es teuer wird. Im November kostet ein missglückter Eingriff Umsatz, und das Risiko lässt niemand mehr zu.

Core Web Vitals messen: Felddaten statt Laborwerte

Ein Laborwert entsteht in einem einzelnen simulierten Durchlauf, mit fest eingestellter Verbindung und ohne Einwilligungsdialog, ohne eingeloggten Warenkorb, ohne Werbeskripte, die zu unterschiedlichen Zeiten laden. Er ist gut für Vorher-Nachher-Vergleiche derselben Seite und ungeeignet als Bestandsaufnahme.

Felddaten kommen dagegen aus echten Aufrufen mit echten Geräten, echten Verbindungen und echten Einwilligungsdialogen. Sie sind das, wonach bewertet wird, und sie erklären auch Abweichungen: Ein Laborwert von 1,8 Sekunden neben einem Feldwert von 4,2 Sekunden bedeutet meistens, dass etwas erst nach dem ersten Aufruf dazukommt.

Praktisch heißt das: Zuerst die Felddaten für Startseite, eine Kategorieseite, eine Produktseite und den Warenkorb ansehen. Erst wenn klar ist, welcher Seitentyp schlecht abschneidet, lohnt sich der Einzeltest im Labor, um die Ursache einzugrenzen.

Die drei Werte und ihre Schwellen

Zwischen „gut“ und „schlecht“ liegt jeweils ein Bereich, der als verbesserungsbedürftig gilt. Für die Prüfliste zählt nur eines: Steht ein Seitentyp außerhalb des grünen Bereichs, kommt er auf die Liste.

Was das 75. Perzentil in der Praxis bedeutet

Bewertet wird nicht der Durchschnitt, sondern der Wert, den drei Viertel aller Aufrufe erreichen. Ein Viertel der Besucher darf also langsamer unterwegs sein, ohne dass die Seite durchfällt. Umgekehrt reicht es nicht, dass die Hälfte der Aufrufe schnell ist.

Das erklärt einen häufigen Widerspruch. Im Büro lädt der Shop in 1,2 Sekunden, in den Daten steht 3,9. Das Büro sitzt am Kabel mit einem neuen Rechner, die realen Besucher an einem drei Jahre alten Telefon im Mobilfunknetz.

Für die Praxis folgt daraus: Testgerät ist ein Mittelklasse-Telefon, nicht das aktuelle Modell. Wer nur auf schnellen Geräten prüft, misst eine Seite, die es so nicht gibt.

Die Prüfliste mit Abnahmekriterium

1. Felddaten für vier Seitentypen ausgelesen. Bestanden, wenn Startseite, Kategorie, Produkt und Warenkorb einzeln vorliegen.
2. Mobile und Desktop getrennt notiert. Bestanden, wenn es zwei Zahlenreihen gibt statt einer.
3. Serverantwortzeit der Kategorieseiten gemessen. Bestanden, wenn die Antwort auch ohne Cache unter einer halben Sekunde bleibt.
4. Cache für anonyme Besucher geprüft. Bestanden, wenn eine Kategorieseite im zweiten Aufruf aus dem Cache kommt.
5. Größtes sichtbares Element je Seitentyp bestimmt. Bestanden, wenn Sie es benennen können, ohne zu raten.
6. Alle Bildflächen mit Breiten- und Höhenangabe versehen. Bestanden, wenn kein sichtbarer Sprung beim Laden auftritt.
7. Fremde Skripte gezählt und nach Notwendigkeit sortiert. Bestanden, wenn jedes verbleibende Skript einen Verantwortlichen im Haus hat.
8. Einwilligungsdialog auf Sprungverhalten geprüft. Bestanden, wenn der Inhalt darunter nicht verrutscht.
9. Schriften mit Ausweichdarstellung geladen. Bestanden, wenn Text sofort sichtbar ist, auch bevor die Schrift da ist.
10. Reaktionszeit auf Klicks in Filter und Warenkorb gemessen. Bestanden, wenn die Rückmeldung unter zwei Zehntelsekunden bleibt.
11. Lasttest auf einem Testsystem gefahren. Bestanden, wenn die Antwortzeit bei fünffachem Aufkommen nicht mehr als das Doppelte beträgt.
12. Beobachtung für den Aktionstag eingerichtet. Bestanden, wenn jemand namentlich zuständig ist.

Zwölf Punkte, davon acht an einem Vormittag prüfbar. Die vier übrigen brauchen Zugriff auf Server und Testsystem und gehören deshalb in die Woche danach.

Bremse 1: der Server antwortet zu langsam

Die erste Bremse liegt vor allem anderen. Solange der Server eine Sekunde braucht, bis er das erste Byte schickt, ist jede Optimierung im Frontend Kosmetik. In Shopsystemen entsteht diese Verzögerung meist an drei Stellen: an Kategorieseiten mit vielen Filtern, an unnötig geladenen Erweiterungen und an Abfragen, die für jedes Produkt einzeln laufen.

Der schnellste Hebel ist ein funktionierender Seiten-Cache für nicht angemeldete Besucher. Er verwandelt eine berechnete Seite in eine ausgelieferte Datei. Wichtig ist zu prüfen, ob er überhaupt greift: Ein Warenkorb-Element im Kopfbereich hebelt in vielen Konfigurationen den kompletten Cache aus.

Prüfen lässt sich das ohne Spezialsoftware. Kategorieseite zweimal aufrufen, Antwortzeit vergleichen. Bleibt der zweite Aufruf gleich langsam, arbeitet kein Cache, und das ist der erste Punkt auf der Liste.

Bremse 2: Skripte von Dritten blockieren den Hauptthread

Einwilligungsdialog, Bewertungswidget, Chatfenster, Kartenanbieter, zwei Messpixel, ein Empfehlungsdienst: In gewachsenen Shops kommen schnell fünfzehn fremde Skripte zusammen. Jedes einzelne wirkt harmlos, gemeinsam belegen sie den Hauptthread und verzögern jede Eingabe.

Das trifft vor allem die Reaktionszeit auf Klicks. Der Besucher tippt auf einen Filter, es passiert eine halbe Sekunde nichts, er tippt erneut, und der Filter schaltet zweimal. Genau dieses Muster taucht später in Aufzeichnungen auf und wird fälschlich als Bedienfehler gedeutet.

Vorgehen: Liste aller geladenen fremden Skripte erstellen, jedem einen Verantwortlichen zuordnen und alles streichen, was niemandem gehört. In der Praxis fällt dabei regelmäßig ein Drittel weg, ohne dass es jemand vermisst. Der Rest wird verzögert geladen, soweit er nicht für die erste Ansicht gebraucht wird.

Bremse 3: Bilder ohne Maße und ohne Priorität

Das größte sichtbare Element ist auf Produktseiten fast immer das Hauptbild. Wird es spät geladen, in voller Auflösung ausgeliefert oder erst nach einem Skript eingesetzt, dauert der Aufbau entsprechend lange.

Zwei Eingriffe reichen meist. Erstens: Das Bild der ersten Ansicht wird nicht verzögert geladen, alle Bilder darunter schon. Zweitens: Breite und Höhe stehen fest, damit der Browser den Platz reservieren kann, bevor die Datei da ist. Ohne diese Angaben springt der Text nach unten, sobald das Bild erscheint.

Dazu kommt die Auslieferungsgröße. Ein Produktfoto mit 2400 Pixel Breite auf einer 390 Pixel breiten Anzeige kostet Ladezeit ohne sichtbaren Nutzen. Moderne Formate und eine passende Größenauswahl je Bildschirm lösen das, und beides gehört in der Regel zum Shopsystem dazu.

Der Einwilligungsdialog ist meistens der teuerste Baustein

Er lädt früh, er blockiert, er schiebt Inhalte, und er ist rechtlich notwendig. Damit ist er der Baustein mit dem schlechtesten Verhältnis aus Wirkung und Kosten, und gleichzeitig der, an dem am seltensten jemand arbeitet.

Zwei Dinge lassen sich fast immer verbessern. Erstens die Darstellung: Ein Dialog, der über dem Inhalt liegt, verschiebt nichts. Einer, der Inhalt nach unten drückt, erzeugt genau den Sprung, der in die Bewertung eingeht. Zweitens die Ladereihenfolge: Der Dialog muss vor den Messskripten kommen, nicht vor dem Seiteninhalt.

Bevor daran jemand schraubt, gehört die Konfiguration einmal fachlich geprüft. An dieser Stelle geht es nicht nur um Ladezeit, sondern um Pflichten, und die Reihenfolge darf nicht dazu führen, dass Skripte vor der Einwilligung starten.

Schriften: der Sprung, den niemand einplant

Eigene Schriften laden nach. In der Zwischenzeit zeigt der Browser entweder nichts oder eine Ersatzschrift, und beim Wechsel verschiebt sich das Layout, weil die Buchstabenbreiten nicht übereinstimmen. Auf Produktseiten mit langen Titeln fällt das besonders auf.

Die Lösung besteht aus drei Schritten: Text sofort in einer Ersatzschrift anzeigen, die Ersatzschrift in ihren Maßen an die Zielschrift angleichen und die Anzahl der Schriftschnitte reduzieren. Vier Schnitte sind für die meisten Shops mehr als genug.

Der Effekt ist klein, aber er ist billig zu haben und dauerhaft. Bei Layoutsprüngen summieren sich viele kleine Ursachen, und die Schrift ist eine, die sich in einer Stunde erledigen lässt.

In welcher Reihenfolge repariert wird

Die Reihenfolge ist nicht beliebig, weil jede Stufe die nächste beeinflusst. Zuerst die Serverantwort, weil sie unter allem liegt. Dann das größte sichtbare Element, weil es den auffälligsten Wert bestimmt. Dann die fremden Skripte, weil sie die Reaktionszeit verderben. Zuletzt die Layoutsprünge.

Wer diese Reihenfolge umdreht und mit Bildmaßen anfängt, misst hinterher dieselben schlechten Werte, weil der Server unverändert langsam antwortet. Umgekehrt verbessert eine schnellere Serverantwort meist mehrere Kennzahlen gleichzeitig.

Zwischen den Stufen wird gemessen, nicht am Ende. Sonst weiß niemand, welcher Eingriff gewirkt hat, und beim nächsten Mal beginnt die Diskussion von vorn. Wie sich solche Messpunkte sauber aufsetzen lassen, beschreibt unser Beitrag zur Rolle von Analytics im Marketing.

Mobile Werte werden getrennt betrachtet

Mobil und Desktop werden getrennt erhoben und getrennt bewertet. In vielen Shops sind die mobilen Werte deutlich schlechter, und weil der überwiegende Teil des Traffics mobil kommt, entscheidet diese Spalte über das Gesamtbild.

Die Ursachen sind andere als am Desktop: schwächere Geräte, wechselnde Verbindung, kleinere Ansicht mit größeren relativen Bildern, klebende Leisten am oberen und unteren Rand. Ein Desktop-Test findet davon nichts.

Deshalb gehört zu jeder Prüfung ein Durchlauf auf einem echten Telefon, in einem Mobilfunknetz, außerhalb des Büro-WLANs. Weitere Punkte, die dabei auffallen, ordnet unser Beitrag zur Responsivität im digitalen Marketing ein.

Statt fremder Benchmarks: die eigene Zahl messen

Zu Ladezeit und Umsatz kursieren viele Zahlen, meist aus großen internationalen Shops, oft ohne nachvollziehbare Methode und selten auf einen mittelständischen Shop im deutschsprachigen Raum übertragbar. Solche Werte taugen als Argument in einer Präsentation und nicht als Grundlage für eine Entscheidung.

Belastbar ist nur die eigene Messung. Vergleichen Sie über denselben Zeitraum Sitzungen mit schneller und langsamer Auslieferung und sehen Sie sich an, wie sich Absprünge und Bestellungen unterscheiden. Das ist keine perfekte Kausalität, aber es ist Ihre Zahl.

Wer das kombiniert mit einer Auswertung nach Gerät und Kanal, hat nach einer Stunde eine Größenordnung, mit der sich intern arbeiten lässt. Ergänzende Methoden dazu stehen in unserem Text über Techniken der Conversion-Optimierung.

Lasttest, bevor der erste Aktionstag kommt

Ein Lasttest beantwortet eine Frage, die keine Messung beantwortet: Was passiert, wenn statt dreißig Besuchern dreitausend gleichzeitig da sind. Getestet wird auf einem Testsystem mit derselben Ausstattung, nicht auf dem laufenden Shop.

Interessant ist dabei weniger der Durchschnitt als der Punkt, an dem die Antwortzeit kippt. Bis dahin ist alles gut, danach steigen die Zeiten steil an, und genau diese Grenze sollte man kennen, bevor eine Kampagne sie überschreitet.

Was daraus folgt, ist eine Entscheidung: mehr Ausstattung buchen, den Cache anders schneiden oder den Zugriff über eine Warteschlange steuern. Alle drei Wege brauchen Vorlauf, und deshalb wird im September getestet.

Was am Aktionstag selbst beobachtet wird

Am Tag zählen drei Dinge: Antwortzeiten, Fehlercodes und Abschlüsse im Checkout. Diese drei Kurven gehören auf einen Bildschirm, und eine Person schaut regelmäßig hin. Alles andere kann warten.

Steigen die Antwortzeiten, wird zuerst reduziert statt repariert: Empfehlungsmodule aus, Filteroptionen begrenzen, nicht zwingende Skripte abschalten. Ein Shop, der schlichter aussieht und funktioniert, verkauft mehr als ein vollständiger, der hängt.

Und für den Notfall gilt: Eine kurze Wartungsphase mit dem passenden Statuscode ist besser als eine halbe Stunde mit halb geladenen Seiten. Diese Entscheidung trifft man vorher, nicht um 21 Uhr am Aktionstag.

Häufige Fragen

Reicht ein einzelner Test der Startseite?

Nein. Startseiten sind meist schlanker als Kategorie- und Produktseiten und liefern deshalb ein zu freundliches Bild. Gemessen werden vier Seitentypen, und der Warenkorb ist der wichtigste davon.

Wie schnell wirkt sich eine Verbesserung aus?

In der Wahrnehmung der Besucher sofort, in den Felddaten erst nach und nach, weil dort ein längerer Zeitraum zusammengefasst wird. Rechnen Sie mit mehreren Wochen, bis der neue Wert vollständig durchschlägt.

Muss ich für die Messung ein Werkzeug kaufen?

Für den Einstieg nicht. Die kostenlosen Berichte der Suchmaschinenanbieter und die eigenen Serverdaten reichen, um die drei Bremsen zu finden. Bezahlte Werkzeuge lohnen sich, wenn dauerhaft überwacht werden soll.

Was ist mit Werbeanzeigen im Shop?

Sie zählen wie jedes andere fremde Skript und wirken sich vor allem auf Layoutsprünge aus. Feste Platzhalterflächen mit reservierter Höhe lösen den größten Teil des Problems.

Lohnt sich der Aufwand für einen kleinen Shop?

Die ersten drei Punkte der Liste lohnen sich immer, weil sie wenig kosten und viel bewirken. Lasttest und dauerhafte Überwachung lohnen sich ab dem Punkt, an dem ein Ausfall an einem Tag mehr kostet als die Vorbereitung.

Setzen Sie sich einen Vormittag in den Kalender, messen Sie vier Seitentypen und schreiben Sie die drei schlechtesten Werte auf. Der Rest der Liste ergibt sich daraus fast von selbst, und im November bleibt Zeit für die Dinge, die sich nicht vorbereiten lassen. Wer tiefer einsteigen will, findet die technischen Grundlagen frei zugänglich auf web.dev.