Ein kleiner WordPress-Blog braucht meist keinen leistungsstarken Root- oder Dedicated Server. Für die Auswahl zählen weniger die monatlichen Besucher allein als gleichzeitige Seitenaufrufe, Cache-Nutzung, datenbankintensive Funktionen und die erwartete Entwicklung. Shared Hosting eignet sich für einen einfachen Start, ein kleiner VPS bietet kontrollierbare Ressourcen und ein Managed VPS reduziert den eigenen Verwaltungsaufwand. Vergleiche diese Betriebsmodelle über dieselbe Zeitspanne und einschließlich Backups, Verwaltung und möglicher Zusatzkosten.
Drei passende Betriebsmodelle im selben Raster
Für einen kleinen WordPress-Blog kommen vor allem Shared Hosting, ein selbst verwalteter VPS und ein Managed VPS infrage. Ein VPS ist ein virtueller Server mit zugewiesenen virtuellen Prozessorkapazitäten, meist als vCPU bezeichnet, sowie eigenem Arbeitsspeicher. Die Varianten unterscheiden sich nicht nur bei CPU und RAM, sondern besonders bei Kontrolle, Wartungsaufwand und der Verlässlichkeit zugesicherter Ressourcen.
| Kriterium | Shared Hosting | Selbst verwalteter VPS | Managed VPS |
|---|---|---|---|
| Ressourcen | Mit anderen Kunden geteilte Plattform; Grenzen häufig über Tarifregeln statt feste CPU-Zusagen | Ausgewiesene vCPU, RAM und Speicher; tatsächliche CPU-Leistung hängt von Virtualisierung und Auslastung des Hosts ab | Ausgewiesene Ressourcen wie beim VPS, ergänzt um vereinbarte Verwaltungsleistungen |
| Administration | Serverbetrieb liegt weitgehend beim Hoster | Betriebssystem, Webserver, PHP, Datenbank, Updates und Absicherung liegen bei Dir | Umfang hängt vom Vertrag ab; WordPress-Wartung ist nicht automatisch eingeschlossen |
| Skalierung | Tarifwechsel innerhalb der Hosting-Plattform | Ressourcen lassen sich je nach Plattform vergrößern; die technische Migration kann trotzdem nötig sein | Skalierung mit Unterstützung gemäß Leistungsumfang |
| Kostenstruktur | Grundpreis kann viele Plattformleistungen bündeln | Niedriger Serverpreis möglich, aber Zeitaufwand und Zusatzdienste kommen hinzu | Höherer Grundpreis durch Betreuung; Leistungsgrenzen genau abgleichen |
| Geeignet für | Einfache Blogs mit überschaubaren Lastspitzen und wenig Administrationsbedarf | Technisch versierte Betreiber mit Wunsch nach Kontrolle | Blogs, die eigene Serverressourcen benötigen, deren Betreiber den Systembetrieb aber nicht vollständig übernehmen möchten |
Shared Hosting ist nicht automatisch langsamer und ein VPS nicht automatisch schneller. Eine gut abgestimmte Hosting-Plattform mit Seitencache kann einen kleinen Blog effizient bedienen. Ein schlecht konfigurierter VPS kann trotz eigener Ressourcen langsam oder unsicher sein. Ein Dedicated Server mit exklusiver physischer Hardware ist für einen kleinen Blog gewöhnlich erst dann plausibel, wenn besondere Workloads hinzukommen, die sich nicht sinnvoll auf einem VPS abbilden lassen.
Besucher, Seitenaufrufe und Gleichzeitigkeit auseinanderhalten
Die Besucherzahl ist für Reichweitenplanung nützlich, beschreibt die Serverlast aber nur grob. Ein Besucher kann eine oder mehrere Seiten öffnen. Zugriffe verteilen sich außerdem nicht gleichmäßig über den Monat: Ein Newsletter, ein stark geteilter Beitrag oder eine Erwähnung in einem größeren Medium kann einen kurzen Lastsprung auslösen.
Für eine erste Planung kannst Du drei Größen aus Deinen Statistikdaten ableiten:
- Monatliche Besuche oder Sitzungen: Wie viele zusammenhängende Besuche finden statt?
- Seiten pro Besuch: Wie viele HTML-Seiten werden durchschnittlich innerhalb eines Besuchs geöffnet?
- Spitzenfaktor: Wie stark liegt die aktivste Stunde über einer rechnerischen Durchschnittsstunde?
Die monatlichen Seitenaufrufe ergeben sich näherungsweise aus:
Seitenaufrufe pro Monat = Besuche pro Monat × Seiten pro Besuch
Für die technische Dimensionierung ist die Spitzenstunde hilfreicher:
Seitenaufrufe in der Spitzenstunde = (Seitenaufrufe pro Monat ÷ betrachtete Stunden pro Monat) × Spitzenfaktor
Die betrachteten Stunden müssen zu Deinem Nutzungsmuster passen. Wenn der Blog praktisch rund um die Uhr besucht wird, kannst Du für eine grobe Monatsbetrachtung mit 30 Tagen × 24 Stunden rechnen. Konzentriert sich das Publikum auf bestimmte Tageszeiten, ist eine Auswertung realer Stundenwerte deutlich aussagekräftiger als eine gleichmäßige Verteilung.
Rechenszenario für einen wachsenden Blog
Ein hypothetischer Blog verzeichnet 12.000 Besuche pro Monat und durchschnittlich 1,6 Seiten je Besuch. Die Rechnung lautet:
12.000 Besuche × 1,6 Seiten pro Besuch = 19.200 Seitenaufrufe pro Monat
Bei einer vereinfachten Verteilung über 30 Tage mit jeweils 24 Stunden ergeben sich durchschnittlich:
19.200 Seitenaufrufe ÷ (30 Tage × 24 Stunden) = rund 26,7 Seitenaufrufe pro Stunde
Mit einem angenommenen Spitzenfaktor von 8 läge die Planungsgröße bei:
26,7 Seitenaufrufe pro Stunde × 8 = rund 214 Seitenaufrufe in der Spitzenstunde
Das entspricht im Mittel etwa 3,6 Seitenaufrufen pro Minute innerhalb dieser Spitzenstunde. Die Rechnung ist kein Lasttest: 214 Aufrufe können gleichmäßig eintreffen oder sich auf wenige Sekunden konzentrieren. Sie zeigt aber, weshalb 19.200 monatliche Seitenaufrufe allein keine hohe Serverklasse begründen. Ein sauber gecachter Blog kann einen großen Teil dieser Anfragen ausliefern, ohne WordPress und die Datenbank für jeden Aufruf vollständig auszuführen.
Wächst der Blog sechs Monate lang um angenommene 10 Prozent pro Monat, muss das Wachstum aufgezinst und nicht einfach sechsmal addiert werden:
19.200 × (1 + 0,10)6 = rund 34.000 Seitenaufrufe pro Monat
Da das erlaubte HTML kein Hochstellungs-Tag vorsieht, ist die Formel ausgeschrieben: 19.200 wird sechsmal nacheinander mit 1,10 multipliziert. Der Zahlencheck ergibt ungefähr 34.000 monatliche Aufrufe. Für eine Tarifentscheidung solltest Du zusätzlich ein zurückhaltendes Szenario und ein starkes Wachstumsszenario rechnen, statt nur den optimistischsten Wert zu übernehmen.
Wann ein Seitenaufruf wenig oder viel Arbeit verursacht
Ein öffentlicher Beitrag kann über einen Seiten- oder Proxy-Cache als fertige HTML-Antwort bereitgestellt werden. WordPress muss dann nicht für jeden Abruf sämtliche PHP-Logik und Datenbankabfragen erneut ausführen. Das senkt vor allem CPU-Bedarf und Antwortzeit. Bilder, CSS und JavaScript können zusätzlich über Browsercache oder ein Content Delivery Network ausgeliefert werden.
Mehr Rechenarbeit entsteht bei nicht cachebaren oder personalisierten Anfragen. Dazu gehören je nach Aufbau angemeldete Benutzer, Vorschauen, manche Suchfunktionen, dynamische Formulare und bestimmte Statistik-, Shop- oder Mitgliederfunktionen. Auch geplante Aufgaben, Backups, Bildverarbeitung, Sicherheitsprüfungen und Plugin-Jobs können Last erzeugen, obwohl gerade nur wenige Leser online sind.
Ordne Deinen Blog daher einem Lastprofil zu:
- Überwiegend redaktionell: öffentliche Beiträge, wenige Formulare, keine Anmeldung für Leser. Hier erzielt ein wirksamer Seitencache meist den größten Nutzen.
- Interaktiv: viele Suchanfragen, Kommentare, Formulare oder personalisierte Ansichten. CPU, Datenbank und verfügbare PHP-Prozesse werden wichtiger.
- Medienlastig: zahlreiche große Bilder, Downloads, Audio- oder Videodateien. Speicherplatz und ausgehender Datentransfer rücken stärker in den Vordergrund.
- Arbeitslast im Hintergrund: häufige Imports, Backups, Bildkonvertierungen oder Sicherheitsläufe. Kurzzeitige CPU- und Speicherbelastung kann die normalen Seitenaufrufe beeinträchtigen.
Ressourcen nicht nach Besucherzahl allein kaufen
CPU und PHP-Verarbeitung
Virtuelle CPU-Kerne sind nur eingeschränkt zwischen Anbietern vergleichbar. Prozessorgeneration, Takt, Überbuchung und Limits beeinflussen die Leistung. Für einen kleinen redaktionellen Blog ist zunächst wichtiger, ob Antwortzeiten unter Last stabil bleiben und CPU-Spitzen zeitlich mit PHP-Anfragen oder Hintergrundjobs zusammenfallen. Mehr vCPU hilft nur, wenn die Software Aufgaben parallel abarbeiten kann und tatsächlich die CPU den Engpass bildet.
RAM und Datenbank
Der Arbeitsspeicher wird unter anderem von Betriebssystem, Webserver, PHP-Prozessen, Datenbank und Caches genutzt. Zu wenig RAM kann zu Auslagerung auf Datenträger oder beendeten Prozessen führen. Eine pauschale Besuchergrenze pro Gigabyte wäre dennoch irreführend: Ein schlanker Blog mit Cache verhält sich anders als dieselbe Besucherzahl auf einer Installation mit vielen dynamischen Plugins.
Bei einem eigenen VPS sollte nach der normalen Auslastung noch Reserve für Updates, Backups und kurze Spitzen bleiben. Ist der Speicher im Alltag schon fast vollständig belegt oder treten während üblicher Jobs Fehler auf, muss zuerst der verursachende Prozess geprüft werden. Ein größeres Paket verdeckt sonst möglicherweise eine fehlerhafte Aufgabe.
NVMe-Speicher und Kapazität
NVMe bezeichnet schnellen Flash-Speicher über eine für geringe Latenzen ausgelegte Schnittstelle. Für WordPress kann das bei Datenbankzugriffen, Updates und Backups helfen. Die benötigte Kapazität setzt sich jedoch nicht nur aus der Mediathek zusammen. Betriebssystem, Protokolle, Datenbank, temporäre Dateien, lokale Sicherungen und Arbeitsraum für Updates benötigen ebenfalls Platz.
Miss das monatliche Wachstum der belegten Datenmenge über mehrere Abrechnungszeiträume. Für eine Planungsperiode kannst Du rechnen:
erwarteter Speicherbedarf = heutige Belegung + (monatliches Wachstum × Planungsmonate) + Betriebsreserve
Bei beispielhaft 14 GB heutiger Belegung, 0,8 GB Wachstum pro Monat, zwölf Planungsmonaten und 8 GB Reserve ergibt sich:
14 GB + (0,8 GB pro Monat × 12 Monate) + 8 GB = 31,6 GB
Das Ergebnis beschreibt den nutzbaren Bedarf des Szenarios, nicht die passende beworbene Tarifgröße. Externe Backups sollten außerdem nicht ausschließlich auf demselben Server liegen; ihr Speicherbedarf und ihre Übertragungskosten sind separat zu betrachten.
Wachstum mit Messpunkten statt Bauchgefühl planen
Ein Server muss nicht schon am ersten Tag die theoretische Reichweite mehrerer Jahre abdecken. Sinnvoller ist eine moderate Reserve zusammen mit klaren Auslösern für die nächste Stufe. Prüfe zunächst, ob der Anbieter CPU, RAM oder Speicher ohne vollständigen Plattformwechsel vergrößern kann und ob eine Verkleinerung ebenfalls möglich ist. Gerade zusätzlicher Speicher lässt sich technisch nicht bei jeder Plattform wieder zurücknehmen.
- Erfasse monatliche Seitenaufrufe und die aktivste Stunde, nicht nur Besucher.
- Miss Antwortzeiten für öffentliche Seiten sowie eine nicht gecachte Anfrage getrennt.
- Beobachte CPU, RAM, Speicherbelegung und Datenbanklast während normaler Nutzung und während Backups oder Updates.
- Notiere Cache-Treffer, sofern die Hosting-Plattform diese Kennzahl bereitstellt.
- Lege vor dem Tarifwechsel fest, welches Signal eine Aufrüstung auslöst: wiederkehrende Auslastung, Speicherknappheit oder nachgewiesene Warteschlangen bei dynamischen Anfragen.
Wenn nur einzelne Kampagnen hohe Spitzen erzeugen, sind Cache, CDN und die zeitliche Planung von Hintergrundjobs oft wirtschaftlicher als dauerhaft ungenutzte Serverleistung. Steigt dagegen die dynamische Grundlast über Wochen, ist mehr CPU- oder RAM-Kapazität eher gerechtfertigt. Bei wachsender Mediathek kann externer Objektspeicher eine Alternative zur bloßen Vergrößerung des Systemlaufwerks sein, sofern WordPress und die verwendeten Erweiterungen dafür passend eingerichtet werden können.
Gesamtkosten über denselben Zeitraum vergleichen
Der sichtbare Monatsbetrag ist nur eine Position. Berücksichtige beim Vergleich den regulären Folgepreis, Umsatzsteuer, Einrichtungsgebühr, Backups, zusätzliche IPv4-Adresse, Verwaltungsleistung, Lizenzen und Deine eigene Arbeitszeit. Eine IPv4-Adresse ist eine öffentlich erreichbare Netzwerkadresse; sie kann je nach Angebot eingeschlossen oder gesondert berechnet werden.
Für einen Vergleich über zwölf Monate eignet sich dieses Schema:
effektive Monatskosten = (Grundpreise im Zeitraum + einmalige Gebühren + Zusatzleistungen + bewerteter Verwaltungsaufwand) ÷ 12 Monate
Ein rein hypothetischer Vergleich zeigt die Methode. Variante A koste 8 Euro pro Monat, erfordere Zusatzleistungen für 3 Euro pro Monat und verursache einmalig 18 Euro. Variante B koste 19 Euro pro Monat und schließe die benötigten Zusatzleistungen ein. Alle Beträge werden im Beispiel als Bruttowerte behandelt:
Variante A: ((8 Euro × 12) + (3 Euro × 12) + 18 Euro) ÷ 12 = 12,50 Euro pro Monat
Variante B: (19 Euro × 12) ÷ 12 = 19 Euro pro Monat
Variante A bleibt in diesem Szenario beim Geldbetrag günstiger. Benötigt sie jedoch monatlich zwei Stunden eigener Administration und Variante B übernimmt genau diese Arbeiten vertraglich, ist der reine Preisvergleich unvollständig. Umgekehrt rechtfertigt die Bezeichnung Managed keinen Aufpreis, wenn der Leistungsumfang lediglich das Betriebssystem abdeckt, während WordPress, Plugins, Wiederherstellung und Leistungsanalyse bei Dir verbleiben. Prüfe auf der Tarifseite und in der Leistungsbeschreibung ausdrücklich, welche Ebene betreut wird.
Eine belastbare Erstwahl für den kleinen Blog
Wähle Shared Hosting, wenn Dein Blog überwiegend öffentliche, cachebare Beiträge enthält, Du keine Serveradministration übernehmen möchtest und der Tarif nachvollziehbare Grenzen sowie einen gangbaren Wechselpfad bietet. Ein selbst verwalteter VPS passt, wenn Du Betriebssystem und Dienste sicher warten kannst, eigene Konfigurationen brauchst und den Zeitaufwand bewusst einrechnest. Ein Managed VPS wird interessant, wenn getrennte Ressourcen oder besondere Servereinstellungen nötig sind, die vereinbarte Betreuung aber tatsächlich Updates, Überwachung, Störungsbehebung oder Wiederherstellung in dem von Dir benötigten Umfang umfasst.
Eine Aufrüstung sollte auf Messwerten beruhen: wiederkehrende Engpässe während realer Spitzen, fehlender Speicher trotz Bereinigung oder anhaltend langsame dynamische Anfragen. Bleiben CPU und RAM entspannt, während nur eine einzelne Seite langsam ist, liegt die Ursache eher bei dieser Seite, einem Plugin, einer Datenbankabfrage oder einem externen Dienst als bei der Servergröße. So wächst die Infrastruktur mit dem WordPress-Blog, ohne dass Du jahrelang ungenutzte Kapazität bezahlst.
