Hosting-Vergleichsportale liefern Ratings und Rankings, doch ihre technische Aussagekraft leidet häufig unter kurzen Testzeiträumen, inkonsistenten Setups und fehlenden Messdetails. Ich zeige, welche Kennzahlen wirklich zählen, wie TTFB, P95 und I/O sauber gemessen werden und warum echte Lastprofile die Spreu vom Weizen trennen.
Zentrale Punkte
Ich fasse die wichtigsten Kritikpunkte und Empfehlungen kompakt zusammen, damit du Ratings richtig einordnest und eigene Prüfungen planst. Viele Portale testen zu kurz, mischen Setups oder verwechseln Frontend-Scores mit Serverleistung. Aussagekräftig wird es erst, wenn Messreihen groß genug sind, Bedingungen konstant bleiben und Fehlerquoten sichtbar werden. Dann erkennst du reale Engpässe bei CPU, RAM, I/O, Datenbank und Netzwerk. So triffst du eine Entscheidung, die auf Daten statt Bauchgefühl beruht.
- Methodik: Testdauer, Setup-Klarheit, Wiederholbarkeit
- Benchmarks: P95/P99, Fehlerquoten, I/O-Profile
- Lastbilder: Smoke, Load, Stress, Soak sauber trennen
- Messorte: Regionen vergleichen, Cache-Zustand angeben
- Transparenz: Rohdaten, Metrik-Gewichte, Testpläne offenlegen
Wie Portale messen – und wo die Aussage kippt
Viele Portale bewerten Performance, Verfügbarkeit, Support und Preis-Leistung, doch die technische Tiefe bleibt oft dünn. Ich sehe häufig Messreihen über wenige Wochen, die saisonale Schwankungen, Backups oder Cronjobs ausblenden und dadurch Spitzen verschleiern. Ohne klares Baseline-Setup – etwa gleiche PHP-Version, identisches CMS samt Plugins, gleiche Themes, gleiches Cache-Verhalten – lassen sich Ergebnisse kaum vergleichen. Rankings wirken dann objektiv, obwohl Setup-Unterschiede den Ausschlag geben. Solche Kontraste erklären, warum ein Anbieter trotz höherer Kosten mit 99,97 % Uptime vorn landet, während ein anderer mit guter Frontend-Ladezeit im Lasttest einbricht – beides kann stimmen, falls Messdesign und Gewichtung differieren.
Testdauer, Setup und Noisy Neighbors
Kurze Testzeiträume blenden Wartungsfenster, Saisoneffekte und schwankende Nachbarsysteme in Shared-Umgebungen aus. Ich plane Messreihen mindestens über sechs Wochen, dokumentiere Wartungsereignisse, setze identische Software-Stacks und halte Plugin-Versionen konstant. Ohne diese Disziplin spielen Noisy-Neighbor-Effekte, Backup-Fenster und Virenscanner in die Daten hinein. Wichtig ist auch, Fehlerseiten zu zählen und nicht bloß Ladezeiten zu mitteln; HTTP-5xx-Raten zeigen Engpässe oft vor dem Totalausfall. Wer diese Punkte ignoriert, misst Zufall und nennt ihn Leistung.
Frontend ist nicht Backend: TTFB, I/O und Datenbank
Frontend-Scores via Lighthouse, GTmetrix oder PageSpeed geben Impulse, ersetzen aber kein Server-Profiling. Ich trenne TTFB in Serverzeit und Netzwerk-Latenz und messe zusätzlich I/O, Query-Dauer und Lock-Wartezeiten, damit CPU-, RAM- und Storage-Flaschenhälse sichtbar werden. Eine saubere TTFB-Analyse ohne Cache-Tarnkappe zeigt, ob die Maschine effizient antwortet. Ebenso prüfe ich NVMe vs. SATA, Zufalls- vs. sequentielle Zugriffe und Datenbank-Latenzen unter gleichbleibenden Abfragen. Erst die Kombination dieser Blickwinkel trennt kosmetische Frontend-Optimierung von echter Serverkraft.
Lastprofile richtig lesen: Smoke, Load, Stress, Soak
Ich unterscheide vier Lastbilder: Smoke-Tests prüfen Grundfunktion, Load-Tests simulieren typischen Traffic, Stress-Tests zeigen das Limit und Soak-Tests entlarven Speicherlecks über Stunden. Jede Stufe braucht genug Anfragen, parallele Nutzer und P95/P99-Auswertung, damit Ausreißer nicht verschwinden. Reine Durchschnittswerte wirken freundlich, ignorieren aber zähe Tails und fehlerhafte Antworten. Ohne definierte Fehlerschwellen – zum Beispiel P95 über 800 ms oder 1 % 5xx – führt die Interpretation in die Irre. So erkenne ich, ob ein Host unter Dauerlast langsam ausfranst oder abrupt mit Fehlern kippt.
Regionen, Caches und kalte Läufe
Messorte prägen Ergebnisse: Europäische Messpunkte kaschieren Verzögerungen für Nutzer in Amerika oder Asien. Ich messe daher aus mehreren Regionen und markiere kalte sowie warme Cache-Läufe separat, denn Warm-Cache beschönigt Time-to-First-Byte und Transferzeiten. Ein einziger Standort und nur Warm-Cache ergeben zwar schöne Charts, erzählen aber wenig über reale Nutzerwege. Auch CDN-Transparenz zählt: Ist CDN aktiv, gehört der Hinweis in die Legende. Wer sich zu stark an PageSpeed-Scores orientiert, verwechselt Frontend-Tricks mit echter Serverleistung.
Welche Kennzahlen zählen wirklich?
Ich gewichte Metriken nach Einfluss auf Erlebnis und Betrieb: P95-Ladezeit, Fehlerrate, Uptime samt MTTR, I/O-Leistung und Query-Latenz stehen oben. TTFB bewerte ich nur im Kontext von Latenz und Cache-Zustand, sonst verführt die Zahl zu falschen Schlüssen. Uptime braucht längere Messzeiträume, damit Ausfälle und deren Behebungszeit sichtbar werden. Beim Storage prüfe ich Random-Reads/Writes und Queue-Tiefe, weil Web-Workloads selten sequenziell laufen. Die folgende Tabelle zeigt typische Schwächen von Portalen und eine bessere Praxis.
| Kriterium | Häufiger Mangel in Portalen | Bessere Praxis |
|---|---|---|
| TTFB | Einzelmessung, kein Latenz-Split | P95 aus mehreren Regionen, Serverzeit getrennt |
| Uptime | Kurzer Zeitraum, keine MTTR | 6+ Wochen, Ausfälle und Reparaturzeit dokumentiert |
| Lasttest | Keine Parallelität, nur Mittelwerte | Smoke/Load/Stress/Soak, P95/P99 und 5xx-Quote |
| Storage | Kein I/O-Typ, nur sequentiell | SSD/NVMe, random und sequentiell getrennt |
| Cache | Ohne kalte/warm Cache-Trennung | Getrennte Läufe, Zustand in der Legende |
Solche Leitplanken verwandeln hübsche Grafiken in belastbare Evidence. Ich protokolliere deshalb Setup, Messorte, Läufe, Konfidenzintervalle und Ausreißerbehandlung in einem Testplan. So lassen sich Ergebnisse reproduzieren und fair vergleichen. Fehlt diese Transparenz, bleibt ein Ranking eine Momentaufnahme ohne Kontext. Wer Kaufentscheidungen daran knüpft, riskiert Fehlgriffe und spätere Migrationskosten.
WordPress-Realtests: Journey statt Startseite
Reine Startseiten-Checks unterschlagen teure Abläufe wie Suche, Warenkorb oder Checkout. Ich messe echte User-Journeys: Einstieg, Produktliste, Produktdetail, Add-to-Cart, Checkout und Bestätigung. Dabei zähle ich Queries, transferierte Bytes, CPU-Spitzen, PHP-Worker-Auslastung und Blockierungszeiten in der Datenbank. NVMe-SSDs, 2+ vCPUs, PHP 8.x, OPcache, HTTP/2 oder HTTP/3 und eine saubere Cache-Strategie bringen messbare Vorteile. Wer diese Faktoren überprüft, erkennt früh, ob der Host zur eigenen Lastkurve passt oder bei Trafficspitzen Fehler wirft und Umsätze kostet.
Eigenes Messdesign: So teste ich vor Vertragsabschluss
Ich starte mit einem kleinen Staging-Setup und lasse es eine Woche durchmonitieren, bevor ich migriere. Parallel belaste ich mit realistischen Nutzerszenarien und stoppe P95/P99, 5xx-Rate, Error-Logs, CPU-Steal und I/O-Wartezeiten. Zusätzlich prüfe ich Backup-Fenster, Cronjob-Zeitpunkte, Limits für Prozesse und offene Verbindungen, damit verdeckte Drosselungen sichtbar werden. Ergebnisdiagramme vergleiche ich gegen Wochentage, Peak-Zeiten und Wartungsereignisse. Wer sich auf Charts aus falsche Speedtests stützt, bezahlt später mit Ausfällen und Mehraufwand, den eine Woche Vorprüfung erspart hätte.
Daten fair gewichten und Scores verstehen
Viele Portale kombinieren Metriken über gewichtete Scores, etwa 40 % Performance, 20 % Stabilität, 15 % Technik und der Rest für Support und Preis. Ich prüfe zuerst, ob die Gewichtung zum Projekt passt: Ein Shop braucht andere Prioritäten als ein Portfolio. Dann bewerte ich, ob die Messwerte die Gewichte tragen – kurze Uptime-Fenster sollten keine hohe Punktzahl für Verfügbarkeit bringen. Ohne Offenlegung der Rohdaten bleibt jede Zahl spekulativ. Aussage gewinnt ein Score erst, wenn Messdauer, Setups, Perzentile und Fehlerquoten sichtbar werden und ich das Gewicht für meinen Usecase anpassen kann.
Frontend-Scores richtig einordnen
Gute PageSpeed-Werte ohne saubere Serverbasis wirken wie Make-up: hübsch, aber unter Last schnell dahin. Ich prüfe daher zuerst Serverkennzahlen und setze Frontend-Tuning erst danach an. Ein schneller TTFB aus der Nähe kaschiert keine trägen Datenbankabfragen oder blockierte I/O-Queues. Auch CDN darf keine Ausrede sein, um schwache Backends zu verstecken. Wer Frontend-Scores isoliert feiert, ignoriert Ursachen und bekämpft lediglich Symptome.
Transparenzforderungen an Vergleichsportale
Ich erwarte von Portalen klare Testpläne, offene Rohdaten, identische Setups, markierte Messorte und eine saubere Trennung von kalten und warmen Läufen. Dazu gehören Logs für Ausfälle, MTTR, Limits, Backup-Zeiten und Cronjobs. Fair wäre auch, Fehlerraten und P95/P99 auszuspielen statt nur Durchschnittswerte. Wer Affiliate-Modelle nutzt, sollte Bewertungslogik und potenzielle Interessenkonflikte sichtbar machen. Erst dann gewinnen Hosting-Vergleichsportale echte Glaubwürdigkeit und dienen Nutzerinnen und Nutzern als tragfähige Entscheidungsbasis.
SLI, SLO und SLA sauber unterscheiden
Ich trenne drei Ebenen: Service Level Indicators (SLI) sind Messwerte wie P95-Latenz, Fehlerrate oder TTFB-Serverzeit. Service Level Objectives (SLO) definieren Zielwerte, z. B. P95 < 800 ms und Fehlerrate < 0,5 %. Service Level Agreements (SLA) sind vertragliche Zusagen mit Kompensation. Viele Portale mischen das: Sie zitieren ein 99,9 %-SLA, messen aber gar keine SLI, die für Erlebnis und Betrieb zählen. Ich definiere erst SLI, leite daraus SLO ab und prüfe anschließend, ob der Anbieter-SLA realistisch ist. Wichtig ist das Error Budget: Bei 99,9 % Uptime bleiben pro Monat knapp 43 Minuten Ausfall „erlaubt“. Wer dieses Budget in Spitzenzeiten verbraucht, gefährdet Umsatz trotz SLA-Konformität. Deshalb gewichte ich SLI tageszeitabhängig und bewerte Ausfälle im Kontext von Peak-Phasen.
Statistik ohne Fallen: Stichprobe, Konfidenz, Ausreißer
Ich achte auf genügend Messpunkte pro Szenario: Für stabile P95-Werte plane ich mindestens tausende Requests über mehrere Zeitfenster. Konfidenzintervalle gehören in jede Grafik, sonst täuschen minimal unterschiedliche Balken Relevanz vor. Ausreißer behandle ich transparent: Ich winsorisiere in Ausnahmefällen, aber ich entferne keine Fehlerantworten. Stattdessen trenne ich „Schnell, aber fehlerhaft“ von „Langsam, aber korrekt“. Zeitliche Aggregation ist ebenso kritisch: 1-Minuten-Buckets zeigen Spikes, 1-Stunden-Mittelwert kaschiert sie. Ich prüfe beide. Für Vergleichbarkeit synchronisiere ich Uhren (Zeitserver), notiere Zeitzonen und stimme Aggregation über Hosts hinweg ab, damit Backups nicht statistisch „wandern“.
Limits und Throttling sichtbar machen
Viele Hoster deckeln Ressourcen in Shared- und Managed-Umgebungen: PHP-FPM-Worker, CPU-Cores, RAM, inodes, offene Dateien, Prozess- und Verbindungs-Limits, SQL-Connections, Netzwerk-Shaping. Ich provoziere diese Grenzen gezielt, bis Fehlermeldungen oder Zeitüberschreitungen auftreten. Wichtige Indikatoren sind CPU-Steal (zeigt Hypervisor-Druck), Run-Queue-Längen, FPM-Warteschlangen und Datenbank-Semaphore. Auch Burst-Modelle (kurz hohe CPU, danach Drossel) verfälschen Kurztests: Ein Anbieter wirkt flott bei 5 Minuten Last, bricht aber nach 20 Minuten ein. Deshalb sind Soak-Tests und das Protokoll von Limit-Hits entscheidend.
Netzwerk und TLS im Griff
Ich zerlege TTFB in Netzwerk- und Serverkomponente: DNS-Lookup, TCP/TLS-Handshakes, H2/H3-Multiplexing und Paketverluste addieren sich zum Gesamterlebnis. Ein Anbieter mit guter Serverzeit kann durch hohe RTT oder Verlustquoten trotzdem langsam wirken. Ich messe RTT und Jitter aus mehreren Regionen, notiere TLS-Version und Kompressionsstufe (z. B. Brotli/ gzip) pro Ressource und beobachte, ob unter Last Retransmits steigen. HTTP/2 bringt Vorteile bei vielen Objekten, HTTP/3 hilft bei hohen RTT und Verlusten. Entscheidend ist Konsistenz: Ich halte Protokoll, Cipher und Zertifikatslängen in den Tests konstant, um Netzwerkvariablen von Serverzeit zu trennen.
Caching-Strategien präzisieren
Ich trenne Full-Page-Cache (FPC), Objekt-Cache und CDN-Kanten-Cache. Für jeden Layer messe ich Trefferquote, Invalidierungen und Warmup-Dauer. Ein Host, der FPC gut bedient, kann trotzdem durch fehlenden Objekt-Cache (z. B. transiente Queries) ausgebremst werden. Ich dokumentiere, welche Pfade bewusst nicht gecacht werden (Warenkorb, Checkout, personalisierte Seiten) und wie sich diese auf P95 auswirken. Testskripte markieren Cache-Bedingungen (kalt/warm) und Vary-Header. So sehe ich, ob ein Anbieter nur im Warm-Cache glänzt oder auch bei kalten Pfaden performant bleibt. Wichtig ist, OPcache und JIT sauber vorzuwärmen, damit erste Requests nicht künstlich schlechter abschneiden.
Sicherheit, Isolation und Wiederherstellung messbar machen
Leistung ohne Sicherheit ist wertlos. Ich prüfe Patch-Kadenz (Betriebssystem, PHP, Datenbank), Isolationsmechanismen (cgroups, Container, jails), Backup-Strategie und Wiederherstellungszeiten. Zwei Kennzahlen sind operativ zentral: RPO (Recovery Point Objective) und RTO (Recovery Time Objective). Ich teste Restore-Zeiten praktisch: Wie lange braucht ein vollständiger Restore einer realistischen Datenmenge, wie hoch ist die Erfolgsquote und welche Downtime entsteht? Zusätzlich messe ich, ob Security-Scanner oder Malware-Sweeps planbar laufen und wie stark sie I/O und CPU belasten. Solche Jobs gehören in den Testkalender, sonst erklären sie nächtliche Spikes nicht und führen zu falschen Schlüssen.
Kosten, Vertragsdetails und Skalierung
Ich rechne Gesamtbetriebskosten: Hosting, Backups, Staging-Umgebungen, zusätzliche IPs, SSL-Varianten, Egress-Traffic und Supportstufen. Faire Bewertungen berücksichtigen Upgrade-Pfade: Lässt sich vertikal skalieren (mehr vCPU/RAM) oder horizontal (weitere Instanzen), und wie schnell? Ich prüfe, ob Limits unter dem Radar liegen (Fair-Use-Regeln, Drosseln nach X GB, Cron-Limits). In Lasttests simuliere ich Bursts und beobachte Reaktionszeit von Auto-Scaling (wo verfügbar): Wie viele Minuten bis zusätzliche Worker aktiv sind? Kosten, die sich erst unter Last zeigen, gehören ins Bild – sonst wirkt ein günstiger Tarif attraktiv, bis die Rechnung mit Traffic explodiert.
Werkzeugkoffer und Automatisierung
Ich setze auf reproduzierbare Messungen: Lastgeneratoren für HTTP(S), Tools für I/O-Profile (random vs. sequentiell), Systemmetriken (CPU, RAM, Steal, Run-Queue), Netzwerk-Analyse (RTT, Jitter, Retransmits) und Datenbank-Profiler (langsame Abfragen, Locks). Wichtig ist eine Automatisierung des Setups, damit jede Testrunde identisch startet – inklusive identischer PHP- und DB-Konfiguration, gleicher Plugins, identischer Seed-Daten und deterministic Cache-Zustände. Infrastruktur als Code, Seed-Skripte und wiederverwendbare Journeys minimieren Varianz und machen Ergebnisse belastbar. Ich archiviere Rohdaten, Parser und Diagramm-Templates, damit spätere Vergleiche nicht an Formatänderungen scheitern.
Interpretation nach Usecase: Shop, Publishing, SaaS
Ich passe die Gewichtung an den Zweck an: Ein Content-Portal braucht global gute Latenz und Caching-Trefferquote, ein Shop priorisiert niedrige P95 unter Personalisierung und Transaktionslast, eine SaaS-Anwendung braucht stabile Datenbank-Locks und geringe 5xx-Rate bei langen Sessions. Dementsprechend variiert der Testplan: Für Shops fokussiere ich Warenkorb/Checkout, für Publishing setze ich mehr Regionstests und CDN-Transparenz, für SaaS erweitere ich Soak-Tests und Session-Langlebigkeit. Ein Einheits-Score wird keinem dieser Profile gerecht; deshalb dokumentiere ich die Prioritäten pro Projekt vor dem ersten Messpunkt.
Fehlerbilder schnell erkennen
Typische Muster lassen sich systematisch zuordnen: Steigt P95 bei konstanter Fehlerrate, deuten Queue-Bildungen auf CPU- oder I/O-Engpässe hin. Springt gleichzeitig die 5xx-Quote, sind Limits erreicht (FPM, Verbindungen, Memory). Wellenförmige Peaks zur vollen Stunde sind Cron-Indikatoren, nächtliche Sägezähne deuten auf Backups. Wenn TTFB-Serverzeit stabil bleibt, aber Latenz steigt, ist das Netzwerk der Verdächtige (RTT, Verlust). Ich korreliere Metriken in Zeitreihen und markiere Ereignisse – so entstehen keine Interpretationen ohne Kontext. Mit dieser Disziplin trenne ich Zufall von Ursache und vermeide teure Fehlentscheidungen.
Kurz zusammengefasst
Vergleichsportale liefern einen Einstieg, doch echte Aussage entsteht erst mit langen Messreihen, konsistenten Setups und klaren Perzentilen. Ich prüfe TTFB getrennt, messe I/O und Datenbank, analysiere P95/P99 und Fehlerquoten und teste mehrere Regionen samt Cache-Zustand. Für WordPress baue ich Journeys nach, achte auf NVMe, vCPUs, PHP 8.x, OPcache, HTTP/2 oder HTTP/3 und Limits. Frontend-Scores werte ich vorsichtig und vermeide Schnellschlüsse ohne Kontext. Wer diese Leitlinien befolgt und bei Bedarf eine kurze Pagespeed-Einordnung mit technischen Messdaten kombiniert, trifft Entscheidungen auf Basis belastbarer Messwerte statt hübscher Rankings.
