Warum lädt Ihre Website langsam? Acht Ursachen und wie man sie erkennt.

Die häufigsten Gründe, warum eine Website langsam lädt, sind ein Server, der spät antwortet, eine Adresse, die mehrfach weiterleitet, große Bilder, Stil- und Skriptdateien, die die Seite aufhalten, zu viel JavaScript, Code von Drittanbietern, Webschriften und der Prozessor des Smartphones. Welche davon auf Ihre Website zutrifft, findet man nicht durch Raten heraus, sondern mit drei kostenlosen Werkzeugen: PageSpeed Insights, Search Console und dem Netzwerk-Tab des Browsers.

„Die Website ist langsam“ klingt nach einer einzigen Beschwerde, doch Besucher erleben drei verschiedene Dinge als Langsamkeit: dass der Bildschirm lange leer bleibt, dass die Seite selbst nach dem Laden spät auf Klicks reagiert und dass der Inhalt beim Laden springt. Google misst diese drei getrennt unter dem Namen Core Web Vitals: wie lange der Hauptinhalt zum Erscheinen braucht (LCP), wie lange die Reaktion auf eine Interaktion dauert (INP) und die Layoutverschiebung (CLS). Laut web.dev gelten als gut die Grenzwerte 2,5 Sekunden, 200 Millisekunden und 0,1; gemessen wird, ob der Grenzwert bei 75 Prozent der Besuche eingehalten wird.

Dieser Artikel ist aus der Sicht derer geschrieben, die eine Website in Auftrag geben: Wie finde ich die Ursache der Langsamkeit heraus, und was frage ich mein Webteam? Für jede Ursache gibt es eine Prüfung, die Sie selbst durchführen können. Die technischen Einzelheiten stehen im Leitfaden zur Web-Performance; wenn wir messen und beheben sollen, beschreibt die Seite Website-Geschwindigkeitsoptimierung die Methode.

Mit welchen Werkzeugen untersucht man Langsamkeit?

Drei kostenlose Werkzeuge reichen, und jedes beantwortet eine andere Frage. Das erste ist PageSpeed Insights: Sie geben die Adresse der Seite ein; der obere Bereich zeigt die Daten der letzten 28 Tage, gesammelt von echten Chrome-Nutzern, der untere einen Labortest auf einem einzigen simulierten Smartphone. Die Punktzahl von 0–100 im unteren Bereich ändert sich bei jedem Durchlauf ein wenig; warum, erklären wir in Wie misst man die Website-Geschwindigkeit.

Das zweite ist der Core-Web-Vitals-Bericht in der Search Console. Er betrachtet nicht eine einzelne Seite, sondern die ganze Website: Er teilt die Adressen in Gruppen ähnlicher Seiten ein, als schlecht, verbesserungswürdig und gut, und berichtet Mobilgeräte und Desktop getrennt. Hier sehen Sie, welche Seitenfamilie ein Problem hat. Das dritte ist der Netzwerk-Tab (Network) in den Entwicklertools des Browsers: In Chrome öffnet er sich mit F12; wenn das Kästchen „Disable cache“ (Cache deaktivieren) angehakt und die Seite neu geladen wird, erscheint jede geladene Datei als eigene Zeile; die Zusammenfassung ganz unten nennt die Gesamtzahl der Anfragen, die übertragene Datenmenge und die Ladezeit.

1 · Antwortet der Server spät?

Die Zeit zwischen der Anfrage des Browsers und dem Eintreffen des ersten Bytes vom Server heißt Time to First Byte (TTFB), und der Rest der Seite baut auf dieser Zeit auf. web.dev empfiehlt den meisten Websites, 0,8 Sekunden oder weniger anzustreben. Typische Gründe für eine lange Dauer sind ein überfüllter Shared Server, ein Aufbau, der die Seite bei jeder Anfrage neu aus der Datenbank erzeugt, und ein Server weit weg vom Besucher.

So erkennen Sie es: Im Netzwerk-Tab ist die oberste Zeile der Liste die Seite selbst. Klicken Sie darauf und wechseln Sie in den Bereich Timing (Zeitablauf); die Zeile „Waiting for server response“ (Warten auf Serverantwort) zeigt diese Zeit. Ist sie über mehrere Neuladungen hinweg durchgehend lang, liegt das Problem nicht im Design, sondern auf der Serverseite. Einzelheiten: TTFB und Serverantwort.

2 · Wie oft leitet die Adresse weiter?

Wenn ein Besucher „http://firmaniz.com“ eingibt, wird der Browser womöglich erst auf https, dann auf die Adresse mit www, dann auf die Adresse mit Schrägstrich am Ende weitergeleitet. Jede Weiterleitung ist ein eigener Hin- und Rückweg, und die Seite ist noch nicht einmal angefordert. Alte Kampagnenlinks und Adressen einer früheren Website verlängern diese Kette.

So erkennen Sie es: Haken Sie im Netzwerk-Tab das Kästchen „Preserve log“ (Protokoll beibehalten) an und geben Sie die Adresse in ihrer längsten Form ein, mit http und ohne www. Zeilen mit 301, 302, 307 und ähnlichen Werten in der Spalte Status sind Weiterleitungen; gibt es mehr als eine, bevor die Seite selbst erreicht ist, liegt eine Kette vor. Auf dieser Website kannte Google am 22. August 2026 93 Adressen, obwohl die Website 58 Seiten hatte: Der Unterschied waren dieselben Seiten ohne www, mit http, ohne Schrägstrich am Ende und mit der Endung „/index.html“. Alle wurden per dauerhafter Weiterleitung auf eine einzige Adresse zusammengeführt.

3 · Sind die Bilder größer als nötig?

Wird ein Foto, das auf dem Smartphone wenige hundert Pixel breit erscheint, in der Größe hochgeladen, in der es aus der Kamera kam, lädt der Besucher Pixel herunter, die er nie sieht. Das größte Bild der Seite ist oft zugleich das LCP-Element; kommt es spät, gilt die Seite als spät geladen.

So erkennen Sie es: Der Diagnosebereich von PageSpeed Insights zeigt, welches Element das LCP-Element ist. Wählen Sie im Netzwerk-Tab den Filter Img (Bild) und sortieren Sie nach der Spalte Size (Größe), dann stehen die schwersten Dateien oben. Wiegt ein einzelnes Bild mehr als der ganze Rest der Seite zusammen, ist das die erste Stelle, an der man ansetzt.

4 · Wartet die Seite auf eine Datei?

Der Browser zeichnet nichts auf den Bildschirm, bevor er die am Seitenanfang eingebundenen Stildateien und manche Skripte heruntergeladen und verarbeitet hat. Man nennt sie Render-blockierende Ressourcen. Je mehr es davon gibt und je mehr davon von anderen Servern kommen, desto länger bleibt der Bildschirm leer.

So erkennen Sie es: PageSpeed Insights listet diese Dateien im Diagnosebereich gesondert auf. In der Spalte Waterfall (Wasserfall) rechts im Netzwerk-Tab sehen Sie, wie viele Stil- und Skriptdateien geladen werden, bevor die Seite zum ersten Mal gezeichnet wird; eine lange Treppe bedeutet eine wartende Seite.

5 · Hat die Seite zu viel JavaScript?

Die Kosten von JavaScript liegen nicht nur im Herunterladen: Das Smartphone parst, kompiliert und führt es aus, und währenddessen kann die Seite nicht auf Klicks reagieren. Das Gefühl „Ich habe geklickt, aber nichts ist passiert“ kommt oft daher und zeigt sich im INP-Wert. Slideshows, Animationsbibliotheken und Page Builder sind typische Posten, die die JavaScript-Last vergrößern.

So erkennen Sie es: Mit dem JS-Filter im Netzwerk-Tab sehen Sie die gesamte Skriptgröße. Der Bereich Coverage (Abdeckung) in den Entwicklertools zeigt, wie viel des geladenen Codes auf dieser Seite nie verwendet wird. Die Total Blocking Time im Laborbereich von PageSpeed ist das Laborgegenstück dieser Last. So setzen Sie eine Obergrenze: JavaScript-Budget.

6 · Wie viel Last bringt Code von Drittanbietern?

Live-Chat-Blase, Werbe- und Analyse-Tags, eingebettete Karte und Video, Social-Media-Feed: All das kommt vom Server eines anderen Unternehmens, und dessen Geschwindigkeit bestimmen nicht Sie. Jedes Element mag für sich klein aussehen, zusammen können sie der schwerste Teil der Seite sein.

So erkennen Sie es: Klicken Sie im Netzwerk-Tab mit der rechten Maustaste auf eine Spaltenüberschrift und blenden Sie die Spalte Domain ein. Zeilen außerhalb Ihrer eigenen Domain sind Code von Drittanbietern; hier zählen Sie, wie viele es sind und wie viele Daten sie laden. Die Frage dazu ist nicht technisch, sondern geschäftlich: Bringt jedes davon einen geschäftlichen Gegenwert, und wird es auf jeder Seite gebraucht?

7 · Halten die Schriften die Seite auf?

Markenschriften sind schön, aber jede Familie und jeder Schnitt ist eine eigene Datei. Bis die Datei eintrifft, ist der Text entweder gar nicht sichtbar oder wird in einer Ersatzschrift gezeichnet und später ausgetauscht; im zweiten Fall verschieben sich die Zeilen.

So erkennen Sie es: Wählen Sie im Netzwerk-Tab den Filter Font und schauen Sie auf die Anzahl der Dateien. Sehen Sie beim Öffnen der Seite über eine langsame Verbindung, dass der Text erst verzögert erscheint oder sich die Zeilen beim Schriftwechsel bewegen, ist das die Ursache.

8 · Warum schnell am Desktop, aber langsam auf dem Smartphone?

Dieselbe Seite ist auf dem Smartphone meist langsamer, und der Hauptgrund ist nicht das Netz, sondern der Prozessor: Ein Mittelklasse-Smartphone führt dasselbe JavaScript deutlich langsamer aus als ein Laptop. Deshalb ist es irreführend, am Desktop zu messen und „wir sind schnell“ zu sagen.

So erkennen Sie es: PageSpeed Insights öffnet das Ergebnis im Tab für Mobilgeräte; vergleichen Sie ihn mit dem Desktop-Tab. Auch die Search Console berichtet Mobilgeräte und Desktop getrennt. Ist der Unterschied groß, geben Sie der fünften und sechsten Ursache oben Vorrang.

Die Seite lädt schnell, springt aber – was tun?

Das ist keine Langsamkeit, sondern Layoutverschiebung, doch der Besucher erlebt sie ebenfalls als schlechte Erfahrung: Die Zeile, die er liest, rutscht weg, und statt der gewünschten Schaltfläche drückt er etwas anderes. Die häufigsten Ursachen sind Bilder ohne angegebene Abmessungen und Banner, die sich nachträglich einfügen. Fügen Sie den Quellcode eines Teils Ihrer Seite in den Prüfer für Layoutverschiebungsrisiken ein, listet das Werkzeug Bilder, Videos und Frames ohne vorab reservierten Platz einzeln auf.

Warum messen statt raten?

Weil die Ursache der Langsamkeit oft nicht dort liegt, wo man zuerst hinsieht. Auf dieser Website stieg nach einer Arbeitsrunde die Blockierzeit der Startseite plötzlich an; erster Verdacht war das in dieser Runde hinzugefügte JavaScript. Der Browser-Trace sagte etwas anderes: Rund 70 Prozent der gesamten Blockierzeit stammten von einem einzigen CSS-Selektor, und dieser Selektor färbte auf dieser Seite überhaupt nichts ein. Die ganze Geschichte steht in Wie ein :has()-Selektor die Blockierzeit beeinflusste.

Dieselbe Lektion haben wir aus einer anderen Richtung gelernt: Als die beiden Bibliotheken entfernt wurden, die auf der Website das Scrollen steuerten, sank das komprimierte JavaScript von 51,1 Kilobyte auf 33,5 Kilobyte, weil der Browser diese Aufgabe selbst erledigen konnte. Heute liegt der Median der Labor-Performance-Punktzahl dieser Website bei 99, der Median der Total Blocking Time bei 21 Millisekunden, die Labor-Layoutverschiebung bei 0; der schlechteste LCP, gemessen mit einem echten Chrome-Browser an der Live-Adresse, liegt bei 420 Millisekunden. Die Grenze, die wir uns gesetzt haben, sind 0,8 Sekunden, und sie wird vor jeder Veröffentlichung gemessen.

Die Ursache der Langsamkeit wird nicht erraten; sie zeigt sich im Trace.

Was tun, wenn die Ursache gefunden ist?

Die Reihenfolge ist wichtig. Prüfen Sie zuerst in der Search Console, welcher Wert in welcher Seitengruppe fehlschlägt und ob auf Mobilgeräten oder am Desktop. Öffnen Sie dann eine Seite aus dieser Gruppe in PageSpeed Insights und lesen Sie den Diagnosebereich. Bestätigen Sie zuletzt mit dem Netzwerk-Tab, welche der acht Ursachen oben hervorsticht. Ist Ihre Website mit WordPress gebaut, beschreibt ein eigener Artikel, wie man den Anteil von Plugins, Theme und Server trennt: WordPress-Website lädt langsam.

Im Gespräch mit Ihrem Webteam oder einem externen Fachmann helfen diese Fragen:

• Welcher Wert schlägt fehl — LCP, INP oder CLS — und stammt das aus Felddaten oder aus einem Labortest?
• In welcher Seitengruppe liegt das Problem, und auf Mobilgeräten oder am Desktop?
• Worauf stützen Sie die Ursache — auf einen Browser-Trace oder auf eine Vermutung?
• Wird nach der Korrektur dieselbe Messung unter denselben Bedingungen wiederholt?
• Was verhindert, dass die Geschwindigkeit wieder einbricht, wenn ein neues Plugin oder Bild hinzukommt?

Die letzte Frage wird am häufigsten übersprungen. Wird die Geschwindigkeit einmal korrigiert und dann sich selbst überlassen, nimmt jedes neue Plugin und jedes neue Kampagnenbild ein Stück davon zurück. Die dauerhafte Lösung ist, Grenzen festzuschreiben, die die Website nicht überschreiten darf, und sie bei jeder Veröffentlichung zu messen.

Wenn Sie die Geschwindigkeit Ihrer eigenen Website verbessern möchten: Unser individuelles Webdesign liefert Performance als messbares Budget aus — Ziel ist ein LCP unter 0,8 Sekunden.