WordPress Benchmark: Hosting-Performance reproduzierbar testen

Was ein WordPress Benchmark beantwortet

Ein WordPress Benchmark beginnt mit einer konkreten Frage: Lädt eine bestimmte Seite unter festgelegten Bedingungen zügig? Ein Browser lädt dafür HTML, Bilder, Skripte und weitere Ressourcen und stellt die Seite dar. Das Ergebnis beschreibt das Zusammenspiel dieser Bestandteile, nicht allein die Geschwindigkeit des Hosting-Servers.

Eine zweite Frage betrifft das Antwortverhalten unter Last: Wie verändern sich Antwortzeiten und Fehler, wenn Anfragen nach einem festgelegten Profil eintreffen? Ein einzelner Seitenaufruf beantwortet das nicht. Umgekehrt zeigt ein HTTP-Lasttest nicht unmittelbar, wie schnell ein Browser die vollständige Seite sichtbar aufbaut.

Bei einem öffentlichen Blogartikel kann ein Page Cache fertiges HTML liefern; ein CDN kann Ressourcen oder Antworten näher am Messstandort bereitstellen. Zugleich beeinflussen Theme, Plugins, Bilder und externe Skripte das Ergebnis. Welche weiteren Ursachen eine Seite ausbremsen können, erklärt der Beitrag über versteckte Performance-Killer bei WordPress.

Für den Einfluss des Hostings helfen zwei Vergleichsfragen. Beim Stack-Vergleich gleichst du Website und Einstellungen möglichst an und dokumentierst verbleibende Unterschiede. Beim Paketvergleich prüfst du die angebotenen Konfigurationen einschließlich ihrer jeweiligen Caches und Dienste. Das ist für eine Kaufentscheidung praxisnah, isoliert aber nicht die reine Serverleistung.

Halte deshalb fest, welche Seite, welcher Tarif und welche Umgebung zu einem Ergebnis gehören. Ein Vorteil für den getesteten Blogartikel kann bei einer angemeldeten Kontoansicht anders ausfallen. Die Messung gilt für ihre dokumentierten Bedingungen und ihren Zeitraum; sie begründet weder einen allgemeinen Testsieger noch eine Leistungsgarantie.

Browsermessung und Felddaten verstehen

Ein WordPress Speed Test mit Lighthouse liefert eine Laboraufnahme der Seite unter bestimmten Messbedingungen. Browserprofil, Gerät beziehungsweise Emulation, Netzwerkprofil, Messstandort und Werkzeugversion gehören deshalb ins Protokoll. Nur so lässt sich später beurteilen, ob zwei Läufe tatsächlich vergleichbar sind.

Der Lighthouse-Performance-Score fasst mehrere Messgrößen gewichtet zusammen. Er kann durch wechselnde Inhalte und Messbedingungen schwanken und verdeckt, welche Einzelmetrik sich verändert hat. Wiederhole die Messung mit demselben Profil und dokumentiere die Einzelwerte aller Läufe, statt nur den besten Score auszuwählen.

Zu den wichtigen Größen gehört LCP: Es beschreibt, wann das größte relevante Inhaltselement sichtbar geladen ist. CLS erfasst unerwartete Layoutverschiebungen während der Nutzung. INP beschreibt die Reaktionsfähigkeit auf Interaktionen; es braucht dafür tatsächlich erfasste Interaktionen und ist nicht allein durch einen einfachen Seitenabruf bestimmt.

Der Chrome UX Report, kurz CrUX, liefert dagegen gegebenenfalls verfügbare Felddaten aus Besuchen teilnehmender realer Nutzer. Diese Erfahrungen hängen unter anderem von deren Geräten und Netzwerken ab. Sie sind nicht für jede Seite verfügbar und beantworten eine andere Frage als ein unter kontrollierten Bedingungen ausgeführter Laborlauf.

Kennzeichne bei jedem Wert, ob er aus dem Labor oder dem Feld stammt. Eine reine HTTP-Abfrage kann beispielsweise Status und Antwortzeit erfassen, führt aber nicht automatisch das Rendering und die Interaktionen eines Browsers aus. Aus ihr lassen sich daher LCP, CLS und INP nicht als Browsererlebnis ablesen.

Cache-Ebenen richtig unterscheiden

Ein Page Cache kann fertiges HTML für wiederholte Anfragen vorhalten. Ein Object Cache speichert dagegen Anwendungsdaten, die WordPress bei der Verarbeitung benötigt. Daneben kann der Browser bereits geladene Ressourcen lokal wiederverwenden; ein CDN kann Inhalte auf einer weiteren Ebene außerhalb des ursprünglichen Servers zwischenspeichern.

Bei einem warmen Page Cache rufst du eine öffentliche Seite nach einer dokumentierten Aufwärmphase wiederholt ab. Das ist für häufig besuchte Inhalte relevant, sagt aber wenig darüber aus, wie teuer deren dynamische Erzeugung ist. Halte fest, welche URL aufgewärmt wurde und welche Cache-Regeln und CDN-Einstellungen galten.

Für eine ungecachte Anfrage musst du den Cache-Bypass nachvollziehbar prüfen, statt ihn nur anzunehmen. Eine angemeldete Sitzung kann anderen Regeln folgen und personalisierte Inhalte ausliefern. Kontrolliere bei ihr die tatsächliche Antwort: Ein schneller Abruf ist wenig wert, wenn er einen falschen oder veralteten Inhalt liefert.

Ein erster Besuch in einem neuen Browserzustand belegt keinen kalten Server- oder CDN-Cache. Ebenso ist ein CDN-Miss nicht automatisch ein geleerter Anwendungscache. Cache-Header können Hinweise geben, beweisen aber je nach Anbieter nicht den Zustand jeder beteiligten Ebene; dokumentiere deshalb auch die verfügbaren Einstellungen und Prüfmethoden.

Der WordPress-Object-Cache ist ohne passende persistente Erweiterung grundsätzlich auf den jeweiligen Request beschränkt. Die Konstante WP_CACHE allein aktiviert weder Redis noch eine automatisch funktionierende Caching-Lösung. Welche Rolle Redis und Memcached als persistenter Object Cache spielen können, erläutert der Beitrag zu Redis und Memcached im WordPress-Hosting.

Vergleich und Freigaben vorbereiten

Für einen Hosting-Vergleich brauchst du zunächst einen vergleichbaren Website-Stand. Erstelle eine bereinigte Kopie mit denselben Inhalten, demselben Datenbestand, Theme und denselben Plugins einschließlich ihrer Versionen. Entferne beziehungsweise ersetze personenbezogene Daten und produktive Zugangsdaten so, dass die Testseite trotzdem den gewünschten Anwendungsfall abbildet.

Gleiche PHP- und Datenbankversionen sowie relevante Einstellungen möglichst an. Notiere Unterschiede, die sich nicht beseitigen lassen oder zum gebuchten Paket gehören. Ein Vergleich der jeweiligen Standardpakete beantwortet eine andere Frage als ein möglichst angeglichener Stack-Vergleich: Das Ergebnis lässt sich nicht ohne Weiteres allein der Serverleistung zuschreiben.

Halte vor dem ersten Lauf einen Messplan fest. Er muss so konkret sein, dass eine andere Person den Aufbau nachvollziehen und Abweichungen bei einer Wiederholung erkennen kann. Die folgende Checkliste trennt Eigenschaften des Hosting-Angebots von denen der Website und der Messung.

• Tarif, Ressourcenlimits, Serverstandort und Softwareversionen beider Umgebungen.
• Test-URLs und Seitentypen, Anmeldestatus, Cookies sowie verwendete Testkonten.
• CDN, Page Cache und Object Cache einschließlich Regeln, Aufwärmphase und geplantem Bypass.
• Messstandort, Werkzeugversion, Browser- und Geräteprofil, Netzwerkbedingungen, Zeitpunkte und Wiederholungen.
• Lastprofil, Zuständigkeiten, vereinbartes Testfenster und konkrete Abbruchgrenzen.

Für Lasttests vereinbarst du die Freigabe mit allen Verantwortlichen und gegebenenfalls dem Hoster, bevor du Last erzeugst. Kläre Ansprechpartner, Ressourcenlimits und das Vorgehen bei Störungen. Schließe fremde Dienste ohne deren Zustimmung aus; verhindere insbesondere echte Zahlungen, Bestellungen und Benachrichtigungen. Prüfe vorab, ob die Testkopie solche Vorgänge tatsächlich unterbindet.

Messkonzept für typische Seiten

Wähle das Werkzeug nach der Frage, nicht nach einem möglichst guten Einzelwert. Ein Messkonzept ordnet jeder Reihe einen Seitentyp und einen Cache-Zustand zu. Die Tabelle zeigt, welche Ergebnisse sich mit den jeweiligen Ansätzen gewinnen lassen und wo ihre Aussage endet.

Für einen öffentlichen Blogartikel misst du dieselbe repräsentative URL mehrfach mit einem festen Browser- und Netzwerkprofil. Notiere, ob CDN und Page Cache eingeschaltet sind und wie die Seite vor den Läufen aufgewärmt wurde. So lässt sich das Ladeerlebnis dieser öffentlichen Seite beurteilen, nicht automatisch das einer angemeldeten Sitzung.

Eine dynamische Suche oder Kontoansicht erhält eine eigene Messreihe mit freigegebenen Testdaten und bei Bedarf einem Testkonto. Kontrolliere nicht nur den Statuscode: Die Antwort muss zur Suchanfrage beziehungsweise zum angemeldeten Konto passen und aktuell sein. Prüfe außerdem, ob ein geplanter Cache-Bypass tatsächlich greift; ein Cookie allein beweist das nicht.

Unterscheiden sich die Antwortzeiten, ist damit die Ursache noch nicht gefunden. Anwendungslogik, Datenbankzugriffe, ein persistenter Object Cache und die Hosting-Umgebung können jeweils zum Ergebnis beitragen. Dokumentiere die Unterschiede im Aufbau und untersuche sie anschließend gezielt, statt eine einzelne langsame Anfrage als Beweis für einen bestimmten Engpass zu behandeln.

Lasttest kontrolliert aufbauen

Beginne auf einer ausdrücklich freigegebenen Testseite mit wenigen einzelnen Abrufen. Kontrolliere Status und Inhalt und vergewissere dich, dass keine produktiven Nebenwirkungen entstehen. Erst danach folgt ein separat abgestimmter Lasttest, etwa für freigegebene Produktansichten eines Shops. Echte Bestellungen, Zahlungen und Benachrichtigungen bleiben ausgeschlossen.

Plane eine stufenweise Last mit Anfangsniveau, Dauer und Steigerungen. Vereinbare vorab messbare Abbruchgrenzen für Fehler, Antwortzeiten oder andere verfügbare Betriebswerte sowie einen Kontakt für den Abbruch. Bleibe bei den ausdrücklich erlaubten Abläufen; eine Produktansicht liefert keine Aussage über einen nicht getesteten Checkout.

Im geschlossenen Lastmodell wartet eine virtuelle Nutzerinstanz auf das Ende ihrer aktuellen Iteration, bevor sie die nächste beginnt. Wird die Anwendung langsamer, kann dadurch die angebotene Last sinken. Das Modell eignet sich für Abläufe, bei denen genau dieses Warten Teil der Frage ist; es hält aber keine feste Ankunftsrate aufrecht.

Ein offenes Lastmodell plant dagegen neue Iterationen unabhängig davon, ob vorherige abgeschlossen sind. Dafür muss der Lastgenerator genügend Kapazität und verfügbare virtuelle Nutzerinstanzen haben. Kann er Iterationen nicht starten, erreicht der Test das geplante Profil nicht; dokumentiere deshalb auch diese nicht gestarteten Iterationen.

Halte sowohl die eingestellte als auch die tatsächlich erreichte Rate fest. Iterationen pro Sekunde entsprechen nur dann Requests pro Sekunde, wenn jede Iteration genau einen Request erzeugt. Erfasse daneben Antwortzeitverteilung, Fehler und Timeouts sowie die Prüfung korrekter Inhalte: Ein hoher Durchsatz mit fehlerhaften Antworten ist kein erfolgreicher Belastungsnachweis.

Messreihen nachvollziehbar auswerten

Eine Messreihe ist nur zusammen mit ihrem Umfang aussagekräftig. Notiere deshalb für jede getestete Seite und jeden Lastschritt die Anzahl der ausgewerteten Anfragen sowie die Zahl der Fehler und Timeouts. Trenne erfolgreiche Antworten von fehlgeschlagenen, ohne Ausfälle aus dem Bericht verschwinden zu lassen: Eine niedrige Antwortzeit bei vielen Fehlern beschreibt kein zuverlässig schnelles Angebot.

Der Median beschreibt den mittleren Wert der sortierten erfolgreichen Messungen. Das 95. Perzentil, kurz p95, zeigt ergänzend eine Schwelle, unter der ungefähr 95 Prozent dieser Messwerte liegen. Bei wenigen Anfragen hängt p95 stark von einzelnen Beobachtungen ab; nenne deshalb immer die Stichprobengröße und interpretiere Unterschiede zurückhaltend.

Halte für jeden Lauf auch das Lastmodell und die tatsächlich erreichte Rate fest. Eine konfigurierte Rate allein zeigt nicht, ob der Generator alle geplanten Iterationen starten konnte. Die folgende Vorlage bleibt bis zur Messung leer; mehrere Läufe erhalten jeweils ein eigenes Protokoll.

Sichere Rohdaten, Testskript und Konfiguration zusammen mit dem Protokoll. So lässt sich später prüfen, welche Anfragen in eine Auswertung eingingen und ob zwei Reihen überhaupt vergleichbar sind. Wähle nicht nachträglich nur den schnellsten Lauf aus: Überlappen die Ergebnisse stark, kann die beobachtete Differenz innerhalb der Schwankungen liegen.

Ergänze neben Kennzahlen auch Auffälligkeiten am Inhalt, etwa eine unerwartete Anmeldeseite statt der erwarteten Kontoansicht. Ein technisch erfolgreicher Status beweist noch nicht, dass die richtige Seite ausgeliefert wurde. Solche Abweichungen gehören getrennt zur Fehlerbeschreibung und können eine Messreihe für die geplante Entscheidung unbrauchbar machen.

Ursachen eingrenzen und erneut messen

Beginne die Fehlersuche bei der ausgelieferten Antwort: Stimmen Inhalt, Anmeldestatus und getestete URL? Prüfe anschließend den dokumentierten Cache-Zustand und die Messumgebung. Unterschiedliche Cookies, ein anderer Messstandort oder eine geänderte CDN-Regel können zwei Läufe ungleich machen, ohne dass sich die Leistung des eigentlichen Anwendungsstacks verändert hat.

Erst danach helfen verfügbare Betriebsdaten beim Eingrenzen: Ressourcenbelegung und Warteschlangen können auf Engpässe hinweisen, Anwendungs- oder Datenbankinformationen auf aufwendige Verarbeitung. Ein einzelner langsamer HTTP-Wert benennt die Ursache nicht. WordPress nennt neben dem Hosting auch Software, Konfiguration und Inhalte als Einflussgrößen.

Für einen Vorher-nachher-Vergleich veränderst du bewusst nur eine Einstellung, etwa die Einbindung eines persistenten Object Cache. Website-Stand, Testseite, Lastprofil und Messstandort bleiben möglichst gleich; dokumentiere auch die jeweilige Cache-Aufwärmung. Der WordPress Object Cache ist ohne passende persistente Implementierung auf den einzelnen Request begrenzt, sodass seine tatsächliche Einbindung überprüft werden muss.

Führe mehrere Läufe vor und nach der Änderung durch und verteile sie zeitlich. So erkennst du besser, ob ein Unterschied wiederholt auftritt oder mit normalen Schwankungen zusammenfallen könnte. Vergleiche dabei nicht nur Median und p95, sondern auch Fehler, Antwortinhalte und erreichte Rate; sonst kann eine scheinbare Beschleunigung auf veränderte Testbedingungen zurückgehen.

Auch ein sorgfältiger Vergleich kontrolliert nicht jeden Einfluss. Bei Shared Hosting können andere Nutzer und nicht einsehbare Infrastruktur das Ergebnis mitprägen. Fehlen dir Ressourcen- oder Warteschlangendaten, halte diese Lücke ausdrücklich fest und formuliere eine vermutete Ursache als Hypothese statt als nachgewiesenen Befund.

Hosting-Ergebnis richtig einordnen

Leite die Hosting-Entscheidung aus den Seiten und Abläufen ab, die für deine Website wichtig sind. Ein öffentlicher Blogartikel mit warmem Page Cache kann eine andere Belastung erzeugen als eine angemeldete Kontoansicht. Gute Cache-Treffer auf öffentlichen Seiten belegen deshalb weder schnelle personalisierte Antworten noch einen belastbaren Checkout.

Definiere vor dem Vergleich, welche Antwortzeiten, Fehlerquoten und welches Lastprofil für den jeweiligen Ablauf akzeptabel sind. Prüfe anschließend, ob die dokumentierten Messreihen diese Anforderungen unter den vereinbarten Bedingungen erfüllen. Dazu gehören auch korrekte Inhalte und ein stabiler Ablauf; eine hohe Anfragerate allein ist keine ausreichende Entscheidungsgrundlage.

Setze virtuelle Nutzer nicht mit gleichzeitig anwesenden echten Besuchern gleich. Ihr Verhalten ergibt sich aus dem Testskript und dem Lastmodell: Im geschlossenen Modell wartet eine Instanz auf das Ende ihrer Iteration, bevor sie die nächste beginnt. Aus ihrer Anzahl lässt sich daher ohne passendes Verhaltensmodell keine reale Besucherzahl ableiten.

Berichte das Ergebnis zusammen mit Tarif, Website-Stand, getesteten URLs, Cache- und CDN-Regeln, Messstandort sowie Zeitraum. Unterscheide außerdem, ob du möglichst angeglichene Stacks oder die jeweils angebotenen Gesamtpakete verglichen hast. Im Paketvergleich können Konfigurationsunterschiede zum Ergebnis beitragen; er isoliert nicht automatisch die reine Serverleistung.

Überlappen die Reihen stark oder lässt sich die Umgebung nicht ausreichend kontrollieren, ist „kein belastbarer Unterschied nachgewiesen“ eine mögliche und hilfreiche Aussage. Das bedeutet nicht, dass beide Angebote unter allen Bedingungen gleich schnell sind. Es bedeutet lediglich, dass der vorliegende Test die gewünschte Unterscheidung nicht trägt.

Für Betriebskontrollen bewahrst du das Messprofil auf und wiederholst ausgewählte Browser- und Lastmessungen nach größeren Änderungen oder in abgestimmten Abständen. Vergleiche neue Ergebnisse nur mit passenden früheren Reihen und dokumentiere Änderungen an Inhalten, Versionen und Cache-Regeln. Lasttests benötigen weiterhin ein freigegebenes Zeitfenster und vereinbarte Abbruchgrenzen.