Die meisten Hosting-Anbieter sprechen von Geschwindigkeit in Durchschnittswerten. Durchschnittliche Antwortzeit. Durchschnittliche Ladezeit. Durchschnittliche Benchmark-Ergebnisse. Aber echte Besucher erleben keine Durchschnittswerte. Sie erleben die Seite, die gerade vor ihnen liegt – auf ihrem Gerät, über ihre Verbindung, in genau diesem Moment.
Eine Website mag in einem Geschwindigkeitstest großartig abschneiden und sich dennoch langsam anfühlen, wenn ein Käufer zur Kasse schreitet, sich ein Mitglied anmeldet, ein Formular abgeschickt wird oder der Traffic plötzlich ansteigt. Diese langsameren Momente betreffen vielleicht nur einen kleinen Prozentsatz der Besuche, aber oft sind es gerade diese, die am wichtigsten sind.
Deshalb verdient die Leistungskonstanz mehr Aufmerksamkeit. Spitzengeschwindigkeit ist nützlich, aber erst eine vorhersehbare Geschwindigkeit sorgt für ein reibungsloseres Nutzererlebnis.
Bei WordPress-Websites, besonders solchen mit E-Commerce, Mitgliedschaften, LMS-Funktionen, Admin-Aktivitäten oder unvorhersehbaren Traffic-Mustern, lautet die eigentliche Frage nicht nur: „Wie schnell kann diese Website sein?“, sondern: „Wie oft bleibt sie schnell?“
Das Problem mit Leistungsangaben auf Basis von Durchschnittswerten
Die Durchschnittsgeschwindigkeit lässt sich leicht bewerben, da sie eine Vielzahl von Aktivitäten in einer einzigen einfachen Zahl zusammenfasst. Sie bietet Teams eine übersichtliche Grundlage für Vergleiche, Berichte und Marketing.
Doch Durchschnittswerte können auch genau die Probleme verbergen, an die sich deine Besucher am ehesten erinnern.
Beispielsweise könnte eine Seite für die meisten Nutzer schnell laden, bei einer Handvoll Nutzern jedoch stark langsamer werden. Sobald diese schnellen und langsamen Besuche miteinander vermischt werden, kann der endgültige Durchschnittswert immer noch akzeptabel aussehen. Auf dem Papier scheint die Leistung in Ordnung zu sein. In der Praxis müssen einige Nutzer jedoch endlos warten.
Das ist wichtig, weil langsame Ladezeiten selten gleichmäßig verteilt sind. Sie treten oft unter bestimmten Bedingungen auf, wie zum Beispiel:
- Traffic-Spitzen
- Cache-Fehlgriffe
- Angemeldete Sitzungen
- Kassenvorgänge
- Suchanfragen
- Formularübermittlungen
- Backend-Verwaltungsaufgaben
- Bot-Traffic
- Datenbankintensive Anfragen
Ein Geschwindigkeitstest der Startseite deckt diese Probleme möglicherweise nie auf. Genauso wenig wie eine einzelne durchschnittliche Antwortzeit. Du könntest eine Website haben, die in einem Monatsbericht schnell erscheint, während ein Teil der Besucher regelmäßig in entscheidenden Momenten Verzögerungen erlebt.
Und bei WordPress-Websites sind diese wichtigen Momente oft mit dynamischen Vorgängen verbunden, wie zum Beispiel einem WooCommerce-Warenkorb, einem Mitglieder-Dashboard, einer LMS-Lektion oder einer gefilterten Produktsuche.
Deine Geschwindigkeitstests sehen vielleicht gut aus, aber das ist nicht das ganze Bild
Geschwindigkeitstests sind nützlich. Sie können offensichtliche Leistungsprobleme aufzeigen, Teams dabei helfen, Verbesserungen nachzuverfolgen, und dir eine Vergleichsgrundlage liefern.
Aber sie sind immer noch nur eine Momentaufnahme.
Die meisten synthetischen Tests messen eine einzelne Seite, von einem einzigen Standort aus, zu einem einzigen Zeitpunkt. Je nachdem, wie der Test konfiguriert ist, misst er möglicherweise auch eine „saubere“, zwischengespeicherte Version der Seite unter idealen Bedingungen. Das kann für kontrollierte Tests hilfreich sein, spiegelt aber nicht immer wider, was echte Nutzer erleben.
Bei echten Besuchern spielen mehr Variablen eine Rolle. Sie nutzen unterschiedliche Geräte, Browser, Netzwerke und Standorte. Manche sehen zwischengespeicherte Seiten. Andere lösen nicht zwischengespeicherte oder teilweise zwischengespeicherte Anfragen aus. Manche sind angemeldet. Andere legen Produkte in den Warenkorb, senden ein Formular ab, durchsuchen einen Katalog oder klicken zur Kasse.
Diese Interaktionen können ganz unterschiedliche Anforderungen an eine WordPress-Website stellen.
Ein synthetischer Test sagt dir vielleicht, dass deine Startseite schnell lädt. Er sagt dir aber möglicherweise nicht, ob dein Bestellvorgang während einer Werbeaktion reaktionsschnell bleibt, ob angemeldete Mitglieder reibungslos durch ihr Benutzer-Dashboard navigieren können oder ob eine suchintensive Produktseite langsamer wird, wenn der Traffic steigt.
Das ist ein Grund, warum die Aussage „Unsere Geschwindigkeitstests sehen gut aus“ irreführend sein kann. Die Tests mögen für das, was sie gemessen haben, zutreffend sein. Sie erfassen jedoch nicht jede Erfahrung, auf die es ankommt.
Warum die p95- und p99-Leistung wichtig sind
Während Durchschnittswerte den Mittelwert widerspiegeln, zeigen Perzentile die Extreme auf.
Leistungsperzentile helfen dir zu verstehen, was langsamere Besucher erleben – und nicht nur, wie ein typischer Besuch aussieht. Anstatt alle Anfragen zu einer einzigen Zahl zu verdichten, zeigen sie, wie die Leistung bei verschiedenen Nutzergruppen variiert.
Die p95-Leistung steht zum Beispiel für die langsamsten 5 % der Nutzererfahrungen. Wenn deine p95-Ladezeit hoch ist, bedeutet das, dass 5 von 100 Besuchen spürbar langsamer sind als der Rest. p99 geht noch einen Schritt weiter und zeigt das langsamste 1 % der Nutzererfahrungen.
Das klingt vielleicht nach einem kleinen Teil des Traffics. Aber auf einer stark frequentierten Website summiert sich das schnell.
Wenn deine Website monatlich 100.000 Besuche verzeichnet, könnte ein langsames p95-Erlebnis Tausende von Sitzungen beeinträchtigen. Wenn diese Sitzungen während des Bezahlvorgangs, der Kontoanmeldung, der Lead-Generierung oder der Produktsuche stattfinden, können die geschäftlichen Auswirkungen viel größer sein, als der Prozentsatz vermuten lässt.
Perzentile sind besonders nützlich, weil sie Muster aufdecken, die durch Durchschnittswerte verdeckt werden können. Eine Website kann eine angemessene durchschnittliche Antwortzeit aufweisen und dennoch Nutzern, die von Traffic-Spitzen, Cache-Fehlern, datenbankintensiven Anfragen oder nicht zwischengespeicherten E-Commerce-Abläufen betroffen sind, ein schlechtes Erlebnis bieten.
Für technische Teams bieten die p95- und p99-Kennzahlen eine realistischere Möglichkeit, die Hosting-Leistung zu bewerten. Sie helfen bei der Beantwortung von Fragen wie:
- Wie oft wird die Website langsamer?
- Wie schlimm werden die langsamsten Anfragen?
- Bleiben dynamische Seiten reaktionsschnell?
- Bleibt die Leistung auch bei höherem Datentraffic stabil?
- Beeinträchtigen eine kleine Anzahl langsamer Anfragen wichtige Nutzerpfade?
Diese Zahlen ersetzen zwar nicht die Durchschnittsgeschwindigkeit, geben ihr aber einen Kontext. Eine hohe Durchschnittsgeschwindigkeit ist schön zu haben. Stabile p95- und p99-Werte zeigen dir, ob diese Geschwindigkeit auch bei den Nutzern ankommt, die es am ehesten bemerken, wenn sie ausbleibt.
Was verursacht eine schwankende WordPress-Leistung?
Die WordPress-Leistung lässt sich meist nicht auf ein einziges Problem zurückführen. Es kommt auf die Auslastung an.
Eine einfache zwischengespeicherte Seite und eine dynamische Checkout-Anfrage können auf derselben Website liegen, stellen aber ganz unterschiedliche Anforderungen an den Server. Wenn das Hosting eine Art von Anfrage gut bewältigen kann, mit der anderen aber Probleme hat, wirkt die Leistung ungleichmäßig.
Zwischengespeicherte Seiten sind der einfache Teil
Durch Caching kann WordPress extrem schnell werden. Wenn jemand eine zwischengespeicherte Startseite, einen Blogbeitrag oder eine Landingpage besucht, kann der Server oft eine gespeicherte Version dieser Seite ausliefern, anstatt sie von Grund auf neu zu erstellen. Das bedeutet weniger Arbeit für PHP, weniger Datenbankabfragen und schnellere Antwortzeiten für Besucher.
Deshalb kann eine Website bei einem Geschwindigkeitstest für die Startseite hervorragend abschneiden. Die Seite ist vielleicht schlank, zwischengespeichert und leicht bereitzustellen.
Aber viele der Momente, auf die es bei WordPress am meisten ankommt, funktionieren nicht so.
Dynamische Seiten benötigen mehr Serverressourcen
WooCommerce-Warenkorb- und Checkout-Seiten können sich in der Regel nicht auf dasselbe Vollseiten-Caching verlassen wie ein öffentlicher Blogbeitrag. Der Inhalt ändert sich je nach dem einzelnen Käufer, dem Warenkorbinhalt, den Versanddetails, Steuern, Gutscheinen, Zahlungsoptionen und Sitzungsdaten.
Das Gleiche gilt für:
- Seiten für angemeldete Benutzer
- Mitglieder-Dashboards
- LMS-Lektionen und Fortschrittsverfolgung
- Personalisierte Inhalte
- Produktfilter und interne Suche
- Formularübermittlungen
- Admin-Seiten und redaktionelle Arbeitsabläufe
Diese Anfragen erfordern oft PHP-Threads, Datenbankabfragen, Plugin-Logik und manchmal auch Dienste von Drittanbietern, bevor WordPress eine Antwort zurückgeben kann.
Genau hier treten oft Unstimmigkeiten auf. Ein Besucher, der einen zwischengespeicherten Artikel liest, erhält vielleicht eine schnelle Antwort. Ein anderer Besucher, der seinen Warenkorb aktualisiert oder ein Formular absendet, stößt vielleicht Sekunden später auf eine viel aufwendigere Anfrage.
Plugins, Themes und Aufrufe von Drittanbietern können zu ungleichmäßigen Verlangsamungen führen
Plugins und Themes können es zudem schwieriger machen, die Leistung vorherzusagen.
Ein Plugin könnte Datenbankabfragen auf Produktseiten hinzufügen. Ein Theme könnte zusätzliche Skripte auf der gesamten Website laden. Ein Formular-Plugin könnte beim Absenden einen externen Dienst aufrufen. Eine Integration für Versand, Steuern, CRM, Analysen oder Zahlungen könnte an einer Stelle der User Journey zusätzliche Wartezeit verursachen.
Diese Probleme betreffen nicht immer jede Seite. Die Startseite fühlt sich vielleicht immer noch schnell an, während der Checkout, die Suche, die Kontoseiten oder der WordPress-Adminbereich langsamer werden.
Das macht es frustrierend, eine uneinheitliche Leistung zu bewerten. Eine Website ist nicht einfach „schnell“ oder „langsam“. Es hängt davon ab, was der Besucher gerade tut.
Hintergrundaufgaben können mit dem Live-Traffic konkurrieren
WordPress-Websites sind auch dann ausgelastet, wenn Besucher nicht gerade herumklicken. Produktimporte, geplante Beiträge, Backups, Plugin-Updates, Sicherheitsscans, Analyseaufträge, E-Mail-Synchronisierungen, Berichtstools und Admin-Aktivitäten beanspruchen alle Ressourcen. Auf einer ruhigen Website laufen diese Aufgaben vielleicht unbemerkt ab. In Stoßzeiten können sie jedoch mit dem Live-Traffic konkurrieren.
Ein WooCommerce-Shop könnte zum Beispiel eine Bestandsabgleichung durchführen, während Käufer Produkte durchstöbern und den Bestellvorgang durchlaufen. Eine Mitglieder-Website könnte E-Mail-Automatisierungen verarbeiten, während angemeldete Nutzer Kursseiten laden. Eine Content-Website könnte Backups durchführen, während Redakteure im Dashboard arbeiten.
Jede Aufgabe mag für sich genommen sinnvoll sein. Zusammen können sie jedoch die Ladezeiten in die Höhe treiben.
Traffic-Spitzen und Bots erhöhen den Druck schnell
Der Traffic verläuft selten in einer perfekt gleichmäßigen Linie. Ein Sale, ein Newsletter, eine Werbekampagne, ein Social-Media-Beitrag, eine Produkteinführung oder eine Erwähnung in der Presse können einen schnellen Ansturm von Besuchern auf die Website auslösen. Bot-Traffic kann denselben Effekt auslösen, oft ohne Vorwarnung. Im Gegensatz zu einem werbebedingten Anstieg steht er in keinem Zusammenhang mit geschäftlichen Aktivitäten, anhand derer du ihn vorhersehen könntest.
Die Auswirkungen auf die Infrastruktur hängen davon ab, wo die Bots landen. Ein Bot, der auf zwischengespeicherte Seiten zugreift, verursacht relativ wenig Belastung. Ein Bot, der dynamische Endpunkte wie Warenkorbseiten, gefilterte Produkt-URLs oder Suchanfragen mit Parametern aufruft, beansprucht bei jeder einzelnen Anfrage dieselben Serverressourcen wie ein echter Besucher. In großem Maßstab kann diese Art von automatisiertem Traffic die PHP-Kapazität erschöpfen und die Antwortzeiten für legitime Nutzer verlangsamen, selbst wenn sich an der Website selbst nichts geändert hat.
Wenn der Großteil des eingehenden Datentraffics auf zwischengespeicherte Seiten trifft, kann die Website die Belastung gut bewältigen. Wenn jedoch Bots oder ein Traffic-Anstieg das Volumen über nicht zwischengespeicherte dynamische Endpunkte leiten, ändert sich die Auslastung schnell – und die Antwortzeiten folgen diesem Trend.
Gemeinsam genutzte Ressourcen können die Leistungsanalyse erschweren
Gemeinsam genutzte Infrastruktur sorgt für eine weitere Ebene der Ungewissheit. Wenn mehrere Websites um dieselbe zugrunde liegende CPU und denselben Arbeitsspeicher konkurrieren, kann die Aktivität einer Website die Leistung einer anderen beeinträchtigen. Deine WordPress-Website hat sich vielleicht gar nicht verändert. Deine Plugins wurden vielleicht gar nicht aktualisiert. Dein Traffic sieht vielleicht ganz normal aus. Aber wenn der Ressourcenkonflikt rund um deine Website zunimmt, kann sie trotzdem langsamer werden.
Diese Unvorhersehbarkeit erschwert die Fehlersuche. Du kannst die Website selbst optimieren und trotzdem aufgrund der umgebenden Bedingungen auf Leistungseinbußen stoßen.
Warum Beständigkeit wichtiger ist als Spitzengeschwindigkeit
Spitzengeschwindigkeit sorgt für eine gute Schlagzeile. Sie kann zeigen, wozu eine Hosting-Umgebung unter den richtigen Bedingungen fähig ist.
Aber Nutzer beurteilen eine Website nicht anhand ihres besten Moments. Sie beurteilen sie anhand des Besuchs, den sie tatsächlich haben.
Eine Startseite, die in einem Test schnell lädt, garantiert noch lange kein reibungsloses Checkout-Erlebnis. Eine zwischengespeicherte Landingpage sagt nichts darüber aus, wie sich Suchanfragen, Anmeldungen, Warenkorb-Aktualisierungen oder Formularübermittlungen verhalten, wenn die Website unter Last steht. Und ein schnelles Ergebnis von einem Standort zu einem bestimmten Zeitpunkt beweist nicht, dass die Leistung den ganzen Tag über konstant bleibt.
Beständigkeit ist das, was das Erlebnis zuverlässig macht.
- Für E-Commerce-Websites bedeutet das, dass Warenkorb- und Checkout-Seiten reaktionsschnell bleiben, wenn Käufer bereit sind, zu kaufen.
- Bei Mitglieder-Websites bedeutet das, dass Nutzer sich ohne Verzögerungen anmelden und auf Inhalte zugreifen können.
- Für Websites zur Lead-Generierung bedeutet es, dass Formulare reibungslos abgeschickt werden, anstatt im ungünstigsten Moment hängen zu bleiben.
Das Gleiche gilt für Agenturen und technische Teams. Eine Website, die nur unter idealen Bedingungen gut läuft, ist schwieriger zu betreuen. Das führt zu mehr Unsicherheit, mehr Fehlerbehebung und mehr unangenehmen Kundengesprächen. Vorhersehbare Leistung gibt Teams eine stabilere Grundlage, die sie überwachen, erklären und verbessern können.
Wie Kinsta eine vorhersehbare WordPress-Leistung gewährleistet
Eine konsistente Leistung beginnt bei der Hosting-Umgebung selbst. Bei Kinsta läuft jede WordPress-Website in einem eigenen, isolierten Container mit dedizierten Ressourcen, die nicht mit anderen Websites geteilt werden – auch nicht mit Websites auf demselben Konto. Diese Trennung behebt direkt das Problem, dass eine Website die Reaktionszeiten einer anderen ohne erkennbaren Grund beeinträchtigt.
Caching spielt auf zwei Ebenen eine wichtige Rolle. Edge-Caching verteilt zwischengespeicherte HTML-Inhalte über ein globales Netzwerk von Rechenzentren, liefert Seiten von Standorten aus, die nahe am jeweiligen Besucher liegen, steigert die Leistung um bis zu 40 % und umgeht PHP-Threads bei zwischenspeicherbaren Anfragen vollständig. Das setzt PHP-Kapazität für die Anfragen frei, die sie tatsächlich benötigen. Bei dynamischen Seiten, die nicht vollständig zwischengespeichert werden können, reduziert das Redis-Objekt-Caching die Datenbanklast, indem Abfrageergebnisse im Arbeitsspeicher gespeichert werden, sodass PHP die Datenbank nicht bei jeder Anfrage erneut abfragen muss.
Da Edge-Caching und Redis mehr Anfragen komplett aus dem PHP-Prozess heraushalten, stehen die verbleibenden PHP-Threads für Workloads zur Verfügung, die sie wirklich benötigen. Für Teams, die komplexe WordPress-Seiten betreiben, bietet Kinsta direkt in MyKinsta Einblick in und Kontrolle über die PHP-Leistung – besonders nützlich, wenn die Workloads nicht zwischengespeicherte WooCommerce-Websites, Mitgliederbereiche, LMS-Inhalte, Admin-Aktivitäten oder anhaltenden, ungleichmäßig verteilten Traffic umfassen.
Transparenz ist ebenfalls wichtig. Das Kinsta-APM-Tool hilft dabei, PHP-Leistungsengpässe, langsame MySQL-Abfragen, externe HTTP-Aufrufe und andere Backend-Aktivitäten zu identifizieren, die bestimmte Anfragen beeinträchtigen können. Anstatt zu raten, warum eine Checkout-Seite, ein Anmeldebildschirm oder der Kontobereich langsam ist, können Teams die Teile der Anfrage untersuchen, die am meisten Zeit in Anspruch nehmen.
Nichts davon macht eine gute Website-Architektur, sauberen Code, optimierte Plugins und sinnvolle Caching-Regeln überflüssig. Aber es gibt WordPress-Teams eine solidere Grundlage für den Umgang mit der Vielfalt des Datentraffics, den echte Websites erhalten: zwischengespeicherte Besucher, nicht zwischengespeicherte Anfragen, angemeldete Sitzungen, Admin-Arbeit und anhaltender Traffic, der nicht immer ordentlich oder gleichmäßig ankommt.
Schnelle Durchschnittswerte garantieren keine schnelle Nutzererfahrung
Die Durchschnittsgeschwindigkeit kann nützlich sein, sollte aber nicht die einzige Kennzahl sein, die deine Hosting-Entscheidungen bestimmt.
Eine Website kann in einem Benchmark schnell wirken und Nutzer dennoch frustrieren, wenn der Bezahlvorgang ins Stocken gerät, Seiten nach dem Einloggen verzögert werden, die Suche zu lange dauert oder das Absenden eines Formulars hängen bleibt.
Diese Momente ruinieren vielleicht nicht deinen durchschnittlichen Leistungswert, aber sie können die Meinung der Nutzer über deine Website prägen.
Beständigkeit ist das praktischere Ziel: WordPress-Leistung, die bei zwischengespeicherten Seiten, dynamischen Anfragen, Admin-Aktivitäten und anhaltendem Traffic gleichbleibend gut ist.
Im Durchschnitt schnell zu sein ist nicht dasselbe wie schnell für den Nutzer, der bereit ist, eine Conversion durchzuführen.
Wenn du bereit bist für ein WordPress-Hosting, das auf beständige Leistung ausgelegt ist, schau dir die Managed-WordPress-Hosting-Pakete von Kinsta an.
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.
