Ihre Website lädt länger als drei Sekunden? Dann ist ein Teil Ihrer Besucher in diesem Moment schon wieder weg. Nicht vielleicht, sondern messbar.
Eine viel zitierte Google-Analyse fand: 53 Prozent der mobilen Nutzer verlassen eine Seite, die länger als drei Sekunden lädt. Und je langsamer es wird, desto schneller kippt es. Steigt die Ladezeit von einer auf fünf Sekunden, erhöht sich die Wahrscheinlichkeit eines Absprungs um rund 90 Prozent. Das ist kein Rundungsfehler, das ist fast jeder zweite Besucher.
Wie schnell muss eine Website wirklich laden?
Google bewertet Website-Tempo über die Core Web Vitals. Drei Werte entscheiden, ob eine Seite als gut oder schlecht gilt:
- Largest Contentful Paint (LCP): Der größte sichtbare Inhalt sollte in unter 2,5 Sekunden stehen. Alles darüber ist im roten Bereich.
- Interaction to Next Paint (INP): Die Seite sollte innerhalb von 200 Millisekunden auf eine Eingabe reagieren. Träge Buttons kosten Vertrauen.
- Cumulative Layout Shift (CLS): Während des Ladens darf nichts springen oder verrutschen. Ziel ist ein Wert unter 0,1.
Wer diese Werte reißt, rutscht im Google-Ranking nach unten. Nicht als Strafe, sondern weil Google Seiten bevorzugt, die Nutzer nicht frustrieren.
Was macht Websites eigentlich langsam?
Die Ursachen sind fast immer dieselben. Keine Raketenwissenschaft, aber erstaunlich verbreitet:
- Unkomprimierte Bilder. Ein einziges Hero-Bild mit 4 MB reicht, um die Ladezeit zu verdoppeln. Mit WebP und ordentlicher Komprimierung sind es 100 bis 200 KB, ohne sichtbaren Qualitätsverlust.
- Zu viele Plugins und Skripte. WordPress-Seiten mit 30 und mehr Plugins laden oft zwanzig externe Skripte, bevor der Nutzer überhaupt etwas sieht. Jedes davon ist eine zusätzliche Anfrage, die den Browser ausbremst.
- Billiges Hosting. Shared Hosting für drei Euro im Monat teilt sich einen Server mit Hunderten anderer Seiten. Die Serverantwort (Time to First Byte) liegt dann schnell bei 800 Millisekunden statt 200.
- Kein Caching. Ohne Caching lädt ein wiederkehrender Besucher jedes Mal alles neu. Das ist, als würde man bei jedem Besuch die Eingangstür neu einbauen.
- Render-blockierendes CSS und JavaScript. Muss der Browser erst alle Stylesheets und Skripte abarbeiten, bevor er etwas anzeigt, starrt der Nutzer so lange auf eine weiße Seite.
Was kostet eine langsame Website konkret?
Rechnen wir es durch. Ihre Website hat 1.000 Besucher im Monat. Bei einer Ladezeit über drei Sekunden verlieren Sie rund 53 Prozent davon sofort, es bleiben etwa 470. Wenn davon 2 Prozent zu einer Anfrage werden, sind das neun Anfragen.
Eine schnelle Seite unter zwei Sekunden hält deutlich mehr Besucher. Bleiben grob 850, dann sind es bei gleicher Conversion-Rate rund 17 Anfragen, also fast doppelt so viele. Bei einem durchschnittlichen Auftragswert von 2.000 Euro reden wir über 16.000 Euro Unterschied im Monat.
Eine Auswertung von Portent stützt das: Die Conversion-Rate sinkt mit jeder zusätzlichen Sekunde Ladezeit (0 bis 5 Sekunden) im Schnitt um rund 4,4 Prozent, und eine Seite, die in einer Sekunde lädt, konvertiert etwa zweieinhalbmal so gut wie eine mit fünf Sekunden. Wie Sie aus dem so gewonnenen Traffic mehr Anfragen machen, steht in unserem Leitfaden zur Conversion-Optimierung.
Warum schneiden so viele Agentur-Websites schlecht ab?
Testen Sie es selbst: Geben Sie die Website Ihres Webdesigners bei PageSpeed Insights ein. Oft liegt der Score zwischen 30 und 50.
Der Grund: Viele Agenturen setzen auf schwere Page-Builder wie Elementor oder Divi. Die machen das Bauen einfach, aber den Output schwer. Eine typische Elementor-Seite lädt ein bis zwei Megabyte CSS und JavaScript, bevor auch nur ein Buchstabe sichtbar ist.
Das ist kein Vorwurf, sondern ein Geschäftsmodell-Problem. Page-Builder sparen Entwicklungszeit und kosten Performance. Die Rechnung zahlt der Kunde, mit weniger Sichtbarkeit und weniger Anfragen. Genau deshalb bauen wir Websites ohne diesen Ballast, und Shops unter E-Commerce-Entwicklung ebenso.
Wie prüfe ich die Geschwindigkeit meiner Website?
Zwei Tools reichen:
- Google PageSpeed Insights misst die Core Web Vitals auch mit echten Nutzerdaten. Ein Score unter 90 heißt: da geht was.
- GTmetrix zeigt im Detail, welche Datei wie lange lädt und wo die Engpässe sitzen. Praktisch für die Wasserfall-Analyse.
Wichtig: immer mobil testen. Der größere Teil der Zugriffe kommt vom Handy. Eine Seite, die nur am Desktop schnell ist, hilft Ihnen wenig.
Was bringt eine Performance-Optimierung in der Praxis?
Bei einem Hamburger Handwerksbetrieb haben wir die Ladezeit von 6 auf 1,2 Sekunden gedrückt. Die Anfragen verdreifachten sich, der PageSpeed-Score stieg von 34 auf 98. Die Website war dieselbe, nur ohne den Ballast.
Die Maßnahmen waren keine Hexerei: Bilder in WebP umgewandelt, ungenutztes CSS entfernt, kritisches CSS inline geladen, JavaScript auf Lazy Loading umgestellt und Server-Caching aktiviert. Zusammen hat das zwei Tage gedauert.
Der Punkt ist: Performance ist kein nettes Extra. Sie ist die einfachste Methode, mehr aus dem vorhandenen Traffic zu holen, ohne einen Cent mehr für Werbung. Wenn ein kompletter Neuaufbau sinnvoller ist, hilft unsere Website-Relaunch-Checkliste bei der Planung.
Was Sie jetzt tun sollten
- Website bei PageSpeed Insights testen und den Score notieren.
- Bilder prüfen: Format, Größe, Komprimierung.
- Hosting hinterfragen: liegt die TTFB unter 200 Millisekunden?
- Plugins und Skripte zählen und ehrlich aussortieren.
- Die Core Web Vitals als Messlatte nehmen, nicht das Bauchgefühl.
Tempo ist kein technisches Detail. Es ist der erste Eindruck Ihrer Website, und der entscheidet, ob jemand bleibt oder geht. Wollen Sie wissen, wo Ihre Seite steht? Fordern Sie eine kostenlose Analyse an.
Quellen
- Think with Google, „Mobile Page Speed New Industry Benchmarks": 53 % der mobilen Nutzer verlassen Seiten mit über 3 s Ladezeit. thinkwithgoogle.com
- Portent, „Site Speed Is Still Impacting Your Conversion Rate" (2022): ~4,4 % weniger Conversion pro zusätzlicher Sekunde (0–5 s); 1 s konvertiert ~2,5× besser als 5 s. portent.com
- Google, web.dev: Schwellenwerte der Core Web Vitals (LCP, INP, CLS). web.dev/vitals
