WordPress Website schneller machen: Praktischer Leitfaden

WordPress website schneller machen: Reihenfolge statt Vermutungen

Die Anleitung um eine WordPress website schneller zu machen ist nicht kompliziert, aber sie verlangt Reihenfolge: Zunächst messen, dann in Gewinn-Reihenfolge reparieren. Server-Response und Seiten-Caching, dann das schwere Hero-Bild, dann render-blocking CSS und JavaScript, dann Datenbank und Plugin-Gewicht. Die meisten langsamen Sites bremst eines von zwei oder drei Dingen, nicht alle.

Starte ein PageSpeed Insights auf deinem langsamsten Template, merke dir das Element für Largest Contentful Paint, und arbeite diese Liste systematisch ab, bis die Grünzone erreicht ist.

Bevor du anfängst: eine Messgrunglage schaffen, sonst optimierst du die falsche Stelle

Optimierung ohne Messwert ist Aberglaube. Bevor du irgendwas anfasst, notiere dir drei Zahlen auf deinem echten Langsamsten-Template (üblicherweise ein Beitrag mit großem Hero-Bild oder eine WooCommerce-Produktseite): Largest Contentful Paint, Interaction to Next Paint und Time to First Byte. Teste im mobilen Modus – dort zeigt sich der Unterschied zwischen «schnell auf meinem Rechner» und «schnell für die Kunden deiner Kunden».

Die Zielwerte sind publiziert, nicht Folklore. Google´s Web-Dev-Leitfaden zu LCP nennt 2,5 Sekunden oder weniger als gut auf dem 75. Perzentil realer Besuche. INP sollte unter 200 Millisekunden liegen und Layout Shift unter 0,1. Schreib diese Werte auf einen Klebezettel neben deinen Monitor.

Labortools wie Lighthouse geben dir eine wiederholbare Messbasis. Felddaten aus dem Chrome User Experience Report, oben auf PageSpeed Insights angezeigt, zeigen dir, was Besucher wirklich erleben. Wenn die beiden auseinandergehen: Vertrau den Felddaten und nutze den Laborlauf, um die Ursache zu finden.

Marginalien: Dieses Vorgehen gilt für WordPress 6.5 und später. Ältere Installationen haben mehr zu reparieren, bevor irgendetwas davon zählt.

Server zuerst: Hosting, PHP und Time to First Byte

Jeder Frontend-Trick sitzt auf der ersten Response. Wenn das HTML 1,5 Sekunden braucht, retten keine Bildkomprimierungen dein LCP. Time to First Byte offenbart einen schwachen Host, einen veralteten PHP-Branch oder eine Seite, die bei jedem Request neu gebaut wird.

Überprüfe in dieser Reihenfolge drei Dinge. Lauf einen aktuell unterstützten PHP-Branch, denn jede neue Version ist messbar billiger pro Request. Bestätige, dass der Host einen persistenten Object Cache bietet (Redis oder Memcached), denn er entfernt wiederholte Datenbanklesevorgänge für Options, Menus und Queries. Und schau dir den Tarif selbst an: Ein Shared Server mit hundert Nachbarn würgt dich genau in dem Moment drosseln, in dem der Traffic spitzt.

Wenn du viele Kundenseiten verwaltest, zahlt sich verwaltetes Hosting hier aus. Eine Plattform, die Hosting, Caching und ein Performance-Ziel bündelt, nimmt dir eine ganze Kategorie von Raterei ab. 10Web ist ein Beispiel – es hostet WordPress auf Google Cloud und strebt quitt ab Werk einen PageSpeed-Score von 90+ an, eine sinnvolle Grundlage für eine kleine Agentur ohne eigene Ops-Person.

Vermeid die Versuchung, einen größeren Tarif zu buchen, bevor du Caching aktiviert hast. Hardware zu upgradeln, um ungepufferte Seiten schneller zu servieren, ist mehr zahlen, um die gleiche Verschwendung schneller zu tun.

Caching: Volle Seiten speichern, und dann prüfen, dass es wirklich trifft

WordPress baut jede Seite mit PHP und MySQL jedes Mal neu, wenn sie angefordert wird. Ein Page Cache speichert das fertige HTML und serviert diese Datei statt neu zu bauen. Für eine vorwiegend lesende Site – Blog, Brochure-Site, Portfolio – wechselt dieser eine Schritt oft TTFB von Sekunden zu Zehner-Millisekunden.

Wähle eine Page-Caching-Ebene und nur eine. Mehrschichtig – Host-Level-Cache, Caching-Plugin und CDN-Cache ohne zu wissen, welcher antwortet – führt zu einem vollen Nachmittag Fehlersuche bei veralteten Inhalten. Frag deinen Host vorher, was er bereits bietet.

Und dann prüf, dass der Cache tatsächlich trifft. Öffne das Netzwerk-Panel des Browsers, laden eine öffentliche Seite zweimal, und lies die Response-Header. Die meisten Caches kündigen Hit oder Miss an, viele auch Age. Wenn du immer nur Misses siehst, umgeht etwas – ein Cookie, ein Query String, ein Logged-In-Status – deinen Cache, und die «Optimierung» ist Dekoration.

Shops brauchen Extra-Sorgfalt. Cart, Checkout und Account dürfen nie gepuffert sein. WooCommerce-Seiten verlassen sich üblicherweise auf ein Caching-Plugin, das diese Ausnahmen kennt. Falsche Ausnahmen sind schlimmer als langsame Seiten – Kunden sehen dann gegenseitig ihre Warenkörbe.

Das Hero-Bild: Die übliche LCP-Bremse, ein paar Kilo abnehmen

Bei den meisten langsamen WordPress-Seiten ist das LCP-Element ein Bild: Hero, Featured Image oder Full-Width-Banner. Das macht Bildgewicht zur häufigsten einzelnen Ursache für einen fehlgeschlagenen Score. Eine 4000-Pixel-breite JPEG gerade aus der Kamera, dargestellt in einer 1200-Pixel-Spalte, verschickt mehrfaches Gewicht von dem, was die Seite nutzt.

Arbeite die Bild-Pipeline in dieser Reihenfolge ab:

• Größe auf das Maximum setzen, das die Seite wirklich zeigt, nicht die Größe, in der der Designer exportiert.

• WebP oder AVIF liefern, beides bearbeitet WordPress Core seit mehreren Releases.

• Lass Core die responsiven srcset-Varianten erzeugen, statt eine große Datei hart zu codieren.

• Das Hero-Bild nicht lazy-loaden. Core überspringt Lazy Loading auf dem ersten Content-Bild und setzt fetchpriority="high" seit WordPress 6.3, also prüf, dass dein Theme oder Plugin das nicht rückgängig gemacht hat.

• Jedes Bild mit explizitem width und height ausstatten, damit der Browser Platz reserviert und Layout Shift nahe Null bleibt.

Unter der Falte ist Lazy Loading korrekt und kostenlos. Über der Falte ist es selbst verursachte Verzögerung – der Fehler, der nach der Installation eines «alles lazy-loaden»-Plugins am häufigsten auftaucht.

Für E-Commerce kommt das Gewicht oft von Produktfotos. Gleichbleibende, richtig große Bilder von vornherein zu machen ist billiger, als hinterher fünfzig zu große Dateien zu komprimieren. Eine KI-Produktfotografie-Plattform wie Klayn macht aus einem Produktfoto einen Set von Szenen, damit du die Größen planen kannst, bevor es in die Medienbibliothek kommt.

Render-Blocking CSS und JavaScript an der Quelle kürzen

Sobald Server und Hero sortiert sind, kommt die nächste Verzögerung vom Browser: alles, das er herunterladen und laufen muss, bevor er paint kann. Jedes Stylesheet im head blockiert Rendering. Jedes synchrone Script blockiert Parsing. Page Builder und Multipurpose-Themes sind die üblichen Verdächtigen, denn sie versenden Stile und Scripts für jede Funktion, egal ob die Seite sie nutzt.

Block-Themes haben einen strukturellen Vorteil. Core lädt die Styles für einen Block nur dann, wenn dieser Block auf der Seite ist – eine einfache Post hat keine Kosten für Query Loop oder Gallery. Das ist ein Grund, warum ein schlankes Full Site Editing Theme mit Vorsprung startet als ein Legacy-Theme mit eingebautem Slider und eingebauter Icon-Schrift. Classic Page Builder können den Abstand verringern, aber nur wenn du Module deaktivierst, die du nicht nutzt.

Divi ist ein fairer Testfall. Divi 5 wurde auf modernere Architektur umgebaut und versenden hunderte Module – genau deshalb verdienen Performance-Einstellungen wie Dynamic CSS und Critical CSS einen sorgfältigen Blick auf jeder Site, die du lieferst.

Praktische Schritte in Risiko-Reihenfolge:

• Nicht-kritisches JavaScript aufschieben und Third-Party-Scripts (Chat-Widgets, Analytics, Tag-Manager) nach Interaktion laden, wo möglich.

• Kritisches CSS für Above-the-Fold inline und den Rest asynchron laden, wenn dein Cache-Werkzeug es unterstützt.

• Fonts selbst hosten, subsetten, und font-display: swap verwenden, damit Text sichtbar ist, während die Font lädt.

• Plugin entfernen oder ersetzen, das ein großes Script auf jeder Seite lädt für eine Funktion, die auf einer benutzt wird.

• Nach jeder Änderung testen. Aggressives JavaScript-Deferral ist die Nr. 1 Ursache für ein kaputtes Menu oder einen toten Checkout-Button.

Plugins prüfen und die Datenbank atmen lassen

Plugin-Zahl ist eine schlechte Metrik. Was zählt ist, was jedes Plugin frontend lädt und auf jedem Request tut. Ein schlecht geschriebenes Plugin mit einer teuren Query kostet mehr als dreißig gut behütete. Nutze Query Monitor auf einer Staging-Kopie, um langsame Queries zu sehen, welches Plugin sie ausgelöst hat, und welche Scripts jedes enqueut.

Dann schau die options-Tabelle an. Plugins, die vor Jahren gelöscht wurden, lassen oft Rows hinter, die als autoload markiert sind – das heißt, WordPress lädt sie auf jedem Request in den Speicher. Site Health fängt an zu warnen, wenn autoload-Optionen ungefähr 800 KB erreichen. Wenn du diese Warnung siehst: audit die größten Rows und räume Überreste von Plugins auf, die du nicht mehr laufen lässt.

Post-Revisionen, abgelaufene Transients und verwaiste Metadaten sammeln Gewicht im Lauf der Zeit, aber behandle das als Instandhaltung statt als Headline-Fix. Backup zuerst, Cleanup auf Staging, nochmal messen. Der Gewinn ist oft bescheiden auf einer kleinen Site und spürbar auf einem Store mit Jahren von Orders und Sessions.

CDN und spekulatives Laden für die letzte Strecke

Ein Content-Delivery-Network serviert statische Dateien, oft auch gepuffertes HTML, von einem Ort nah beim Besucher. Für ein Publikum über Regionen verteilt – wie eine arabischsprachige Site, gelesen aus dem Golflanden und Nordafrika, während der Origin-Server in Europa sitzt – ist die Latenz-Ersparn nicht kosmetisch. Entfernung ist Kosten, und ein CDN ist die billigste Art, sie zu verkürzen.

WordPress 6.8 hat etwas hinzugefügt, das kostenlos ist: spekulatives Laden. Es nutzt die Speculation Rules API, um eine Seite vorab zu laden, während der Besucher anzuklicken beginnt, damit die nächste Navigation fast sofort ankommt. Das Core-Team berichtet, dass Sites mit dem früheren Plugin-Version ihre LCP-Pass-Rate um ungefähr 1,9% am Median verbessert haben, wie in der WordPress 6.8 Developer Note zu spekulative Loading beschrieben. Das ist klein pro Site und kostet null Konfiguration.

Core aktiviert es für ausgeloggte Besucher auf Sites mit Pretty Permalinks. Wenn ein Plugin Action-URLs nutzt, die State auf einem einfachen GET ändern, schließ diese Pfade mit dem wp_speculation_rules_href_exclude_paths Filter aus, bevor du die Einstellung aggressiver machst. Bleib beim Standard bis du deine Warenkörbe und Analytics geprüft hast.

Wann aufhören, und welcher Fix zuerst

Es gibt einen Punkt, wo mehr WordPress-Tuning mehr kostet als es bringt. Wenn ein kleiner Shop jeden Monat gegen Cache-Ausnahmen, Plugin-Konflikte und Hosting-Upgrade kämpft, ist die ehrliche Frage, ob der Stack zum Business passt. Eine gehostete Plattform wie WiziShop tauscht etwas Flexibilität gegen einen Store ein, dessen Schnellheit jemand anderes´ Job ist – und das lohnt sich gegen die Stunden, die du für Wartung abrechnet.

Für Content-Sites, Agenturen und RTL-Projekte bleibt WordPress das richtige Werkzeug, und alles oben bleibt lohnenswert. Der Punkt ist, zu wissen, auf welche Seite dieser Linie jeder Kunde sitzt.

Mach die Messung auf deinem Langsamsten-Template heute. Wenn TTFB über 800 Millisekunden liegt: Start mit Hosting, PHP und Caching. Wenn TTFB gesund ist aber LCP fehlt: öffne den Waterfall und find das Hero-Bild. Wenn beide passen und Interaction ist langsam: schau JavaScript und die Plugin-Reihe an. Welche dieser drei versagt deine schlechteste Seite?