Why shared hosting is fast on Monday and slow on Friday

A support ticket that reads "the site was fine yesterday" is almost never about yesterday. It is about a shared resource crossing a threshold. On traditional shared hosting that resource is usually one of four things, and each has a distinct symptom.

First, separate the two halves of a request

Time to first byte (TTFB) is server thinking time. The rest is transfer. Measure both:

curl -o /dev/null -s -w 'ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

Run that against a static asset and against a dynamic page, at 10am and at 8pm. If TTFB on the static file is flat but the dynamic page balloons in the evening, the problem is in the application stack, not the network. If both are flat and only the total grows, you have a bandwidth or cache-header problem, which is a different article.

Cause 1: the PHP worker pool is full

Shared hosting runs PHP-FPM with a fixed number of workers per account, often something like pm.max_children = 5 to 10. Each worker handles one request at a time. When all workers are busy, new requests queue.

The trap is that a single slow request holds a worker. One unindexed query, one outbound API call without a timeout, one image resize on upload, and five concurrent visitors can park the whole pool. Website traffic that looks trivial in analytics can still saturate five workers if each request takes two seconds.

What it looks like: requests that normally return in 200ms take 30 seconds and then succeed, rather than failing fast. Spiky, not consistently slow.

Cause 2: everyone shares one database server

On a shared platform, hundreds of accounts often point at the same MySQL instance. It has a connection limit and a shared buffer pool. A neighbour's plugin doing a full table scan evicts your hot pages, and your queries start hitting disk.

What it looks like: database-bound pages slow down while static pages stay fast, and the slowdown correlates with other tenants' activity rather than your traffic.

Cause 3: the disk is busy

Shared storage is the classic bottleneck. Nothing in your account limits tells you that another account is running mysqldump across the same array. You just see iowait climb and every write-back stall.

What it looks like: writes and admin pages (wp-admin, checkout, anything that touches the database) slow first. Reads of cached files stay quick.

Cause 4: quotas you did not know existed

Shared plans routinely cap inodes, CPU seconds, concurrent processes and mail volume. Hitting a cap is not always an error: sometimes the platform silently throttles you, and the only symptom is latency. Check the account's resource panel before you rewrite anything.

What actually fixes it

The fixes are ordered by effort, not by how satisfying they feel.

1. Cache the expensive thing. A page cache in front of PHP removes most requests from the worker pool entirely. If 80% of your traffic is anonymous reads, this alone can end the problem.
2. Find the slow query. Enable a slow query log if your plan allows it, or time the page with the database in isolation. One missing index is frequently the whole story.
3. Kill outbound calls without timeouts. A payment gateway or newsletter API that hangs for 30 seconds holds a worker for 30 seconds. Set 2-3 second timeouts and a retry budget.
4. Move the workload somewhere with reserved resources. This is the step people jump to first, and it is the right step only when the first three are done.

Why containers behave differently

Container-based hosting changes the shape of the problem rather than the size of the box. Each application gets its own filesystem, its own runtime version and a reserved share of CPU and memory. Two properties matter in practice:

• Your workers are yours. A busy neighbour cannot consume your pool, because the pool is scoped to your app.
• Your runtime is reproducible. You deploy a build, not a set of files copied into a shared document root. Rolling back is switching to the previous build, not restoring a backup.

It does not make slow code fast. A WordPress install with 40 plugins will still be slow in a container; it will just be slow in a predictable way that you can profile.

When to keep shared hosting

If your site is a brochure with a contact form, shared hosting is honestly fine. The moment you have customer logins, a checkout, or a background queue, you are sharing a worker pool with strangers and your p99 latency is somebody else's business decision.

The useful test: if a slow neighbour can make your checkout time out, the platform is not matched to the workload.