Ladezeit: was Ihre Besucher wirklich merken

„Die Seite ist zu langsam“ ist eine Diagnose ohne Befund. Ladezeit besteht aus mehreren Abschnitten, und nur einer davon entscheidet über den ersten Eindruck.

Drei Werte, drei verschiedene Ursachen

Die Antwortzeit des Servers

Vom Klick bis zum ersten Byte: Wie lange braucht der Server, um überhaupt etwas zu schicken? Alles unter 200 Millisekunden ist gut, ab etwa 600 wird es spürbar. Ist dieser Wert schlecht, liegt es fast nie am Design und fast immer am Hosting, an einer überladenen Datenbank oder an zu vielen Plugins, die bei jedem Aufruf mitlaufen.

Das ist der Wert, den unser Test misst – er lässt sich von außen sauber bestimmen, ohne Annahmen über das Gerät des Besuchers.

Bis etwas Sichtbares erscheint

Danach lädt der Browser das Stylesheet, oft mehrere Schriften und JavaScript. Solange das läuft, bleibt die Seite weiß. Hier entscheidet sich, ob eine Seite „schnell“ wirkt.

Bis das größte Element steht

Meist ist das ein großes Bild im oberen Bereich. Google misst diesen Punkt als „Largest Contentful Paint“ und hält 2,5 Sekunden für die Grenze zum Guten.

Der häufigste Fehler: an der Serverzeit optimieren, wenn das Problem ein vier Megabyte großes Hintergrundbild ist. Erst messen, dann handeln.

Was am meisten bringt

Bilder in der richtigen Größe

Das ist mit Abstand der größte Hebel. Ein Foto aus der Handykamera hat gern 4000 Pixel Breite und mehrere Megabyte. Angezeigt wird es in 800 Pixel Breite. Der Browser lädt trotzdem alles.

Was hilft:

• Auf die tatsächliche Anzeigegröße skalieren, bevor das Bild hochgeladen wird.
• Modernes Format verwenden. WebP ist bei gleicher Qualität deutlich kleiner als JPEG und wird von allen aktuellen Browsern unterstützt.
• Bilder außerhalb des sichtbaren Bereichs verzögert laden – mit loading="lazy". Beim obersten Bild gehört das ausdrücklich nicht hin, das soll sofort kommen.
• Breite und Höhe im HTML angeben. Sonst springt das Layout, sobald das Bild eintrifft – lästig für Besucher und ein eigener Google-Messwert.

Skripte, die den Aufbau blockieren

Ein <script> ohne Zusatz hält den Seitenaufbau an, bis es geladen und ausgeführt ist. Bei drei, vier solchen Skripten summiert sich das. Die Attribute defer und async lösen das: Das Skript wird geladen, ohne den Aufbau zu stoppen.

Unser Test zählt deshalb, wie viele blockierende Skripte im HTML stehen. Mehr als drei sind ein Hinweis, dass sich hier etwas holen lässt.

Schriften selbst hosten und vorladen

Schriften von fremden Servern kosten eine zusätzliche Verbindung – und sind datenschutzrechtlich heikel. Liegen sie auf dem eigenen Server, hilft ein preload-Hinweis im Kopf der Seite: Sonst entdeckt der Browser die Schrift erst, nachdem er das Stylesheet gelesen hat.

Was wenig bringt

• Ein CDN für eine rein regionale Seite. Wenn die Besucher aus einem Umkreis von fünfzig Kilometern kommen, bringt ein weltweites Auslieferungsnetz kaum etwas. Ein Server in der Region tut es genauso.
• Minifizierung von CSS und JavaScript, wenn die Dateien ohnehin klein sind. Ein paar Kilobyte gegenüber einem Megabyte-Bild sind Rundungsfehler.
• Caching-Plugins als erste Maßnahme. Sie helfen bei der Serverzeit, ändern aber nichts an zu großen Bildern.

Der ehrliche Teil

Ladezeit ist ein Rankingfaktor, aber ein schwacher. Eine Seite rutscht nicht nach oben, nur weil sie schnell ist – und eine gute Seite fällt nicht ab, weil sie eine halbe Sekunde länger braucht.

Wo es wirklich zählt, ist der Abbruch. Wer auf dem Mobiltelefon mit mäßigem Empfang drei Sekunden auf eine weiße Seite schaut, geht zurück zur Suchergebnisliste und ruft beim Nächsten an. Deswegen lohnt sich der Aufwand – nicht wegen Google.