Traffic does not break a site by using up disk space. It breaks a site by asking the server to build the same page thousands of times a minute, each build touching PHP and the database. Everything below is about doing that work once, or not at all.
Where a busy site really stalls
On a normal request your server runs the app code (usually PHP), which queries the database, renders HTML and sends it back. One visitor, a few dozen milliseconds. The trouble starts when many visitors arrive at once and every request needs its own PHP process and its own database connections.
Shared hosting caps how many PHP processes your account can run at the same time, often between 20 and 60. Hit the cap and new requests queue. Visitors see a slow page, then a 503 error. The disk was fine. You ran out of workers.
Directional figures for a typical WordPress page. Your numbers depend on the theme, plugins and server.
The order that fixes it
Work through these in sequence. Most sites never need to reach the bottom.
- Server-side page cache. The host stores the finished HTML for each page and serves that copy to logged-out visitors. LiteSpeed with LSCache, NGINX FastCGI cache, or a plugin like WP Rocket. This alone takes most sites from "falls over at 100 concurrent" to "fine at 1,000".
- A CDN in front. Cloudflare or Bunny caches pages and static files at locations near your visitors, so many requests never reach your server at all.
- Object cache. Redis or Memcached stores the results of repeated database queries in memory. This is what helps logged-in traffic, carts and dashboards, which cannot use the page cache.
- More PHP workers and RAM. Now a bigger plan helps, because the remaining uncached work has room to run in parallel.
- Move the database. On a large store, put the database on its own server or a managed database service so a slow query cannot freeze the web server.
Quick test: load your home page while logged out, then in your browser tools look at the response headers. An x-litespeed-cache: hit or x-fastcgi-cache: HIT line means the page cache is working. No such header, and every visitor is triggering a full build.
What to look for on the plan page
- Named server-side cache: LSCache, NGINX cache, or Varnish, not just "we are fast"
- Redis or Memcached available, ideally included rather than an add-on
- A stated PHP worker or process limit, so you can size against your traffic
- Dedicated CPU and RAM on the plan you are considering, not "unmetered" shared cores
- A free CDN, or clear support for putting Cloudflare in front
- HTTP/2 or HTTP/3, and PHP 8.2 or newer
When to leave shared hosting
Move to a VPS or a managed cloud plan when your cached setup still hits the worker cap during normal peaks, when you need guaranteed CPU for a checkout or an API, or when the host emails you about resource usage more than once. Below that, a well-cached shared plan handles more traffic than most people expect.
Mahdi Hassan · Web Developer & Site Speed
Before you buy a bigger plan, turn on full-page caching and a CDN and re-run a load test. Nine times out of ten the "we need a dedicated server" problem is a site rebuilding every page from scratch because nothing was cached.
Illustrative example
A news site that fell over on its best day
Picture a site on a mid shared plan that gets a link from a large account. Traffic goes from 3 to 300 concurrent in minutes. With no page cache, PHP workers max out and most visitors get a timeout during the exact window the traffic was worth something.
With LSCache and Cloudflare turned on first, the same spike would have been served mostly from cache, and the shared plan would likely have held without an upgrade.