WordPress Performance unter Hochlast: Caching, REST API & Lasttests bei FCBinside

Wer schon mal versucht hat, eine WordPress-Installation unter echter Last zu betreiben, weiß: Die meisten Tutorials enden ungefähr da, wo es interessant wird. „Aktivier doch einfach Caching" ist ein netter Anfang. Wenn aber 30.000 Leute innerhalb weniger Minuten auf dieselbe Push-Notification klicken, weil ein Bundesliga-Spieler vielleicht doch nicht zum FC Bayern wechselt, dann reicht das nicht.

FCBinside.de ist eines der reichweitenstärksten deutschen Portale rund um den FC Bayern München. Bis zu 5 Millionen Besucher pro Monat, News, Transfergerüchte, Spielerbewertungen, Kommentare, eine eigene App mit werbefreiem Abo-Modell – und das alles auf WordPress. Wir betreuen die Infrastruktur seit längerem bei We Manage. In diesem Artikel zeige ich, wie so ein WordPress High Performance Hosting Setup aussieht, wo die echten Engpässe (Hochlast, langsame Queries, falsche Cache-Konfiguration) liegen und warum 24/7-Support bei dieser Art von Projekt keine Marketing-Floskel ist, sondern Betriebsvoraussetzung.

Übrigens: Mit Vjeko Keskic, dem Gründer von ballnews media und Kopf hinter FCBinside, habe ich auch in Folge 89 meines Podcasts Happy Bootstrapping ausführlich gesprochen – über den Weg vom Hobby-Blog zum mehrköpfigen Team, über Reichweite, App, Vermarktung. Wer die Geschichte hinter dem Portal interessant findet: reinhören lohnt sich.

Das eigentliche Problem ist nicht das Spiel

Man könnte annehmen, dass die kritischen Momente bei einem Fußball-Portal die Spieltage selbst sind. Tatsächlich sind die gut planbar – Anpfiff, Halbzeit, Abpfiff, Nachbericht, Pressestimmen, alles in einem bekannten Rhythmus. Die schwierigen Peaks sehen anders aus: ad-hoc, ohne Vorwarnung, mit massiver Konzentration auf wenige Minuten. Ein Tweet von Fabrizio Romano, eine Bild-Meldung um halb zwei nachts, eine Pressekonferenz, die jemand mitschneidet, ein Spieler, der überraschend verletzt vom Platz humpelt: Wenn FCBinside als erstes deutsches Portal eine fundierte News dazu raushaut, läuft der Traffic innerhalb von Minuten heiß.

Genau diese Ad-hoc-Charakteristik macht das Hosting anders als bei klassischen WordPress-Sites. Ein Onlineshop kennt seine Black-Friday-Termine. Eine Veranstaltungsseite kennt ihren Ticketverkauf-Start. Ein Newsportal über den FC Bayern weiß morgens nicht, ob heute der Tag wird, an dem ein 100-Millionen-Transfer durchsickert. Die Infrastruktur muss also nicht für einen vorhersehbaren Peak ausgelegt sein, sondern für unangekündigte Peaks rund um die Uhr.

Dazu kommt: FCBinside hat eine eigene App mit Abo, mit der Fans die Inhalte werbefrei lesen. Diese App konsumiert den Content über die WordPress REST API. Das ist technisch elegant, weil dieselbe Datenbasis Web und App versorgt – es bedeutet aber auch, dass jede Push-Nachricht aus der App nicht nur Browser-Traffic auf der Website erzeugt, sondern parallel auch API-Requests aus der App selbst. Beide Wege müssen die Infrastruktur aushalten.

Die Architektur: Bewusst einfach, bewusst groß

Bei FCBinside.de läuft die Plattform auf einem einzigen, großzügig dimensionierten Hetzner Cloud Server. Kein Cluster, keine Read Replicas im Hot-Standby, keine Kubernetes-Spielwiese. Davor sitzt Cloudflare als CDN. Das Analytics liegt auf einem separaten Server, damit Tracking und CMS sich nicht gegenseitig in die Quere kommen.

Das ist eine bewusste Entscheidung. Ein einzelner kräftiger Server mit reichlich Reserven ist in dieser Konstellation oft die bessere Wahl als ein verteiltes Setup, das im Normalbetrieb 80 Prozent seiner Kapazität ungenutzt lässt – und im Lastfall genau die Komplexität liefert, die du nachts um drei nicht debuggen möchtest.

Die App-Anbindung über die REST API bedeutet, dass wir die typischen WordPress-Caching-Tricks für die Website nicht eins zu eins auf die API anwenden können. Eine vollständig gecachte HTML-Seite wird vom Frontend ohne PHP ausgeliefert. Ein REST-API-Request muss zwar nicht zwingend frisch sein, aber er muss authentifizierungsfähig bleiben, JSON liefern und auf Updates reagieren. Hier ist die Cache-Strategie feinkörniger – kürzere TTLs, Object Cache für die Datenbank, gezielte Invalidierung bei neuen Artikeln.

Cloudflare, Cache-Plugins und nginx: Drei Ebenen, eine Strategie

Cloudflare löst nicht automatisch Probleme. Cloudflare löst die Probleme, die du Cloudflare aktiv lösen lässt. Default-Einstellungen sind für eine generische Marketing-Website gemacht – nicht für ein Newsportal mit hoher Aktualisierungsfrequenz. Cache-Regeln pro URL-Pattern, Page Rules für API-Endpunkte, granulares Bypass-Verhalten für eingeloggte Nutzer und Kommentar-Endpunkte – das ist Konfigurationsarbeit, die einmal sauber gemacht werden muss und dann regelmäßig nachjustiert wird.

Hinter Cloudflare sitzt aber noch eine zweite Cache-Ebene: ein WordPress-Cache-Plugin, das mit nginx zusammenspielt. Welches Plugin am besten passt, ist keine Glaubensfrage – wir evaluieren regelmäßig neue Versionen und Alternativen und schauen uns konkret an, wie sie sich auf die Web Vitals auswirken: Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. Ein Plugin, das den TTFB halbiert, aber durch falsche Critical-CSS-Optimierung das Layout zerreißt, ist keine Verbesserung.

Wichtig dabei: Das Cache-Plugin allein reicht nicht. Es muss sauber mit nginx integriert sein, damit gecachte Seiten direkt vom Webserver ausgeliefert werden, ohne dass PHP überhaupt anspringt. Ein in PHP gerendertes „Cache-Hit" ist immer noch ein PHP-Prozess, der CPU kostet.

Reserve allein reicht nicht – die unscheinbaren Stellen entscheiden

Der WordPress-Server hat bewusst Reserven nach oben. Das hilft gegen unerwartete Peaks – schützt aber nicht vor allen Klassen von Problemen. Ein langsamer Query, der unter Normallast keine Rolle spielt, kann unter Hochlast den ganzen MySQL-Pool blockieren. Ein Plugin-Update, das zusätzliche AJAX-Requests pro Pageview erzeugt, verschiebt die Last-Charakteristik. Ein neuer Werbepartner mit synchron eingebundenem Script kann die User Journey ausbremsen, obwohl der Server selbst topfit ist.

Deshalb gehört zum Setup mehr als nur „großer Server plus CDN":

• OPcache sauber konfiguriert, mit ausreichend Memory und passenden Validierungs-Intervallen, damit PHP-Code nicht bei jedem Request neu kompiliert wird

• Redis als Object Cache für WordPress, damit wiederholte Datenbank-Queries (Optionen, Term-Lookups, Transients) aus dem RAM kommen

• MySQL-Tuning mit angepasstem Buffer Pool, Slow-Query-Logging und regelmäßiger Beobachtung der Fragmentation

• nginx mit FastCGI Cache als zusätzliche Cache-Ebene, damit gecachte Seiten ohne PHP-Roundtrip rausgehen

• Kernel- und Systemparameter für hohe Concurrent Connections, korrekt gesetzte File Descriptor Limits, sauber dimensionierter TCP-Stack

Nichts davon ist spektakulär. Aber jeder Punkt ist eine potenzielle Bruchstelle, wenn man ihn übersieht.

Lasttests, bevor es ernst wird

Eine Sache, die in den meisten WordPress-Tuning-Artikeln fehlt: Lasttests. Wir testen vor größeren Umbauten, bei Plugin-Wechseln, bei neuen PHP-Versionen und vor allem dann, wenn wir die Cache-Konfiguration anpassen. Nicht „mal kurz mit ab 100 Requests durchballern", sondern realistische Szenarien – Mischung aus gecachten Artikeln, REST-API-Calls aus der App, AdServer-Endpoints, Kommentarseiten.

Was wir dabei messen: Durchsatz pro Sekunde, Antwortzeiten im 95. und 99. Perzentil, PHP-FPM Pool Auslastung unter Last, MySQL Connections, Cache Hit Ratio auf nginx- und Cloudflare-Ebene. Und – fast wichtiger – wie sich das System nach Ende der Last verhält. Eine Site, die unter Last weh tut, aber sich danach sauber erholt, ist okay. Eine, die nach dem Peak weiter taumelt, hat ein anderes Problem (oft im Connection-Handling oder im Cache-Warmup).

Lasttests zeigen außerdem, ob ein neues Caching-Plugin tatsächlich liefert, was die Marketing-Seite verspricht. Spoiler: erstaunlich oft nicht.

Monitoring: Du willst es vorher wissen, nicht hinterher

Wir betreiben für FCBinside.de das gleiche Monitoring-Stack wie für alle unsere Kunden: Icinga2 für Checks, Telegraf für Metriken, Grafana zur Visualisierung, VictoriaMetrics als Time Series Datenbank, dazu zentrales Log-Management. Wichtig sind dabei nicht die Tools, sondern die richtigen Metriken: PHP-FPM Pool Auslastung, MySQL Slow Queries, Redis Hit Rate, Cloudflare Cache Hit Ratio, App-API-Response-Times.

Die hilfreichsten Alerts sind nicht die für „Server down", sondern die für „etwas verändert sich gerade ungewöhnlich". Wenn die API-Latenz innerhalb von zehn Minuten um 80 Prozent steigt, ist das oft das erste Anzeichen einer kommenden Welle – noch bevor irgendein klassisches Schwellwert-Limit erreicht ist.

Hands-on Support: Telefon, Slack, kurze Wege

Bei einem Portal wie FCBinside ist 24/7-Bereitschaft kein nettes Extra, sondern Voraussetzung. Wenn samstags um 23:30 Uhr ein Transfergerücht hochkocht und die App-Push-Nachricht 50.000 Geräte gleichzeitig zur Website schickt, dann ist die Frage nicht, ob jemand reagiert – sondern wer und wie schnell.

Bei uns heißt das: kleines Team, kurze Wege, direkter Kontakt. Kein Ticket-System, das in drei Stufen eskaliert. Wir sind per Telefon erreichbar – und genauso per Slack, in einem gemeinsamen Channel mit dem Kunden. Das funktioniert in beide Richtungen: Wir melden uns, wenn wir was sehen, das auffällig ist. Der Kunde meldet sich, wenn er was sieht, das uns vielleicht entgangen ist. Kurze Nachricht, schnelle Antwort, keine Eskalationsstufen.

Das geht nur, weil wir bewusst nicht versuchen, hunderte Kunden mit gleichem Personal zu betreuen, sondern eine überschaubare Zahl an Plattformen wirklich kennen.

Was bleibt

WordPress kann sehr große, sehr lebendige Sites tragen – wenn die Infrastruktur dazu passt. Das ist weniger eine Frage des CMS und mehr eine Frage davon, wie ernst man die unscheinbaren Stellen nimmt: OPcache, MySQL-Buffer, CDN-Regeln, Plugin-Auswahl mit Web-Vitals-Blick, Lasttests, Monitoring-Schwellen. Und davon, wer sich kümmert, wenn es brennt.

Bei FCBinside.de funktioniert das Setup, weil die Architektur bewusst einfach gehalten ist, die Komponenten an den richtigen Stellen sitzen und der Betreiber weiß, wen er anrufen oder per Slack pingen kann. Wer mehr Hintergrund zum Projekt sehen will: die ausführliche FCBinside Case Study fasst Architektur, Ergebnisse und Eckdaten im Detail zusammen.

Hast du ähnliche Probleme? Sprecht uns an

Hast du auch Probleme mit deiner WordPress-Site unter Last oder zu Peak-Zeiten – Black Friday, plötzliche TV-Erwähnung, virale Aktion? Ausfallende Seiten, langsame REST-API-Calls, kaputte Cache-Layer? Wenn dir das bekannt vorkommt, sind wir vielleicht der richtige Ansprechpartner.

Wir betreuen bei We Manage eine Reihe von WordPress-Installationen, die unter ernsthafter Last laufen – Newsportale, Community-Plattformen, Event-Sites – auf Basis unserer Managed Cloud Server. Wenn ihr ähnliche Anforderungen habt – hohe Traffic-Spitzen, App-Anbindung über die REST API, 24/7-Verlässlichkeit mit echtem Ansprechpartner – meldet euch. Wir schauen uns euer Setup an und sagen ehrlich, was funktioniert und was nicht.