Ladezeit verbessern: Die Hebel, die wirklich etwas bringen

01Was langsam wirklich kostet

Ehrlich betrachtet: Geschwindigkeit ist kein Selbstzweck.

Über Ladezeit wird viel Unsinn geschrieben, meistens mit Prozentzahlen, die niemand nachprüfen kann. Deshalb der nüchterne Teil zuerst: Eine schnelle Website verkauft kein schlechtes Angebot, und sie ersetzt keine klare Seitenstruktur. Was sie tut, ist banaler und trotzdem wichtig: Sie sorgt dafür, dass die Leute, die ohnehin auf deine Seite gekommen sind, auch ankommen. Wer auf dem Handy im Zug auf einen Link tippt und vier Sekunden auf eine weiße Fläche starrt, geht zurück zu Google und klickt das nächste Ergebnis an. Nicht aus Ungeduld, sondern weil er annimmt, die Seite sei kaputt.

Der zweite Punkt ist die Wahrnehmung. Eine Seite, die zäh aufbaut, bei der Bilder nachträglich hineinspringen und der Text noch einmal umbricht, wirkt unprofessionell, ohne dass der Besucher benennen könnte warum. Das trifft besonders Handwerk, Kanzleien, Praxen und alle, die über ihre Website Vertrauen aufbauen wollen. Eine ruhige, sofort stehende Seite hat denselben Effekt wie ein aufgeräumter Empfangsbereich: Sie sagt etwas über die Sorgfalt dahinter, bevor jemand den ersten Satz liest.

Und Google? Ja, die Ladeerfahrung ist ein Rankingfaktor, das bestätigt Google selbst über die Core Web Vitals. Aber sie ist einer von sehr vielen, und sie ist ein schwacher. Eine schnelle Seite mit dünnem Inhalt schlägt keine langsame Seite, die die Frage des Suchenden wirklich beantwortet. Realistisch ist Geschwindigkeit ein Tiebreaker: Bei zwei inhaltlich ähnlich guten Seiten hilft sie, und bei mobiler Suche fällt sie stärker ins Gewicht als am Desktop. Wer seine Ladezeit optimiert, aber sonst nichts, wird auf Platz 14 statt auf Platz 15 landen. Das ist der ehrliche Rahmen.

02Erst messen, dann schrauben

Ohne Ausgangswert weißt du hinterher nicht, ob es besser wurde.

Der häufigste Fehler ist, sofort loszuoptimieren. Jemand liest von Bildkomprimierung, drückt alle Fotos durch ein Tool, und danach ist die Seite gefühlt genauso langsam, weil das eigentliche Problem ein überlastetes Shared-Hosting war. Miss also zuerst, notier dir die Werte mit Datum, und miss nach jeder Änderung erneut. Das dauert fünf Minuten und verhindert, dass du drei Wochenenden in die falsche Baustelle steckst.

Wichtig ist der Unterschied zwischen Labordaten und Felddaten. Labordaten entstehen, wenn ein Werkzeug deine Seite einmal unter simulierten Bedingungen lädt (gedrosseltes Netz, langsames Testgerät). Sie sind reproduzierbar und gut zum Vergleichen von vorher und nachher. Felddaten stammen von echten Besuchern mit echten Geräten und echten Verbindungen, gesammelt über Chrome. Sie sind die Wahrheit, aber sie brauchen genug Traffic, sonst zeigt dir das Werkzeug schlicht keine. Für kleine Firmenseiten heißt das: Du arbeitest meist mit Labordaten und akzeptierst, dass die Realität etwas anders aussieht.

Die Werkzeuge, die du brauchst

1. PageSpeed Insights von Google: kostenlos, im Browser, zeigt Labor- und (falls vorhanden) Felddaten. Der Standard für den ersten Blick.
2. Lighthouse in Chrome: dasselbe Prüfverfahren direkt in den Entwicklerwerkzeugen (F12, Reiter Lighthouse). Praktisch, weil du auch Seiten testen kannst, die noch nicht öffentlich sind.
3. WebPageTest: detaillierter, du kannst Standort, Gerät und Verbindung wählen. Das Wasserfalldiagramm zeigt dir, welche einzelne Datei die Bremse ist.
4. Der Netzwerk-Reiter in den Chrome-Entwicklerwerkzeugen: zeigt dir Seitengewicht und Anzahl der Anfragen. Wenn deine Startseite über 3 MB wiegt, brauchst du kein weiteres Werkzeug mehr, dann weißt du schon, wo du anfängst.
5. Die Search Console von Google: unter "Core Web Vitals" siehst du, welche deiner Seiten aus Nutzersicht auffällig sind. Nur nutzbar, wenn deine Seite dort verifiziert ist.

Ein Wort zum Punktestand: Der Lighthouse-Wert zwischen 0 und 100 ist eine Zusammenfassung, kein Naturgesetz. Er schwankt zwischen zwei Messungen um mehrere Punkte, weil er unter anderem von der Auslastung des Testservers abhängt. Nimm ihn als Richtung, nicht als Note. Die einzelnen Metriken darunter sind aussagekräftiger, und die stehen in dieser Tabelle.

Die ersten drei Werte sind die Core Web Vitals, an denen sich Google orientiert. Die Zielwerte stammen von Google selbst und gelten seit Jahren stabil. Die beiden unteren Zeilen sind Erfahrungswerte aus der Praxis, keine offiziellen Grenzen, aber sie helfen bei der Einordnung. Wenn du nur einen Wert im Blick behalten willst, nimm LCP: Er beschreibt am ehesten das, was ein Mensch als "die Seite ist da" empfindet.

03Bilder: der größte Hebel, fast immer

In neun von zehn langsamen Seiten sind die Bilder das Hauptproblem.

Wenn du nur eine Baustelle angehst, dann diese. Der typische Fall: Jemand lädt Fotos direkt aus der Kamera oder vom Handy hoch, 4.000 Pixel breit, 4 MB pro Datei. Das Content-Management-System zeigt sie brav verkleinert an, aber der Browser lädt trotzdem das Original. Fünf solcher Bilder auf der Startseite ergeben 20 MB, die über die Mobilfunkverbindung müssen. Das ist kein Feintuning-Thema mehr, das ist der Unterschied zwischen einer und acht Sekunden.

Drei Dinge musst du unterscheiden, weil sie unabhängig voneinander wirken. Erstens die Abmessungen: Ein Bild, das auf der Seite maximal 800 Pixel breit dargestellt wird, muss nicht 4.000 Pixel breit sein. Als Faustregel reicht die doppelte Anzeigebreite, damit es auch auf hochauflösenden Displays scharf bleibt. Zweitens das Format: JPEG, WebP und AVIF komprimieren Fotos unterschiedlich effizient, PNG ist für Fotos die schlechteste Wahl. Drittens die Kompressionsstufe: Zwischen Qualität 100 und Qualität 80 sieht kaum ein Mensch einen Unterschied, die Datei ist aber deutlich kleiner.

Die Größenangaben sind Erfahrungswerte aus der Praxis und schwanken stark mit dem Motiv: Ein Foto mit viel Himmel komprimiert deutlich besser als eine Detailaufnahme mit Struktur. Verlass dich nicht auf die Zahlen, sondern auf deinen Datei-Explorer. Wenn ein einzelnes Bild auf deiner Website über 300 KB wiegt, hat es entweder eine Sonderrolle als großes Kopfbild, oder es ist schlicht nicht optimiert.

Was du selbst tun kannst

• Bilder vor dem Hochladen auf die tatsächlich benötigte Breite skalieren. Das geht in jedem Bildprogramm und ist die wirksamste Einzelmaßnahme überhaupt.
• Als WebP speichern, wenn dein System es unterstützt. Die meisten aktuellen Systeme tun das inzwischen von selbst.
• Alte Bilder auf der Seite durchgehen. Bei Seiten, die seit Jahren laufen, sammeln sich Altlasten in der Mediathek an.
• Videos nicht als Hintergrund in den Kopfbereich legen, wenn es nicht sein muss. Ein Autoplay-Video ist der zuverlässigste Weg, eine sonst gute Seite auszubremsen.

Was der Entwickler übernehmen muss

• Responsive Bilder ausliefern: Der Browser bekommt mehrere Größen angeboten und lädt die passende für das Gerät. Das ist der Unterschied zwischen "verkleinert dargestellt" und "klein geladen".
• Lazy Loading für alles unterhalb des sichtbaren Bereichs, aber ausdrücklich nicht für das Hauptbild ganz oben. Wer das falsch macht, verschlechtert den LCP-Wert statt ihn zu verbessern.
• Feste Breiten- und Höhenangaben, damit der Browser den Platz reserviert und das Layout nicht springt. Das ist die häufigste Ursache für schlechte CLS-Werte.
• Automatische Formatumwandlung im Build- oder Upload-Prozess, damit auch der Praktikant in zwei Jahren kein 4-MB-Foto mehr hochladen kann.

04Schriften: klein, aber gemein

Wenige Kilobyte, die trotzdem eine Sekunde kosten können.

Schriften sind ein unterschätztes Thema, weil die Dateien im Vergleich zu Bildern winzig sind. Das Problem ist nicht die Größe, sondern der Zeitpunkt. Eine Schrift, die von einem fremden Server geladen wird, erzeugt eine zusätzliche Verbindung zu einer weiteren Domain, und bis diese Verbindung steht, wartet der Browser mit der Textdarstellung. Das Ergebnis kennst du: eine Seite, die kurz leer bleibt oder erst in einer Ersatzschrift erscheint und dann sichtbar umspringt.

Dazu kommt der rechtliche Aspekt, der in Deutschland handfest ist. Wenn du Schriften dynamisch von einem Google-Server einbindest, wird die IP-Adresse deines Besuchers ohne dessen Zustimmung an einen Anbieter in den USA übertragen. Nach einem viel diskutierten Urteil des Landgerichts München I aus dem Jahr 2022 folgte eine Abmahnwelle, die viele kleine Websitebetreiber getroffen hat. Die saubere Lösung löst beide Probleme auf einmal: Schriften herunterladen, auf dem eigenen Server ablegen, lokal einbinden. Schneller und datenschutzrechtlich unbedenklich. Das gilt genauso für Kartendienste, eingebettete Videos und Icon-Bibliotheken, die aus derselben Ecke kommen.

1. Nur WOFF2 ausliefern. Ältere Formate wie TTF oder EOT braucht heute kein Browser mehr, sie sind aber deutlich größer.
2. Schnitte zählen. Jede Stärke (Regular, Medium, Bold) und jeder Stil (kursiv) ist eine eigene Datei. Zwei Schriftfamilien mit je vier Schnitten sind acht Dateien. Zwei bis drei Schnitte insgesamt reichen für die allermeisten Firmenseiten.
3. font-display richtig setzen: Mit dem Wert "swap" zeigt der Browser sofort eine Ersatzschrift und tauscht später. Text ist damit von Anfang an lesbar, dafür siehst du den Umsprung. Mit "optional" bleibt es ruhiger, aber die Schrift erscheint beim ersten Besuch eventuell gar nicht.
4. Subsetting nutzen: Eine Schriftdatei enthält oft Zeichensätze für Sprachen, die du nie brauchst. Auf Latein reduziert schrumpft die Datei spürbar.
5. Kritische Schriften vorladen (preload), damit der Browser sie parallel holt, statt zu warten, bis er das Stylesheet gelesen hat.

Punkt 1, 2 und 4 sind Entwicklerarbeit, aber Punkt 2 ist eine Designentscheidung, die du selbst treffen kannst. Wenn dir jemand einen Entwurf mit drei Schriftfamilien vorlegt, ist das nicht nur ein Ladezeitproblem, sondern meist auch ein gestalterisches. Eine gute Schrift mit zwei Schnitten trägt eine komplette Website.

05Skripte, Plugins und Drittanbieter

Hier sitzt das Problem, das kein Bildkomprimierer löst.

Bilder machen eine Seite schwer, Skripte machen sie träge. Der Unterschied ist wichtig: Ein großes Bild verlängert die Ladezeit, aber der Browser kann daneben weiterarbeiten. Ein JavaScript, das ausgeführt werden muss, blockiert den Hauptprozess. Solange er rechnet, reagiert die Seite auf nichts. Genau das misst der INP-Wert, und genau deshalb fühlen sich manche Seiten auch dann noch klebrig an, wenn optisch längst alles da ist.

Der Klassiker in WordPress-Projekten ist der Plugin-Wildwuchs. Ein Slider hier, ein Formular-Plugin dort, ein Page Builder darüber, dazu ein Optimierungs-Plugin, das die Probleme der anderen wieder einfangen soll. Jedes davon lädt eigenes JavaScript und eigenes CSS, oft auf allen Seiten, auch dort, wo es gar nicht gebraucht wird. Ein Kontaktformular-Plugin, das seine Skripte auf jeder Unterseite mitschickt, ist Alltag und nicht die Ausnahme. Wenn eine Seite 30 aktive Plugins hat, ist die Ladezeit selten das einzige Problem: Auch Wartung und Sicherheit werden dann zur Dauerbaustelle, und wie sich das auf die laufenden Kosten auswirkt, steht im Ratgeber zu Website-Pflege und laufenden Kosten.

Die zweite große Gruppe sind Drittanbieter-Einbindungen. Tracking, Cookie-Banner, Chat-Widgets, Bewertungssterne, eingebettete Karten, Social-Media-Feeds. Jede dieser Einbindungen bedeutet: Verbindung zu einer fremden Domain aufbauen, deren Antwortzeit du nicht kontrollierst, und deren Code auf deiner Seite ausgeführt wird. Wenn der Server des Anbieters langsam ist, ist deine Seite langsam, und du kannst nichts dagegen tun außer sie zu entfernen.

Die realistische Reihenfolge

1. Aufräumen: Jedes Plugin und jedes Skript, das keiner mehr braucht, fliegt raus. Kostet nichts und wirkt sofort.
2. Ersetzen: Wo drei Plugins eine Aufgabe erledigen, die eines besser kann, konsolidieren.
3. Verzögern: Skripte, die nicht sofort gebraucht werden, mit defer oder async laden, damit sie den Aufbau nicht blockieren.
4. Bedingt laden: Formular-Skripte nur auf der Kontaktseite, Karten-Skripte nur dort, wo eine Karte steht. Das ist Entwicklerarbeit, aber es ist die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung.
5. Neu bauen: Wenn eine Seite auf einem Page Builder mit 40 Plugins steht, ist Optimieren irgendwann teurer als ein sauberer Neubau. Wann dieser Punkt erreicht ist, behandelt der Ratgeber zum Relaunch.

06Hosting: der unsichtbare Boden

Alles, was du optimierst, steht auf dieser Grundlage.

Wenn dein TTFB-Wert bei 1,5 Sekunden liegt, kannst du jedes Bild auf 30 KB drücken und die Seite bleibt langsam. Denn diese anderthalb Sekunden vergehen, bevor der Browser überhaupt das erste Byte HTML bekommt. Er wartet einfach. Das ist der Punkt, an dem billiges Hosting teuer wird: Für 2,99 Euro im Monat teilst du dir einen Server mit hunderten anderen Websites, und wenn eine davon gerade viel Traffic hat, merkst du das.

Die Faktoren, die die Serverantwortzeit bestimmen, sind überschaubar: die Auslastung des Servers, die PHP-Version (aktuelle Versionen sind spürbar schneller als die von vor fünf Jahren), die Datenbank, die Entfernung zwischen Server und Besucher, und ob überhaupt ein serverseitiger Cache aktiv ist. Für eine deutsche Firmenwebsite mit deutschen Kunden ist ein Serverstandort in Deutschland oder Mitteleuropa naheliegend. Das ist außerdem datenschutzrechtlich die einfachere Variante, weil keine Übermittlung in Drittländer im Spiel ist.

Die Preise sind Erfahrungswerte aus dem deutschen Markt und schwanken je nach Anbieter und Vertragslaufzeit erheblich. Die Antwortzeiten sind ebenfalls Richtwerte, kein Versprechen: Ein gut konfiguriertes Shared Hosting schlägt einen schlecht konfigurierten eigenen Server jederzeit. Was du daraus mitnehmen solltest: Der Sprung vom Billigtarif auf einen ordentlichen Tarif kostet meist unter 15 Euro im Monat und bringt oft mehr als ein ganzer Nachmittag Bildoptimierung.

Ein Hinweis, den viele überraschend finden: Der Umzug auf besseres Hosting ist keine Raketenwissenschaft, aber auch nichts, was man mal eben nebenbei macht. Datenbank, Dateien, Mailkonten, DNS-Einträge und SSL-Zertifikat müssen mitgenommen werden, und zwischen Umschaltung und vollständiger Verteilung der DNS-Änderung liegen je nach Einstellung einige Stunden. Wer eine Website mit Bestellungen oder Terminbuchungen betreibt, legt den Umzug auf einen ruhigen Abend und hat einen Rückweg parat.

07Caching, Kompression und Auslieferung

Die Technik dahinter, in verständlich.

Caching heißt: nicht jedes Mal neu bauen, was sich nicht geändert hat. Bei einem klassischen CMS wird bei jedem Seitenaufruf die Seite frisch aus der Datenbank zusammengesetzt. Das ist Arbeit, die bei einer Seite, die sich seit drei Wochen nicht geändert hat, komplett unnötig ist. Ein Seiten-Cache legt das fertige Ergebnis ab und liefert es beim nächsten Aufruf direkt aus. Das ist bei datenbankgestützten Seiten oft die wirksamste einzelne technische Maßnahme, und sie ist bei den meisten Systemen mit überschaubarem Aufwand einzurichten.

Es gibt mehrere Ebenen, und sie greifen ineinander. Der Browser-Cache speichert Dateien wie Logos, Schriften und Stylesheets auf dem Gerät des Besuchers, sodass beim zweiten Besuch nur noch das HTML geladen wird. Der Server-Cache spart die Rechenarbeit. Ein Objekt-Cache legt einzelne Datenbankabfragen ab und lohnt sich erst bei größeren Seiten. Ein CDN verteilt deine Dateien auf Server in verschiedenen Regionen, was bei internationalem Publikum viel bringt und bei rein deutscher Kundschaft wenig. Für eine Handwerksfirma aus Karlsruhe mit Kunden aus Karlsruhe ist ein CDN meist Aufwand ohne spürbaren Nutzen, und wenn es aus den USA betrieben wird, holst du dir zusätzlich eine Datenschutzfrage ins Haus.

• Kompression: Textdateien (HTML, CSS, JavaScript) werden komprimiert übertragen. Brotli ist effizienter als das ältere gzip, beides ist Standard und muss serverseitig aktiviert sein. Prüfbar in den Entwicklerwerkzeugen unter den Antwort-Headern.
• HTTP/2 und HTTP/3: neuere Protokollversionen, die viele Dateien parallel über eine Verbindung übertragen. HTTP/2 sollte heute überall aktiv sein, HTTP/3 ist ein sinnvolles Extra, besonders bei mobilen Verbindungen.
• Minifizierung: Leerzeichen und Kommentare aus CSS und JavaScript entfernen. Bringt spürbar weniger als Caching, ist aber praktisch kostenlos und in jedem Build-Prozess dabei.
• Ungenutztes CSS entfernen: Themes liefern oft Stylesheets für Bausteine mit, die du nie verwendest. Das aufzuräumen ist Handarbeit und lohnt sich erst, wenn die großen Hebel gezogen sind.

Ein ehrliches Wort zu Optimierungs-Plugins: Sie können viel, und sie können viel kaputt machen. Aggressive Einstellungen beim Zusammenfassen und Verzögern von JavaScript führen regelmäßig dazu, dass Formulare nicht mehr absenden, Slider stehen bleiben oder das Menü auf dem Handy nicht mehr aufgeht. Und weil der Fehler nur unter bestimmten Bedingungen auftritt, merkt es niemand sofort. Wenn du ein solches Plugin einsetzt, ändere eine Einstellung nach der anderen und teste danach jedes Mal die Kontaktseite, das Menü und die Suche. Sonst hast du am Ende eine schnelle Seite, über die keine Anfrage mehr hereinkommt.

08Was du selbst kannst und wo ein Entwickler ran muss

Die Übersicht, nach Wirkung sortiert.

Nicht jede Maßnahme lohnt denselben Aufwand, und nicht jede lässt sich ohne Vorkenntnisse umsetzen. Diese Tabelle ordnet die gängigen Hebel nach dem, was sie in der Praxis bringen. "Wirkung" meint dabei den typischen Effekt auf eine durchschnittliche Firmenwebsite, nicht auf jede Seite. Wenn dein Hosting bereits gut ist, bringt ein Wechsel logischerweise nichts mehr.

Die Zeitangaben sind Erfahrungswerte für eine kleine bis mittlere Firmenwebsite mit 5 bis 15 Unterseiten. Bei größeren Projekten skaliert vor allem die Bildarbeit. Die letzte Zeile ist bewusst dabei, weil sie oft die ehrlichste Antwort ist: Wenn eine Seite auf einem überladenen Theme mit drei Page Buildern steht, kostet das Zurechtbiegen mehr als ein sauberer Neubau, und das Ergebnis bleibt trotzdem ein Kompromiss. Wie du Angebote für so einen Neubau sauber vergleichst, steht im Ratgeber zum Angebotsvergleich.

09Fazit: was du jetzt konkret tun solltest

Kurz, ehrlich, ohne Verkaufsversprechen.

Die meisten langsamen Websites sind nicht kompliziert langsam. Sie sind langsam, weil zu große Bilder auf zu billigem Hosting liegen und dazwischen ein Dutzend Skripte laufen, die niemand mehr braucht. Wer diese drei Punkte angeht, holt in der Regel den größten Teil der möglichen Verbesserung heraus, ohne dass ein einziger exotischer Kniff nötig wäre. Der Rest, ungenutztes CSS, Preload-Feinheiten, HTTP/3, ist Feinschliff für Seiten, die schon gut sind.

Fang so an: Öffne PageSpeed Insights, teste deine Startseite mobil, schreib dir LCP und die Serverantwortzeit mit Datum auf. Dann öffne den Netzwerk-Reiter und schau dir die drei größten Dateien an. In den allermeisten Fällen sind das Bilder, und damit hast du deine erste Aufgabe für den Nachmittag. Miss danach erneut. Wenn sich dabei nichts tut, liegt das Problem beim Server, und dann ist der nächste Schritt ein Blick in den Hosting-Vertrag statt in die Mediathek.

Und die ehrliche Grenze: Wenn deine Website ein Hobbyprojekt ist, das dreißig Besucher im Monat hat, ist der Aufwand einer professionellen Optimierung nicht gerechtfertigt. Dann reicht es, die Bilder kleiner zu machen und den Rest zu lassen. Auch ein Baukastensystem kann für so einen Fall völlig in Ordnung sein, selbst wenn es nie Spitzenwerte erreichen wird. Optimierung lohnt sich dort, wo über die Seite tatsächlich Anfragen, Buchungen oder Verkäufe laufen, und wo eine verlorene halbe Sekunde bares Geld ist.

Wenn du an den Punkt kommst, an dem Optimieren teurer wird als neu bauen, ist das keine Niederlage, sondern eine normale Rechnung. Bei Pixylmedia entstehen neue Seiten von vornherein so, dass sie schnell sind: lokale Schriften, kein US-CDN, kein Baukasten, Lighthouse 95 und darüber als Ausgangswert und nicht als Ziel für später. Aber wenn deine bestehende Seite im Kern gesund ist und nur unter ihren Bildern erstickt, dann brauchst du kein Angebot. Dann brauchst du einen Nachmittag und die Liste aus diesem Artikel.