Do You Need a Bigger Server, or a Faster App? Case Study: Juridice.ro

When we first looked at Juridice.ro’s infrastructure, the numbers told a grim story: the server was pinned at 100% load with about 5,000 readers on the site. Visitors saw slowdowns, errors, and — at the worst moments — a site that simply wouldn’t load.

Today, the same publication routinely serves over 14,000 online readers, with peaks beyond 20,000, at around 35% load.

Three to four times the traffic. A third of the load. This is the story of how that happened — and why the answer was almost never “buy a bigger server.”

Juridice.ro is one of Romania’s largest and best-known online resources for legal professionals, with roughly 550,000 monthly visits according to SimilarWeb. For a publication whose entire product is being available when a lawyer needs it, every slowdown costs brand power that no server invoice can buy back.

The 100% Problem

We didn’t meet Juridice through a sales call. We found them during a routine SEO prospecting exercise — and noticed a respected publication visibly struggling under its own success. We reached out.

At the time, the site ran on a hosting platform with a custom-built OS and web stack, where — by the provider’s own access policy — clients don’t receive privileged access to their servers. Through a miscommunication about the nature of the hosting, Juridice believed they were on dedicated hardware; in reality, the machine was shared, and it was full.

That access policy shaped our first big decision. Normally, our instinct is to tune before we move — squeeze the existing hardware first, spend money later. Here, tuning in place was simply impossible: no privileged access, no tuning. The only door was migration.

A Move Nobody Noticed

We proposed a dedicated server at the same budget Juridice was already spending — except now the money bought real hardware, a service agreement, and a team actively improving the platform instead of just hosting it.

The migration itself was designed for zero downtime. We replicated everything to the new environment, paused publishing for just one to two hours while the final database restoration completed, then switched the IPs. The new location began serving immediately, while the old one acted as a proxy forwarding stragglers whose DNS hadn’t updated yet. No reader ever saw a maintenance page.

Worse Before Better

Here’s the part most case studies would quietly skip: right after the migration, the load was over 100% again.

The old platform’s custom stack had actually been well-tuned for what it was. The standard cPanel setup we landed on — nginx in front of Apache — coped noticeably worse with Juridice’s traffic. We had traded a full shared machine for a dedicated one running a stack that couldn’t use it.

Our first fix attempt was nginx page caching. It made things faster — and broke something more important: pages weren’t updating reliably. For a publication that publishes new legal content multiple times a day, a cache that serves this morning’s front page is worse than a slow one.

So within days — and on our own dime — we moved the stack to LiteSpeed. And the LiteSpeed Cache plugin for WordPress worked, frankly, miracles: full-page caching that actually understood WordPress, invalidating correctly when content changed. Fast and fresh.

Two more layers completed the foundation: static files went to a CDN, because the old setup had been serving images and assets through Apache far too often; and later, a systematic purge of malicious bot traffic shaved another 15% off total load — a battle that earned its own case study.

Success Creates New Villains

Then something interesting happened. As server resources freed up, the site got faster — and as the site got faster, visitor counts climbed. The feedback loop we’d hoped for was real: performance was feeding growth.

And growth broke things nobody had seen break before. A lot of WordPress plugins are simply not designed for a site with tens of thousands of readers online. Working together with Juridice’s technical team — and armed with Datadog’s flamechart profiling, which turned out to be the single most valuable diagnostic tool of the whole engagement — we hunted down two of them.

Villain #1: the banner plugin. The plugin used to display advertising banners loaded the entire WordPress core every time it counted an impression. And it counted a lot of them: the rotator switched banners every few seconds, registering a new impression for each switch, for each banner slot on the page. A single reader, simply sitting on an article, generated a steady stream of 2, 4, 10, sometimes 20 full WordPress requests — for as long as they kept reading. That does not scale — it multiplies.

Our interim fix was a WordPress filter that intercepted and blocked these requests before they fired. Eventually, a member of Juridice’s tech team found the cleaner answer: an option buried in the plugin to disable impression tracking entirely.

Villain #2: the online users counter. This one was a textbook lesson in how small features become exponential problems. The plugin that counted currently active readers stored every reading session in its own database table — and scanned the entire table on every single visit. Worse, the table used the MyISAM storage engine, whose table-level locking forced all of Juridice’s parallel traffic into a single slow-moving queue. The more visitors arrived, the longer the table, the slower the scan, the longer the queue. Exponentially.

Converting the table to InnoDB improved things considerably. But the flamecharts kept talking: even after the conversion, 30–50% of the application’s wall time was still being burned inside that one plugin. So we retired it and replaced it with a small custom service written in Go — purpose-built to count online readers and nothing else.

Where That Leaves Us

Every exponential limiter we could find is now gone. At 14,000–20,000+ online readers, the server sits around 35% load, and the stack scales linearly from here: on the current hardware, without further changes, it should comfortably handle at least 2.5x today’s traffic — up to around 50,000 online visitors reading the site at the same time.

And we’re not done. We’re currently building and testing an in-house tool called Growl: a simplified frontend head for WordPress, written in Go, with all the bells and whistles stripped away and total in-memory caching. It touches the database only at startup and when a post is updated. In our tests, it brings page load times down to a few milliseconds and delivers a 100% Google PageSpeed score — and on Juridice’s current hardware, it should scale to something in the neighborhood of 10 million visitors.

If Growl performs in production the way it performs in testing, Juridice’s CPU usage drops below 10% — possibly below 5% — and RAM below 10%. At which point we’ll be making a recommendation you don’t often hear from the company managing your servers: downgrade.

And one more thing: we intend to release Growl as open source. Escaping one lock-in shouldn’t mean acquiring another — not to a hosting stack, and not to us.

Why We Can Afford to Say “Downgrade”

There’s no trick to it — just incentive design. Juridice pays us a flat retainer. We profit the most when everything runs beautifully and nobody has to lift a finger; when things go wrong, we lose money. A vendor paid by the hour profits from problems. A vendor paid by the outcome hunts them down.

That structure is why every decision in this story — moving stacks on our own dime, replacing plugins with custom code, building Growl, recommending smaller servers — points in the same direction as the client’s interest.

The Takeaway

Upgrading servers without tuning application performance has severely diminishing returns. Power laws will bite you worse, and worse, and worse — until they ruin your party.

— Alexandru Eftimie, Helios Live

Juridice’s original problem was never really a hardware problem. A bigger server bought at day one would have masked the banner plugin, the table-scanning counter, and the missing cache layer — right up until traffic doubled and the exponential curves caught up all at once, on a bigger invoice.

If your server load is climbing faster than your traffic, that ratio is the diagnosis. Something in your application is multiplying work. Find it before you pay to feed it.

Conclusion

From 100% load with 5,000 readers on the site to 35% with more than 20,000 at peak moments. From a shared machine with no root access to a dedicated stack with millisecond ambitions. From “the site is down again” to “we might suggest a smaller server.”

The sequence that got Juridice here — migrate for control, cache correctly, profile relentlessly, kill exponential behavior, then rebuild the hot path — is now how we approach every publisher at scale. The hardware was the least interesting part of the story. It usually is.