SpeedupWP

WordPress-Performance mit Plan.

WordPress-Hosting auswählen und passend dimensionieren

← Zur Wissensdatenbank

Typischer Nutzwert
Hoch
Aufwand
Hoch
Risiko
Mittel
Hosting / Umgebung
Vom Managed Shared Hosting bis zum dedizierten Multi-Tenant-Server
Voraussetzungen
Messbare Last, Wachstumsannahmen, Budget und geklärte Betriebsverantwortung
Aussagekraft
hoch
Zuletzt geprüft
17. August 2026

Kurzfassung: Anforderungen kaufen, nicht Produktnamen

Ein schneller Webserver kompensiert weder zu wenig CPU noch langsame Datenbankabfragen, unklare Paketlimits oder fehlenden Betrieb. Wähle Hosting deshalb in dieser Reihenfolge: Nutzerregion und Verfügbarkeit, messbare dynamische Spitzenlast, Betriebsverantwortung, Ressourcenisolation, Speicher und Netzwerk, danach Panel und Webserver. Ein Umzug ist erst begründet, wenn der aktuelle Engpass wiederholt gemessen oder eine notwendige Funktion nachweislich nicht verfügbar ist.

Nicht-Ziel: Dieser Leitfaden kürt keinen pauschal besten Hoster. Tarife, Limits, Rechenzentren und Support ändern sich. Er liefert eine reproduzierbare Ausschreibung und Dimensionierung, mit der zwei Angebote vergleichbar werden.

Schritt 1: Betriebsmodell und Hosting-Klasse wählen

Modell Passt typischerweise Vor Vertrag klären
Managed Shared Hosting Unternehmensseiten, Blogs und kleine Shops ohne eigene Serveradministration CPU-/RAM-Limits, gleichzeitige PHP-Worker, I/O, Inodes, Cron, Redis, Staging, Backup-Restore und Eskalationsweg
Managed WordPress Teams, die Updates, Cache, Security und Restore als Dienstleistung einkaufen Welche Plugins oder Jobs eingeschränkt sind, Cache-Ausnahmen, SSH/WP-CLI, Staging, Restore-Zeit, Export- und Kündigungsweg
VPS oder Cloud-VM Mehr Kontrolle, eigene Dienste, planbare Ressourcen und mehrere Websites Geteilte oder dedizierte vCPU, CPU-Steal, Storage-IOPS und -Latenz, Snapshot-Grenzen, Netzwerk und wer Patch, Monitoring und Backup betreibt
Dedizierter Server Dauerhaft hohe oder stark schwankende Last, viele Sites, strenge Isolation oder große Datenbank Hardwaretausch, Remote-Konsole, RAID/Datenträgerausfall, Ersatzteil-SLA, DDoS, Backup außerhalb des Servers und Kapazitätsreserve

Shared versus Dedicated ist kein Qualitätsurteil. Gutes Shared Hosting mit harten Kontolimits, schnellem Cache und kompetentem Betrieb kann eine einzelne Website besser tragen als ein schlecht administrierter Root-Server. Dedizierte vCPU oder Hardware werden sinnvoll, wenn CPU-Steal, Nachbarlast, I/O-Streuung oder Compliance messbar stören – nicht allein wegen einer Besucherzahl.

Schritt 2: Paketparameter übersetzen

Angabe Was wirklich zählt Typische Falle
vCPU/Cores CPU-Modell, Takt, dediziert oder geteilt, zulässige Dauerlast und Steal Viele geteilte vCPU können unter Nachbarlast langsamer sein als wenige verlässliche Kerne.
RAM Garantierter RAM und Budget für DB, PHP, Cache, Panel und Reserve Swap wird als Arbeitsspeicher verkauft oder Panel, Mail und Scanner werden nicht eingerechnet.
PHP-Worker/Entry Processes Gleichzeitige ungecachte PHP-Anfragen und Warteschlange Hohes memory_limit wird mit realer Parallelität verwechselt.
SSD/NVMe Messbare Latenz, IOPS, Durchsatz, Queue, Burst-Regeln, Redundanz und Reserve Das Label NVMe sagt nichts über Überbuchung oder Backend-Limit aus.
Speicherplatz Web, DB, Mail, Logs, Staging, lokale Backups, temporäre Dateien und Inodes Nur die aktuelle Mediathek wird gezählt; Restore braucht kurzfristig zusätzlichen Platz.
Traffic Ausgehend/eingehend, CDN-Origin-Traffic, Backups, Fair Use, Portlimit und Mehrpreis Analytics zählt weder alle Bots noch Backup- und Systemübertragungen.
Backup RPO, RTO, Aufbewahrung, externes Ziel, Verschlüsselung und getesteter Self-Service-Restore Snapshot auf demselben Host wird mit unabhängigem Backup verwechselt.

Schritt 3: CPU und dynamische Parallelität berechnen

Page-Cache-Hits benötigen normalerweise keinen PHP-Worker. Für die Servergröße zählen deshalb vor allem ungecachte Spitzen: Login, Suche, REST, Warenkorb, Checkout, Admin, Cron und Cache-Misses. Miss mittlere Laufzeit und CPU-Zeit separat.

ungecachte Parallelität = Spitzen-RPS ohne Page Cache × mittlere PHP-Laufzeit × 1,2 bis 1,5 Reserve
PHP-CPU-Kerne = Spitzen-RPS ohne Page Cache × CPU-Sekunden je Request / Zielauslastung
Gesamt-vCPU = PHP-CPU-Kerne + Datenbank/OS/Jobs + Wachstumsreserve

Als Zielauslastung sind 0,6 bis 0,75 ein vernünftiger Startbereich, damit Cron, Deployments und kurze Spitzen Platz behalten. Beispiel: 25 ungecachte Requests/s × 0,20 CPU-s / 0,70 = 7,1 CPU-Kerne nur für PHP. Mit Datenbank, System und Reserve ist ein Testkandidat mit 12 bis 16 verlässlichen vCPU plausibel. Das ist keine Tarifempfehlung, sondern eine zu lasttestende Herleitung. Die Workerzahl wird anschließend mit dem PHP-FPM-Cookbook gegen RAM, CPU und Datenbank begrenzt.

Schritt 4: RAM als gemeinsames Budget planen

RAM gesamt = OS und Panel + Datenbankbudget + PHP-Worker-Budget
           + OPcache und Object Cache + Mail/Security/Monitoring/Jobs
           + 15 bis 25 % Reserve

Auf einem All-in-one-Server konkurrieren MariaDB, PHP und Dateicache um denselben RAM. Plane nicht jede Komponente separat mit dem gesamten Speicher. Bei Shared Hosting ersetzt die Frage nach garantierten PHP-Workern, Kontospeicher und Datenbanklimits die Serverrechnung. Bei einem Panel-Host müssen zusätzlich Webmail, Spam-/Virenscanner, DNS, Backups und mehrere PHP-Pools einbezogen werden.

Schritt 5: Speicher – NVMe ja, aber nicht als Zauberwort

WordPress und MySQL/MariaDB erzeugen viele kleine, teils zufällige I/O-Operationen. SSD ist deshalb für Live-Datenbank und aktive Website der sinnvolle Mindeststandard. NVMe kann Latenz und Parallelität weiter verbessern, besonders bei Shops, vielen Websites, Importen, Bildverarbeitung, Backups und großen Datenbanken. Eine gut provisionierte Netzwerk-SSD kann dennoch verlässlicher sein als überbuchtes lokales NVMe.

Verlange bei anspruchsvollen Angeboten Zahlen oder einen Test zu IOPS, MiB/s, Latenz, Queue und Burst-Dauer. Prüfe außerdem Redundanz und Persistenz: lokaler NVMe-Instance-Store kann sehr schnell sein, ist aber je nach Plattform nicht der dauerhafte Datenträger. HDD ist für günstige externe Backups oder Archivdaten vertretbar, nicht als erste Wahl für die produktive WordPress-Datenbank.

Speicherbedarf = (Webdateien + Datenbank + Mail + Logs + Staging
                 + lokale Backups + temporärer Restore-Platz) × 1,25 Reserve

Beispiel: 35 GiB Web/Uploads + 8 GiB DB + 12 GiB Mail/Logs + 30 GiB Staging + 60 GiB lokale Backupgenerationen + 25 GiB Restore-/Updateplatz = 170 GiB. Mit 25 % Reserve sind rund 213 GiB nötig; der nächste sinnvolle Tarifschritt wäre etwa 240 bis 256 GiB. Ein zusätzliches Offsite-Backup bleibt Pflicht.

Schritt 6: Traffic und Anbindung realistisch kalkulieren

Monatstransfer in GiB ≈ Pageviews × übertragene MiB je Pageview / 1024 × Overheadfaktor
Peak-Mbit/s ≈ gleichzeitige Transfers × MiB je Transfer × 8 / Transferdauer in s

Der Overheadfaktor 1,2 bis 1,5 berücksichtigt als Startannahme Bots, Cache-Misses, APIs und Messungen; Backups und Replikation werden separat addiert. Beispiel: 200.000 Pageviews × 1,5 MiB / 1024 × 1,3 ≈ 381 GiB/Monat. Ein CDN kann den Ursprung entlasten, aber Origin-Misses, Purges und Vertragsregeln bleiben relevant.

Frage nach Rechenzentrumsregion, Routing und Peering zu den Hauptnutzern, redundanten Uplinks, DDoS-Schutz, IPv4/IPv6, geteilter oder garantierter Portgeschwindigkeit und Traffic-Mehrpreis. Ein 1-Gbit/s-Port bedeutet nicht automatisch 1 Gbit/s dauerhaft oder gute Latenz. Für regionale Sites ist ein naher, stabil angebundener Ursprung oft wichtiger als eine theoretisch größere Portzahl.

Schritt 7: Webserver nach Betrieb und Kompatibilität wählen

Stack Gute Wahl, wenn Abhängigkeiten und Grenzen
Apache 2.4 + PHP-FPM Kompatibilität, .htaccess, viele Standardanwendungen und einfacher Betrieb wichtig sind Mit Event-MPM, PHP-FPM und Page Cache reicht Apache für sehr viele Sites. Erst bei gemessener Verbindungs- oder Speicherlast wechseln.
Apache + nginx Reverse Proxy Plesk-Standard, statische Auslieferung und viele langsame Verbindungen abgefangen werden sollen Zwei Konfigurationsebenen; echte Client-IP, Header, Cache und Purge müssen zusammenpassen.
nginx + PHP-FPM Ein bewusst schlanker, selbst verwalteter Stack mit nativer FastCGI-/Proxy-Konfiguration gewünscht ist Kein .htaccess; WordPress-Rewrites, Security-Header und Plugin-Anforderungen gehören in Serverkonfiguration. nginx ist weiterhin sinnvoll, aber kein automatischer WordPress-Turbo.
LiteSpeed Enterprise Apache-Kompatibilität, Hosting-Panel-Integration, LSCache und hohe Parallelität zusammen benötigt werden Kostenpflichtige Lizenz nach Tarif und Hardware; in Plesk und cPanel als Apache-Ersatz integrierbar. Cache-Vary, Purge und Lizenzgrenzen prüfen.
OpenLiteSpeed Ein bewusst dafür gebauter, kostenfreier OLS-Stack mit unterstütztem Panel oder eigener WebAdmin-Verwaltung betrieben wird Kein Drop-in für Apache/Plesk; .htaccess unterstützt nur Rewrite-Regeln, andere Direktiven werden ignoriert, Änderungen erfordern Reload oder Neustart.

Wann reicht Apache? Wenn Cache-Hits schnell sind, dynamische P95-Zeiten passen, CPU und RAM Reserve haben und kein Verbindungsengpass messbar ist. Wann LiteSpeed oder OLS? Wenn LSCache und deren Betriebsmodell bewusst gewollt sind und die Panel- und Konfigurationsabhängigkeiten passen. Wann nginx? Bei eigenem Betrieb, Reverse Proxy, statischer Auslieferung oder FastCGI-Cache – nicht bloß, weil nginx als moderner gilt.

Plesk und OpenLiteSpeed: die konkrete Antwort

Plesk für Linux verwendet offiziell Apache, standardmäßig ergänzt durch nginx als Reverse Proxy; einzelne Domains können nginx-only mit PHP-FPM laufen. LiteSpeed Enterprise bietet eine Plesk-Integration und liest Apache-Konfiguration weitgehend als Ersatz. OpenLiteSpeed ist dagegen kein direkter Apache-Ersatz und führt Plesk nicht in seiner Liste unterstützter Panels. Die offizielle OLS-Dokumentation nennt unter anderem CyberPanel, DirectAdmin, Enhance, aaPanel, Webuzo und OpenPanel.

Daher gilt: OLS nicht in einen bestehenden Plesk-Server hineinplanen. Wer Plesk benötigt und LiteSpeed möchte, prüft LiteSpeed Enterprise samt Lizenz und Extension. Wer OLS bewusst wählt, nimmt ein offiziell unterstütztes Panel oder administriert den nativen OLS-Stack. Eine inoffizielle Kombination erhöht Migrations-, Update- und Support-Risiko.

Schritt 8: Panel nach Aufgabe auswählen

Panel oder Betrieb Passt typischerweise Einplanen
Managed-Hoster-Panel Eine oder wenige Sites, wenig Systemadministration Export, SSH/WP-CLI, Staging, Cachekontrolle und Restore-Funktionen prüfen.
Plesk Agenturen, mehrere Kunden oder Abonnements, WordPress Toolkit, optional Mail/DNS Panel-, Mail-, Backup- und Security-RAM; Apache+nginx, nginx-only oder LiteSpeed Enterprise – nicht OLS.
cPanel/WHM Klassisches Shared- oder Reseller-Hosting mit Apache-Ökosystem Lizenz und Systembedarf; LiteSpeed Enterprise ersetzt Apache, nutzt aber nicht denselben PHP-FPM-Pfad.
DirectAdmin Multi-Site- oder Hostingbetrieb mit per CustomBuild gewähltem Stack Konkrete Webserver-/PHP-Kombination dokumentieren; OLS wird nativ erzeugt statt Apache-Konfiguration direkt zu lesen.
CyberPanel Bewusster OLS- oder LiteSpeed-Enterprise-Betrieb Update-, Backup-, Security- und Supportprozess eigenständig bewerten.
Kein Panel oder Infrastructure as Code Erfahrenes Team, wenige standardisierte Workloads, automatisierte Deployments Weniger Panel-Software bedeutet mehr eigene Verantwortung für Patches, Mail, DNS, Zertifikate, Monitoring und Restore.

Schritt 9: Hoster mit einer prüfbaren Ausschreibung vergleichen

  1. Muss-Kriterien: Region und Datenschutz, aktuelle unterstützte PHP- und DB-Versionen, HTTPS, SSH/WP-CLI, Backup/RTO, benötigter Cache und Exit-Export.
  2. Ressourcen: garantierte oder geteilte CPU, RAM, PHP-Worker, I/O/IOPS, Inodes, DB-Limits, Cron und Redis schriftlich erfragen.
  3. Netz: Trafficdefinition, Portlimit, DDoS, Statusseite, Uptime-SLA, Wartungsfenster und Erstattung prüfen.
  4. Betrieb: Wer patcht OS, PHP, DB, Panel und Webserver? Wer reagiert nachts auf volle Disk, Queue, 5xx oder Zertifikatsfehler?
  5. Test: Stagingkopie mit anonymisierten Daten und repräsentativem Lastprofil aus Zielregion betreiben; Cache-Hits und dynamische Pfade getrennt messen.
  6. Ausgang: Kündigungsfrist, Datenexport, DNS-TTL, Backupformat, IP-Wechsel und paralleles Migrationsfenster dokumentieren.

Ein mögliches Bewertungsraster von 0 bis 5 gewichtet Passung und Ressourcen 30 %, gemessene Leistung 25 %, Betrieb und Support 20 %, Backup und Restore 15 % und Gesamtkosten 10 %. Die Gewichte sind ein Beispiel und werden vor dem Angebotsvergleich festgelegt – nicht nachträglich zugunsten eines Anbieters verändert.

Praxisbeispiel 1: Unternehmensseite mit planbarem Verkehr

Eine Unternehmensseite mit 30.000 Pageviews im Monat, wenigen Formularen und fast ausschließlich anonymen Cache-Hits braucht selten einen Root-Server. Gutes Managed Shared Hosting mit dokumentierten Kontolimits, 20 bis 40 GiB SSD/NVMe, täglichem externem Backup, Staging, aktuellem PHP, OPcache und integriertem Page Cache ist meist die wirtschaftlichere Wahl. Wichtig sind mehrere gleichzeitige PHP-Ausführungen für Cache-Misses und Admin, aber die konkrete Zahl wird durch einen Test bestätigt. Ein selbst verwalteter VPS-Startkandidat wäre 2 vCPU und 4 GiB – nur wenn jemand Updates, Monitoring und Restore zuverlässig übernimmt.

Praxisbeispiel 2: Magazin mit 300.000 Pageviews und Lastspitzen

Bei 300.000 Pageviews im Monat, 1,2 MiB je View und Faktor 1,3 entstehen ungefähr 457 GiB Transfer. Mit hohem Page-Cache-Hit-Anteil kann ein 4-vCPU-/8-GiB-VPS oder entsprechend transparentes Managed-Paket genügen. Sinnvoll sind 80 bis 160 GiB SSD/NVMe, CDN für große statische Assets, kontrollierter Cache-Warmup nur bei Bedarf und ein Plan für Newsletter-Spitzen. Entscheidend ist nicht die Monatszahl, sondern die höchste ungecachte RPS-Rate nach Purge.

Praxisbeispiel 3: Agenturserver mit Plesk und 25 Websites

Ein Startkandidat mit 8 vCPU, 16 GiB RAM und 240 bis 320 GiB NVMe kann für 25 überwiegend kleine Sites passen, wenn Limits pro Abonnement, ondemand-Pools, externe Backups und Monitoring eingerichtet sind. Beispielbudget: 3 GiB OS, Plesk, Mail und Security, 4 GiB Datenbank, 5 GiB PHP-Pools, 1 GiB Redis/OPcache und 3 GiB Reserve. Eine einzelne stark besuchte Site darf dieses gemeinsame Budget nicht ungeplant verdrängen. Plesk Apache+nginx ist der konservative Standard; LiteSpeed Enterprise ist eine lizenzierte Alternative. OLS ist hier nicht die passende Ergänzung.

Praxisbeispiel 4: größerer WooCommerce-Shop

Ein Shop erreicht 25 ungecachte RPS bei 0,20 CPU-s und 0,35 s mittlerer PHP-Laufzeit. Daraus folgen rund 11 gleichzeitige PHP-Anfragen inklusive Faktor 1,25 und 7,1 PHP-CPU-Kerne bei 70 % Zielauslastung. Ein Testkandidat mit 12 bis 16 dedizierten vCPU, 32 GiB RAM und 400 bis 500 GiB redundantem NVMe ist plausibel. Beispiel-RAM: 6 GiB System, Web und Panel, 10 bis 12 GiB MariaDB, 8 bis 10 GiB PHP, 2 GiB Redis/OPcache und mindestens 4 GiB Reserve. Checkout, Suche, REST und eingeloggte Konten werden lastgetestet; Page-Cache-Benchmarks allein sind wertlos.

Migration, Erfolgskontrolle und Rollback

  1. Vorher P50, P95 und P99 für Cache-Hit, Cache-Miss, Checkout und Admin sowie Fehlerrate, CPU-Steal, RAM, I/O-Latenz, Queue und Transfer erfassen.
  2. Dateien und Datenbank konsistent replizieren; sensible Daten im Test anonymisieren. Mail, Cron, Webhooks, DNS, TLS und echte Client-IP einbeziehen.
  3. Mit niedriger DNS-TTL und parallelem Rückkehrfenster umschalten. Schreibzugriffe während finaler Synchronisierung kontrollieren.
  4. Erfolg nur anerkennen, wenn dynamische P95-Latenz und Fehlerrate passen, Backups und Restore funktionieren, keine Queue-, Swap- oder I/O-Spirale entsteht und die Kosten inklusive Betrieb tragbar sind.
  5. Bei Regression DNS oder Proxy auf den alten, weiterhin konsistenten Ursprung zurückführen. Neue Bestellungen oder Formulare verhindern ein blindes Zurückspielen einer alten Datenbank; zunächst Routing und Konfiguration zurücknehmen und Daten gezielt synchronisieren.

Der beste Tarif ist der kleinste, der die gemessene Spitzenlast mit Reserve, überprüfbarem Restore und klarer Betriebsverantwortung trägt. Nach vier bis acht Wochen reale Auslastung erneut prüfen und erst dann dauerhaft hoch- oder herunterskalieren.

Quellen und Prüfstand

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.