Wie optimieren Sie WordPress für maximale Lade-Geschwindigkeit?

· Daniel

Wie optimieren Sie WordPress für maximale Lade-Geschwindigkeit?

Das ist relativ einfach, wenn man versteht, was genau die Bremsen sind. Bei WordPress ist es natürlich die Datenbank an sich, aber viel wichtiger: Der WP-Load im Frontend.

  • Es werden meist alle Plugins und Scripte geladen, die aktiv sind. Dabei ist meist unnötiger Kram dazwischen.
  • Themes feuern für gewöhnlich all ihr CSS und Javascript ins Frontend, benutzen davon aber nur das, was Du in die Seite reingepackt hast. 90% des CSS ist meist ungenutzt und muss mit geladen werden.
  • Drittanbieter Bibliotheken
  • Die Datenbank
  • Die Initialisierung der Plugins

Simpelste Lösung: WP-Load aus dem Frontend entfernen und stattdessen das, was nötig ist, per API oder statischen Dateien holen. Letzteres behebt alle Bremsen mit einem Schlag. Klar ist es etwas mehr Arbeit, vor allem wenn man mit Baukästen arbeitet, da man die zuständigen CSS Deklarationen und das Javascript im Frontend integrieren muss, die tatsächlich verwendet werden. Ich habe dafür mein eigenes Theme entwickelt, welches komplett headless arbeitet. WordPress liefert bei jeder Inhaltsspeicherung eine statische Version, die alles beinhaltet, was WordPress sonst aus der Datenbank einzeln fischen muss. Das Frontend nutzt genau diese Datei um die Inhalte anzuzeigen mit einem Routing, welches autark zuweist.

Warum Generate Press und Speed-Plugins nichts (wenig) bringen

Sie bringen schon etwas, aber beheben kaum etwas von den Bremsen. Der Effekt ist trivial. Beispiel: GeneratePress ist cool an sich, da es eine statische HTML-Version von jeder Seite erstellt. Aber alle von den Plugins und Themes integrierten CSS und JS bleiben drin und auch Drittanbieter Bibliotheken werden weiterhin von extern geladen. Es überspringt die Datenbank nur teilweise, da WordPress dennoch das Routing übernimmt und dazu den Artikel/Seite identifizieren muss, was es mit Hilfe der Datenbank tun muss.

Caching Plugins wie WP-Rocket, Autoptimize und weitere

Fakes. Ja, es macht die Seite gefühlt schneller und Speedtests zeigen deutlich bessere Werte, ist aber in der Realität fake. Klingt hart, aber so ist es leider und jeder, der sich die CruX-Daten anschaut sieht sofort das Problem: Selbst auf bester Einstellung verschieben diese Plugins meist nur die Reihenfolge des Loads. Beispielsweise ist der übliche Trick: JS und schweres CSS im Footer positionieren und lazy. Ergebnis: Speedtest berechnen diese nicht mit, da sie zum Zeitpunkt des Speedtests nicht wirksam werden. Der Besucher der Website muss sie aber sehr wohl laden, da die Website sonst nicht funktioniert. Damit werden Speedtests ausgetrickst, doch CruX-Daten beweisen: Es bringt genau gar nichts. User haben teilweise utopische Ladezeiten, trotz perfekter Pagespeed-Ergebnisse.

Des Weiteren  bieten diese Plugins zwar einige coole Dinge, wie Komprimierung und Minimalisierung von JS und CSS, aber dies beschränkt sich auf die Schreibweise und entfernt kein überflüssiges Codegewirre. Man spart ein paar Byte und das wars. Der Rest trickst einfach nur die Speedtests aus.

Beste Lösungen zur Optimierung der Ladezeit in WordPress

Ohne den Load anzufassen oder Programmieren zu können

  • Finger weg von großen Baukästen wie Elementor oder ähnlichen Buildern. Sie machen hübsche Dinge, aber bremsen extrem und werfen unendlich viele Daten ins Frontend.
  • So wenig Plugins wie möglich. Jedes Plugin wird geladen ohne wenn und aber. Kaum ein Plugin hat in sich integriert, dass es nur dann in den Load kommen darf, wenn es aktiv etwas tun muss.
  • Optimierung im Theme erledigen, nicht mit Hilfe von Plugins.
  • Wenig Spielereien und Animationen. Die meisten Animationen werden in modernen Themes und Buildern mit Javascript statt CSS erledigt. Diese müssen im Frontend geladen werden und bremsen. Animationen per CSS, oder gar keine.
  • Caching nur mit Sinn. Ohne den Load anzufassen bietet WP-Rocket eine gute Lösung zwischen GeneratePress und Headless, indem es einen guten Cache baut, der die Datenbanklast signifikant verkleinert und dadurch den Speed beschleunigt. Dafür ist es gut. Der Rest sind wie o.g. nur Symptombekämpfende Speedtest-Tricks.

Also das ideale WordPress ohne Programmierkenntnisse hat 1 bis 2 Plugins (Ein Caching Plugin, ein Funktionsplugin wie ein Kontaktformular, o.ä.) und ein Theme, welches gut optimiert ist. Es sollte nicht mehrere Speed Plugins haben und keine übertrieben vielen Animationen.

Mit Programmierkenntnissen aber ohne WP-Load zu entfernen

Hier ist dann schon mehr möglich. Simple Steps:

  1. Website so herrichten, wie sie aussehen soll. Ganz normal ohne etwas zu ändern. Mach sie fertig.
  2. Schriftarten und Drittanbieter-Bibliotheken herunterladen.
  3. Frontend durchsehen im Quelltext und alle CSS Dateien und JS Dateien merken/speichern.
  4. Besagte CSS Dateien zusammenlegen in eine CSS-Datei. JS ebenso. Dabei auf Kollisionen achten und idealerweise durchsehen, welche Elemente tatsächlich gebraucht werden und nur die behalten, die wirklich benötigt werden. Schriftarten ebenso lokal hochladen oder idealerweise komplett ersetzen mit Standartschriftarten, um gar keine Fonts laden zu müssen.
  5. Mit wp_dequeue_style(‚ALTE-CSS-DATEI‘); und wp_dequeue_script(‚ALTE-JS-DATEI‘); die alten CSS und JS Dateien aus dem Head entfernen. Einzufügen in die functions.php des Themes. Dafür dann deine eigene, neue CSS-Datei und die JS-Datei hinzufügen mit wp_enqueue_style bzw. wp_enqueue_script. 
    add_action('wp_enqueue_scripts', function() { 
wp_dequeue_style('unwanted-plugin-style-handle'); 
wp_dequeue_script('unwanted-plugin-script-handle'); 
}, 999);
  6. Wenn die Dateien klein sind, z.B. das CSS unter 15KB, dann vergiss das einfügen im Head als Datei, sondern knall es direkt inline in den Head als <style>-Tag. Kritisches CSS, wenn schlank, ist immer besser als Dateien zu laden. Beim JS ebenso als <script>-Tag. Ist es klein genug, pack es inline in den Head.
  7. Stell die Datenbank um auf InnoDB, idealerweise alle, aber die wichtigsten reichen auch. Beispiel: 
    ALTER TABLE wp_posts ENGINE = InnoDB;
  8. Lege Indexe an, damit WordPress schneller zuordnen kann. 
    ALTER TABLE wp_postmeta 
    ADD INDEX meta_key_value (meta_key(191), meta_value(100));

ALTER TABLE wp_posts 
    ADD INDEX post_status_type_date (post_status, post_type, post_date);

ALTER TABLE wp_term_relationships 
    ADD INDEX term_taxonomy_id_object_id (term_taxonomy_id, object_id);

    Bei vielen Custom Fields:

    ALTER TABLE wp_postmeta ADD INDEX meta_value (meta_value(255));
  9. Bildoptimierung. Dafür gibt es wenig Plugins, deswegen direkt beim Upload bereits gute und kleine Bilder nutzen. WordPress legt sich seine Bildgrößen selbst zurecht. Achte darauf, dass das Theme auch die korrekten Größen verwendet und idealerweise als SCRSET integriert, statt wild die full-Version zu nehmen. Das Bildoptimierungsplugin von WordPress Performence kann sie dazu in webp oder avif umwandeln als Bonus. Das reduziert nochmal deutlich. Achtung: avif wird nicht auf allen Geräten unterstützt. Wenn du dir unsicher bist, nimm webp.
  10. Hosting: Sollte klar sein. Kein USB-Stick mit Internetanschluss, sondern ein normaler, guter Hoster. Preislich unterscheiden die sich kaum. Ich bevorzuge und empfehle all-inkl.com, da die sich auch strikt an die Limits der Kunden pro Server halten und immer die Leistung optimieren, während Ionos bis zu 30.000 Kunden pro Server reinzwängt, die sich dann die Leistung teilen müssen.

Mit Programmierkenntnissen und Entfernung von WP-Load

Hier kommen wir nun in den Profi-Bereich. Achtung: Nicht für Amateure. Verzweiflung garantiert, wenn du nicht folgende Fähigkeiten mitbringst:

  • Php-Expert
  • Schnittstellenkommunikation
  • Headless Strukturen
  • Json Formatierung
  • WordPress Core Expert

Ich fasse es in kurz zusammen, da die Profis schon wissen was ich meine und wovon ich rede und nein, eine KI kann dir dabei nicht helfen 😉 Dazu fehlt es an Trainingsdaten und Experten verraten selten ihre Tricks im Internet.

  1. Website komplett fertigmachen, wie normal.
  2. Theme auf den Müll schmeißen und eigenes Theme anlegen mit eigenen Templates oder Child-Theme des verwendeten Themes.
  3. Autoload entfernen
  4. functions.php nutzen, um entweder die Inhalte in Dateien (z.B. Json) abzulegen (schnellste Variante, benötigt aber eigenes Routing fürs Frontend) oder eine Schnittstelle zu integrieren, die exakt genau das Liefert, was man im Frontend benötigt (z.B. Titel, Inhalt, Datum, Bilder, Menüs, etc.), z.B. als eigenen API-Endpoint als REST. Der Rest ist pures, oldschool Styling per html und das Einfügen der Daten an die richtigen Stellen per Schleifen oder als Arrays.
  5. Das ermöglicht auch die Integration von SEOs, Schemas und mehr nach belieben. Die Daten sind da, dann kann man sie auch voll nutzen für alles, ohne sie zig mal laden zu müssen, wie es bei SEO-Plugins wie Yoast oder Rankmath der Fall ist, die alles in postmetas zumüllen, die ebenfalls geladen werden müssten.

Ergebnis: Ein Headless WordPress Hybrid. Wenn man es richtig anstellt, knallt das die Website auf einen Speed, den selbst ein komplett leeres WordPress nicht schaffen kann. WordPress braucht alleine, um sich selbst zu initialisieren und etwas aus der Datenbank zu holen knappe 400ms. Ein solcher Headless Hybrid, wenn datengetrieben (oben beschriebene Datei-Version) schafft es, die Website komplett zu rendern in unter 300ms. Da ist WordPress noch nicht einmal aufgewacht.

Was ich nutze

Je nach Kunde ist das unterschiedlich, aber ich stelle aktuell viele meiner Kunden auf meinen Headless-Hybriden um. Ein Theme, welches Datengetrieben das WordPress auf Maximalleistung bringt. Durchschnittlicher LCP laut GTMetrix: 260ms. Google Pagespeed Mobile: 0,9s Google Pagespeed Desktop: 0,3s. Schneller geht’s nicht. Da ist quasi nur noch die Zeit der Datenübertragung vom Gerät zum Server und wieder zurück. Effektive Ladezeit der Website passiert in unter 0,1s. Vor Allem datengetrieben, wenn die Festplatten dann noch NVMe angeschlossen sind, ist das gesamte Lesen der Inhalte in wenigen Nanosekunden abgeschlossen. Zu dem Zeitpunkt weiß WordPress noch nicht einmal, dass es irgendwas tun soll.

Mein eigenes Theme baut dabei auch vollautomatisch alle Schemas und Mikrodatas auf, erstellt und Cacht die Bilder sowohl in WebP, als auch Avif und liefert in srcsets je nach Gerät perfekt aus. Keine Fakes, die Speedtests sind echt und der Speed-Index (der wichtigste Wert des Google Pagespeed Tests, den jeder ignoriert), ist minimal.

Kommentare (0)

Kommentar schreiben