/// Case Study · Performance
WordPress schneller machen — mit Messung statt Bauchgefühl.
Eine RFID-Industrieseite (WordPress, Divi, WPML, WooCommerce) war spürbar zu langsam. Wir haben sie Schritt für Schritt vermessen, optimiert — und am Ende ehrlich gesagt, wo die strukturelle Grenze liegt.
· Werte: PageSpeed Insights (mobil) + HTTP-Diagnose
Spürbar zu langsam — aber warum?
Die Seite ist inhaltlich stark (zweisprachiger Produktfinder, KI-Chatbot, Downloads), aber sie lud quälend langsam. PageSpeed-Score 56, der erste Inhalt erschien erst nach rund 10 Sekunden, das größte Element der Startseite nach 21,8 Sekunden. Gleichzeitig war eines auffällig gut: Layout-Stabilität (CLS 0) und Reaktionsfähigkeit (TBT nahe 0). Das Problem war also rein die Ladezeit — und die hat selten nur eine Ursache.
Server-Generierung pro Seite
render-blockierende CSS- & JS-Dateien
einzelnes Startseiten-Bild (PNG)
Thumbnail-Größen je Bild
Messen. Diagnostizieren. Belegen.
Kein „wir installieren mal ein paar Plugins". Jeder Schritt wurde vorher und nachher gemessen — und wo eine Maßnahme nichts brachte oder schadete, haben wir sie zurückgenommen und es transparent festgehalten.
Baseline messen — automatisiert, nicht nach Gefühl
Vor der ersten Änderung: PageSpeed Insights (mobil) auf drei repräsentativen Seitentypen plus HTTP-Diagnose der echten Server-Antwortzeiten. Alles automatisiert über die PageSpeed-API, jeder Wert vor und nach jedem Schritt dokumentiert. Ohne Baseline ist „schneller" nur ein Gefühl.
Diagnose statt Bauchgefühl
Die Messung zeigte den wahren Engpass: eine bimodale Server-Antwortzeit (Cache-Treffer 0,2 s, Cache-Neuaufbau bis 8 s), 16 Stylesheets und über 40 render-blockierende Skripte pro Seite sowie ein einzelnes Startseiten-Bild mit 1,56 MB. Nicht ein Problem, sondern eine Kette.
Caching, das den Nutzer schützt
Serverseitiges Caching mit Vorab-Generierung (Preload) und „alte Datei während Neuaufbau ausliefern" — so trifft kein Besucher mehr den langsamen Neuaufbau. Ergebnis: Antwortzeit durchgängig ~0,2 s statt bis zu 8 s.
Ballast raus — gezielt, nicht pauschal
Shop-Ressourcen auf reinen Informationsseiten entladen (eigenes Mu-Plugin, shop-sicher gebaut für den späteren Ausbau), eine 78 KB schwere Animations-Bibliothek entfernt, Theme-Performance-Optionen aktiviert — jede Änderung einzeln gemessen, eine kontraproduktive (Critical CSS → Layout-Shift) sofort wieder zurückgenommen.
Bilder auf modernes Format
Komplette Mediathek auf WebP — 966 MB gespart (82 % weniger Bildgewicht), das überdimensionierte Hero-Bild von 1,56 MB auf unter 100 KB.
Die ehrliche Grenze benennen
Die Diagnose legte das strukturelle Limit offen: der schwere Stack (WordPress, Divi, WPML, WooCommerce, FacetWP) auf Shared Hosting braucht ~6 Sekunden, um eine Seite zu erzeugen. Statt endlos Plugins zu tunen, lautet die ehrliche Empfehlung: schnelleres Hosting mit Object-Cache — der einzige Hebel, der diese 6 Sekunden wirklich auflöst.
Vorher / Nachher — gemessen
Alle Werte aus PageSpeed Insights (mobil) und direkter HTTP-Messung. Keine geschätzten Zahlen.
| Kennzahl | Vorher | Nachher | Kontext |
|---|---|---|---|
| Server-Antwortzeit (TTFB) | bis 8 s | ~0,2 s | bei Cache-Treffer, ~40× schneller |
| Erste Inhaltsanzeige (FCP, Inhaltsseiten) | ~10 s | 1,7 s | Lösungsseiten, mobil |
| Largest Contentful Paint (Startseite) | 21,8 s | 12,6 s | durch Bild- + Script-Optimierung |
| Bildgewicht der Mediathek | ~1,18 GB | −82 % | 966 MB gespart, 5.505 Dateien zu WebP |
Wir verkaufen keine Wunder — wir nennen den echten Hebel.
Caching, Bilder und Skripte haben die Seite messbar schneller gemacht. Doch die Diagnose legte ein strukturelles Limit offen: Der schwere Stack braucht auf Shared Hosting rund 6 Sekunden, um eine Seite zu erzeugen. Diese Zeit lässt sich mit Plugins nicht wegzaubern — sie braucht einen schnelleren Server mit Object-Cache (Redis), der die Generierung von Sekunden auf Millisekunden bringt.
Genau das ist unser Anspruch in der Beratung: lieber die unbequeme, ehrliche Empfehlung als die teure Plugin-Lotterie. Die durchgeführten Optimierungen zahlen sich dann auf dem schnelleren Host voll aus.
Methodik & Technik
Womit wir gearbeitet haben
WordPress-Performance — kurz erklärt
Warum ist meine WordPress-Seite langsam? +
Meist eine Kette aus mehreren Ursachen: ein überladenes Theme mit vielen render-blockierenden Skripten, nicht optimierte Bilder, fehlendes oder schwaches Caching und ein Server, der jede Seite langsam neu generiert. Der erste Schritt ist immer eine Messung — erst die Diagnose, dann die Maßnahme.
Was sind Core Web Vitals? +
Googles Kennzahlen für die Nutzererfahrung: LCP (wann das größte Element sichtbar ist), CLS (Layout-Stabilität) und INP/TBT (Reaktionsfähigkeit). Sie fließen ins Ranking ein und entscheiden, ob sich eine Seite „schnell" anfühlt. Wir messen und optimieren genau diese Werte.
Reicht ein Caching-Plugin, um meine Seite schnell zu machen? +
Caching hilft enorm — aber nur, wenn der Cache zuverlässig warm gehalten wird (Vorab-Generierung) und Besucher bei einem Cache-Ablauf nicht in den langsamen Neuaufbau laufen. Wenn der Server pro Seite mehrere Sekunden zum Erzeugen braucht, stößt jedes Plugin an eine Grenze — dann ist das Hosting der Hebel.
Wann lohnt sich ein Hosting-Wechsel für WordPress? +
Wenn die reine Server-Generierungszeit (TTFB beim Cache-Neuaufbau) auch nach Caching- und Frontend-Optimierung hoch bleibt. Bei schweren Setups (WPML, WooCommerce, Page-Builder) bringt ein Host mit Redis-Object-Cache und NVMe die Generierung oft von mehreren Sekunden auf unter eine Sekunde — und macht alle weiteren Optimierungen erst wirksam.
Ist deine WordPress-Seite zu langsam?
Wir messen ehrlich, finden den echten Engpass und sagen dir, was wirklich hilft — vom Caching bis zur Hosting-Frage. 30 Minuten kostenloses Erstgespräch.