Lädt deine Website langsam, liegt es meist an einer trägen Serverantwort, zu großen Bildern und Skripten oder einem überladenen Plugin-Stack. Miss zuerst mit PageSpeed Insights, finde die größte Bremse und behebe sie gezielt, statt wahllos Optimierungs-Plugins zu installieren.
Google bewertet Ladezeit über die Core Web Vitals; für den Seitenaufbau zählt vor allem der Largest Contentful Paint (LCP), der höchstens 2,5 Sekunden betragen sollte. Auswertungen von web.dev zeigen: Bei Seiten mit schlechtem LCP geht die meiste Zeit verloren, bevor der Server überhaupt antwortet, und durch spät entdeckte Hauptbilder. Der Download des Bildes selbst ist selten das Problem. Mit dem 5-Schritte-Tempo-Check misst du, ordnest die Bremse zu und behebst zuerst das, was am meisten bringt.
Woran erkennst du, ob deine Website wirklich zu langsam ist?
An Messwerten, nicht am Gefühl. Prüfe deine Seite mit PageSpeed Insights von Google. Gut ist laut Google ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1. Darüber verlieren Besucher spürbar Geduld.
Wichtig ist der Unterschied zwischen zwei Datenarten, die PageSpeed Insights anzeigt. Felddaten stammen aus dem Chrome User Experience Report (CrUX) und spiegeln echte Besuche der vergangenen 28 Tage wider. Google wertet dabei das 75. Perzentil aus, also den Wert, den drei Viertel deiner Besucher erreichen oder unterbieten. Labordaten erzeugt Lighthouse in einer kontrollierten Testumgebung; sie eignen sich zur Fehlersuche, bilden reale Engpässe aber nicht immer ab.
| Messwert | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|
| LCP (Hauptinhalt sichtbar) | bis 2,5 s | 2,5 bis 4 s | über 4 s |
| INP (Reaktion auf Eingaben) | bis 200 ms | 200 bis 500 ms | über 500 ms |
| CLS (Layout-Verschiebungen) | bis 0,1 | 0,1 bis 0,25 | über 0,25 |
| TTFB (erste Serverantwort) | bis 0,8 s | 0,8 bis 1,8 s | über 1,8 s |
Quellen: PageSpeed-Insights-Dokumentation (Stand 21.10.2024), TTFB-Werte von web.dev (November 2025). Details erklärt unser Glossareintrag Core Web Vitals.
Wo geht die Ladezeit typischerweise verloren?
Meist vor dem eigentlichen Bild-Download. web.dev zerlegt den LCP in vier Abschnitte: Serverantwort, Wartezeit bis zum Laden des Hauptbildes, dessen Download und die Darstellung. Bei langsamen Seiten fressen die ersten beiden Abschnitte den Großteil der Zeit.
Die Zahlen stammen aus einer Auswertung realer Chrome-Nutzerdaten auf web.dev (Stand 20.08.2024). Bei Websites mit schlechtem LCP lag die typische Serverantwort (TTFB) bei 2.270 Millisekunden, die Wartezeit bis zum Start des Bild-Downloads bei 1.290 Millisekunden. Der Download des Hauptbildes dauerte dagegen nur rund 350 Millisekunden. Laut web.dev verbringen die meisten Websites mit schlechtem LCP weniger als zehn Prozent dieser Zeit mit dem Herunterladen des LCP-Bildes.
| LCP-Abschnitt | Websites mit gutem LCP | Websites mit schlechtem LCP |
|---|---|---|
| Serverantwort (TTFB) | 600 ms | 2.270 ms |
| Wartezeit bis zum Bild-Download | 350 ms | 1.290 ms |
| Download des Hauptbildes | 160 ms | 350 ms |
| Darstellung | 230 ms | 360 ms |
Daneben spielt das Seitengewicht eine Rolle. Laut Web Almanac 2025 des HTTP Archive wog die mittlere Startseite im Juli 2025 auf Mobilgeräten 2,56 MB, davon 911 KB Bilder und 632 KB JavaScript. Viel JavaScript belastet vor allem schwächere Smartphones beim Ausführen, nicht nur beim Laden.
Schau in PageSpeed Insights nicht nur auf die Gesamtnote, sondern auf die Diagnose „LCP-Aufschlüsselung“ (LCP breakdown). Sie zeigt, welcher der vier Abschnitte bei deiner Seite dominiert. Ist es die Serverantwort, bringt Bildkomprimierung kaum etwas. Ist es die Wartezeit, wird das Hauptbild vermutlich zu spät entdeckt, etwa weil es per Lazy Loading oder erst über CSS oder JavaScript nachgeladen wird.
Wie findest du heraus, ob der Server die Bremse ist?
Prüfe die Time to First Byte. Liegt sie dauerhaft über 0,8 Sekunden, ist das Problem auf dem Server oder davor zu suchen. Dazu zählen laut web.dev Weiterleitungen, DNS-Auflösung, Verbindungsaufbau samt TLS-Handshake und die Zeit, bis das erste Byte eintrifft.
Typische Ursachen bei kleinen Websites sind ein knapp bemessener Hosting-Tarif, eine veraltete PHP-Version und fehlendes Seiten-Caching. WordPress empfiehlt aktuell PHP 8.3 oder neuer sowie MySQL 8.0 oder MariaDB 10.11 oder neuer. Ältere PHP-Versionen laufen teilweise noch, haben laut WordPress aber ihr Supportende erreicht und können Sicherheitslücken öffnen. Die Version änderst du meist im Kundenmenü deines Hosters; mach vorher ein Backup und teste die Seite danach.
Auch Weiterleitungsketten kosten Zeit, etwa von http auf https und anschließend von „ohne www“ auf „mit www“. Verlinke intern immer direkt auf die endgültige Adresse. Worauf du bei Tarif, Ressourcen und Serverstandort achten solltest, beschreibt Webhosting für Selbstständige: Worauf es bei Tarif und Serverstandort ankommt.
Was bringt Caching, und welche Art brauchst du?
Caching spart dem Server Arbeit. Ein Seiten-Cache legt fertig erzeugte Seiten als statische Dateien ab, sodass WordPress nicht bei jedem Aufruf PHP und Datenbank bemühen muss. Für die meisten kleinen Websites ist das die wirksamste einzelne Maßnahme gegen hohe Serverantwortzeiten.
Die WordPress-Dokumentation zur Optimierung (Stand 14.10.2026) unterscheidet mehrere Ebenen:
- Seiten-Cache: per Caching-Plugin oder direkt beim Hoster; viele Tarife bringen serverseitiges Caching mit, dann brauchst du kein zusätzliches Plugin.
- Objekt-Cache: speichert häufige Datenbankabfragen zwischen; setzt einen Cache-Dienst wie Redis oder Memcached beim Hoster und ein passendes Plugin voraus.
- Opcode-Cache: etwa OPcache, hält übersetzten PHP-Code im Speicher; ist bei aktuellen PHP-Versionen meist aktiv.
- CDN: liefert Bilder, CSS und JavaScript von Servern in Nutzernähe aus und entlastet den eigenen Webspace, am besten in Kombination mit einem Seiten-Cache.
Betreibst du einen Shop oder Mitgliederbereich, müssen Warenkorb, Kasse und Kundenkonto vom Seiten-Cache ausgenommen sein. Prüfe das nach der Einrichtung mit einem Testkauf.
Wie bekommst du Bilder, Skripte und Plugins in den Griff?
Bilder komprimierst du, lieferst sie in passender Größe und in modernen Formaten wie WebP aus. Bei Skripten und Plugins gilt: Was du nicht brauchst, deaktivierst und löschst du. Die WordPress-Dokumentation nennt das Entfernen unnötiger Plugins als einfachsten ersten Schritt.
Bei Bildern lohnt sich ein genauer Blick auf das Hauptbild oben auf der Seite, denn es ist häufig das LCP-Element. Dieses eine Bild solltest du nicht per Lazy Loading verzögern, sondern direkt im HTML einbinden, damit der Browser es früh entdeckt. Alle Bilder weiter unten dürfen dagegen nachgeladen werden. Gib Bildern außerdem Breite und Höhe mit, damit der Platz reserviert ist und das Layout beim Laden nicht springt.
Plugins testest du am besten einzeln: auf einer Staging-Kopie deaktivieren, neu messen, Unterschied notieren. So findest du heraus, welches Plugin Skripte auf jeder Seite lädt, obwohl es nur auf einer gebraucht wird. Läuft nach einem Plugin-Test plötzlich gar nichts mehr, hilft WordPress „Kritischer Fehler“: Website wiederherstellen.
Optimierungs-Plugins, die CSS und JavaScript zusammenfassen, verzögern oder entfernen, können Menüs, Formulare, Cookie-Banner oder den Warenkorb unbrauchbar machen. Lege vor jeder Änderung ein vollständiges Backup an, ändere immer nur eine Einstellung und prüfe danach die wichtigsten Funktionen der Seite. Wie du Backups verlässlich aufsetzt, steht in Backup-Strategie für Selbstständige: Die 3-2-1-Regel umsetzen.
Wie gehst du strukturiert vor, statt planlos zu optimieren?
Mit dem 5-Schritte-Tempo-Check: messen, Bremse zuordnen, Server prüfen, Inhalte verschlanken, erneut messen. Jeder Schritt baut auf dem vorigen auf. So investierst du Zeit dort, wo die Messung den größten Engpass zeigt, und nicht in Maßnahmen ohne Wirkung.
- Messen: Startseite und zwei wichtige Unterseiten in PageSpeed Insights prüfen, mobil und Desktop.
- Bremse zuordnen: In der LCP-Aufschlüsselung nachsehen, welcher Abschnitt dominiert: Serverantwort, Wartezeit, Download oder Darstellung.
- Server prüfen: Bei hoher TTFB PHP-Version, Seiten-Caching und Weiterleitungen kontrollieren, notfalls mit dem Hoster über Tarif und Ressourcen sprechen.
- Inhalte verschlanken: Hauptbild früh laden, übrige Bilder komprimieren und nachladen, unnötige Plugins und Skripte entfernen.
- Erneut messen: Laborwerte direkt nach der Änderung prüfen, Felddaten nach etwa vier Wochen, weil CrUX einen 28-Tage-Zeitraum abbildet.
💬 Meine Einschätzung
Verbreitet ist die Annahme, eine langsame Website liege vor allem an zu großen Bildern, und ein Komprimierungs-Plugin löse das Problem. Die Auswertung auf web.dev spricht dagegen: Bei Seiten mit schlechtem LCP entfällt auf den Download des Hauptbildes typischerweise der kleinste Teil der Ladezeit, während Serverantwort und Wartezeit dominieren. Ich würde deshalb zuerst Hosting, Caching und die Einbindung des Hauptbildes prüfen und Bilder erst danach systematisch verkleinern.
Lohnt sich der Aufwand auch für SEO?
Ja, aber mit realistischen Erwartungen. Laut Google Search Central werden die Core Web Vitals von den Ranking-Systemen genutzt, relevanter Inhalt bleibt jedoch wichtiger. Google zeigt nach eigener Aussage den relevantesten Inhalt, auch wenn dessen Seitenerfahrung schwächer ist.
Eine schnelle Seite ersetzt also keine guten Texte, verhindert aber, dass Besucher abspringen, bevor sie deine Inhalte überhaupt sehen.
Wie Ladezeit, Indexierung und Inhalte zusammenspielen, zeigt unser Pillar SEO für kleine Unternehmen: So wird die eigene Website bei Google gefunden. Tiefer in die technische Seite steigt Technisches SEO-Fundament: Core Web Vitals optimieren ein. Planst du ohnehin einen Neuaufbau, lohnt der Blick in Website erstellen für Selbstständige: Wege, Kosten und Ablauf, denn Theme und Hosting legen das Tempo-Fundament von Anfang an fest.
- Gut sind laut Google ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1.
- Bei langsamen Seiten dominieren laut web.dev Serverantwort und Wartezeit, nicht der Bild-Download.
- Eine TTFB über 0,8 Sekunden deutet auf Hosting, fehlendes Caching oder Weiterleitungen hin.
- Das Hauptbild früh laden, übrige Bilder nachladen, unnötige Plugins löschen.
- Der 5-Schritte-Tempo-Check endet mit einer erneuten Messung; Felddaten brauchen rund vier Wochen.
Häufige Fragen zu langsamen Websites
Warum ist meine Seite auf dem Smartphone langsamer als am Rechner?
Smartphones haben oft schwächere Prozessoren und schwankende Mobilfunkverbindungen. Vor allem JavaScript braucht dort länger zur Ausführung. PageSpeed Insights testet deshalb mobil und Desktop getrennt; optimiere zuerst für die mobile Ansicht, weil dort die Werte meist schlechter ausfallen.
Warum zeigt PageSpeed Insights bei jedem Test andere Werte?
Die Laborwerte schwanken mit Serverauslastung, Netzwerk und Testumgebung. Miss deshalb mehrmals und vergleiche Tendenzen statt Einzelwerte. Die Felddaten sind stabiler, weil sie echte Besuche über 28 Tage zusammenfassen.
Reicht ein Caching-Plugin, um das Problem zu lösen?
Oft verbessert es die Serverantwort deutlich, behebt aber keine zu großen Skripte, spät geladenen Hauptbilder oder springenden Layouts. Prüfe nach der Einrichtung erneut die LCP-Aufschlüsselung und arbeite den nächsten Engpass ab.
Wann solltest du über einen Hosting-Wechsel nachdenken?
Wenn die Serverantwort trotz aktueller PHP-Version, aktivem Caching und schlankem Plugin-Stack dauerhaft über 0,8 Sekunden liegt. Dann fehlen dem Tarif meist Ressourcen. Frag zuerst deinen Hoster nach einem Upgrade, bevor du umziehst; ein Umzug kostet Zeit und braucht ein frisches Backup.
Quellen
Die Angaben stammen aus der offiziellen Dokumentation von Google, WordPress und dem HTTP Archive, Stand der Recherche: November 2026.
- About PageSpeed Insights · developers.google.com · Labor- und Felddaten, 28-Tage-Zeitraum, Schwellenwerte für LCP, INP und CLS (21.10.2024).
- Time to First Byte (TTFB) · web.dev · Definition und Schwellenwerte der Serverantwortzeit (November 2025).
- Common misconceptions about how to optimize LCP · web.dev · Aufschlüsselung des LCP in vier Abschnitte auf Basis realer Chrome-Nutzerdaten (20.08.2024).
- Web Almanac 2025: Page Weight · almanac.httparchive.org · Mittleres Seitengewicht, Bild- und JavaScript-Anteil, Datenstand Juli 2025 (15.01.2026).
- Understanding page experience in Google Search results · developers.google.com · Rolle der Core Web Vitals in den Ranking-Systemen (22.09.2026).
- Requirements · wordpress.org · Empfohlene PHP- und Datenbankversionen (abgerufen November 2026).
- Optimization · developer.wordpress.org · Caching, Plugins, Bilder, CDN, Datenbank und PHP-Version (14.10.2026).