WordPress schneller machen – zuerst die Ursachen verstehen.
Kurz beantwortet
Langsame WordPress-Seiten haben meist mehrere Ursachen: große Bilder, blockierende Skripte, Fremddienste, Plugins oder das Hosting. Eine statische Umstellung entfernt die Server-Laufzeit und Datenbankabfragen – große Bilder oder schwere Skripte löst sie nicht automatisch.
Erst messen, dann optimieren
„Langsam“ kann vieles heißen: Der Server antwortet spät, der sichtbare Inhalt erscheint spät, oder die Seite reagiert träge auf Klicks. Jede Ursache braucht eine andere Maßnahme. Deshalb steht am Anfang eine Messung – am besten an mehreren typischen Seiten, nicht nur an der Startseite.
- PageSpeed Insights zeigt zwei Arten von Daten: Felddaten echter Besucher aus dem Chrome UX Report (sofern genug Besucher vorhanden sind) und eine Labormessung mit Lighthouse. Die Felddaten sind das, was Google für die Bewertung heranzieht.
- Die Entwicklerwerkzeuge des Browsers zeigen im Netzwerk-Tab, welche Dateien wie groß sind und wie lange sie brauchen. Ein langer erster Balken für das HTML-Dokument deutet auf den Server hin, viele große Dateien danach auf das Frontend.
- Die Search Console fasst im Bericht zu den Core Web Vitals zusammen, welche Seitengruppen Probleme haben.
Halte die Ausgangswerte fest. Nur so siehst du später, ob eine Maßnahme etwas gebracht hat.
Ursache → Maßnahme → Grenze der statischen Umstellung
| Ursache | Mögliche Maßnahme | Statisches HTML |
|---|---|---|
| Große Bilder | Komprimieren, moderne Formate, passende Größen | Hilft nicht automatisch – Bilder bleiben gleich groß. |
| Render-blockierende Ressourcen | CSS/JS verschlanken, Skripte verzögern | Bleibt bestehen, wenn Theme-Code übernommen wird. |
| Drittanbieter-Skripte | Tracking, Chats, Widgets prüfen | Hilft nicht – Fremdskripte laden weiterhin. |
| Schweres Theme | Theme wechseln oder entschlacken | HTML wird übernommen, Ballast teils auch. |
| Viele Plugins | Plugin-Audit, Überflüssiges entfernen | Serverlast entfällt, Frontend-Assets bleiben. |
| Langsames Hosting | Tarif oder Anbieter wechseln, Caching | Hilft deutlich: keine PHP-Laufzeit. |
| Datenbank-Last | Aufräumen, Objekt-Cache | Hilft deutlich: keine Datenbankabfragen. |
Quick-Wins bei bestehendem WordPress
- Bildoptimierung: Größen anpassen, komprimieren, Lazy Loading.
- Caching: Seiten-Cache und Browser-Cache sinnvoll einrichten.
- Kritische Skripte: Nur laden, was die Seite wirklich braucht.
- Hosting: Aktuelle PHP-Version, ausreichende Ressourcen.
- Theme- und Plugin-Audit: Doppelte und ungenutzte Funktionen entfernen.
Maßnahmen im Detail
Bilder
Bilder sind auf vielen Websites der größte Anteil an der Datenmenge. Lade sie in der Größe hoch, in der sie angezeigt werden, nutze moderne Formate wie WebP oder AVIF und lass WordPress responsive Varianten erzeugen. Bilder unterhalb des sichtbaren Bereichs dürfen verzögert laden (loading="lazy") – das große Bild ganz oben dagegen nicht, sonst erscheint der Hauptinhalt später.
CSS und JavaScript
Viele Themes und Page-Builder laden auf jeder Seite Code für Funktionen, die dort gar nicht vorkommen. Prüfe in der Coverage-Ansicht der Entwicklerwerkzeuge, wie viel davon tatsächlich genutzt wird. Skripte, die für den ersten Eindruck nicht nötig sind, können mit defer später ausgeführt werden.
Drittanbieter
Tracking, Chat-Widgets, eingebettete Karten, Videos und Schriftarten von fremden Servern kosten jeweils eigene Verbindungen und Rechenzeit. Frage bei jedem Dienst, ob er auf jeder Seite nötig ist. Videos und Karten lassen sich oft erst nach einem Klick laden – das hilft auch beim Datenschutz.
Server und Caching
Ohne Seiten-Cache führt WordPress bei jedem Aufruf PHP aus und fragt die Datenbank ab. Ein Seiten-Cache speichert das fertige HTML und liefert es beim nächsten Besuch direkt aus. Das ist im Kern das, was eine statische Website dauerhaft tut – mit dem Unterschied, dass WordPress dahinter weiterläuft und gepflegt werden muss. Eine aktuelle PHP-Version und ausreichend Ressourcen beim Hosting gehören ebenfalls dazu.
Wann hilft die Umstellung auf statisches HTML?
Vor allem, wenn die serverseitige Laufzeit der Engpass ist: Jede Anfrage startet PHP und fragt die Datenbank ab. Statische Dateien lassen sich direkt ausliefern und sehr gut cachen. Nicht automatisch gelöst werden zu große Bilder, umfangreiche JavaScript-Bundles oder Fremdskripte – die wandern unverändert mit.
Web Vitals verständlich erklärt
Googles Core Web Vitals beschreiben, wie schnell der Hauptinhalt erscheint (LCP), wie schnell die Seite auf Eingaben reagiert (INP) und wie stabil das Layout beim Laden bleibt (CLS). Miss diese Werte mit echten Werkzeugen an deiner eigenen Website, bevor und nachdem du etwas änderst. Vorher/Nachher-Vergleiche zeigen wir nur mit dokumentierten Messungen.
Als Faustregel: LCP hängt oft an Serverantwort und großen Bildern, INP an zu viel JavaScript, CLS an Bildern ohne feste Größe, nachladenden Bannern und Schriftwechseln. Eine statische Umstellung verbessert vor allem die Serverantwort und damit die Grundlage für einen guten LCP.
Fragen zur Performance
Ist eine statische Website schneller als WordPress?
Sie kann es sein – weil Seiten ohne WordPress-Laufzeit und Datenbank ausgeliefert werden. Die tatsächliche Ladegeschwindigkeit hängt aber weiterhin stark von Bildern, JavaScript, CSS, Hosting und externen Diensten ab.
Ursachen langsamer Websites verstehenWerden Bilder übernommen?
Bilder, die öffentlich ausgeliefert werden, lassen sich in der Regel mit exportieren. Kritisch sind responsive Bildvarianten (srcset), per JavaScript nachgeladene Bilder und Medien von externen Domains. Diese Punkte gehören auf jede Export-Checkliste.
Benötige ich noch Hosting?
Ja. Auch HTML-Dateien müssen online ausgeliefert werden. Statische Hosting-Angebote können einfach und kostengünstig sein, sind aber nicht grundsätzlich kostenlos und haben je nach Anbieter Beschränkungen.
Welche Kosten bleibenIst eine statische Website sicherer?
Sie reduziert bestimmte Angriffsflächen wie WordPress-Logins, Plugins und die Datenbank. Sicherheitsfragen verschwinden dadurch nicht vollständig: Hosting, Domains, externe Formulardienste, Skripte und Konten müssen weiterhin geschützt werden.