Warum Ihre Website langsam ist: die fünf häufigsten Ursachen

Von Manuel Hack, ihp media · Aktualisiert am 14. Juni 2026

Wenn Besucher auf eine Seite warten, springen die meisten ab. Google misst als Zielwert für den Largest Contentful Paint eine Ladezeit von unter 2,5 Sekunden. Wer darüber liegt, verliert nicht nur Besucher, sondern auch Ranking-Positionen, weil die Core Web Vitals seit 2021 ein Rankingfaktor sind. Die häufige Annahme, eine langsame Website brauche ein teures Redesign, stimmt nicht. Meistens liegen die Ursachen an wenigen technischen Stellen, die sich gezielt beheben lassen.

Dieser Artikel zeigt die fünf häufigsten davon, wie sich jede Ursache messen lässt und was dagegen hilft. Was die Core Web Vitals im Detail bedeuten, erklärt der Artikel Core Web Vitals einfach erklärt. Hier geht es um die Diagnose.

Wo anfangen: Geschwindigkeit zuerst messen

Unter pagespeed.web.dev reicht es, die URL einzugeben. Der Bericht gliedert sich in zwei Teile. Der obere zeigt, falls ausreichend Nutzerdaten aus Chrome-Browsern vorliegen, die tatsächlich erlebten Ladezeiten echter Besucher. Der untere Teil zeigt einen simulierten Labortest und listet konkrete Probleme auf, oft mit einer Größenangabe, wie viel Zeit sich durch die Behebung einsparen lässt.

Die wichtigsten Kennzahlen im Überblick: Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element geladen ist. Der Time to First Byte (TTFB) zeigt, wie schnell der Server überhaupt antwortet. Der Total Blocking Time (TBT) beschreibt, wie lange Skripte den Hauptthread des Browsers blockieren. Diese drei Werte führen meist direkt zu einer der fünf Ursachen unten.

Ursache 1: Zu große und unoptimierte Bilder

Das Problem entsteht fast immer ohne böse Absicht. Fotos werden vom Designer, Fotografen oder aus dem internen Bildarchiv geliefert und direkt in die Mediathek hochgeladen. Niemand hat diesen Schritt bewusst optimiert, weil er beim ersten Hochladen oft nicht als Engpass auffällt. Erst wenn zehn, zwanzig oder mehr solche Bilder auf einer Seite liegen, ist der Schaden spürbar.

Google empfiehlt auf web.dev drei Hebel bei der Bildoptimierung: Komprimierung, modernes Format und passende Abmessungen. In der Praxis bedeutet das:

• Komprimierung: JPEG-Dateien lassen sich oft auf 20 bis 30 Prozent der Originalgröße reduzieren, ohne dass ein Unterschied sichtbar wird. Tools wie Squoosh, ShortPixel oder die automatische WordPress-Komprimierung erledigen das.
• Format: WebP liefert bei gleicher Qualität 25 bis 35 Prozent kleinere Dateien als JPEG. Alle aktuellen Browser unterstützen WebP problemlos. AVIF geht noch weiter, braucht aber noch ein PNG- oder JPEG-Fallback.
• Abmessungen: Ein Bild mit 4000 Pixeln Breite, das auf dem Bildschirm in einer 600-Pixel-Spalte erscheint, überträgt unnötig das fast 45-fache der nötigen Pixelanzahl. Responsive Images mit dem srcset-Attribut liefern jedem Gerät nur die passende Größe.

PageSpeed Insights zeigt es so: Der Audit „Properly size images“ und „Efficiently encode images“ erscheinen im Bericht mit einer Ersparnis in Sekunden. Ist das die größte Einzelposition, beginnt die Optimierung hier.

Wer in WordPress arbeitet, findet eine vollständige Anleitung im Artikel Bilder fürs Web optimieren ohne sichtbaren Qualitätsverlust.

Ursache 2: Zu viele oder schlechte Plugins

Das eigentliche Problem ist nicht die Anzahl, sondern die Qualität und die fehlende Selektivität. Ein sauber programmiertes Plugin lädt seine Ressourcen nur auf den Seiten, wo es auch eingesetzt wird. Schlecht entwickelte Plugins laden immer alles, egal ob ein Kontaktformular auf einer bestimmten Seite vorkommt oder nicht.

Hinzu kommen Plugins, die kaum noch genutzt werden, aber aktiv geblieben sind. Ein Slider-Plugin aus dem ersten Website-Aufbau vor vier Jahren, das längst durch eine andere Lösung ersetzt wurde, hat keinen sichtbaren Einfluss mehr auf das Layout, schleppt aber trotzdem Code mit.

Diagnose: Im Chrome-Browser lässt sich in den Entwicklertools unter „Network“ sehen, welche Dateien beim Laden der Seite übertragen werden. Lange Listen von Dateien aus erkennbaren Plugin-Ordnern (oft erkennbar am Pfad /wp-content/plugins/) sind ein Hinweis. Für eine detailliertere Analyse zeigt der Lighthouse-Audit „Eliminate render-blocking resources“, welche dieser Dateien den Seitenaufbau direkt aufhalten.

Eine externe Einbindung wie ein Chat-Widget oder ein Analyse-Skript verhält sich technisch ähnlich wie ein Plugin. Drittanbieter-JavaScript lädt von externen Servern nach und kann den Seitenaufbau um mehrere hundert Millisekunden verlängern, wenn der externe Server langsam antwortet oder das Skript blockierend eingebunden ist.

Ursache 3: Kein oder schlechtes Caching

WordPress-Seiten sind dynamisch aufgebaut. Bei jedem Aufruf fragt WordPress die Datenbank nach Inhalten, Einstellungen, Menüs und Widget-Daten. Ein Artikel mit eingebetteten Elementen kann dabei mehr als 50 Datenbankabfragen auslösen, bevor die erste Zeile HTML an den Browser geht. Auf einem schwächeren Server summiert sich das messbar.

Caching greift auf drei Ebenen:

• Seiten-Cache (Server-seitig): Die fertige HTML-Seite wird gespeichert und bei Folgeaufrufen direkt ausgeliefert. Plugins wie W3 Total Cache oder WP Rocket übernehmen das für WordPress.
• Browser-Cache: Statische Dateien wie Bilder, CSS und JavaScript werden mit einem Ablaufdatum versehen. Beim nächsten Besuch lädt der Browser sie aus dem lokalen Speicher statt neu vom Server. Die korrekte Konfiguration über den HTTP-Header Cache-Control ist Serveraufgabe.
• Object-Cache: Datenbankabfragen werden zwischengespeichert. Auf Seiten mit vielen gleichzeitigen Besuchern oder komplexem Inhalt macht ein Object-Cache über Redis oder Memcached einen messbaren Unterschied.

Diagnose: PageSpeed Insights zeigt unter „Serve static assets with an efficient cache policy“ an, ob Dateien korrekt mit Ablaufdaten ausgeliefert werden. Ein Wert von no-cache bei Bildern und Skripten bedeutet, dass der Browser sie bei jedem Besuch neu laden muss.

Eine ausführliche Anleitung dazu steht im Artikel Caching verständlich erklärt.

# Browser-Cache: Ablaufdaten für statische Dateien
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg            "access plus 1 year"
  ExpiresByType image/png             "access plus 1 year"
  ExpiresByType image/webp            "access plus 1 year"
  ExpiresByType image/avif            "access plus 1 year"
  ExpiresByType image/svg+xml         "access plus 1 year"
  ExpiresByType text/css              "access plus 6 months"
  ExpiresByType application/javascript "access plus 6 months"
  ExpiresByType application/x-javascript "access plus 6 months"
  ExpiresByType font/woff2            "access plus 1 year"
  ExpiresByType application/font-woff2 "access plus 1 year"
</IfModule>

# Gzip-Komprimierung
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css
  AddOutputFilterByType DEFLATE application/javascript application/x-javascript
  AddOutputFilterByType DEFLATE image/svg+xml application/json
</IfModule>

Ursache 4: Billiges oder überlastetes Hosting

Shared-Hosting-Pakete teilen sich Server-Ressourcen mit Dutzenden oder Hunderten anderer Websites. Wenn ein Nachbar auf demselben Server gerade viel Traffic hat oder Daten verarbeitet, leidet die Antwortzeit der eigenen Seite mit. Das ist keine Ausnahme, sondern das Grundprinzip des günstigsten Hostings.

Google empfiehlt auf web.dev einen TTFB unter 800 ms als guten Wert. Lighthouse markiert bereits Werte über 600 ms als Auffälligkeit, weil dieser Schwellenwert als Hosting-Indikator gilt. Den eigenen Wert zeigt PageSpeed Insights im Abschnitt „Server response times (TTFB)“ oder im Netzwerk-Tab des Chrome-Entwicklertools: Der erste Balken für die HTML-Anfrage enthält die reine Wartezeit auf den Server, erkennbar an der helleren Farbgebung vor dem eigentlichen Download.

Drei weitere Faktoren beim Hosting, die die Performance beeinflussen:

• PHP-Version: PHP 8.x ist messbar schneller als PHP 7.4. Wer noch auf einer alten PHP-Version läuft, verliert Performance ohne jeden Gegenwert.
• Serverstandort: Ein Server in Frankfurt antwortet auf Anfragen aus Deutschland schneller als ein Server in den USA, weil die physische Entfernung die Latenz direkt beeinflusst. Bei einem Content-Delivery-Network (CDN) liegen Kopien der Inhalte auf Servern weltweit, der Nutzer wird automatisch zum nächstgelegenen geleitet.
• MySQL-Version und Datenbankoptimierung: Veraltete MySQL-Versionen und fragmentierte Tabellen können Datenbankabfragen verlangsamen. Viele Hosting-Anbieter bieten MariaDB an, das für WordPress-Lasten oft besser optimiert ist.

Was gutes WordPress-Hosting ausmacht und welche Merkmale wirklich relevant sind, steht im Artikel WordPress-Hosting: Worauf es bei Tempo und Sicherheit ankommt.

Ursache 5: Render-blockierender Code und aufgeblähte Themes

Browser bauen eine Seite von oben nach unten auf. Trifft er auf eine <script>-Anforderung ohne defer oder async, hält er an, lädt die Datei, führt sie aus und arbeitet erst dann weiter. Dasselbe gilt für CSS-Dateien: Sie blockieren das Rendering, solange sie nicht vollständig geladen sind.

Page-Builder wie Divi oder Elementor laden typischerweise viele dieser Dateien. Ein Teil davon ist für das Grundlayout nötig, ein anderer Teil gehört zu Modulen, die nur auf bestimmten Seiten vorkommen. Ohne gezielte Optimierung wird alles gemeinsam an den Browser geschickt.

Umfangreiche JavaScript-Bundles erzeugen sogenannte Long Tasks, also Verarbeitungsaufgaben, die den Hauptthread länger als 50 ms blockieren. Während ein Long Task läuft, reagiert die Seite nicht auf Nutzereingaben. Das ist der technische Hintergrund hinter einem hohen Interaction to Next Paint (INP)-Wert.

Drei konkrete Punkte, die PageSpeed Insights direkt benennt:

• Render-blocking resources: Aufgelistete Dateien, die den LCP verzögern. Die Lösung ist meist das Hinzufügen von defer bei JavaScript oder das Verschieben nicht-kritischer Skripte ans Ende der Seite.
• Unused JavaScript und Unused CSS: Code, der zwar übertragen, aber auf der aktuellen Seite nicht verwendet wird. Bei Page-Buildern typischerweise groß.
• Minimize main-thread work: Wenn der Verarbeitungsaufwand für JavaScript hoch ist, zeigt dieser Audit die Hauptverursacher.

Eine gezielte Anleitung zum Auflösen von Render-Blocking steht im Artikel Render-blocking CSS und JavaScript auflösen.

Übersicht: Ursachen, Symptome, Messung, Lösung

Schritt für Schritt: Diagnose mit PageSpeed Insights

Die folgende Anleitung führt in wenigen Minuten von der Messung zur Priorität.

1. Startseite messen: URL auf pagespeed.web.dev eingeben, Bericht aufrufen. Beide Tabs prüfen: „Mobile“ und „Desktop“.
2. TTFB ablesen: Im Abschnitt „Server response times“ den TTFB-Wert prüfen. Liegt er über 600 ms, ist Hosting die erste Baustelle, bevor Frontend-Optimierungen Sinn ergeben.
3. Bilder-Audits prüfen: „Properly size images“ und „Efficiently encode images“ aufklappen. Zeigen die genannten Dateien zusammen mehr als 500 KB Einsparpotenzial, beginnt die Optimierung hier.
4. Render-blocking prüfen: „Eliminate render-blocking resources“ aufklappen. Jede gelistete Datei kostet Zeit bei jedem Seitenaufruf.
5. Cache-Header prüfen: „Serve static assets with an efficient cache policy“ prüfen. Bilder, CSS und JavaScript ohne Ablaufdatum werden bei jedem Besuch neu geladen.
6. Wichtigste Unterseite testen: Neben der Startseite die am häufigsten besuchte Unterseite oder den zentralen Conversion-Punkt (Kontakt, Produktseite) messen. Probleme verteilen sich nicht immer gleichmäßig.

Praxisbeispiel

In einem Projekt für ein mittelständisches Dienstleistungsunternehmen maß der LCP auf der Startseite 7,4 Sekunden. PageSpeed Insights listete drei Probleme: Bilder mit einem Einsparpotenzial von 2,1 MB, einen TTFB von 830 ms und drei render-blockierende JavaScript-Dateien.

Die Analyse zeigte, dass das gebuchte Shared-Hosting-Paket auf einem Server mit einer Auslastung lief, die die TTFB-Werte dauerhaft über 600 ms hob. Das war der kritischste Einzelpunkt, weil jede weitere Optimierung auf diesem Fundament aufbaute. Ein Wechsel auf ein Managed-WordPress-Hosting senkte den TTFB auf 180 ms.

Im zweiten Schritt wurden die sieben größten Bilder über ShortPixel neu komprimiert und auf WebP umgestellt. Das Volumen sank von 2,3 MB auf 340 KB. Im dritten Schritt wurden zwei der drei JavaScript-Dateien mit defer versehen, eine war ein nicht mehr genutztes Plugin, das deaktiviert wurde.

Das Ergebnis nach diesen drei Schritten: LCP von 7,4 auf 2,1 Sekunden, also in den grünen Bereich. Alle drei Maßnahmen lagen unter drei Stunden Arbeitszeit. Das illustriert das Grundprinzip: Messen, die wichtigste Ursache zuerst, dann prüfen, ob das Problem gelöst ist.

Sofort-Checkliste

• PageSpeed Insights-Bericht für Startseite und wichtigste Unterseite ausgeführt?
• TTFB unter 600 ms? Falls nicht, Hosting-Paket und PHP-Version prüfen.
• Bilder komprimiert und in WebP oder AVIF konvertiert?
• Bildabmessungen passend zur tatsächlichen Darstellungsgröße (kein 4000px-Bild in einer 600px-Spalte)?
• Ungenutzte Plugins deaktiviert und gelöscht?
• Externe Skripte (Chat, Tracking, Social) auf Notwendigkeit geprüft?
• Caching-Plugin aktiv oder Seiten-Cache über Hosting konfiguriert?
• Browser-Cache für Bilder, CSS und JS mit Ablaufdatum konfiguriert?
• Render-blocking-Skripte auf defer oder async umgestellt?
• Lighthouse-Audit „Unused JavaScript“ und „Unused CSS“ geprüft?

Häufige Fragen

Wie messe ich, ob meine Website langsam ist?

Der einfachste Einstieg ist Google PageSpeed Insights. Das Werkzeug ist kostenlos, braucht keine Anmeldung und zeigt, wenn genug Nutzerdaten vorliegen, die tatsächlich erlebten Ladezeiten aus Chrome-Browsern. Der Labortest läuft immer. Wichtig: Beide Tabs messen, Mobile und Desktop, denn mobile Netzwerke zeigen Probleme deutlicher.

Muss ich alle fünf Ursachen beheben?

Nein. PageSpeed Insights priorisiert die Probleme nach Einsparpotenzial in Sekunden. Meistens dominieren ein oder zwei Punkte das Ergebnis. Dort anfangen und nach jeder Maßnahme neu messen gibt mehr als fünf Maßnahmen parallel zu beginnen.

Beeinflusst die Ladezeit mein Google-Ranking?

Ja. Die Core Web Vitals, also LCP, INP und CLS, sind seit 2021 offiziell ein Rankingfaktor. Wer die Grenzwerte deutlich überschreitet, verliert im Wettbewerb gegen inhaltlich gleichwertige, aber schnellere Seiten. Was diese Werte im Detail bedeuten, zeigt der Artikel Core Web Vitals einfach erklärt.

Meine Website sieht modern aus, ist aber trotzdem langsam. Warum?

Optik und technische Performance hängen nicht voneinander ab. Hochwertige Fotos, Animationen und eingebettete Dienste machen eine Seite attraktiv, erzeugen aber Last, wenn sie nicht technisch sauber umgesetzt sind. Ein schlichtes Design kann technisch hervorragend laufen. Vom visuellen Eindruck lässt sich nicht auf die Performance schließen.

Lohnt sich Optimierung für eine kleine Unternehmenswebsite?

Gerade dort. Kleine Websites haben wenig Zugriffe und können sich kaum leisten, Besucher durch Abbrüche zu verlieren. Hinzu kommt, dass die technischen Grundlagen bei kleineren Seiten überschaubar sind, sodass sich Bilder komprimieren und ein Caching-Plugin einrichten in wenigen Stunden erledigen lassen, ohne teure Entwicklungsarbeit.

Was kostet eine professionelle Performance-Optimierung?

Das hängt vom Ausgangszustand ab. Wenn nur Bilder optimiert und ein Caching-Plugin konfiguriert werden müssen, liegt der Aufwand im niedrigen dreistelligen Bereich. Wenn das Hosting gewechselt, render-blockierende Skripte umgebaut und das Theme ausgetauscht werden muss, kann es ein Vielfaches davon sein. Ein strukturierter Website-Check zeigt, was wirklich nötig ist, bevor Kosten entstehen.

Hilft ein CDN bei langsamen Websites?

Ein Content-Delivery-Network verteilt statische Inhalte auf Server weltweit und liefert sie von dem aus, der dem Nutzer am nächsten liegt. Das senkt die Latenz messbar, besonders für internationale Besucher. Es löst aber kein Hosting-Problem am Ursprungsserver und keine Bild-Komprimierungsprobleme. Ein CDN ist sinnvoll, wenn die Grundlagen stimmen.