Eine langsame WordPress-Seite beschleunigen: Die Reihenfolge, in der ich tatsächlich arbeite

"Unsere WordPress-Seite ist extrem langsam geworden" ist mit Leichtigkeit eine der häufigsten Bitten um Hilfe, die ich erhalte. Der erste Instinkt der allermeisten Leute ist es, blind irgendein Plugin zu installieren. Meistens einen Bild-Optimierer oder ein "Speed Booster"-Plugin, das lautstark verspricht, jedes Problem mit nur einem Klick zu beheben.

Manchmal hilft das tatsächlich ein kleines bisschen. Aber die massiven, wirklich spürbaren Leistungssprünge kommen fast immer von Dingen, die absolut nichts mit dem Plugin-Ökosystem von WordPress zu tun haben. Geht man sie in der falschen Reihenfolge an, bedeutet das schlichtweg, dass man Stunden damit verschwendet, für 10 % Frontend-Verbesserung zu kämpfen, bevor man den serverseitigen Flaschenhals, der die restlichen 90 % der Verzögerung verursacht, überhaupt angerührt hat.

Als Allererstes: Ist es der Server oder ist es die Seite?

Bevor ich auch nur eine einzige Einstellung anfasse, prüfe ich strikt die Time to First Byte (TTFB). Diese misst exakt, wie lange der Server braucht, um überhaupt damit zu beginnen, eine Antwort zu senden – völlig unabhängig davon, wie lange der Browser danach noch braucht, um all die schweren Bilder und Skripte herunterzuladen und zu rendern:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com

Eine TTFB, die bei einer simplen, nicht eingeloggten (logged-out) Seite über einer halben Sekunde pendelt, bedeutet normalerweise, dass WordPress bei jedem einzelnen Request verzweifelt Schwerstarbeit leistet. Die Datenbank wird aktiv abgefragt, PHP wird aggressiv ausgeführt, und absolut nichts wird gecacht.

Eine rasend schnelle TTFB in Kombination mit einem brutal langsamen Seitenaufbau insgesamt deutet hingegen stark auf Frontend-Probleme hin: überdimensionierte Bilder, gigantische, nicht optimierte Skripte oder render-blockierende Schriftarten. Das ist ein komplett anderes (und in der Regel viel leichter zu lösendes) Problem.

Wenn es der Server ist: Caching, in strikten Schichten

Eine öffentliche WordPress-Seite, die für jeden einzelnen Besucher völlig identisch aussieht (was auf 95 % aller Seiten zutrifft), muss absolut nicht bei jedem einzelnen Aufruf PHP und MySQL neu bemühen.

Ein robuster Page-Cache – ob nun über ein solides Plugin wie WP Super Cache gelöst, oder noch viel besser, komplett auf Serverebene mit Nginx' fastcgi_cache – liefert eine statische HTML-Kopie aus und überspringt PHP damit komplett. Diese eine einzige Änderung ist extrem oft der dramatische Unterschied zwischen einer TTFB von 800ms und einer von 50ms. Es ist der buchstäbliche Unterschied, ob man den Server zwingt, "komplett WordPress hochzufahren", oder ihn einfach nur bittet, "eine simple Textdatei auszuliefern".

Für die Requests, die PHP tatsächlich zwingend benötigen – wie eingeloggte Benutzer, WooCommerce-Warenkörbe oder alles Dynamische – ist ein Object-Cache (wie Redis oder Memcached) absolute Pflicht. Er cacht die rohen Ergebnisse der WordPress-Datenbankabfragen brutal effizient. Das bedeutet, dass wiederholte Abfragen (und WordPress wiederholt beim Laden einer Seite exakt dieselbe Abfrage oft dutzendfach) sofort aus dem RAM beantwortet werden, anstatt MySQL auf die Nerven zu gehen:

// wp-config.php, nachdem ein Redis Object Cache Plugin installiert wurde
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Zu guter Letzt speichert der native OPcache von PHP den fertig kompilierten PHP-Bytecode selbst ab, damit exakt dieselben PHP-Dateien nicht bei jedem einzelnen Request schmerzhaft von Grund auf neu kompiliert werden müssen. Dies sollte einfach dauerhaft in der php.ini aktiviert sein. Es erfordert absolut null WordPress-spezifische Konfiguration und beschleunigt universell jeden einzelnen PHP-Request auf dem gesamten Server.

Die Datenbank sammelt leise massives Gewicht an

Die Datenbank von WordPress wächst langsam auf eine Art und Weise, die erst dann sichtbar wird, wenn sie die Seite bereits brutal in die Knie zwingt. Denken Sie an Post-Revisions (wo jeder einzelne Autosave still und heimlich eine neue Datenbankzeile anlegt), abgelaufene Transients (temporär gecachte Daten, die oft schlichtweg nie bereinigt werden) und massiv verwaiste Metadaten, die von längst gelöschten Plugins zurückgelassen wurden.

Nichts davon ist bei einer brandneuen, kleinen Seite dramatisch. Aber bei einer gut besuchten Seite, die seit drei Jahren läuft, ist es unglaublich häufig, eine wp_options-Tabelle vorzufinden, bei der allein die strikt "automatisch geladenen" (autoloaded) Optionen – jene also, die bei jedem einzelnen Seitenaufruf aggressiv in den Speicher geladen werden, unabhängig davon, ob sie überhaupt gebraucht werden – sich zu mehreren Megabyte an purem Müll aufsummieren:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 10;

Alles, was hier massiv ist und von einem Plugin stammt, das vor zwei Jahren gelöscht wurde, ist purer, schmerzhafter Overhead, der zu jedem einzelnen Request hinzugefügt wird. Dies aufzuräumen erfordert kein blindes Raten; diese SQL-Abfrage sagt Ihnen brutal ehrlich, wo genau sich das tote Gewicht versteckt.

Erst dann, und absolut nur dann, kommt das Frontend

Sobald der Server endlich schnell antwortet, hat die Frontend-Optimierung überhaupt erst ein solides Fundament, auf dem sie aufbauen kann. Bilder mit Lazy-Loading nachzuladen, strikt moderne Formate wie WebP auszuliefern und unkritische JavaScript-Dateien aktiv zurückzustellen, ergibt erst jetzt wirklich Sinn.

Diese Frontend-Arbeit als Allererstes auf einer Seite mit einer quälend langsamen TTFB von 800ms zu machen, ist exakt so, als würde man die sichtbaren 20 % eines Autos auf Hochglanz polieren, während die unsichtbaren 80 % (der Motor) lichterloh brennen. Die Zeit, die verschwendet wird, noch bevor der Browser überhaupt mit dem Rendern der Seite beginnen kann, bleibt dabei völlig unangetastet.

Warum die exakte Reihenfolge so wichtig ist

Jeder einzelne dieser spezifischen Schritte ist für sich genommen nützlich, aber diese strikte Reihenfolge spiegelt exakt wider, wohin die Verarbeitungszeit auf einer typischen langsamen WordPress-Seite tatsächlich fließt.

Serverseitiges Page-Caching behebt aggressiv den mit Abstand größten Teil der Verzögerung für normalen, nicht eingeloggten Traffic. Der Object-Cache und OPcache adressieren direkt die brutalen Rechenkosten von WordPress selbst für alles andere. Ein tiefgreifendes Datenbank-Cleanup entfernt dauerhaft das angesammelte tote Gewicht, das jede einzelne Seite nach unten zieht. Und zu guter Letzt poliert die Frontend-Optimierung auf, was dann noch übrig ist.

Am absoluten Ende dieser Liste anzufangen, nur weil es am sichtbarsten ist – wie etwa ein Bild zu komprimieren oder ein Skript zu minifizieren – fühlt sich zwar hochgradig produktiv an. Aber Sie optimieren damit aktiv das kleinstmögliche Stück der gesamten Ladezeit zuerst.