Geschwindigkeit entscheidet: Was eine langsame Website wirklich kostet

Ladezeit ist eine Umsatzkennzahl. Keine technische Kennzahl — eine Umsatzkennzahl. Amazon hat berichtet, dass jede zusätzliche Latenz von 100 ms 1 Prozent des Umsatzes kostet. Googles eigene Daten zeigen, dass die Bounce-Rate um 32 Prozent steigt, wenn die Ladezeit von 1 s auf 3 s anwächst.

Ihre Website ist vermutlich auf Arten langsam, die Sie noch nicht gemessen haben.

Die tatsächlichen Zahlen

Largest Contentful Paint (LCP) ist die Kennzahl, die am stärksten mit der Conversion korreliert. Googles Schwellenwerte:

• Gut: unter 2,5 s
• Verbesserungswürdig: 2,5 s bis 4 s
• Schlecht: über 4 s

Die meisten Business-Websites, die wir auditieren, liegen im Bereich von 3 bis 6 s. Die Lücke zwischen 6 s und 2 s ist kein Design-Erfolg — sie ist ein Conversion-Rate-Erfolg, der sich direkt im Umsatz zeigt.

Wo die Zeit verloren geht

Bilder — nicht optimierte Bilder sind die häufigste Ursache. Ein 4 MB großes Hero-Bild, das mobilen Nutzern ausgeliefert wird, ist eine 4-MB-Steuer auf jeden ersten Eindruck.

Drittanbieter-Skripte — Analytics, Chat-Widgets, Werbe-Pixel. Jedes blockiert das Rendering. Eine typische Marketing-Website lädt 8 bis 12 Drittanbieter-Skripte.

Render-blockierende Ressourcen — CSS und JS, die im Document-Head geladen werden und den Browser daran hindern, irgendetwas zu zeichnen.

Server-Antwortzeit (TTFB) — wenn Ihr Server 800 ms zum Antworten braucht, schließt keine Frontend-Optimierung diese Lücke.

Client-seitiges Rendering — SPAs, die eine leere HTML-Seite ausliefern und dann hydrieren, sind beim ersten Laden inhärent langsam.

Der Fix-Stack

Für die meisten Websites die Fixes mit der höchsten Hebelwirkung in dieser Reihenfolge:

1. Wechsel zu einer CDN-Edge-Runtime — Vercel, Cloudflare Pages oder ähnliches. Sub-100-ms-TTFB weltweit.
2. Optimierte Bilder ausliefern — next/image oder Cloudflare Image Resizing verwenden. WebP, korrekte Abmessungen, Lazy Loading.
3. Nicht-kritische Skripte aufschieben — Analytics und Chat-Widgets erst nach Interaktivität der Seite laden.
4. Render-blockierendes CSS eliminieren — kritisches CSS inline einbetten, den Rest aufschieben.
5. Auf Server-Rendering umstellen — HTML vorrendern, damit Nutzer den Content sofort sehen.

Korrekt messen

Testen Sie Performance nicht aus Ihrem Büro auf einer schnellen Maschine. Verwenden Sie:

• WebPageTest mit einer mobilen 4G-gedrosselten Verbindung
• Lighthouse CI in Ihrer Build-Pipeline, um Regressionen abzufangen
• Core Web Vitals in der Google Search Console für reale Nutzerdaten

Das Ziel ist, auf einem Mittelklasse-Android-Telefon in einem überlasteten Mobilfunknetz sichtbar schnell zu sein. Alles andere ist Optimierung für ein Publikum, das es ohnehin nicht bemerken würde.