WordPress at Scale: How We Run FCBinside

If you've ever tried to run a WordPress installation under real load, you know: most tutorials end about where it gets interesting. "Just turn on caching" is a nice start. But when 30,000 people click the same push notification within minutes because a Bundesliga player might or might not be moving to FC Bayern, that's not enough.

FCBinside.de is one of Germany's largest portals covering FC Bayern Munich. Up to 5 million monthly visitors, news, transfer rumors, player ratings, comments, an in-house app with an ad-free subscription model – all running on WordPress. We've been running the infrastructure at We Manage for a while now. In this article, I'll walk through what a WordPress high-performance hosting setup like that looks like, where the real high-load bottlenecks are, and why 24/7 support on a project like this isn't a marketing line but an operating requirement.

By the way: I also had Vjeko Keskic, the founder of ballnews media and the person behind FCBinside, on episode 89 of my podcast Happy Bootstrapping (in German) – we talked about the path from hobby blog to a multi-person team, reach, the app, and ad sales. If you're curious about the story behind the portal, it's worth a listen.

The real problem isn't the match itself

You'd think the critical moments for a football portal are match days. Those are actually quite predictable – kick-off, half-time, full-time, post-game coverage, press reactions, all in a known rhythm. The hard peaks look different: ad-hoc, no warning, concentrated into a few minutes. A Fabrizio Romano tweet, a Bild story at 1:30 in the morning, a press conference someone records, a player who limps off the pitch unexpectedly. When FCBinside is the first German portal to publish a solid news piece about it, traffic climbs within minutes.

This ad-hoc characteristic is what makes hosting different here than for classical WordPress sites. An online shop knows its Black Friday dates. An event site knows when its ticket sale starts. A news portal about FC Bayern doesn't know in the morning whether today is the day a 100-million-euro transfer leaks. The infrastructure doesn't have to be sized for a predictable peak; it has to be sized for unannounced peaks, around the clock.

On top of that: FCBinside has its own app with a subscription, where fans can read content ad-free. That app pulls content through the WordPress REST API. Technically elegant, because the same data backs web and app – but it also means every push notification from the app doesn't just produce browser traffic on the website; it produces parallel API requests from the app itself. Both paths have to hold up.

The architecture: intentionally simple, intentionally generous

FCBinside.de runs on a single, generously sized Hetzner Cloud Server. No cluster, no hot-standby read replicas, no Kubernetes playground. In front sits Cloudflare as the CDN. Analytics runs on a separate server so tracking and CMS don't get in each other's way.

This is a deliberate choice. A single strong server with plenty of headroom is often the better option in this constellation than a distributed setup that leaves 80 percent of its capacity unused under normal operation – and delivers exactly the complexity you don't want to debug at three in the morning when load hits.

App integration via the REST API means we can't apply the typical WordPress caching tricks for the website one-to-one to the API. A fully cached HTML page is served by the front-end without PHP. A REST API request doesn't strictly need to be fresh, but it has to stay authenticatable, deliver JSON, and react to updates. The cache strategy here is finer-grained – shorter TTLs, object cache for the database, targeted invalidation on new articles.

Cloudflare, cache plugins and nginx: three layers, one strategy

Cloudflare doesn't automatically solve problems. Cloudflare solves the problems you actively let it solve. Default settings are made for a generic marketing site – not for a news portal with a high update frequency. Cache rules per URL pattern, page rules for API endpoints, granular bypass for logged-in users and comment endpoints – that's configuration work you do once cleanly and then revisit regularly.

Behind Cloudflare sits a second cache layer: a WordPress cache plugin that interlocks with nginx. Which plugin fits best isn't a matter of religion – we re-evaluate new versions and alternatives regularly and look concretely at how they affect web vitals: Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. A plugin that halves TTFB but tears the layout apart through wrong critical-CSS optimization is not an improvement.

Important: the cache plugin alone is not enough. It has to integrate cleanly with nginx so cached pages are served straight from the web server, without PHP ever starting up. A "cache hit" rendered by PHP is still a PHP process burning CPU.

Headroom alone isn't enough – the unspectacular details decide

The WordPress server has plenty of headroom by design. That helps against unexpected peaks – but it doesn't protect against every class of problem. A slow query that doesn't matter under normal load can block the entire MySQL pool under high load. A plugin update that produces additional AJAX requests per pageview shifts the load profile. A new ad partner with a synchronous script embed can slow down the user journey even though the server itself is in great shape.

So the setup involves more than "big server plus CDN":

• OPcache cleanly configured, with enough memory and matching validation intervals so PHP code isn't recompiled on every request

• Redis as the WordPress object cache so repeated database queries (options, term lookups, transients) come from RAM

• MySQL tuning with adjusted buffer pool, slow-query logging, and regular fragmentation checks

• nginx with FastCGI cache as an additional cache layer so cached pages go out without a PHP round-trip

• Kernel and system parameters tuned for high concurrent connections, correct file-descriptor limits, a properly sized TCP stack

None of this is spectacular. But every single one of these is a potential breaking point if you overlook it.

Load tests, before it gets serious

One thing missing from most WordPress tuning articles: load tests. We test before major rebuilds, before plugin swaps, before new PHP versions, and especially when we change the cache configuration. Not \"quickly hammer 100 requests with ab,\" but realistic scenarios – a mix of cached articles, REST API calls from the app, ad-server endpoints, comment pages.

What we measure: throughput per second, response times at the 95th and 99th percentiles, PHP-FPM pool saturation under load, MySQL connections, cache hit ratio on the nginx and Cloudflare layers. And – almost more important – how the system behaves after load ends. A site that hurts under load but recovers cleanly afterwards is okay. One that keeps stumbling after the peak has a different problem (often in connection handling or cache warm-up).

Load tests also tell you whether a new caching plugin actually delivers what its marketing page promises. Spoiler: surprisingly often it does not.

Monitoring: you want to know before, not after

For FCBinside.de we run the same monitoring stack as for all our customers: Icinga2 for checks, Telegraf for metrics, Grafana for visualization, VictoriaMetrics as the time-series database, plus centralized log management. What matters here is not the tools, but the right metrics: PHP-FPM pool saturation, MySQL slow queries, Redis hit rate, Cloudflare cache hit ratio, app/API response times.

The most useful alerts aren't the "server down" ones, but the "something is shifting unusually" ones. When API latency rises by 80 percent within ten minutes, that's often the first sign of an incoming wave – before any classic threshold limit is hit.

Hands-on support: phone, Slack, short paths

For a portal like FCBinside, 24/7 availability isn't a nice extra; it's a precondition. When a transfer rumor lights up on Saturday at 11:30 pm and the app push notification sends 50,000 devices at once to the website, the question isn't whether someone will respond – it's who, and how fast.

For us, that means: small team, short paths, direct contact. No ticket system that escalates in three steps. We are reachable by phone – and just as much on Slack, in a shared channel with the customer. It works both ways: we ping when we see something unusual; the customer pings when they see something we might have missed. Short message, fast reply, no escalation tiers.

This only works because we deliberately don't try to serve hundreds of customers with the same staffing. We serve a manageable number of platforms and really know them.

What's left to say

WordPress can carry very large, very lively sites – if the infrastructure fits. That is less a question of the CMS and more a question of how seriously you take the unspectacular details: OPcache, MySQL buffer, CDN rules, plugin choice with a web-vitals lens, load tests, monitoring thresholds. And of who steps in when things catch fire.

At FCBinside.de the setup works because the architecture is deliberately simple, the components sit in the right places, and the operator knows whom to call or ping on Slack. If you want more background on this specific project: the FCBinside case study sums up the architecture, results, and key numbers in one place.

Got similar problems? Get in touch

Do you have a WordPress site that buckles under peak load — Black Friday, a sudden TV mention, a viral campaign? Outages, slow REST API calls, broken cache layers? If that sounds familiar, we might be the right partner for you.

At We Manage, we run a number of WordPress installations under serious load – news portals, community platforms, event sites – on top of our Managed Cloud Server. If you have similar requirements – high traffic spikes, app integration via the REST API, 24/7 reliability with a real contact person – reach out. We'll take a look at your setup and tell you honestly what works and what doesn't.