Langsame Website: zehn Ursachen und wie Sie sie beheben
Eine Website lädt langsam, wenn der Server zu spät antwortet oder der Browser zu viel und zu spät laden muss: große Bilder, Schriften, Skripte, fehlendes Caching. Prüfen Sie zuerst die Serverantwort, dann das, was danach geladen wird.
Die Ladezeit einer Seite besteht aus zwei Teilen. Zuerst wartet der Browser auf die erste Antwort des Servers. Danach lädt er alles, was die Seite braucht: Stylesheets, Schriften, Bilder, Skripte. Jede der zehn Ursachen unten sitzt in einem dieser Teile, und die Prüfung beginnt beim ersten, weil alles Weitere darauf wartet.
Wie Google die Erfahrung der Besucher mit LCP, INP und CLS misst, steht unter Core Web Vitals verstehen: LCP, INP und CLS ohne Fachchinesisch. Hier geht es um die Ursachen hinter schlechten Werten und um die Reihenfolge, in der Sie sie angehen.
Erste Messung
Wo die Zeit verloren geht
Die Zeit bis zum ersten Byte (Time to First Byte, TTFB) umfasst Weiterleitungen, Namensauflösung, Verbindungsaufbau mit Verschlüsselung und die Rechenzeit des Servers. web.dev nennt als grobe Richtschnur höchstens 0,8 Sekunden, über 1,8 Sekunden gilt der Wert als schlecht. Liegt Ihre Seite deutlich darüber, sitzt die Ursache bei Server, Datenbank oder Caching auf dem Server (Ursachen 8 bis 10). Ist die erste Antwort schnell und die Seite trotzdem träge, liegt es an dem, was der Browser danach laden und ausführen muss (Ursachen 1 bis 7).
Die erste Antwort messen Sie mit den curl-Befehlen weiter unten oder in den Entwicklerwerkzeugen des Browsers im Reiter Netzwerk, am ersten Eintrag der Liste. Messen Sie mehrmals und zu verschiedenen Tageszeiten, denn ein einzelner Wert sagt wenig.
Ursachen 1 und 2
Bilder und Schriften
1. Zu große Bilder
Ein Foto in 4.000 Pixel Breite, das auf dem Smartphone 400 Pixel breit erscheint, überträgt ein Vielfaches der Daten, die gebraucht werden. Lighthouse meldet ein Bild, wenn die ausgelieferte Datei mindestens 4 KiB größer ist, als die dargestellte Größe verlangt. Abhilfe schaffen mehrere Größen je Bild mit den Attributen srcset und sizes, ein modernes Format wie WebP und feste Breiten- und Höhenangaben. Das größte Bild im sichtbaren Bereich wird nicht verzögert geladen. Wie Sie viele Fotos auf einer Seite organisieren, ist eine eigene Frage; hier zählt das einzelne Bild.
2. Webschriften
Jeder Schriftschnitt ist eine eigene Datei, und bis sie geladen ist, zeigt der Browser den Text womöglich gar nicht an. web.dev empfiehlt das Format WOFF2, nur die Zeichen, die die Seite braucht (Subsetting), und eine bewusste Wahl von font-display: optional, wenn Tempo vorgeht, swap, wenn die Schrift auf jeden Fall erscheinen soll. Prüfen Sie im Netzwerk-Reiter mit dem Filter „Font“, wie viele Schriftdateien geladen werden. Prüfen Sie, ob jeder geladene Schnitt auf der Seite vorkommt, und streichen Sie die übrigen aus dem Stylesheet.
Ursachen 3 bis 5
Skripte von Drittanbietern und eigener Code
3. Blockierende Stylesheets und Skripte im Kopf der Seite
Ein Skript im head ohne async oder defer und jedes Stylesheet ohne passende media-Angabe halten die Darstellung an, bis sie geladen sind. Lighthouse weist sie als render-blockierend aus. Abhilfe: Skripte mit defer laden, die Stile für den ersten sichtbaren Bereich direkt in die Seite schreiben und den Rest nachladen.
4. Zu viel eigenes JavaScript
Ein Paket, das auf jeder Seite den Code für alle Seiten mitbringt, belastet Leitung und Prozessor. Der Reiter Coverage in den Chrome-Entwicklerwerkzeugen zeigt zeilengenau, welcher Code beim Aufruf ungenutzt bleibt; Lighthouse meldet jede Datei mit mehr als 20 KiB ungenutztem Code. Abhilfe ist das Aufteilen in Pakete je Seite oder Funktion.
5. Skripte von Drittanbietern
Tag-Manager, Chat-Fenster, Karten, Videos und Werbenetzwerke laden eigenen Code von fremden Servern. web.dev rät, Skripte ohne klaren Nutzen zu entfernen und die übrigen mit async oder defer zu laden, Einbettungen wie Videos erst bei Bedarf. Wie solche Skripte auch die Reaktion auf Klicks bremsen, steht unter INP verbessern: Wenn Ihre Website träge auf Klicks reagiert.
Ursachen 6 bis 8
Fehlendes Caching
6. Kein Browser-Cache für statische Dateien
Ohne Cache-Header lädt jeder wiederkehrende Besucher Stylesheets, Skripte und Bilder neu. web.dev empfiehlt für Dateien mit Versionskennung im Namen, etwa app.3f9a.css, den Header Cache-Control: max-age=31536000, also ein Jahr. Für das HTML selbst gilt no-cache: Der Browser darf es speichern, fragt aber vor jeder Nutzung beim Server nach, ob es noch aktuell ist.
7. Keine Kompression
Text in HTML, CSS und JavaScript schrumpft mit Brotli oder gzip deutlich. Lighthouse meldet Antworten ab 1,4 KiB, bei denen gzip mindestens 10 Prozent sparen würde. Ob komprimiert wird, zeigt der Antwort-Header content-encoding. Abhilfe ist eine Zeile in der Konfiguration des Webservers.
8. Kein Seiten-Cache auf dem Server
Ein CMS, das jede Seite bei jedem Aufruf neu aus Datenbank und Vorlagen zusammensetzt, rechnet für jeden Besucher dieselbe Arbeit. Ein Seiten-Cache speichert das fertige HTML und liefert es direkt aus; Statamic schreibt in seiner schnellsten Stufe statische Dateien, die der Webserver ohne PHP ausliefert. Welche Cache-Ebene für welche Daten passt, beschreibt Redis als Cache-Layer in Statamic.
Ursachen 9 und 10
Datenbank, Server und Standort
9. Langsame Datenbankabfragen
Seiten, die nicht aus dem Cache kommen, warten auf die Datenbank. Zwei Muster bremsen besonders: fehlende Indizes und Schleifen, die für jeden Listeneintrag eine eigene Abfrage absetzen. Wie Sie dieses Muster in Laravel finden, steht unter Eloquent N+1 systematisch finden und beheben. Prüfen lässt es sich mit einem Abfrageprotokoll: Eine Produktliste mit 50 Einträgen sollte nicht 51 Abfragen auslösen.
10. Server und Standort
Ein Server mit zu wenig Arbeitsspeicher oder Rechenleistung antwortet unter Last langsamer, und jede Weiterleitung kostet einen weiteren Umlauf, bevor die eigentliche Seite kommt. Prüfen Sie die erste Antwort deshalb zu ruhigen und zu belebten Zeiten. Steigt sie nur unter Last, ist die Kapazität der Engpass, und dann geht es um Skalierung. Sitzen Ihre Besucher in Deutschland, gehört der Server in ein deutsches oder nahes europäisches Rechenzentrum, und eine Adresse sollte mit höchstens einem Sprung am Ziel sein.
Übersicht
Zehn Ursachen auf einen Blick
Die Tabelle fasst die zehn Ursachen in der Reihenfolge des Textes zusammen. Ist die erste Antwort des Servers langsam, beginnen Sie bei Ursache 8, sonst bei Ursache 1.
| So prüfen Sie | Was hilft | |
|---|---|---|
| 1. Zu große Bilder | Lighthouse-Hinweis zur Bildauslieferung, Dateigröße im Netzwerk-Reiter | Mehrere Größen mit srcset und sizes, WebP, Breite und Höhe angeben |
| 2. Webschriften | Netzwerk-Reiter mit Filter „Font“: Anzahl und Größe der Dateien | WOFF2, Subsetting, weniger Schnitte, font-display bewusst wählen |
| 3. Blockierende Ressourcen im Kopf | Lighthouse-Hinweis zu render-blockierenden Anfragen | defer für Skripte, kritische Stile direkt in die Seite |
| 4. Zu viel eigenes JavaScript | Reiter Coverage in den Chrome-Entwicklerwerkzeugen | Pakete je Seite aufteilen, Ungenutztes entfernen |
| 5. Skripte von Drittanbietern | Netzwerk-Reiter nach fremden Domains sortieren | Entfernen, was keinen Nutzen hat, Rest mit async oder defer |
| 6. Kein Browser-Cache | Header cache-control einer CSS- oder JS-Datei | Ein Jahr für Dateien mit Versionskennung, no-cache für HTML |
| 7. Keine Kompression | Header content-encoding der HTML-Antwort | Brotli, gzip als Rückfall |
| 8. Kein Seiten-Cache | Erste Antwort bei wiederholtem Aufruf derselben Seite | Fertiges HTML zwischenspeichern oder statisch ausliefern |
| 9. Langsame Datenbankabfragen | Abfrageprotokoll: Zahl und Dauer der Abfragen je Seite | Indizes, Daten gemeinsam laden statt in Schleifen |
| 10. Server und Standort | Erste Antwort zu ruhigen und belebten Zeiten, Zahl der Weiterleitungen | Kapazität anpassen, Server nahe den Besuchern, Weiterleitungsketten kürzen |
Selbst messen
Drei Prüfungen mit curl
Drei der zehn Ursachen lassen sich ohne Browser von der Kommandozeile prüfen: die erste Antwort mit Weiterleitungen, die Kompression und die Cache-Header. Ersetzen Sie die Adressen durch Ihre Startseite und eine CSS- oder JavaScript-Datei aus dem Quelltext der Seite. Erscheint bei der zweiten oder dritten Prüfung keine Zeile, fehlt der Header.
Unter Windows laufen die Befehle in Git Bash oder WSL; in Windows PowerShell ist curl ein Alias für Invoke-WebRequest, und grep fehlt.
url="https://www.example.com/"
asset="https://www.example.com/build/app.css"
# 1. Redirects, time of redirects and time to first byte (in seconds)
curl -s -o /dev/null -L -m 15 \
-w "redirects %{num_redirects}, redirect time %{time_redirect}, first byte %{time_starttransfer}, total %{time_total}\n" \
"$url"
# 2. Is the HTML compressed? Expect "content-encoding: br" or "gzip"
curl -s -o /dev/null -m 15 -D - -H "Accept-Encoding: br, gzip" "$url" | grep -i "^content-encoding"
# 3. How long may the browser keep a static file?
curl -s -o /dev/null -m 15 -D - "$asset" | grep -i "^cache-control"
Zehn Ursachen geprüft, und die Seite ist immer noch langsam?
Im Performance-Audit-Sprint werten wir Lighthouse, Core Web Vitals und Backend-Tracing in zwei Wochen aus und übergeben einen priorisierten Maßnahmenplan. Das Audit Light für eine klar abgegrenzte Website kostet ab 6.900 Euro.
Zwei Fragen zur Ladezeit
Häufige Fragen
-
Eine einzelne Zahl für die ganze Seite gibt es nicht. Google bewertet den größten sichtbaren Inhalt als gut, wenn er bei drei von vier Aufrufen echter Besucher nach spätestens 2,5 Sekunden erscheint. Für die erste Antwort des Servers nennt web.dev höchstens 0,8 Sekunden als grobe Richtschnur.
-
Nein. Ein größerer Server verkürzt nur die Zeit bis zur ersten Antwort, und auch die nur, wenn der Server unter Last an seine Grenzen kommt. Liegt die erste Antwort schon unter 0,8 Sekunden und geht die Zeit bei Bildern, Schriften oder Skripten verloren, ändert ein neuer Server an der Ladezeit kaum etwas.
Nachweise
Quellen und Stand
Stand: 07.08.2026. Die curl-Befehle haben wir unter macOS mit curl 8.7 gegen eine erreichbare Website ausgeführt; Grenzwerte und Prüfregeln stammen aus der Dokumentation von web.dev und Chrome for Developers.
Artikel teilen