Website Performance Optimization: A Guide to Handling High Traffic Loads

At CrowdHandler, we often meet people who are preparing for high traffic for the first time. Sometimes, all they really need is a waiting room.

However, they often add servers and load balancing for the first time too – and are keen to discuss these matters with us. 

Without sounding too dismissive, this isn’t the primary concern of our product. It doesn't really matter to us since our product is agnostic about what architecture lies behind the waiting room. Our main concern is the rate of transactions our customers can process. 

In fact, it’s rarely practical to scale up enough to handle 10 times your usual traffic for occasional peak events. That said, the more optimised your site is, the shorter the queues will be.

Most web developers have perfectly respectable careers, without ever working on anything truly popular. So, they are surprised to find that much of the presumed best practice advice out there doesn't survive contact with the real world.

Our expertise initially came from building highly available websites for big media and entertainment brands. So, we have some knowledge of scaling websites. We know what really works and what doesn’t. 

 

---

 

What Doesn’t Matter

Number of Application Servers

You might be moving from a shared server to a dedicated one. Maybe you’re even moving from a dedicated server to multiple servers behind a load balancer (whether at a traditional hosting provider or a cloud service like AWS). 

The truth is, we rarely see application servers maxed out in load, so the number isn’t very significant. 

Handling JavaScript, PHP, or .NET tasks to produce HTML or JSON just isn’t that resource-intensive. Even a single server can cope with quite a bit of traffic.

People usually scale up application servers for redundancy (to serve requests if one server fails). In high-traffic scenarios, app servers tend to spend most of their time waiting on something else, often a database or API (which functions as a remote database). 

An application server typically crashes when it runs out of outgoing connections while waiting for responses upstream. Ten application servers all stuck waiting on the same database query or API call will not help much.

Adding CPUs to Your Database (DB) Server

So, does that mean you should look at your database server first? 

People often throw around the word “cluster,” but unless you’ve built sharding into your application (check it out), you can’t just add extra database servers to scale performance.

Sure, you could upgrade to a more powerful DB machine with more CPU cores. However, most modern apps don’t put a huge CPU load on the database. The queries slowing you down are often limited by disk speed (IO)—especially in fancy cloud environments where your DB storage is located who-knows-where, and you can overlook IO throttling until you really need to address it. Then, you discover how expensive real IO performance can be.

Adding Disk IO

If you investigate query execution times on your DB server, you’ll find that adding more CPU and disk IO might help some, but not enough to prevent the site from crashing under load. Doubling or even quadrupling your database specs will not magically save your site.

Why not? Typically, it’s because your queries are poorly optimised—often generated by some popular but inefficient framework—and they aren’t indexed properly. By applying the right indexes, you could see queries run 1,000 times faster. That’s a lot more cost-effective than spending 1,000 times more on your DB server.

“Infinite” Cloud Scaling

Sounds easy: just click a button for more executions/processes/hamsters. 

But even if you nail all those configurations and are okay with the cost, if you rely on transactions (most sites do), you’ll hit a bottleneck at the transaction phase—whether it’s in your database (transactional DBs can’t scale infinitely; look it up) or a third-party service like a payment API (they are built on transactional DBs with rate limits, too).

 

---

 

What Does Matter

Cache the Landing Page

You know that one page that everyone is going to share on Instagram, etc.? 

Cache it. 

Don’t waste server resources regenerating that same page hundreds of thousands (or millions) of times. If it’s a dynamic page, then make it static—or at least partially static. Add a button to a separate call-to-action step if users need to load inventory or other dynamic data.

Not sure which page users land on most? Find out. This is crucial data. Set your cache settings and use a reverse proxy (like Varnish) or a CDN (such as Cloudflare), or even serve a completely static file from the web server. Developers might not like this solution, but for websites expecting millions of hits, caching is 80% of the work.

Use a CDN (Content Delivery Network) 

A CDN is a sophisticated, distributed caching layer. While fully optimising it can be tricky, getting started is straightforward. Do you think CDNs are only for distributing static files worldwide? 

Not exactly. Many of today’s most heavily trafficked sites are behind a CDN, no matter how “dynamic” they appear. In fact, this principle powers frameworks like Next.js/Vercel, which achieve notable performance benchmarks this way. But it’s not new—TV networks, eCommerce, and ticketing sites have been using CDNs since before you were born. New frameworks just streamline the approach. Some CDN options include:

• Cloudflare: Affordable, popular, and simple to configure.

• CloudFront: Comes with AWS, convenient if you host your site there.

• Akamai: One of the pioneers, used by many large retail sites.

Use a Waiting Room

Most websites have transactional limits that you can’t scale away. Even massive players like Ticketmaster use queues for peak-volume sales – and they have plenty of servers. Start by caching what can be cached, then place a waiting room in front of the truly dynamic parts. It’s a better first step than randomly scaling servers in hopes of meeting demand.

Put in a waiting room, set a transaction rate you know you can handle, and watch your site under peak load to spot real-world bottlenecks—often in your database’s slow query log or API response times. You might fix scaling problems simply by adding an index to a table. And you’ll learn from actual traffic behaviour, not theoretical load tests or guesswork.

CrowdHandler

In high-traffic scenarios, the most effective strategy isn’t endless scaling but smart resource management. Waiting rooms are key to this. 

CrowdHandler specialises in providing flexible, easy-to-integrate virtual waiting rooms to help you manage high-traffic periods. 

Sign up today for a free trial.