We Manage Blog

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

2026-05-16T00:00:00+02:00

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.

Cloud Exit erfolgreich: Wie wir Everysize beim Ausstieg aus AWS halfen und 80% der Kosten sparten

2025-05-27T00:00:00+02:00

Als Eugen Falkenstein, Mitgründer der Sneaker-Suchmaschine Everysize, vor einiger Zeit zu uns kam, stand sein Unternehmen vor einem klassischen Problem vieler wachsender Start-ups: explodierende Cloud-Kosten bei AWS und schwindende Flexibilität. Was folgte, war eine der erfolgreichsten Cloud-Migrationen, die wir bei We Manage begleitet haben – mit einer Kosteneinsparung von 80% und deutlich verbesserter Performance.

Die Ausgangssituation: Gefangen im AWS-Kostenkarussell

Everysize ist die einzige Suchmaschine im deutschen Web, die Sneaker zu Bestpreisen in der gewünschten Schuhgröße findet. Das siebenköpfige Team hatte wie viele andere auch den vermeintlich einfachen Weg gewählt: "Wir waren vom Start weg bei Amazon AWS, weil's alle so machen", erinnert sich Eugen Falkenstein.

Doch die anfangs pragmatische Entscheidung wurde zunehmend zum Problem. "Immer kompliziertere Preismodelle folgten. Irgendwann zahlten wir bei AWS einen fünfstelligen Betrag pro Jahr und damit doppelt so viel wie zu Anfang – bei fast konstantem Ressourcenbedarf", berichtet Falkenstein. Die monatlichen AWS-Kosten waren auf über 4.000 Euro gestiegen, bei gleichzeitig sinkender Agilität durch komplexe Abhängigkeiten.

Warum Everysize zu uns kam

Als wir Eugen das erste Mal trafen – übrigens über eine private Verbindung, "Unsere Ehefrauen kannten sich" – war schnell klar, dass hier mehr gebraucht wurde als nur ein weiterer Dienstleister. Falkenstein suchte einen echten Partner: "Dazu brauchst du jemanden, der dein Geschäftsmodell wirklich versteht und eigene Ideen einbringt, um das auf einer technischen Infrastruktur umzusetzen, und zwar ohne Vendor-Lock-in."

Seine Anforderungen waren klar definiert: 24/7-Service, technische Kompetenz und die Balance zwischen professionellem Service und partnerschaftlicher Zusammenarbeit auf Augenhöhe. "Ich seh mich nicht nur als Kunde, sondern auch als Partner und Kollege. Ich schmeiße gerne Ideen spontan über den Tisch. Das geht nur mit Mitstreitern, die die Balance aus Service und Augenhöhe halten."

Unsere Analyse: Wo AWS überdimensioniert war

Bei der Analyse der bestehenden Infrastruktur wurde schnell deutlich, warum die Kosten explodiert waren. Everysize nutzte nur einen Bruchteil der AWS-Funktionen, benötigte aber für 80% ihrer Rechenkapazität vorhersagbare Backend-Routinen: Produktdaten-Management, Feed-Import, BI-Datenaufbereitung. "Rechenintensiv, aber alles gut kalkulierbar", wie Falkenstein es ausdrückt.

Für diese Art von Workload waren die Flexibilitätsvorteile eines Hyperscalers schlicht überdimensioniert und unverhältnismäßig teuer.

Die Migration: Maßgeschneiderte Lösungen entwickeln

Nach einem erfolgreichen Probeauftrag übernahmen wir schrittweise den Betrieb und die Optimierung der Elasticsearch-Installation von Everysize. Die Migration zur Hetzner-Cloud erstreckte sich über eineinhalb Jahre – bewusst behutsam und ohne Risiko für den laufenden Betrieb.

"Die Migration vom Hyperscaler zum klassischen Hoster verläuft nicht immer eins zu eins", räumt Falkenstein ein. Genau hier konnten wir unsere Expertise einbringen: Wir entwickelten maßgeschneiderte Lösungen für einen leistungsfähigen MySQL-Cluster auf der neuen Infrastruktur und migrierten komplexe Komponenten wie den URL-Shortener für das Social-Media-Marketing.

Dabei war uns wichtig, nicht nur zu migrieren, sondern zu optimieren. Wir automatisierten die allermeisten IT-Prozesse, um 24/7-Verfügbarkeit zu garantieren, und implementierten proaktives Monitoring und Alerting.

Die Zusammenarbeit: DevOps neu gedacht

Besonders erfolgreich war die enge Verzahnung mit der Entwicklungsagentur Intradesys, die parallel den kompletten Code der Suchmaschine neu schreibt. "Thomas und ich entwickeln die Prototypen, für die Andy dann die optimale IT-Infrastruktur entwirft und aufbaut", beschreibt Falkenstein die Arbeitsweise.

Diese agile, asynchrone Zusammenarbeit über Slack und E-Mail ermöglichte es, schnell auf neue Anforderungen zu reagieren, ohne sich in langwierigen Abstimmungsprozessen zu verlieren. "Durch Asynchronität bekommen wir mehr Fokus, Ruhe und Überlegung rein", so Falkenstein.

Die Ergebnisse: Mehr als nur Kosteneinsparung

Die Zahlen sprechen für sich: Die jährlichen Serverkosten sanken von 50.000 auf knapp 10.000 Euro – eine Ersparnis von 80%. Doch mindestens genauso wichtig waren die qualitativen Verbesserungen:

Höhere Zuverlässigkeit: "In Notfällen muss ich meine Dienstleister nicht mehr in Aktion versetzen. Heute benachrichtigt mich Andy proaktiv und hat das Problem meist auch schon gelöst, auch nachts oder am Wochenende", berichtet Falkenstein.

Zurückgewonnene Agilität: "Neue Ideen setzen wir heute innerhalb weniger Wochen um. Wir haben unsere Leichtfüßigkeit zurückgewonnen und können unsere Stärken als kleines Digitalunternehmen wieder voll ausspielen im Markt."

Aktuelle Projekte und Zukunftspläne

Die neu gewonnene technische Souveränität nutzt Everysize bereits für ambitionierte Zukunftsprojekte. Wir unterstützen sie dabei bei der Modernisierung ihres Content-Management-Systems und dem Aufbau eines eigenen Marktplatzes für Sneaker. "Womöglich wollen wir im nächsten Schritt unser Geschäft internationalisieren", überlegt Falkenstein.

Alle diese Vorhaben sind nur möglich, weil die IT-Infrastruktur wieder als strategischer Enabler und nicht als Kostenfaktor funktioniert.

Was andere Unternehmen daraus lernen können

Der Fall Everysize zeigt exemplarisch, dass ein Cloud Exit mehr sein kann als reine Kostensenkung. Es geht um die Rückgewinnung technischer Souveränität und unternehmerischer Flexibilität.

"Als Online-Unternehmer drucken wir kein fertiges Buch. Unsere Geschäftsstrategie buchstabieren wir in Technologie aus. Dazu musst du deine IT-Prozesse ständig optimieren und weiterentwickeln", bringt Falkenstein die Philosophie auf den Punkt.

Für uns bei We Manage war dieses Projekt besonders befriedigend, weil es zeigt, was möglich wird, wenn technische Expertise auf echte Partnerschaft trifft. Wie Falkenstein es ausdrückt: Wir sind "der Profi-Sysadmin, den ich inhouse bräuchte, der aber bei mir zu wenig zu tun hätte" – nur eben extern und mit der vollen Flexibilität einer Partnerschaft.

Fazit

Die Zusammenarbeit mit Everysize beweist: Mit der richtigen Analyse, maßgeschneiderten Lösungen und echter Partnerschaft lassen sich auch komplexe Cloud-Abhängigkeiten erfolgreich auflösen. Das Ergebnis sind nicht nur drastisch reduzierte Kosten, sondern vor allem die Rückgewinnung der technischen Flexibilität, die für innovative Unternehmen überlebenswichtig ist.

Konkret kümmern wir uns für Everysize um den gesamten Betrieb — auf Basis unserer Managed Cloud Server, mit CDN-Anbindung über Cloudflare und laufender Cloud-Beratung zu Provider-Wahl, Migration und Architektur. Mehr zum Setup findest du in der Everysize Case Study.

Interessiert an ähnlichen Optimierungen für Dein Unternehmen?

Lass uns gerne darüber sprechen, wie wir auch Dir zu mehr technischer Souveränität und optimierten Kosten verhelfen können.

Willkommen auf unserer neuen Website!

2025-03-13T00:00:00+01:00

Was wir für dich tun

Bei "We Manage" nehmen wir dir die technische Last ab, damit du dich auf das konzentrieren kannst, was du am besten kannst: dein Kerngeschäft voranbringen. Unser Angebot umfasst:

Managed Server & Cloud Lösungen: Optimierte Infrastruktur ohne den Overhead
Hosting Lösungen für Laravel, Symfony, PostGIS, GitLab und vieles mehr
CDN-Implementierung & Beratung: Blitzschnelle Content-Auslieferung weltweit
Proaktives Monitoring: Wir erkennen Probleme, bevor sie zu Ausfällen führen
Zuverlässige Backup-Strategien: Deine Daten sind bei uns in sicheren Händen
wir helfen außerdem bei Performance Analyse, Hochlastszenarien und wenn DSGVO und souveräne Lösungen benötigt werden
Dabei sind wir auf Wunsch 24x7 für dich erreichbar

Hands-on Zusammenarbeit

Was uns besonders macht? Wir arbeiten nicht nur für dich, sondern mit dir. Über Slack Shared Channels sind wir praktisch Teil deines Teams – immer erreichbar, immer ansprechbar. Keine Tickets, die im Nirgendwo verschwinden, sondern direkte Kommunikation und schnelle Lösungen.

Technologie, die funktioniert

In der heutigen Tech-Landschaft ist Stabilität kein Luxus, sondern eine Notwendigkeit. Unsere Erfahrung im DevOps-Bereich ermöglicht es uns, maßgeschneiderte Lösungen zu implementieren, die wachsen, wenn du wächst.

Wir freuen uns darauf, dich und dein Projekt kennenzulernen und gemeinsam das nächste Kapitel deiner technischen Infrastruktur zu gestalten! Sprich uns gerne dazu an!

An dieser Stelle möchten wir herzlich dem Team von Stella Projects danken, das unsere Website auf Basis des leistungsstarken Statamic CMS umgesetzt hat.

Dein "We Manage"-Team