Eine langsame WordPress-Seite hat in den meisten Fällen vier Ursachen: unkomprimierte Bilder, fehlendes oder falsch konfiguriertes Caching, ein überladenes Theme mit zu vielen Plugins sowie schwaches Hosting mit veralteter PHP-Version. Die gute Nachricht: Diese Flaschenhälse lassen sich systematisch identifizieren und beheben – meist ohne Komplettrelaunch. Entscheidend ist die richtige Reihenfolge.
Meine Leit-These nach 23 Jahren Audits: Performance-Probleme scheitern fast nie an der Technik. Sie scheitern daran, dass niemand sauber misst. Zuerst messen Sie also mit Google PageSpeed Insights oder GTmetrix, wo das Problem tatsächlich sitzt. Dann setzen Sie an den Stellen an, die den größten Hebel bringen. In diesem Ratgeber zeige ich Ihnen, welche Ursachen in der Praxis am häufigsten auftreten, wie Sie sie korrekt diagnostizieren und mit welchen Maßnahmen Sie die Ladezeit Ihrer WordPress-Seite spürbar und dauerhaft senken.
Das Wichtigste in Kürze
- Messen Sie zuerst mit PageSpeed Insights und GTmetrix – ohne Cache, sonst sehen Sie nicht das echte Problem.
- Die größten Hebel sind Bildoptimierung, korrekt konfiguriertes Caching und ein aktuelles PHP (8.2 oder 8.3).
- TTFB-Werte über 800 ms sind ein klares Hosting-Signal – kein Plugin der Welt löst dieses Problem.
Warum Ladezeit kein technisches Randthema ist
Eine langsame WordPress-Seite kostet Sie zwei Dinge gleichzeitig: Sichtbarkeit in Google und Umsatz aus dem Traffic, den Sie ohnehin schon haben. Ladezeit gehört nicht in die IT-Abteilung. Sie gehört ins Controlling.
Seit 2021 sind die Core Web Vitals – Largest Contentful Paint, Cumulative Layout Shift und Interaction to Next Paint – ein bestätigter Rankingfaktor bei Google. Wer hier schlecht abschneidet, verliert Positionen an Wettbewerber mit vergleichbarem Content, aber besserer Technik. In wettbewerbsintensiven Branchen entscheidet das über Sichtbarkeit auf Seite 1 oder Versenken auf Seite 3.
Hinzu kommt das Nutzerverhalten. Jede zusätzliche Sekunde Ladezeit erhöht die Absprungrate messbar – im E-Commerce besonders deutlich. Stellen Sie sich folgendes Szenario vor: Jemand hat Ihr Produkt im Warenkorb, die Kreditkarte liegt griffbereit – und dann dreht sich drei Sekunden lang ein Ladekreis. Genau in diesem Moment entscheiden Sie über Kauf oder Abbruch, ohne es zu wissen. Conversions, die Sie über Ads-Budget eingekauft haben, verlieren Sie an einem Performance-Problem, das niemand auf dem Schirm hat.
Mobile Nutzer reagieren noch empfindlicher. Schlechtere Netzverbindungen. Kleinere CPUs. Höhere Erwartungen. Eine Seite, die am Desktop „okay“ wirkt, ist auf dem Smartphone oft eine Zumutung.
Das größte Problem an Performance-Themen: Wer seine eigene Seite täglich aufruft, bekommt sie aus dem Browser-Cache. Die wahrgenommene Geschwindigkeit hat nichts mit der Realität neuer Besucher zu tun.
Genau deshalb bleiben diese Probleme oft jahrelang unentdeckt. Geschäftsführung und Marketing-Team sehen eine schnelle Seite. Die Erstbesucher sehen eine, die drei Sekunden lädt. Erst eine saubere Messung mit geleertem Cache zeigt, was Ihre Zielgruppe tatsächlich erlebt.
Ladezeit zuerst messen – bevor Sie irgendetwas ändern
Ohne belastbare Messwerte ist jede Optimierung Blindflug. Bevor Sie ein Plugin installieren, das Theme tauschen oder den Hoster wechseln, brauchen Sie eine Baseline. Sonst wissen Sie hinterher nicht, ob die Maßnahme tatsächlich etwas gebracht hat.
Drei Tools haben sich in der Praxis bewährt und ergänzen sich sinnvoll:
| Tool | Hauptnutzen | Besonderheit |
|---|---|---|
| Google PageSpeed Insights | Scores für Mobile und Desktop, konkrete Optimierungshinweise | Bewertet anhand der Core Web Vitals – also nach Googles eigenen Kriterien |
| Pingdom Website Speed Test | Ladezeit in Sekunden, einzelne Ressourcen aufgeschlüsselt | Gut für schnellen Überblick, welche Datei wie lange braucht |
| GTmetrix | Wasserfall-Diagramm, historische Vergleichswerte | Zeigt zeitliche Abhängigkeiten zwischen Ressourcen |
Als Zielwerte gelten: LCP unter 2,5 Sekunden, TTFB unter 600 Millisekunden, PageSpeed-Score über 80. Wer darunter liegt, hat handfeste Probleme. Keine Schönheitsfehler.
Ein Hinweis aus der Praxis, der erstaunlich oft übersehen wird:
Messen Sie immer im Inkognito-Modus und ohne aktives Caching-Plugin auf der Testseite. Sonst sehen Sie nur, wie schnell Ihr Browser den lokalen Cache lädt – nicht, was Ihre Besucher tatsächlich erleben.
Was TTFB, LCP und CLS bedeuten
Die drei wichtigsten Kennzahlen sollten Sie einordnen können, sonst sind die Tool-Reports nur Zahlenfriedhöfe:
- TTFB (Time to First Byte): Zeit, bis der Server das erste Byte ausliefert. Ein hoher Wert ist fast immer ein Hosting- oder Backend-Problem.
- LCP (Largest Contentful Paint): Zeitpunkt, an dem der größte sichtbare Inhalt geladen ist – meist ein Hero-Bild oder die Headline.
- CLS (Cumulative Layout Shift): Maß für die visuelle Stabilität. Springen Elemente während des Ladens, ist der Wert hoch und die User Experience schlecht.
Die häufigsten Ursachen für eine langsame WordPress-Seite
In über 80 % der Fälle, die ich analysiere, lassen sich die Ladezeitprobleme einer WordPress-Seite auf fünf wiederkehrende Ursachen reduzieren: zu viele oder schlecht programmierte Plugins, unkomprimierte Bilder, überladene Themes, fehlendes oder fehlkonfiguriertes Caching und unzureichendes Hosting. Wer diese fünf Bereiche systematisch prüft, hat den Großteil der Optimierungsarbeit bereits abgedeckt.
Im Detail sehe ich folgende Muster:
| Ursache | Typische Auswirkung |
|---|---|
| Plugin-Wildwuchs | Zusätzliche Datenbankabfragen, doppelte Skripte, Konflikte |
| Unoptimierte Bilder | Megabyte-schwere Uploads, fehlendes WebP, kein Lazy Loading |
| Überladene Themes | Dutzende CSS- und JS-Dateien, die auf keiner Seite genutzt werden |
| Kein oder falsches Caching | Server berechnet jede Anfrage neu, TTFB steigt |
| Billiges Shared Hosting | CPU- und RAM-Limits werden bei Traffic-Spitzen sofort erreicht |
Bilder sind der häufigste Einzelfaktor. Ein einziges 4-MB-Foto im Header reicht, um den Largest Contentful Paint über 4 Sekunden zu treiben. Page-Builder-Themes verstärken den Effekt, weil sie Code laden, den Sie nie aktivieren.
Eine provokante These dazu, die ich aus über zwei Jahrzehnten Audits ableite: Caching-Plugins sind in rund 30 % der Fälle das eigentliche Problem. Sie kaschieren schlechten Theme-Code, statt ihn zu beheben. Sobald der Cache invalidiert wird – nach einem Update, einem Post oder einer Preisänderung im Shop – fällt die Seite auf ihre wahre, miserable Rohgeschwindigkeit zurück. Genau dann verlieren Sie Besucher.
Ein Beispiel aus einem Audit der letzten Monate: Ein WooCommerce-Shop mit rund 3.000 Produkten kam auf einen TTFB von 2,1 Sekunden. Der Geschäftsführer hatte die Plugins im Verdacht. Tatsächlich lag es an Dutzenden verwaister Transients, die sich seit dem letzten Relaunch in der wp_options angesammelt hatten. Nach einer Bereinigung lag der Wert bei 480 Millisekunden – ohne einen einzigen neuen Plugin-Klick.
Veraltete PHP-Version als unterschätzter Faktor
PHP 8.2 und 8.3 verarbeiten WordPress-Anfragen deutlich schneller als PHP 7.4 – je nach Setup um Faktor 2 bis 3. Viele Hosting-Pakete laufen jedoch noch auf älteren Versionen, weil ein Upgrade aktiv im Hosting-Panel gewählt werden muss. Prüfen Sie das umgehend. Der Wechsel kostet nichts, ist in wenigen Klicks erledigt und bringt sofort messbare Wirkung. Ich finde in jedem zweiten Audit noch PHP 7.4 oder älter – und das bei Firmen, die monatlich vierstellig in Ads investieren.
Datenbankprobleme und ungenutzter Code
Jahrelang gewachsene Installationen schleppen tausende verwaiste Einträge mit sich: Revisionen, Transients, alte Optionen. Deinstallierte Plugins hinterlassen häufig komplette Tabellen in der Datenbank. Eine regelmäßige Bereinigung mit Werkzeugen wie WP-Optimize reduziert Abfragezeiten spürbar und verkleinert das Backup-Volumen.
Die wirkungsvollsten Maßnahmen zur WordPress-Beschleunigung
Die größten Performance-Gewinne erzielen Sie mit fünf Maßnahmen in dieser Reihenfolge: Caching einrichten, Bilder optimieren, Lazy Loading aktivieren, Plugin-Bestand bereinigen und ein schlankes Theme einsetzen. Diese Priorisierung ist nicht willkürlich – sie folgt dem Aufwand-Nutzen-Verhältnis aus der Praxis.
| Priorität | Maßnahme | Typischer Effekt |
|---|---|---|
| 1 | Caching-Plugin korrekt konfigurieren | LCP −1 bis −3 Sekunden |
| 2 | Bilder komprimieren, WebP nutzen | Seitengewicht −30 bis −60 % |
| 3 | Lazy Loading für Bilder/Videos | LCP und initiale Last sinken |
| 4 | Ungenutzte Plugins entfernen | Weniger DB-Abfragen, weniger Assets |
| 5 | Schlankes Theme statt Page-Builder-Theme | Score +20 bis +30 Punkte |
Für das Caching nutzen Sie WP Rocket (kommerziell) oder LiteSpeed Cache (kostenlos, wenn der Hoster LiteSpeed einsetzt). Bilder konvertieren Sie in WebP – das Format ermöglicht deutlich kleinere Dateigrößen bei vergleichbarer Qualität gegenüber PNG/JPEG. Lazy Loading lädt Bilder erst, wenn sie in den Sichtbereich kommen. Plugins, die Sie nicht aktiv nutzen, deinstallieren und löschen Sie vollständig – reines Deaktivieren reicht nicht, weil Datenbankeinträge bestehen bleiben. Statt überladener Page-Builder-Themes wie Divi oder Avada empfehle ich GeneratePress oder Kadence.
Caching richtig konfigurieren
Page-Caching speichert die fertige HTML-Version Ihrer Seite und liefert sie ohne erneute PHP- und Datenbank-Verarbeitung aus – der größte Einzelhebel. Browser-Caching weist den Browser an, statische Dateien wie Logos, CSS und Schriften lokal vorzuhalten. Object-Caching mit Redis lohnt sich ab mittlerer Seitengröße oder bei WooCommerce, weil dynamische Abfragen zwischengespeichert werden.
In einem Audit für einen B2B-Dienstleister fand ich kürzlich ein WP Rocket vor, das seit zwei Jahren installiert war. Page-Caching: deaktiviert. Niemand hatte je den Haken gesetzt. Eine Minute Arbeit. LCP von 4,1 auf 1,8 Sekunden. Solche Fälle sind keine Ausnahme.
CSS und JavaScript reduzieren
Minifizierung entfernt Leerzeichen und Kommentare aus Code-Dateien. Über Asset-Management deaktivieren Sie Scripts, die auf bestimmten Seiten nicht gebraucht werden – etwa Kontaktformular-Code auf der Startseite. Render-blocking JavaScript verzögert den sichtbaren Seitenaufbau; mit den Attributen defer oder async lösen Sie das. Die häufigste Stelle, an der ich solche Blockaden finde: nachgeladene Chat-Widgets und Tracking-Pixel, die der Marketingleiter „nur mal kurz“ testen wollte und vor 18 Monaten vergessen hat.
Hosting und CDN: Die Infrastruktur als Fundament
Das richtige Hosting ist eine der grundlegendsten Voraussetzungen für gute WordPress-Performance. Jede Optimierung auf Plugin- oder Theme-Ebene hat eine harte Obergrenze: Wenn der Server zu langsam antwortet, hilft Ihnen weder Caching noch Bildkomprimierung über eine schlechte Time to First Byte hinweg.
Liegt Ihr TTFB konstant über 800 Millisekunden, ist das in nahezu allen Fällen ein Infrastrukturproblem. Kein Plugin der Welt löst das. Der Grund liegt meist in der Hosting-Klasse: Günstiges Shared Hosting verteilt CPU, RAM und I/O auf hunderte andere Websites auf demselben Server. Hat einer dieser Nachbarn einen Traffic-Peak oder läuft ein schlecht programmiertes Skript, leidet Ihre Seite mit – ohne dass Sie etwas dagegen tun können.
Ich nenne die Hoster, die mir in deutschen Mittelstandsprojekten am häufigsten begegnen, ungern öffentlich beim Namen. Aber ein Muster sehe ich klar: Die großen Massen-Anbieter aus dem 4,99-Euro-Segment tauchen in meinen Audits regelmäßig dort auf, wo der TTFB zwischen 900 und 1.500 ms pendelt – unabhängig davon, wie sauber das WordPress aufgesetzt ist. Sobald wir auf Managed-Anbieter wie Raidboxes, Kinsta oder Cloudways umziehen, fällt der Wert in fast jedem Projekt auf unter 400 ms. Ohne dass eine einzige Zeile Code geändert wurde.
Ein konkreter Fall, der mir nicht aus dem Kopf geht: Ein Geschäftsführer aus dem B2B-Maschinenbau hatte sieben Monate an Plugins, Bildgrößen und CSS-Minifizierung gebastelt. Sein Wettbewerber stand auf Platz 1 für das Hauptkeyword, er auf Platz 3. Thematisch fast identischer Content, spürbar schnellere Auslieferung beim Konkurrenten. Als wir uns das erste Mal sprachen, war seine erste Frage: „Was haben wir übersehen?“ Ich sah mir den TTFB an: 1.300 ms. Konstant. Auf jeder Seite. Sein Hoster war einer der bekannten Massen-Anbieter aus dem Niedrigpreis-Segment. Der Moment, in dem ihm klar wurde, dass sieben Monate Plugin-Schrauben am eigentlichen Problem vorbeigegangen waren, war hörbar – am Telefon. Drei Tage später war die Seite bei einem Managed-Hoster. Innerhalb von neun Wochen überholte er den Wettbewerber. Sieben Monate technische Detailarbeit hatten ihm null Plätze gebracht. Drei Stunden Hosting-Migration den entscheidenden Sprung.
Managed WordPress Hosting setzt genau hier an. Sie bekommen serverseitiges Caching auf NGINX- oder LiteSpeed-Basis, eine auf WordPress abgestimmte PHP-Konfiguration, Object-Caching über Redis und in der Regel deutlich strengere Ressourcen-Garantien. Das wirkt sofort und ist bei chronisch schlechten Werten oft die einzige Maßnahme, die tatsächlich greift.
Wer monatelang an Plugins schraubt, ohne den Hoster zu prüfen, optimiert am falschen Ende. Ich sehe das in meinen Audits regelmäßig.
Ein Content Delivery Network ergänzt das Hosting. Es ersetzt es nicht. Ein CDN wie Cloudflare liefert statische Inhalte – Bilder, CSS, JavaScript, Schriften – aus dem geografisch nächstgelegenen Rechenzentrum aus. Für rein deutsche Zielgruppen ist der Effekt begrenzt. Sobald Sie international ausliefern oder viele statische Assets haben, wird ein CDN zum spürbaren Performance-Hebel. Die richtige Reihenfolge bleibt: erst Hosting prüfen, dann CDN aufsetzen.
Typische Fehler, die WordPress-Seiten dauerhaft langsam halten
Die meisten WordPress-Seiten bleiben langsam, weil Optimierungsmaßnahmen halbherzig umgesetzt werden – und niemand kontrolliert, ob sie überhaupt wirken. Aus meiner Praxis sehe ich immer wieder dieselben fünf Muster, die selbst nach mehreren Optimierungsrunden bestehen bleiben:
- Caching-Plugin installiert, aber nie konfiguriert. Ein aktiviertes Plugin reicht nicht. Ohne korrekt eingestelltes Page-Caching, Browser-Caching und Cache-Lebensdauer arbeitet das Plugin im Leerlauf. Ich sehe regelmäßig Installationen, in denen das Caching technisch „an“ ist, aber kein einziger HTML-Snapshot ausgeliefert wird.
- Page-Builder erzeugen aufgeblähten Quellcode. Visuelle Builder wie Elementor oder vergleichbare Lösungen verschachteln Divs, laden eigene CSS- und JS-Bundles und produzieren HTML, das ein Vielfaches eines sauber programmierten Themes wiegt. Auf Content-lastigen Seiten ist das einer der größten unsichtbaren Bremsklötze.
- Externe Schriftarten ohne Self-Hosting. Werden Google Fonts direkt von Google geladen, kommen zusätzliche DNS-Lookups, Verbindungsaufbau und Render-Blocking hinzu. Self-Hosting der Fonts über das eigene Hosting eliminiert diesen Umweg – und ist nebenbei DSGVO-konform.
- Redirect-Chains aus mehreren Relaunches. Jede Weiterleitung kostet Zeit. Bei drei, vier hintereinander geschalteten 301-Redirects summieren sich schnell mehrere hundert Millisekunden. Redirect-Chains finde ich nach Relaunches fast immer – mein persönlicher Rekord lag bei sieben hintereinandergeschalteten 301s auf einer einzigen Produkt-URL. Ein Klick, sieben Sprünge, bevor der Browser endlich die echte Seite zu sehen bekam.
- Kein Monitoring. Ohne kontinuierliche Messung fallen Performance-Probleme erst auf, wenn die Rankings einbrechen. Tools wie Uptime-Monitore mit Performance-Tracking oder regelmäßige PageSpeed-Reports sollten Standard sein.
Performance-Optimierung ist kein einmaliges Projekt. Wer einmal optimiert und dann nie wieder hinsieht, ist in zwölf Monaten wieder bei der alten Ladezeit – meist schlimmer.
Genau hier setze ich in meinen Audits als Erstes an.
Wann Sie einen Experten hinzuziehen sollten
Wenn Ihre WordPress-Seite trotz Caching, Bildoptimierung und Hosting-Wechsel keine messbaren Fortschritte zeigt, ist der Punkt erreicht, an dem DIY-Maßnahmen nicht mehr greifen. Performance-Probleme haben dann in der Regel mehrere überlagerte Ursachen, die nur eine systematische Analyse aufdeckt.
Aus meiner Praxis kenne ich vor allem fünf Signale, die klar darauf hindeuten, dass externe Expertise nötig ist:
- PageSpeed-Score bleibt unter 50, obwohl ein Caching-Plugin sauber konfiguriert ist und die Bilder komprimiert wurden. In diesem Fall liegt das Problem meist tiefer im Theme-Code, im Page-Builder oder in nicht entfernten Render-Blockern.
- TTFB liegt konstant über einer Sekunde – auch nach einem Hosting-Wechsel. Das deutet auf serverseitige Konfigurationsfehler, Datenbankprobleme oder schlecht programmierte Plugins hin, die Abfragen verzögern.
- Die Seite ist über Jahre gewachsen, mehrere Dienstleister haben daran gearbeitet, niemand hat den vollständigen Überblick. Solche Installationen enthalten fast immer Altlasten: verwaiste Datenbankeinträge, doppelte Skripte, widersprüchliche Caching-Regeln.
- Technische SEO- und Performance-Probleme überlagern sich. Crawling-Fehler, fehlerhafte Weiterleitungsketten und langsame Ladezeiten verstärken sich gegenseitig. Wer nur an einer Stelle ansetzt, verschiebt das Problem.
- Im Team fehlen Zeit und Fachwissen für eine saubere Analyse. Marketing-Verantwortliche sollen keine Wasserfall-Diagramme entschlüsseln – das ist nicht ihre Aufgabe.
Wenn Sie zwei oder mehr dieser Signale bei Ihrer Seite wiederfinden, ist eine externe Analyse meist günstiger als weitere Versuche im Blindflug.
In einem kostenlosen Erstgespräch prüfe ich, wo Ihr konkreter Flaschenhals liegt – und ob er sich mit überschaubarem Aufwand beheben lässt oder eine grundlegendere Sanierung nötig ist.
Häufige Fragen
- Wie messe ich, ob meine WordPress-Seite wirklich zu langsam ist?
- Starten Sie mit Google PageSpeed Insights und ergänzend GTmetrix oder dem Pingdom Website Speed Test. Wichtig: Messen Sie immer im Inkognito-Modus und ohne aktives Caching im Browser, sonst sehen Sie nicht das, was Ihre Besucher wirklich erleben. Als Orientierungswerte gelten ein PageSpeed-Score über 80, ein Largest Contentful Paint (LCP) unter 2,5 Sekunden und ein Time to First Byte (TTFB) unter 600 Millisekunden. Prüfen Sie sowohl Mobile als auch Desktop separat – die mobilen Werte sind in der Regel deutlich schlechter und für das Ranking entscheidender.
- Welches Caching-Plugin ist für WordPress am besten?
- Pauschal lässt sich das nicht beantworten, weil die Wahl auch vom Hosting abhängt. Eine bekannte Premium-Lösung bietet sehr gute Resultate bei minimalem Konfigurationsaufwand und ist für die meisten Projekte eine sinnvolle Investition. Setzt Ihr Hoster auf LiteSpeed-Server, fahren Sie mit dem zugehörigen kostenlosen Caching-Plugin häufig genauso gut oder sogar besser, weil es serverseitig tief integriert ist. Entscheidend ist nicht das Plugin selbst, sondern die korrekte Konfiguration: Page-Caching, Browser-Caching, Minifizierung und gegebenenfalls Object-Caching müssen aufeinander abgestimmt sein.
- Bringt ein CDN wirklich etwas für eine deutsche WordPress-Seite?
- Bei rein deutschsprachiger Zielgruppe und einem Server in Deutschland ist der reine Geschwindigkeitsgewinn durch räumliche Nähe überschaubar. Trotzdem lohnt sich ein CDN in den meisten Fällen, weil moderne Anbieter mehr leisten als nur Auslieferung aus dem nächstgelegenen Rechenzentrum: Sie übernehmen Komprimierung, optimierte Bildauslieferung, DDoS-Schutz und entlasten Ihren Origin-Server spürbar. Für internationale Zielgruppen oder Online-Shops mit Kunden im DACH-Raum und darüber hinaus ist ein CDN faktisch Pflicht. Bei lokalen Dienstleistern mit reinem Inlandsgeschäft ist es Nice-to-have, kein Muss.
- Wie viele Plugins sind zu viele für WordPress?
- Eine konkrete Zahl gibt es nicht – relevant ist die Qualität, nicht die Quantität. Zehn schlank programmierte Plugins von etablierten Entwicklern können Ihre Seite weniger ausbremsen als drei aufgeblähte Allzwecklösungen mit Dutzenden Datenbankabfragen pro Seitenaufruf. Achten Sie auf aktive Wartung, Update-Frequenz und Bewertungen im offiziellen Repository. Deaktivieren Sie regelmäßig alles, was Sie nicht aktiv nutzen, und löschen Sie es vollständig – deaktivierte Plugins bleiben in der Datenbank präsent. Im Zweifel hilft ein Plugin wie Query Monitor, um Performance-Sünder gezielt zu identifizieren.
- Kann ein Theme-Wechsel die Ladezeit wirklich deutlich verbessern?
- Ja, und zwar oft drastisch. Viele populäre Multi-Purpose-Themes und Page-Builder-Konstruktionen laden Dutzende CSS- und JavaScript-Dateien, von denen Sie auf einer konkreten Seite nur einen Bruchteil benötigen. Ein Wechsel auf ein schlankes, performance-orientiertes Theme kann den PageSpeed-Score um 20 bis 30 Punkte verbessern – und das ohne weitere Optimierung. Allerdings ist ein Theme-Wechsel kein Plug-and-Play-Projekt: Layout, Templates und Custom-Anpassungen müssen sauber migriert werden. Planen Sie ausreichend Zeit für Testing und Redirects ein, sonst verlieren Sie auf der SEO-Seite, was Sie auf der Performance-Seite gewinnen.
- Was ist der schnellste erste Schritt, wenn WordPress zu langsam ist?
- Messen, nicht raten. Ohne saubere Diagnose optimieren Sie an Symptomen, nicht an Ursachen. Lassen Sie PageSpeed Insights und GTmetrix laufen, notieren Sie LCP, TTFB und die größten blockierenden Ressourcen. In neun von zehn Fällen liegen die größten Hebel danach bei Bildoptimierung (Komprimierung, WebP, Lazy Loading) und einem korrekt konfigurierten Caching-Plugin. Diese beiden Maßnahmen kosten zusammen wenige Stunden Arbeit und bringen meist den größten Sofort-Effekt. Erst danach lohnt sich der Blick auf Theme, Plugins, PHP-Version und Hosting – in dieser Reihenfolge.
