Die Produktseite reagiert verzögert, nachdem jemand eine andere Größe auswählt. Ein gutes Ergebnis für das erstmalige Laden würde dieses Problem noch nicht ausräumen. Bevor du das Budget für eine schnellere Website kalkulierst, brauchst du den betroffenen Schritt und eine passende Messung.

Für die Budgetrechnung fehlt anschließend noch die Annahme zur Nutzung: Was würde sich an den Bestellungen oder Anfragen ändern, wenn die Verzögerung behoben wäre? Aus einer gemessenen Sekunde lässt sich dieser Wert nicht ableiten.

Erst das technische Problem beschreiben

Die Core Web Vitals erfassen, wann der Hauptinhalt erscheint (LCP), wie die Seite auf Interaktionen reagiert (INP) und wie stark sich Inhalte unerwartet verschieben (CLS). Für die stockende Größenauswahl interessiert besonders die Reaktion auf den Eingabewechsel.

Notiere eine betroffene Seite, das Gerät und die Handlung. Lädt das Hauptbild spät? Reagiert die Variantenauswahl erst nach einer Pause? Springt ein Button beim Nachladen weg? Prüfe nach einer Änderung denselben Weg unter vergleichbaren Bedingungen. Laborwerte und Messungen tatsächlicher Besuche liefern dabei unterschiedliche Einblicke.

Die Rechnung braucht eine eigene Wirkungsannahme

Für einen bestehenden Shop kannst du fragen, was zusätzliche Bestellungen bedeuten würden. Für eine Dienstleistungswebsite geht es eher um Anfragen. Der Rechner wandelt einen Geschwindigkeitswert bewusst nicht in eine angenommene Conversion-Verbesserung um.

Fiktive Shop-Rechnung: 5.000 monatliche Besuche, 2 Prozent Bestellrate und eine selbst gewählte relative Verbesserung von 5 Prozent ergeben fünf zusätzliche Bestellungen. Bei 100 Euro Nettobestellwert und 30 Prozent Deckungsbeitrag sind das 150 Euro zusätzlicher monatlicher Deckungsbeitrag.

Kostet die Änderung angenommen 1.800 Euro einmalig, braucht einen vollen Monat ohne Wirkung und verursacht keine neuen laufenden Kosten, ergibt sich nach zwölf Monaten: 11 × 150 Euro − 1.800 Euro = −150 Euro Saldo. Die gewählte Verbesserung reicht im ersten Jahr rechnerisch noch nicht aus. Mit null Wirkung blieben die vollen 1.800 Euro als Aufwand.

Eine Performance-Maßnahme für den Shop durchrechnen. Für einen Kontaktweg lässt sich stattdessen die Anfragenrechnung verwenden.

Den Eingriff auf die Ursache begrenzen

Aus einer langsamen Seite folgt kein automatischer Neubau. Die Ursache kann in Bildern, geladenem Fremdcode, Datenabfragen oder einer einzelnen Interaktion liegen. Welche davon zutrifft, muss am bestehenden System geprüft werden. Ein pauschaler Wechsel würde zusätzliche Kosten einführen, bevor die Ursache geklärt ist.

Die Ladezeiten-Analyse ist zur Eingrenzung gedacht. Eine bereits beschriebene technische Änderung passt eher zur Frontend-Optimierung. Beschreibt dein Problem dagegen langsam antwortende Serverfunktionen, muss der Prüfbereich auch diese Seite des Systems einschließen.

Bei wenigen Besuchen lassen sich kleine Unterschiede in der Bestellzahl schwer einer einzelnen Änderung zuordnen. Prüfe dann zuerst den beobachteten Bedienfehler technisch: Reagiert die Größenauswahl nach dem Eingriff unter denselben Bedingungen zügiger? Für die Umsatzwirkung bleibt die Datenbasis vorerst zu dünn.