Die meisten Ratschläge zur Leistung konzentrieren sich darauf, was passiert, wenn der Traffic in die Höhe schießt, z. B. Kapazitätsplanung, Cache-Aufwärmen und Skalierung. Bei den meisten WordPress-Websites verläuft die Geschichte jedoch in die andere Richtung: eine Phase, in der der Datentraffic nach dem Ende einer Kampagne, einem saisonalen Höhepunkt oder einer Produkteinführung wieder abnimmt.

Wenn der Traffic sinkt, könntest du annehmen, dass sich deine Hosting-Situation verbessert, weil deine Ressourcen weniger beansprucht werden. In der Praxis kann das Gegenteil der Fall sein. Wenn du verstehst, warum das so ist, erfährst du viel darüber, wie die meisten Hosting-Umgebungen tatsächlich funktionieren.

Warum die Hosting-Leistung nicht von deinem Datentraffic abhängen sollte

Für den Endnutzer bietet Shared Hosting oft ein besseres Preis-Leistungs-Verhältnis, birgt aber auch ein höheres Risiko für Sicherheitsprobleme und unbeständige Leistung. Die Versuchung für einen Shared-Hosting-Anbieter besteht darin, den Serverplatz aufzuteilen, um so viele Einnahmen wie möglich zu erzielen.

Ein gängiger Ansatz ist das „Overselling“ Dies geschieht, wenn ein Anbieter den Kunden mehr Ressourcen zuweist, als auf dem Server physisch vorhanden sind. Das funktioniert ähnlich wie bei Banken: Sie erwirtschaften Zinsen, indem sie das von anderen Kunden eingezahlte Geld verleihen. Das System funktioniert, solange nicht jeder versucht, sein Geld auf einmal abzuheben.

In Shared-Hosting-Umgebungen befinden sich Hunderte oder Tausende von Websites auf demselben physischen Server, so dass bei steigender Nachfrage oft nicht mehr genügend Ressourcen zur Verfügung stehen.

Hier kommt die „dynamische Ressourcenzuweisung“ ins Spiel, bei der aktive Websites gegenüber ruhigen bevorzugt werden. Je höher die Besucherzahlen deiner Website sind, desto mehr Ressourcen erhält sie, im Gegensatz zu Websites mit weniger Besuchern. Das Modell priorisiert Websites mit hohem Traffic, während diejenigen mit geringerem Traffic weniger Ressourcen zugewiesen werden.

Das liegt aber nicht an einem Stufenplan. Der Server entscheidet einfach in Echtzeit, wohin er die verfügbaren Ressourcen lenkt. Die Leistung ist nicht mehr von der Infrastruktur, sondern vom Traffic abhängig.

Der Kinsta-Kunde Cosmick Media erlebte ähnliche Symptome. Die Agentur hatte bei ihren vorherigen Hosting-Anbietern mit zeitweiligen Ausfällen und Problemen mit der Ladegeschwindigkeit zu kämpfen. Diese Probleme traten erst auf, als das Team seinen Kundenstamm vergrößerte und die Ressourcengrenzen der gemeinsam genutzten Infrastruktur immer schwerer zu ignorieren waren.

Die versteckte Drosselung, die während des normalen Betriebs auftritt

Die Drosselung beim Shared Hosting kann verschiedene Formen annehmen und erklärt, wie die Ressourcen zwischen den Websites aufgeteilt werden:

  • CPU-Limits begrenzen die Rechenleistung, die eine Website zu einem bestimmten Zeitpunkt nutzen kann.
  • Die RAM-Zuweisung begrenzt, wie viel Speicher eine Website nutzen kann.
  • E/A-Beschränkungen regeln, wie schnell eine Website von der Festplatte liest und auf sie schreibt.

Wenn der Datentraffic hoch ist, verbraucht deine Website in der Regel mehr der verfügbaren Ressourcen. Wenn die Aktivität nachlässt, werden diese gemeinsam genutzten Ressourcen schnell von anderen Websites auf dem Server genutzt. Die sichtbare Konsequenz ist eine Verschlechterung des Frontends, aber die weniger sichtbare (und oft schädlichere) Konsequenz ist das, was mit den Hintergrundoperationen passiert.

WP-Cron löst Hintergrundaufgaben wie die Optimierung der Datenbank, die Überprüfung von Plugin-Updates, geplante Veröffentlichungen und vorübergehende Aufräumarbeiten in WordPress aus. Diese Aufgaben laufen im Hintergrund, konkurrieren aber trotzdem um die gleichen gedrosselten Ressourcen. Auf einem überlasteten Server werden sie unzuverlässig – sie laufen zu spät, fallen stillschweigend aus oder laufen überhaupt nicht.

Die Leistung wird mit der Zeit immer schlechter

Die wirklichen Kosten der Drosselung sind kumulativ, wobei jede verpasste Aufgabe die nächste nach sich zieht:

  • Verpasste Datenbankoptimierungsfenster tragen dazu bei, dass die Abfragen bei jeder weiteren Anfrage langsamer werden.
  • Fehlgeschlagene Hintergrundaufgaben hinterlassen Lücken im Wartungszyklus, die nicht automatisch wieder geschlossen werden, wenn sich der Traffic erholt.
  • Langsame Verwaltungsvorgänge verzögern die routinemäßigen Wartungsarbeiten (Plugin-Updates, Inhaltsänderungen und Konfigurationsaufgaben), die eine WordPress-Website stabil und sicher halten.

Beitragsrevisionen, Transienten und automatisch geladene Optionen werden alle in der WordPress-Datenbank gespeichert. Ohne regelmäßige Optimierung werden die Tabellen größer und die Abfragen langsamer. Auf einem Server mit gleichbleibenden Ressourcen läuft die Bereinigung nach Plan. Auf einem gedrosselten Shared Server wird sie jedoch nur ausgeführt, wenn genügend Ressourcen verfügbar sind. In Zeiten mit geringem Datentraffic werden diese Bereinigungsaufgaben möglicherweise viel seltener ausgeführt.

Das Ergebnis ist eine Rückkopplungsschleife, in der eine Verschlechterung der Leistung die Wartung erschwert, was zu einer weniger gesunden Website führt. Diese Leistungsverschlechterung kann den Rückgang des organischen Trafficstr durch langsameres Laden der Websites und schwächere Core Web Vitals-Werte beschleunigen.

Wie die Container-Architektur von Kinsta die trafficabhängige Leistung eliminiert

Jede WordPress-Website auf Kinsta wird in einem isolierten Linux-Container ausgeführt und teilt sich ihre Zuweisung nicht mit anderen Websites auf der Plattform. Es gibt auch keine Prioritäts-Warteschlangen, die bestimmen, welche Websites mehr Ressourcen erhalten.

Eine Website, die nach einer Kampagnenspitze heruntergefahren wird, läuft mit denselben Ressourcen weiter, die sie während dieser Spitze hatte. Die Infrastruktur teilt die Ressourcen nicht neu zu, wenn die Besucherzahlen sinken.

Das ist wichtig, weil höhere Kinsta-Tiers zwar mehr monatliche Besucher/innen aufnehmen können, aber alle auf demselben isolierten Containermodell und mit denselben Ressourcengarantien laufen. Die Pläne bestimmen stattdessen die Kapazitätsgrenzen, wie z. B. die monatliche Bandbreite/Besuche und die verfügbaren Ressourcen. Dies beeinflusst auch, wie Kinsta PHP-Threads verwendet, um die Gesamtleistung deiner Website zu verbessern.

Insbesondere für WP-Cron bedeutet dies, dass geplante Aufgaben gleichbleibende Ressourcen zur Verfügung haben, um zuverlässig zu laufen. Die technischen Schulden, die sich in gedrosselten Umgebungen ansammeln (z. B. verpasste Aufräumarbeiten, fehlgeschlagene Hintergrundaufgaben, aufgeblähte Tabellen usw.), bauen sich hier nicht auf, da die Ressourcen, die zur Vermeidung dieser Probleme benötigt werden, durchgängig verfügbar sind.

Das mehrschichtige Caching funktioniert bei hohem und niedrigem Datentraffic identisch

Der Caching-Stack von Kinsta besteht aus vier Schichten, die unabhängig von deinem Traffic-Volumen arbeiten. Zusammen reduzieren sie die Arbeit, die dein Container leisten muss, und halten Ressourcen für Verwaltungsvorgänge und Hintergrundaufgaben frei:

  • Edge Caching bedient deine Website direkt aus dem globalen Netzwerk von Cloudflare, bevor eine Anfrage deinen Ursprungsserver erreicht. Die Trefferquote im Cache bleibt sowohl bei Spitzenbelastungen als auch in ruhigeren Zeiten hoch. Im Cache gespeicherte Seiten laufen nicht ab, nur weil der Traffic nachlässt, so dass eine Website nach einer Kampagne weiterhin vom Edge aus bedient wird, genau wie zu Spitzenzeiten.
  • Das Caching auf Serverebene bearbeitet dynamische Anfragen, die den Edge umgehen, und reduziert so die Datenbanklast am Ursprung. Für Websites, bei denen eingeloggte Nutzer oder dynamische Inhalte ein Full-Page-Caching am Edge verhindern, hält diese Schicht die Antwortzeiten vorhersehbar.
  • Das Kinsta CDN stellt statische Inhalte (Bilder, CSS, JavaScript und Schriftarten) von verteilten Edge-Standorten aus bereit. Sie werden unabhängig vom Anfragevolumen mit der gleichen Geschwindigkeit ausgeliefert, so dass sie nicht in deinem Container landen.

Außerdem solltest du das Redis-Objekt-Caching von Kinsta mit niedriger Latenzzeit nicht übersehen. Es speichert die Ergebnisse von Datenbankabfragen im Speicher, damit WordPress nicht bei jedem Seitenaufruf dieselben Abfragen wiederholt. Für inhaltslastige Websites, WooCommerce-Shops und Mitgliederplattformen, bei denen dieselben Abfragen wiederholt ausgeführt werden, bedeutet dies schnellere Antworten und eine geringere Datenbankbelastung.

Warum Premium-Hosting für stabilen Traffic sinnvoll ist

Die Annahme, dass ein geringerer Traffic ein Downgrade des Hostings rechtfertigt, betrachtet die Infrastruktur als ein Skalierungsinstrument, das du für Spitzenzeiten erweiterst und in ruhigen Zeiten reduzierst. Dabei wird jedoch übersehen, was das Hosting einer WordPress-Website in den Zeiten zwischen den Kampagnen bewirkt.

Viele Hosting-Angebote basieren auf dem Traffic-Volumen, aber Traffic-Volumen und Qualität der Infrastruktur sind zwei verschiedene Dinge. Eine Website, die in der Zeit nach einer Kampagne weniger besucht wird, braucht trotzdem eine zuverlässige Infrastruktur, damit die Wartung läuft, die Verwaltungstools ansprechbar sind und die Hintergrundaufgaben pünktlich ausgeführt werden.

Die Komplexität von WordPress-Anwendungen nimmt nicht mit dem Traffic ab

Aufgaben wie der Betrieb von Plugins, die Wartung von Datenbanken, Sicherheitsscans und geplante Veröffentlichungen machen während einer ruhigen Phase keine Pause. Überlege dir, was eine Agentur braucht, die eine Kundenseite zwischen den Kampagnen verwaltet:

  • Staging-Umgebungen, die die Produktionsumgebung so genau widerspiegeln, dass Probleme vor dem Einsatz erkannt werden.
  • SSH- und WP-CLI-Zugang für Datenbankoperationen, Plugin-Management und eigene Skripte.
  • Admin-Reaktionszeiten, die auch bei der Bearbeitung von Inhalten und der Verwaltung der Website eingehalten werden.
  • Geplante Backups und Sicherheitsscans, die pünktlich abgeschlossen werden.

Wenn du Entwicklungs-Workflows durchführst, ist eine zuverlässige Hosting-Leistung erforderlich, um Änderungen von Staging auf Live zu übertragen, Plugin-Updates durchzuführen und Datenbankmigrationen vorzunehmen. Wenn du in einem ruhigen Monat an einer Kundenwebsite arbeitest, müssen die Bereitstellungsprozesse und Staging-Umgebungen immer noch dieselbe Leistung erbringen.

Für eine Agentur, die mehrere Kunden-Websites in unterschiedlichen Phasen des Traffic-Zyklus verwaltet, kann eine gemeinsam genutzte Infrastruktur dazu führen, dass die ruhigeren Websites schwieriger zu verwalten sind, weil der Server die Ressourcen auf die geschäftigeren Websites umleitet. In einer isolierten Container-Infrastruktur verhält sich jede Website gleich, unabhängig davon, was die anderen tun.

Konsistente Leistung ermöglicht eine sichere langfristige Planung

Kurz gesagt, eine vorhersehbare Infrastruktur verändert die Art und Weise, wie du arbeiten kannst. Wenn du weißt, dass Wartungsaufgaben zuverlässig erledigt werden, WP-Cron pünktlich feuert und die Verwaltungsvorgänge konsistent reagieren, wird die Planung einfacher. Das hat mehrere praktische Vorteile:

  • Geringerer Aufwand für den Support, da Leistungsprobleme, die auf Ressourcenproblemen beruhen, nicht zu Support-Tickets führen, die untersucht werden müssen.
  • Zuverlässigere Planungszyklen, weil du das Risiko einer Hosting-Umgebung, die sich in ruhigen Monaten anders verhält, nicht einkalkulieren musst.
  • Weniger Infrastruktur-Raterei bei der Auswahl des Hostings auf der Grundlage von Traffic-Mustern. Upgrades für Kampagnen und Downgrades danach bringen bei jedem Übergang Risiken und Verwaltungsaufwand mit sich.

Dieser letzte Punkt ist es wert, näher betrachtet zu werden. Ein Hosting, das ein aktives Management auf der Grundlage von Traffic-Trends erfordert, arbeitet gegen deine Planung, anstatt sie zu unterstützen. Eine Website sollte in der Lage sein, in eine ruhige Phase einzutreten, ohne dass sich die Art des Hostings ändert, und aus dieser Phase in demselben Zustand herauszukommen, in dem sie sie verlassen hat.

Die Hosting-Infrastruktur sollte das Geschäftswachstum unterstützen, nicht mit Traffickurven schwanken

Das Muster, das WordPress-Websites während eines Rückgangs des Datentraffics schadet, ist nicht kompliziert. Eine überlastete Infrastruktur gibt ruhigeren Websites den Vorrang, Hintergrundaufgaben geraten ins Hintertreffen und mit der Zeit sammeln sich technische Schulden an.

Ein Hosting-Modell, das Zeiten mit geringerem Traffic als Grund für eine Reduzierung der verfügbaren Ressourcen ansieht, schadet letztlich den Websites, die es unterstützen soll.

Wenn du dein aktuelles Hosting-Modell überprüfst, solltest du Fragen stellen. Können zum Beispiel Hintergrundaufgaben in ruhigen Zeiten zuverlässig ausgeführt werden? Bleiben deine Verwaltungstools reaktionsfähig, wenn der Traffic nachlässt? Ganz allgemein solltest du dich fragen, ob das Ressourcenmodell deines Hosting-Anbieters eine Flaute nach einer Kampagne genauso behandelt wie einen Trafficspike oder ob deine Tarifstufe stillschweigend bestimmt, wie viel des Servers du nutzen darfst.

Das verwaltete WordPress-Hosting von Kinsta basiert auf isolierten Containern, einem mehrschichtigen Caching-Stack und dedizierten Ressourcen, die nicht vom Traffic abhängig sind. Das bedeutet, dass deine Website am Ende einer Kampagne die gleiche Leistung erbringt wie zu Spitzenzeiten.

Möchtest du Fragen stellen? Du kannst dich jederzeit an unser Team wenden.

Joel Olawanle Kinsta

Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.