Warum ist meine Website so langsam?

Du merkst es selbst, wenn du deine eigene Seite am Handy aufrufst und wartest. Oder ein Kunde erwähnt es beiläufig im Gespräch: „Ich wollte mir eure Website ansehen, aber die hat ewig gebraucht.“ Manchmal fällt es niemandem im Haus konkret auf – nur die Anfragen werden weniger, ohne dass jemand sagen kann, woran das liegt. In allen drei Fällen steckt oft dieselbe, lösbare Ursache dahinter.

Was dabei auf dem Spiel steht, lässt sich auch ohne erfundene Prozentzahlen klar benennen: Besucher brechen ab, bevor sie überhaupt dein Angebot, deine Preise oder dein Portfolio zu Gesicht bekommen – sie sehen nur eine leere oder halb geladene Seite und wechseln zum nächsten Suchergebnis. Google selbst wertet die Ladezeit als einen von mehreren Rankingfaktoren, eine durchgängig langsame Seite hat also auch bei der Sichtbarkeit einen strukturellen Nachteil. Am teuersten wird es bei bezahltem Traffic: Jeder Klick auf eine Google-Ads-Anzeige kostet dich Geld, egal ob die Seite dahinter in einer oder in acht Sekunden lädt – eine langsame Landingpage verspielt die Chance, für die du bereits bezahlt hast.

Am unauffälligsten, aber langfristig am teuersten, ist der schleichende Effekt: Eine Seite, die über Monate hinweg langsamer wird, verliert Sichtbarkeit und Vertrauen, ohne dass sich ein einzelner Tag als Auslöser benennen ließe – genau deshalb lohnt sich die Prüfung, auch wenn gerade niemand sich konkret beschwert hat.

Dieser Leitfaden ist eine Selbstdiagnose für rund eine halbe Stunde, ohne dass du Entwickler-Wissen brauchst oder Code anfasst. Du lernst, wie du selbst prüfst, ob und wo genau deine Website bremst, und was du davon ohne fremde Hilfe reparierst. Was du hier bewusst nicht findest, ist eine Erklärung der einzelnen Messwerte im Detail, die Google für die Nutzererfahrung heranzieht – die behandelt der Leitfaden am Ende als eigene Vertiefung.

• Startseite lädt überall träge → wahrscheinlichste Ursache: Bilder oder Hosting, Stufe 1 + 3.
• Nur der Adminbereich ist zäh → wahrscheinlichste Ursache: Datenbank oder PHP-Speicher, Sonderfall-Kapitel.
• Seite hängt beim ersten Aufruf, danach läuft sie flüssig → wahrscheinlichste Ursache: fehlendes Caching, hohe Serverantwortzeit, Stufe 3.
• Einzelne Unterseiten sind langsamer als die Startseite → wahrscheinlichste Ursache: große Bilder oder eingebettete Videos auf genau dieser Seite, Stufe 1.
• Seite wird über Wochen spürbar langsamer, ohne erkennbaren Auslöser → wahrscheinlichste Ursache: wachsende Datenbank oder neue Tracking-Skripte aus aktuellen Kampagnen, Stufe 2.

Bevor du irgendetwas an deiner Website änderst, miss zuerst – alles andere ist Raten mit zusätzlichem Risiko. Öffne PageSpeed Insights (pagespeed.web.dev), trage die Adresse deiner Startseite ein und starte den Test. Nach rund 30 bis 60 Sekunden zeigt dir das Tool zwei Reiter: Mobil und Desktop. Lies zuerst den Mobil-Wert – aus zwei Gründen: Google bewertet beide Varianten getrennt, und die meisten Besucher deiner Seite kommen ohnehin über ein Smartphone. Der Desktop-Wert fällt fast immer deutlich besser aus und verschleiert das eigentliche Problem, wenn du ihn zuerst liest.

Der Performance-Wert reicht von 0 bis 100 und ist ampelfarben unterlegt: Rot (0–49) heißt akuter Handlungsbedarf, Orange (50–89) heißt spürbares Verbesserungspotenzial, Grün (90–100) ist der Zielbereich. Alles unterhalb von Grün auf Mobil ist ein Fall für die Diagnose-Route weiter unten.

Miss zweimal, nicht einmal

Die Startseite ist in aller Regel die am besten gepflegte Seite im ganzen Auftritt – frisches Bild, schlankes Layout, kaum Altlast. Prüfe deshalb zusätzlich deine wichtigste Unterseite, etwa die Leistungsseite, die Angebotsseite oder das Kontaktformular. Oft zeigt genau dort ein zweiter Test das eigentliche Problem, das die gute Startseiten-Zahl verschleiert – ein zu großes Team-Foto oder ein eingebettetes Video sitzt selten auf der Startseite, sondern auf der Unterseite, die extra dafür angelegt wurde.

Ein zweiter Punkt, der anfangs verwirrt: PageSpeed Insights zeigt dir mitunter zwei unterschiedliche Werte für dieselbe Seite – einen Labor-Wert aus einem einmaligen, simulierten Testlauf und, sofern genug echte Besucher vorliegen, einen Feld-Wert aus tatsächlichen Aufrufen der letzten Wochen. Für den Einstieg reicht dieses Verständnis: Der Labor-Wert ist reproduzierbar und eignet sich für den Vorher-Nachher-Vergleich nach einer Änderung, der Feld-Wert bildet ab, was echte Besucher mit ihren eigenen Geräten und Netzen tatsächlich erlebt haben. Welche einzelnen Messwerte Google dafür genau heranzieht, vertiefen wir hier bewusst nicht – das gehört in die Metrik-Vertiefung am Ende dieses Leitfadens.

Zeigt ausschließlich der Mobil-Wert Rot, während Desktop längst grün ist, ist das kein Sonderfall, sondern der Normalfall: Mobilgeräte haben weniger Rechenleistung und laufen häufiger über ein langsameres Netz, wodurch dieselbe Seite dort spürbar schwerer wirkt als am Bürorechner mit Kabel-Internet.

Liegt es an deinem eigenen Netz?

Bevor du der Website die Schuld gibst, schließe dein eigenes Umfeld aus – das kostet zwei Minuten und erspart dir, tagelang am falschen Ende zu suchen:

• Inkognito-Fenster öffnen (Strg/Cmd+Umschalt+N). Das umgeht Browser-Cache und Erweiterungen, die eine Seite künstlich schneller oder langsamer wirken lassen.
• Zweites Gerät testen – Smartphone oder Kollegen-Laptop. Lädt die Seite dort genauso zäh, liegt es nicht an deinem einzelnen überladenen Bürorechner.
• Mobilfunk statt WLAN. WLAN aus, mobile Daten an, Seite erneut laden. Bleibt sie langsam, scheidet dein Büro-Router als Ursache aus.

Bestätigen alle drei Gegenproben den schlechten Wert, ist die Website tatsächlich die Ursache – weiter geht es mit der Diagnose-Route.

Bei den allermeisten Business-Websites, die wir uns ansehen, liegt eine schlechte PageSpeed-Zahl nicht an einem einzelnen dramatischen Fehler, sondern an zwei bis drei sich stapelnden Altlasten gleichzeitig. Jede für sich betrachtet wirkt harmlos – erst die Summe macht die Seite spürbar langsam. Ein Rechenbeispiel zur Einordnung: Ein 3-MB-Bild plus sechs mitlaufende Tracking-Skripte plus ein Server, der zwei Sekunden zum Antworten braucht, summieren sich leicht zu acht bis zehn Sekunden Ladezeit – obwohl jede einzelne Komponente für sich genommen gar nicht dramatisch wirkt.

Genau deshalb ist die Reihenfolge, in der du prüfst, wichtiger als jeder einzelne Tipp. Wer ungeprüft „mal ein Plugin deinstalliert“ oder direkt zum teureren Hosting-Tarif wechselt, verbrennt Zeit – und riskiert im schlimmsten Fall, dass die Seite dabei kaputtgeht, während das eigentliche Problem, etwa ein 4-MB-Bild in der Fußzeile, unangetastet bleibt.

In unserer eigenen Praxis sehen wir dieses Muster fast wöchentlich: Eine neue Kundin bringt eine Website mit, an der niemand aus dem heutigen Team länger als zwei Jahre gearbeitet hat – jede vorherige Person hat im Lauf der Zeit etwas hinzugefügt, kaum jemand hat je etwas wieder entfernt. Das ist selten böse Absicht, sondern das ganz normale Ergebnis von Verantwortungswechseln ohne saubere Übergabe.

Drei Altlasten-Quellen, die sich unbemerkt aufbauen

Fast jede gewachsene Website trägt dieselben drei Ablagerungen mit sich herum, meist ohne dass jemand es bewusst verursacht hat:

• Kamera-Uploads: Ein Mitarbeiter macht ein Teamfoto mit dem Smartphone und lädt es direkt in die Mediathek – das Gerät liefert 4.000 Pixel Breite und mehrere Megabyte, angezeigt wird das Bild später in einer Spalte von 600 Pixel.
• Kampagnen-Pixel: Jede neue Marketing-Kampagne bekommt ihr eigenes Tracking-Snippet, eingebaut von einer Agentur, einem Praktikanten oder dir selbst nach Anleitung. Die Kampagne endet nach vier Wochen, das Skript bleibt Jahre darüber hinaus aktiv, weil niemand zuständig ist, es wieder zu entfernen.
• Gewachsenes Hosting: Der Shared-Hosting-Tarif war für die Website von vor drei Jahren mit wenigen Unterseiten und wenig Traffic passend dimensioniert. Heute hat die Seite dreimal so viele Inhalte, mehr Plugins und mehr Besucher – der Tarif ist derselbe geblieben.

Schon ein erster Blick in den Netzwerk-Tab zeigt oft, welche der drei Kategorien bei dir am schwersten wiegt, noch bevor du eine einzelne Stufe im Detail durcharbeitest – ein guter Ausgangspunkt, um deine Zeit gezielt zu setzen.

Die Reihenfolge Bilder → Skripte → Hosting ist deshalb kein Zufall, sondern folgt dem Aufwand-Nutzen-Verhältnis: Bilder sind bei den meisten Websites der größte Einzelposten an Datenmenge und lassen sich ohne jeden Code-Eingriff per Plugin fixen. Skripte zu entfernen oder zu verzögern kostet dich nur einen Blick in den Adminbereich, keine Server-Änderung. Ein Hosting-Wechsel dagegen ist der aufwendigste und teuerste Schritt und deshalb erst dann dran, wenn die ersten beiden Stufen sauber sind und der Server trotzdem noch bremst.

Die drei Stufen dieses Leitfadens sind bewusst in einer festen Reihenfolge sortiert, und diese Reihenfolge ist keine Formsache: Sie spart dir konkret Zeit und, im Fall von Hosting, auch Geld. Sie gilt dabei unabhängig davon, ob deine Website auf WordPress, einem Baukasten wie Wix oder Squarespace oder einer individuell programmierten Lösung läuft – nur die konkreten Werkzeuge je Stufe unterscheiden sich im Detail.

Der Grund ist ein einfaches Aufwand-Nutzen-Verhältnis. Bilder prüfen und komprimieren kostet dich fünf bis zehn Minuten pro Fund und erfordert keinerlei technisches Vorwissen – ein Plugin oder ein Online-Tool erledigt die eigentliche Arbeit. Skripte und Plugins durchgehen kostet zehn bis zwanzig Minuten, weil du dich einmal durch eine Liste fremder Domains oder Tag-Manager-Einträge klicken musst, bleibt aber vollständig im Adminbereich. Ein Hosting-Wechsel dagegen bedeutet Datenübertragung, DNS-Umstellung, oft einen neuen Vertrag und im schlechtesten Fall Ausfallzeit – das ist ein Vorhaben von Stunden bis Tagen, kein Klick zwischendurch.

Ein typischer Fehlgriff, den diese Reihenfolge verhindert: Du siehst einen roten PageSpeed-Wert und installierst sofort ein weiteres Optimierungs-Plugin in der Hoffnung, es löse das Problem pauschal. Oft bringt das wenig, weil ein zusätzliches Plugin selbst wieder Ladezeit und Datenbankabfragen kostet, während die eigentliche Ursache – ein 4-MB-Bild in der Fußzeile oder ein liegen gebliebenes Tracking-Skript – vollkommen unberührt bleibt. Du hast am Ende ein Plugin mehr installiert und bist der Lösung keinen Schritt nähergekommen.

Wer die Reihenfolge umdreht und zuerst das Hosting wechselt, zahlt oft doppelt so viel im Monat für einen Server, der weiterhin dasselbe unkomprimierte Bild ausliefern muss wie der alte – nur etwas schneller. Das Grundproblem bleibt, nur die Rechnung wird höher. Miss deshalb konsequent zuerst, räume dann in der Reihenfolge unten auf, und zieh das Hosting erst dann in Betracht, wenn die ersten beiden Stufen erledigt sind und der Server trotzdem noch bremst.

Die Grafik unten fasst diese Route noch einmal zusammen – vom ersten Symptom bis zur behobenen oder gezielt übergebenen Ursache.

Wie du prüfst: Öffne die Website, drücke F12 (oder Rechtsklick → „Untersuchen“) und wechsle zum Tab „Netzwerk“ (Network). Lade die Seite neu und sortiere die Liste nach der Spalte „Größe“ (Size) – die dicksten Dateien stehen oben. Alternativ liest du im PageSpeed-Insights-Bericht unter den Verbesserungsmöglichkeiten die Hinweise „Bilder in modernen Formaten bereitstellen“ und „Bildgröße richtig dimensionieren“, die die Übeltäter direkt auflisten.

Woran du den Treffer erkennst: Ein Foto im Content über rund 200 KB ist ein Kandidat, Fotos im Megabyte-Bereich sind ein sicherer Treffer. Achte zusätzlich auf das Dateiformat in der Spalte „Typ“: JPEG und PNG sind die Formate von gestern, WebP und AVIF komprimieren dieselbe Bildqualität bei deutlich weniger Bytes.

Was du tust: Bei WordPress erledigt ein Plugin wie ShortPixel oder Imagify die Umwandlung automatisch bei jedem Upload, ohne dass du etwas manuell anfasst. Für einzelne Altlasten, die schon online sind, komprimierst du kostenlos über squoosh.app (Open-Source-Tool, läuft direkt im Browser, kein Konto nötig) und lädst die verkleinerte Version hoch.

Der zweite, oft übersehene Hebel: die Abmessungen

Eine aktuelle Kamera oder ein Smartphone liefert Fotos mit 4.000 Pixel Breite und mehr – angezeigt wird das Bild auf deiner Seite aber meist in einer Spalte von deutlich unter 1.600 Pixel Breite. Der Browser lädt trotzdem die vollen 4.000 Pixel herunter und verkleinert sie erst im Anzeigefenster – die Datenmenge dafür ist bereits verbraucht, bevor überhaupt komprimiert wird. Schneide das Bild deshalb schon vor dem Upload auf die tatsächliche Zielbreite zu, das spart am Ende mehr als jede Kompression danach. WordPress erzeugt beim Hochladen zwar automatisch mehrere kleinere Zwischengrößen, im Hero-Bereich oder im Slider auf der Startseite landet aber oft trotzdem die Originaldatei, weil das Theme dort gezielt die volle Auflösung anfordert – genau dort lohnt sich ein manueller Blick.

Lazyload: wann es hilft, wann es stört

Lazyload bedeutet, dass ein Bild erst dann nachgeladen wird, wenn ein Besucher tatsächlich dorthin scrollt, statt beim Seitenaufruf sofort alle Bilder auf einmal zu laden. WordPress aktiviert das seit Version 5.5 automatisch für die meisten Bilder im Inhalt, du musst dafür nichts einrichten. Eine Ausnahme solltest du kennen: Das Bild ganz oben im sichtbaren Bereich – oft das Hero-Bild – sollte davon ausgenommen sein, weil der Browser sonst erst mit dem Scrollen beginnt zu laden, was genau das Bild verzögert, das als Erstes sichtbar sein soll. Moderne WordPress-Versionen erkennen dieses Bild meist selbst und laden es sofort; findest du im Quelltext ausgerechnet beim obersten Bild ein Lazyload-Attribut, ist das ein Kandidat zum manuellen Ausnehmen.

Typische Sammelstellen

Team- und Über-uns-Seiten sowie Projekt- oder Referenz-Galerien sind die klassischen Sammelstellen für unkomprimierte Bilder: Hier werden oft mehrere hochauflösende Fotos auf einmal hochgeladen, meist unter Zeitdruck kurz vor einem Launch, und die Kompression bleibt auf der Strecke. Prüfe diese Seiten gezielt, auch wenn deine Startseite bereits sauber ist.

Wie du prüfst: Bleib im Netzwerk-Tab. Unten in der Statusleiste steht die Gesamtzahl der Requests. Klickst du mit rechts auf die Kopfzeile der Tabelle, kannst du die Spalte „Domain“ einblenden und die Liste danach sortieren – dann siehst du auf einen Blick, wie viele fremde Domains überhaupt mitladen.

Woran du den Treffer erkennst: Eine schlanke Business-Seite kommt mit unter 15 externen Domains aus. Tauchen 20 oder mehr fremde Domains auf, ist das ein klarer Treffer – typische Kandidaten sind mehrere parallel geladene Tracking-Pixel, Chat-Widgets, eingebettete Videos und extern eingebundene Schriftarten, die jeweils eigenen Code nachladen, bevor die Seite fertig ist.

So identifizierst du ein fremdes Skript

Die Spalte „Domain“ verrät fast immer, wer da mitlädt. connect.facebook.net ist der Meta-Pixel, googletagmanager.com ist der Google Tag Manager, static.hotjar.com steht für ein Verhaltens-Tracking-Tool, widget.intercom.io oder embed.tawk.to sind Chat-Widgets. Ein Tag-Manager-Container selbst ist dabei meist schlank – er wird aber über Jahre zum Sammelbecken, in das jede Kampagne, jede Agentur und jeder Praktikant ein weiteres Tag hineinlegt, das später niemand mehr entfernt. Aufräumen heißt hier: im Tag-Manager-Konto jedes Tag einzeln durchgehen und alles pausieren, dessen zugehörige Kampagne längst beendet ist. Der eingebaute Vorschau-Modus im Tag-Manager-Konto selbst zeigt dir zusätzlich, welche Tags auf einer bestimmten Seite tatsächlich feuern – praktisch, wenn du unsicher bist, ob ein vermeintlich pausiertes Tag doch noch aktiv ist.

Was du tust (WordPress-spezifisch)

Die Anzahl der installierten Plugins ist nicht das Problem – zehn schlanke Plugins sind unauffällig, ein einziges schlecht programmiertes bremst die ganze Seite. Installiere das kostenlose Plugin Query Monitor: Es blendet eine Leiste unten im Adminbereich ein, die Ladezeit, Speicherverbrauch und Anzahl der Datenbankabfragen live anzeigt. Ein Klick auf „Queries by Component“ zeigt dir, welches Plugin wie viele Abfragen verursacht – ein Ausreißer mit hunderten Abfragen bei einem einzelnen Plugin ist dein Kandidat zum Deaktivieren oder Ersetzen.

Schriften: lokal oder extern

Bindest du Google Fonts über den externen Link von Google ein, öffnet der Browser dafür eine zusätzliche Verbindung zu fonts.googleapis.com und fonts.gstatic.com, bevor der Text überhaupt in der richtigen Schrift erscheint. Lädst du dieselben Schriftdateien stattdessen von deinem eigenen Server – bei WordPress übernimmt das ein Plugin wie OMGF automatisch –, entfällt dieser zusätzliche Domain-Sprung, und die Schrift steht meist etwas früher.

Eingebettete Videos und Karten: der Fassaden-Trick

Ein eingebettetes YouTube-Video oder eine eingebettete Google-Maps-Karte lädt beim Seitenaufruf sofort das komplette Player- oder Karten-Skript mit, auch wenn niemand darauf klickt. Der bessere Weg ist eine Fassade (Facade): Statt des Live-Embeds zeigst du zunächst nur ein Vorschaubild mit einem Abspiel-Symbol; erst ein Klick lädt das eigentliche Skript nach. Für WordPress gibt es dafür fertige, schlanke Plugins – der Effekt für den Besucher bleibt optisch gleich, nur das schwere Fremd-Skript fehlt beim ersten Seitenaufruf.

Wie du prüfst: Der relevante Wert heißt TTFB (Time to First Byte) – auf Deutsch: wie lange der Server nachdenkt, bevor überhaupt die erste Antwort ankommt, noch bevor ein einziges Bild oder Skript geladen wird. PageSpeed Insights weist die gemessene Server-Antwortzeit unter den Diagnose-Hinweisen zur Serverleistung direkt aus. Willst du den Wert selbst und für jede Unterseite einzeln nachmessen: Klicke im Netzwerk-Tab ganz oben in der Liste auf die erste Zeile – das HTML-Dokument der Seite selbst – und öffne rechts den Reiter „Timing“ (Chrome) beziehungsweise „Zeit“ (Firefox). Der Wert bei „Warten auf Serverantwort“ ist dein TTFB.

Woran du den Treffer erkennst: Unter etwa 0,8 Sekunden gilt der Server als gut, über 1,5 Sekunden ist er ein eigenständiges Problem – unabhängig davon, wie gut Bilder und Skripte schon optimiert sind.

Shared- vs. Managed-Hosting

Bei Shared-Hosting teilst du dir einen Server mit teils hunderten fremden Websites, die alle um dieselbe begrenzte Rechenleistung konkurrieren. Managed-WordPress-Hosting ist speziell für WordPress eingerichtet, bringt meist serverseitiges Caching von Haus aus mit und reserviert dir einen festeren Anteil an Ressourcen. Als grobe Größenordnung zur Orientierung, ohne Anbieter-Empfehlung: Shared-Hosting bewegt sich meist zwischen 3 und 15 Euro im Monat, Managed-WordPress-Hosting eher zwischen 20 und 50 Euro im Monat, je nach Anbieter und Website-Größe.

Die PHP-Version: ein stiller Faktor

Läuft deine Website noch auf PHP 7.4 oder älter, bremst das spürbar – unabhängig vom restlichen Server. Eine aktuelle PHP-Version verarbeitet dieselbe WordPress-Installation deutlich schneller als eine veraltete. Du findest die eingestellte Version meist im Kundenmenü deines Hosters unter einem Punkt wie „PHP-Version“ oder „PHP-Einstellungen“; der Wechsel auf eine aktuelle Version ist dort in aller Regel ein einzelner Klick, kein Website-Umbau, und kostet dich nichts extra. Findest du die Einstellung nicht auf Anhieb, hilft ein kurzer Chat mit dem Support deines Hosters – bei den meisten Anbietern ist das eine Standardanfrage, die in wenigen Minuten beantwortet wird. Ein Versionssprung über mehrere Hauptversionen hinweg, etwa von PHP 7.x direkt auf eine aktuelle 8er-Version, bringt in aller Regel den größten Einzeleffekt unter den in diesem Abschnitt genannten Hebeln, weil ältere PHP-Versionen jede Codezeile spürbar langsamer verarbeiten.

Wann ein CDN hilft – und wann es nur kaschiert

Ein CDN (Content Delivery Network) verteilt statische Dateien wie Bilder, CSS und Skripte auf Server rund um die Welt, sodass ein Besucher sie von einem Standort in seiner Nähe lädt statt von deinem einen Ursprungsserver. Das hilft spürbar, wenn deine Besucher geografisch verstreut sind. Was ein CDN nicht tut: Es macht ein unkomprimiertes Bild nicht kleiner und einen langsamen Server nicht grundsätzlich schneller – es liefert nur dieselbe Datei etwas näher am Besucher aus. Ein CDN vor einem ungelösten Bild- oder Hosting-Problem kaschiert die Symptome, statt die Ursache zu beheben.

Lädt deine eigentliche Website flott, aber der WordPress-Adminbereich (wp-admin) fühlt sich an wie Kaugummi – jeder Klick auf „Beiträge“ oder „Speichern“ dauert mehrere Sekunden –, hast du eine andere Ursachenklasse vor dir. Die Werkzeuge und Lösungen unterscheiden sich vom Frontend-Problem oben. PageSpeed Insights hilft dir hier nicht weiter: Das Tool misst ausschließlich öffentlich sichtbare Seiten, nicht den passwortgeschützten Adminbereich. Bei diesem Symptom bist du also von Anfang an auf andere Werkzeuge angewiesen.

Die typischen Ursachen

• Aufgeblähte Datenbank durch Revisionen: WordPress speichert bei jedem „Speichern“ eines Beitrags eine komplette neue Revision. Nach Jahren und tausenden Speichervorgängen liegen oft zehntausende überflüssige Revisions-Zeilen in der Datenbank, durch die jede Backend-Abfrage zusätzlich durchsuchen muss.
• Transients, die nie ablaufen: Plugins legen temporäre Zwischenspeicher-Einträge (Transients) an, die sich eigentlich selbst löschen sollen. Bei fehlerhaften Plugins bleiben sie liegen und wachsen unbegrenzt weiter.
• Autoload-Optionen: Einträge in der Tabelle wp_options mit dem Flag autoload = yes werden bei jedem Seitenaufruf komplett in den Arbeitsspeicher geladen – auch im Backend. Wächst diese Tabelle durch ein schlecht programmiertes Plugin auf mehr als 1 MB, bremst das spürbar jeden einzelnen Klick im Adminbereich; Query Monitor zeigt dir die aktuelle Autoload-Größe direkt an.
• Zu kleines PHP-Memory-Limit: Billig-Hosting stellt oft nur 64 bis 128 MB PHP-Arbeitsspeicher bereit. Reicht das für die Summe aller aktiven Plugins im Backend nicht aus, wird jede Aktion spürbar zäh; als Richtwert gelten 256 MB für eine normal bestückte WordPress-Installation als komfortabel.

Was du selbst prüfen kannst

Ein Aufräum-Plugin wie WP-Optimize zeigt dir auf einen Blick, wie viele Revisionen, abgelaufene Transients und Datenbank-Overhead sich angesammelt haben, und räumt sie per Klick auf. Query Monitor funktioniert auch im Backend und zeigt dir, ob eine einzelne Abfrage besonders lange braucht.

Wo das Entwickler-Terrain beginnt

Bleibt die Autoload-Größe nach dem Aufräumen weiterhin hoch, weil ein Plugin ständig neue Optionen nachschreibt, oder reicht das Anheben des PHP-Memory-Limits nicht aus – dafür brauchst du Zugriff auf php.ini oder wp-config.php –, brauchst du jemanden mit Server- und Datenbank-Zugriff. Dasselbe gilt, wenn WP-Cron selbst der Bremsklotz ist: WordPress hat standardmäßig keinen echten Cron-Daemon, sondern prüft bei jedem Seitenaufruf, ob geplante Aufgaben fällig sind. Das lässt sich in der wp-config.php deaktivieren und durch einen echten Server-Cron-Job ersetzen – ein Eingriff in eine Systemdatei, den du einem Entwickler überlassen solltest. Meldet sich außerdem ständig ein neues Plugin-Update mit spürbar mehr Datenbanklast als die Vorversion, lohnt sich vor dem Update ein kurzer Blick in die Änderungshinweise des Herstellers – manche Plugins bauen ihre Datenstruktur grundlegend um, und genau das schlägt sich im Backend zuerst nieder.

In der Praxis genügt bei den meisten kleineren Websites bereits das konsequente Aufräumen von Revisionen und Transients, um den Adminbereich wieder auf ein erträgliches Tempo zu bringen – die tiefere Systemarbeit an Indizes oder WP-Cron bleibt die Ausnahme, nicht die Regel.

Ein Seiten-Cache speichert die fertig berechnete HTML-Seite einmal ab und liefert sie bei jedem weiteren Aufruf direkt aus, statt sie bei jedem Besuch neu aus WordPress, PHP und der Datenbank zusammenzubauen. Das spart vor allem Serverzeit und wirkt sich unmittelbar auf die Serverantwortzeit aus, die du in der Hosting-Stufe gemessen hast.

Was Caching nicht löst: Ein zu großes Bild bleibt genauso groß, ein fremdes Tracking-Skript lädt weiterhin von seiner eigenen Domain, und der Adminbereich profitiert – wie oben beschrieben – überhaupt nicht davon. Ein Caching-Plugin ist ein Verstärker für das, was bereits gut aufgeräumt ist, kein Ersatz für die ersten beiden Stufen.

Woran du erkennst, ob schon ein Cache aktiv ist

Bevor du ein neues Plugin installierst, prüfe, ob nicht bereits eines läuft – das übersieht man auf gewachsenen Websites überraschend oft. Zeig dir im Browser den Seitenquelltext an (Rechtsklick → „Seitenquelltext anzeigen“) und suche nach einem HTML-Kommentar am Seitenende; viele Caching-Plugins hinterlassen dort eine Zeile wie „Cached by …" samt Zeitstempel. Alternativ zeigt dir im Netzwerk-Tab ein Blick auf die Antwort-Header der ersten Zeile oft einen Eintrag wie X-Cache oder X-LiteSpeed-Cache – taucht er auf, arbeitet bereits ein Cache im Hintergrund.

Drei Plugins, drei Einordnungen

• LiteSpeed Cache: kostenlos, entfaltet seine volle Wirkung aber nur auf einem LiteSpeed-Server. Läuft deine Seite dort, ist es die erste Wahl.
• WP Super Cache: kostenlos, funktioniert auf praktisch jedem Hosting und deckt die Grundeinstellungen zuverlässig ab. Für alles darüber hinaus brauchst du etwas manuelle Konfiguration.
• WP Rocket: kostenpflichtig, nimmt dir dafür die meiste Arbeit ab – sinnvolle Voreinstellungen direkt nach der Aktivierung, ohne dass du dich in Cache-Header und Ausschlusslisten einarbeiten musst.

Grundeinstellungen, die reichen

Für den Einstieg brauchst du keine Expertenkonfiguration: Seiten-Cache aktivieren, Browser-Cache-Header setzen (die meisten Plugins bieten das als einfachen Schalter) und, falls dein Hosting es unterstützt, GZIP- oder Brotli-Kompression einschalten. Aktiviere zusätzlich, falls dein Plugin es anbietet, das Vorladen (Preload) deiner meistbesuchten Unterseiten – das baut den Cache für sie schon auf, bevor der erste echte Besucher sie überhaupt aufruft. Aggressivere Funktionen wie das automatische Zusammenfassen und Minimieren von CSS und JavaScript können auf manchen Themes Layout-Fehler auslösen – teste nach jeder Änderung einmal die komplette Seite, bevor du zur nächsten Option gehst.

Ein häufiges Symptom eines solchen Konflikts: Nach einer Änderung an der Website – ein neues Bild, ein korrigierter Text – siehst du im Frontend weiterhin die alte Version, obwohl du den Cache eines Plugins bereits geleert hast. Meist liegt es dann am zweiten, vergessenen Plugin, das noch eine eigene, ältere Kopie der Seite ausliefert. Prüfe in diesem Fall im Adminbereich unter „Plugins“, ob wirklich nur ein einziges aktiviertes Plugin die Bezeichnung „Cache“ trägt.

Rund um Ladezeit kursieren hartnäckige Halbwahrheiten – oft, weil sie in einem Einzelfall tatsächlich zutrafen und seitdem als Faustregel weitergereicht werden. Die folgenden fünf Mythen tauchen in Gesprächen mit Website-Betreibern am häufigsten auf, mit der jeweils ehrlichen Einordnung dahinter.

Mythos 1: „Viele Plugins machen eine Website langsam“

Nicht die Anzahl ist das Problem, sondern die Qualität einzelner Plugins. Zehn schlank programmierte Plugins fallen kaum ins Gewicht, ein einziges schlecht programmiertes Plugin mit hunderten unnötigen Datenbankabfragen bremst die ganze Seite spürbar. Miss mit Query Monitor, statt Plugins pauschal zu deinstallieren – oft reicht es, das eine auffällige Plugin gegen eine schlankere Alternative mit vergleichbarer Funktion zu tauschen.

Mythos 2: „Einfach mehr Hosting-Power kaufen löst es“

Ein teurerer Server liefert weiterhin dieselben unkomprimierten Bilder und dieselben fremden Skripte aus – nur etwas schneller. Miss zuerst, wo das Gewicht wirklich liegt. Oft erübrigt sich der Hosting-Wechsel komplett, wenn Bilder und Skripte bereits aufgeräumt sind, und das gesparte monatliche Budget lässt sich sinnvoller einsetzen, etwa in eine bessere Bildpflege oder ein Caching-Plugin mit Support.

Mythos 3: „Ein Optimierungs-Plugin löst alles auf einmal“

Ein einzelnes Plugin kann Bilder komprimieren oder Seiten cachen – beides gleichzeitig und gut, ist selten. Ein Optimierungs-Plugin ersetzt nicht die Diagnose: Es hilft dir erst, wenn du vorher weißt, an welcher der drei Stufen dein Problem tatsächlich liegt. Installierst du es blind, optimierst du im Zweifel genau die Stufe, die bei dir ohnehin schon sauber war.

Mythos 4: „Am Handy ist jede Seite halt langsam“

Mobile Netze sind grundsätzlich langsamer als Kabel oder gutes WLAN, das stimmt. Das erklärt aber keinen Mobil-Score im roten Bereich – gut optimierte Websites erreichen auch mobil zuverlässig grüne Werte. Ein schlechter Mobil-Wert ist ein echtes, behebbares Problem, keine Naturgesetzlichkeit des Smartphones, und genau deshalb bewertet Google beide Varianten getrennt und misst dem Mobil-Wert das größere Gewicht bei.

Mythos 5: „Der Relaunch wird es schon richten“

Ein neues Theme oder ein neuer Baukasten bringt oft frischen Code mit, überträgt aber ebenso oft dieselben unkomprimierten Bilder und dieselben Tracking-Skripte unverändert in die neue Seite. Ohne die drei Stufen vorher oder währenddessen zu prüfen, landet die alte Last zuverlässig auch im neuen Design wieder – nur in einer frischeren Verpackung. Nutze einen Relaunch stattdessen bewusst als Gelegenheit, alle drei Stufen einmal von Grund auf durchzugehen, statt sie einfach mit umzuziehen.

Nach den Stufen oben weißt du, wo das Gewicht deiner Website wirklich liegt. Das ist bereits der größte Teil der Arbeit: Die meisten Website-Betreiber, die uns kontaktieren, wissen nur, dass „irgendetwas langsam ist“ – nicht, welche der drei Stufen wirklich betroffen ist. Eine ehrliche Trennlinie, was du selbst erledigst und wo Fachmann-Arbeit beginnt:

Das erledigst du selbst

• Große Bilder komprimieren oder per Plugin automatisch umwandeln lassen.
• Offensichtliche Skript-Leichen entfernen – das Chat-Widget, das seit der letzten Kampagne niemand mehr nutzt, das doppelt eingebundene Tracking-Pixel.
• Ein Caching-Plugin aktivieren und die Grundeinstellungen einschalten.
• Die PHP-Version im Hoster-Panel auf den aktuellen Stand bringen.

Hier beginnt Fachmann-Arbeit

• Theme-Umbau: wenn das Theme selbst unnötig viel Code lädt oder Layout-Probleme verursacht, die sich nicht per Einstellung beheben lassen – erkennbar oft daran, dass mehrere nahezu identische CSS- oder JavaScript-Dateien von verschiedenen Theme-Komponenten gleichzeitig geladen werden.
• Tiefere Datenbank-Arbeit: fehlende Indizes, strukturelle Bereinigung über das reine Löschen von Revisionen hinaus. Ein Anzeichen dafür: Query Monitor zeigt dieselbe Abfrage mit leicht unterschiedlichen Parametern zehn- oder zwanzigfach wiederholt.
• Server-Migration: Wechsel auf einen leistungsfähigeren Hosting-Typ inklusive sauberer Übertragung aller Daten, DNS und E-Mail-Konfiguration. Plane dafür ein Zeitfenster mit wenig Traffic ein und sichere vorher eine vollständige Kopie aller Daten.
• Server-seitiges Tag-Management: Tracking- und Marketing-Skripte über einen eigenen Server statt direkt im Browser laden, damit sie den Hauptthread deiner Besucher nicht mehr belasten. Für die meisten kleinen Business-Websites lohnt sich dieser Aufwand erst ab einer zweistelligen Zahl aktiver Tracking-Tools.

Der Übergang zwischen beiden Spalten ist selten scharf. Ein Beispiel: Du hast die Bilder komprimiert und die offensichtlichen Skript-Leichen entfernt, aber die Serverantwortzeit bleibt trotzdem über 1,5 Sekunden. An diesem Punkt lohnt sich ein Gespräch, bevor du in einen teureren Hosting-Tarif wechselst – manchmal steckt die eigentliche Bremse in einer einzelnen, schlecht optimierten Datenbankabfrage, die kein Tarifwechsel behebt, wohl aber eine gezielte Korrektur am Code.

Wenn du an diesem Punkt bist, übernehmen wir bei EINSHOCH genau diese Aufgaben im Rahmen unserer laufenden WordPress-Betreuung – von der Server-Wahl bis zur Datenbank-Wartung, ohne dass du dich selbst in php.ini oder Datenbank-Tabellen einarbeiten musst. Willst du danach tiefer in die Messwerte einsteigen, die Google für die Nutzererfahrung heranzieht, findest du im Leitfaden Core Web Vitals optimieren die passenden Zielwerte und Fixes.