Website-Ladezeit verbessern: Was wirklich Sekunden bringt

Warum Ladezeit geschäftlich zählt

Ladezeit wirkt auf zwei Ebenen. Sie ist ein bestätigter Rankingfaktor bei Google, und sie entscheidet darüber, ob Besucher bleiben.

Der zweite Punkt wiegt schwerer. Wer auf dem Handy im Mobilfunknetz drei Sekunden auf eine weiße Seite schaut, geht zurück zu den Suchergebnissen. Diese Besucher sieht man in keiner Statistik als verlorene Anfrage – sie tauchen einfach nie auf.

Ursache eins: Bilder, mit großem Abstand

In den allermeisten Fällen machen Bilder den überwiegenden Teil der übertragenen Datenmenge aus. Drei Fehler tauchen dabei regelmäßig auf.

• Unkomprimierte Formate: Ein Foto als PNG statt WebP ist oft fünf- bis zehnmal so groß bei gleicher sichtbarer Qualität.
• Nur eine Größe für alle Geräte: Das Smartphone lädt dieselbe Datei wie der Desktop-Monitor.
• Kein verzögertes Laden: Bilder weit unten auf der Seite werden sofort mitgeladen, obwohl sie niemand sieht.

Ursache zwei: Skripte von Drittanbietern

Jedes eingebundene Werkzeug lädt eigenen Code von fremden Servern: Statistik, Chat-Fenster, Karten, Schriften, Bewertungs-Widgets, Cookie-Banner.

Kritisch wird es, wenn diese Skripte im Kopfbereich der Seite stehen und blockierend geladen werden. Dann wartet der Browser darauf, bevor er überhaupt etwas anzeigt.

Die Lösung ist meist einfach: Solche Skripte gehören ans Ende der Seite und sollten verzögert geladen werden, sobald der Browser Luft hat. Auf dieser Website war der Statistik-Code im Kopfbereich eingebunden und hat den ersten Bildaufbau messbar verzögert – verschoben ans Ende, war das Problem behoben.

Ursache drei: Schriften

Schriften, die von externen Servern nachgeladen werden, kosten Zeit und verursachen oft ein sichtbares Umspringen des Textes, sobald die Schrift ankommt.

Besser ist es, Schriften lokal auszuliefern und dem Browser mitzuteilen, dass er zunächst eine Systemschrift anzeigen soll. Der Text ist dann sofort lesbar.

Zusätzlich lohnt die Frage, wie viele Schriftschnitte wirklich gebraucht werden. Vier Stärken einer Schriftfamilie sind vier Dateien – zwei reichen fast immer.

Was wenig bringt

Einige Maßnahmen werden häufig empfohlen, wirken aber kaum, solange die drei Hauptursachen bestehen.

Ein teureres Hosting-Paket hilft nur, wenn der Server tatsächlich der Engpass ist – bei kleinen Websites ist er das selten. Auch das Zusammenfassen von Dateien bringt bei modernen Verbindungen weniger als früher.

Die Reihenfolge ist entscheidend: Erst die Bilder, dann die Skripte, dann die Schriften. Wer mit Serveroptimierung anfängt, während unkomprimierte Bilder ausgeliefert werden, optimiert am Problem vorbei.

Wie du selbst misst

Zwei kostenlose Werkzeuge reichen für eine belastbare Einschätzung.

Googles PageSpeed Insights zeigt Bewertung und konkrete Verbesserungsvorschläge, sortiert nach Einsparpotenzial. Wichtig ist der Mobilwert, nicht der für Desktop – dort ist die Bewertung strenger und näher an der Realität der meisten Besucher.

Der zweite Test kostet nichts: Ruf deine Seite auf dem eigenen Handy im Mobilfunknetz auf, nicht im WLAN. Was sich dort zäh anfühlt, fühlt sich für Besucher genauso an.

Was wirklich bremst: Render-Blocker vor Bildgröße

Die meisten Ratschläge zur Ladezeit fangen bei den Bildern an. Nach meiner Erfahrung ist das die zweite Baustelle, nicht die erste. Der größere Hebel sind Dateien, die der Browser laden und auswerten muss, bevor er überhaupt etwas anzeigen darf – Stilvorlagen und Schriften.

Ein Beispiel aus einem eigenen Projekt: Der Auftritt eines Biergartens lag bei einem Leistungswert von 78. Ohne ein einziges Bild anzufassen, brachten drei Eingriffe ihn auf 94 bis 96. Erstens wanderte die Stilvorlage direkt in den Seitenkopf, statt als eigene Datei nachgeladen zu werden. Zweitens wurden die Schriften auf dem eigenen Server abgelegt, statt sie von einem fremden anzufordern. Drittens fielen Skripte weg, die niemand mehr brauchte.

Der Grund ist die Reihenfolge: Eine nachgeladene Stilvorlage hält die Darstellung an. Eine Schrift von einem fremden Server verlangt zusätzlich eine neue Verbindung samt Verschlüsselung, bevor das erste Zeichen erscheint. Beides passiert, bevor der Besucher irgendetwas sieht.

Auf dem Telefon zählt jedes Kilobyte

Ein zweites Beispiel, diesmal von dieser Seite selbst. Die Startseite lud auf dem Telefon 117 Kilobyte aus sechs Dateien. Nach dem Umbau waren es 84 Kilobyte aus vier Dateien – ohne dass ein Besucher inhaltlich etwas vermisst.

Der entscheidende Eingriff war unscheinbar: Das große Foto über der Kante wird auf schmalen Schirmen gar nicht mehr angefordert. Wichtig ist dabei das Wie. Ein Bild per Anzeigeregel auszublenden reicht nicht – der Browser lädt es trotzdem. Es muss über eine Breitenregel als Hintergrund eingebunden werden, dann fragt er es auf schmalen Geräten nicht einmal an.

Dazu kam eine Regel, die lange Abschnitte erst dann berechnen lässt, wenn sie in die Nähe des Sichtfelds kommen. Vorsicht dabei: Die Platzhalterhöhen müssen einzeln gemessen werden. Mit einem gemeinsamen Schätzwert für unterschiedlich hohe Abschnitte springt die Seitenhöhe beim Scrollen, und alles darunter verrutscht.

Messen, nicht raten – und nicht aus einem Lauf schließen

Prüfe mit PageSpeed Insights, aber lies das Ergebnis richtig. Der Wert oben ist ein Laborwert unter festen Bedingungen. Darunter stehen, sofern genug Besucher da sind, die Felddaten echter Nutzer – die zählen.

Und eine Warnung aus eigener Erfahrung: Diese Werte streuen. Auf dieser Seite schwankt der Mobilwert zwischen 98 und 100, allein über eine einzige Teilmessung, bei völlig identischer Seite. Wer aus einem einzelnen Lauf eine Verschlechterung abliest, jagt Gespenster. Miss mehrfach und achte auf den Trend.

Die drei Größen, auf die es ankommt, heißen LCP für das größte Element über der Kante, INP für die Reaktion auf Eingaben und CLS für das Springen des Layouts. Für LCP gelten 2,5 Sekunden als gut, für INP 200 Millisekunden, für CLS ein Wert von 0,1.