Intermittent slowness is the specific shape of slowness where two identical requests, minutes apart, take very different times to complete. The site is not broken. It is not constantly slow. It stutters in a way that feels arbitrary to the visitor who catches a bad one. The useful insight in this article is that the stutter is never actually random. It is a pattern you have not identified yet.
What intermittent slowness actually is
Intermittent slowness is variance in response time that survives filtering out the obvious. Same page, same visitor, same cache state, same region, same device, five minutes apart: one request is fast, the next is slow. The averages in a hosting dashboard hide it because they flatten the spikes. The visitor who hits the spike does not care about the average.
The reason the pattern is worth taking seriously is that a constant slowness and an intermittent one have different root causes. Constant slowness is usually structural: undersized hosting, a broken cache, a heavy theme. Intermittent slowness is almost always about a shared resource that is contested at specific moments. The site is fast when nothing is competing for the resource and slow when something is.
The mechanism: a waiting room with a fixed number of seats
The single most useful mental model for intermittent slowness is the PHP-FPM worker pool. A WordPress site has a fixed number of PHP workers. Each uncached request occupies one worker for as long as the page build takes. When all workers are busy, the next request waits in a queue until a worker frees up. The pm.max_children directive sets that ceiling, and there is no spillover above it.
That queue is where intermittent slowness is born. Think of a waiting room with a fixed number of seats and one receptionist per seat. On a quiet afternoon you walk straight in. During a sudden rush you wait. Nothing about the receptionists has changed, and nothing about you has changed. The only thing that changed is how many other people arrived in the same minute.
Every shape of intermittent slowness is a variant of this. Either more requests arrived than usual, or the requests that arrived cost more worker-time than usual, or the server ran out of some other shared resource and the workers had to wait for it. CPU, database connections, disk I/O, external APIs, and the cache itself are all shared resources that behave the same way under contention.
The common pattern shapes
Naming the pattern is most of the diagnosis. A handful of shapes cover almost every site.
- Time-of-day. Slow around specific hours, fast outside them. Visitor peaks collide with the worker pool during the working day. High CPU usage usually tracks the same curve.
- Per-page. Cached pages are fast, the cart and checkout are slow. Logged-in pages bypass the full-page cache by design, so they pay the full PHP cost on every request. Category archives and search pages can behave the same way when the underlying database queries are slow.
- Per-user. Anonymous visitors see a fast front end, logged-in users see a slow one. Same cache-bypass mechanism as above. The slow admin article covers the extreme version of this.
- Noisy neighbour. Shared hosting means sharing CPU, memory, and disk with other sites on the same machine. When a neighbour has a traffic spike or starts a backup, your site slows down without anything changing on your end. The only reliable tell is that the slowness does not correlate with any event in your own logs.
- WP-Cron collision. WordPress schedules tasks through WP-Cron, which runs on page loads, not on a system timer. The first visitor after a scheduled time triggers the overdue job in-process. That visitor waits for the job to finish. Everyone after them is fast again. Backup plugins, sitemap rebuilds, and email digests are the usual suspects.
- OPcache cold start after deploy. OPcache caches compiled PHP in memory. After a deploy, a PHP-FPM reload, or a server restart, the cache is empty and every request for the next few seconds pays the compile cost before running. The very first handful of requests after a release are slower than anything that follows.
- Backup window collision. Hosting providers and plugins schedule backups at fixed times. A dump of a large database while the site is serving traffic saturates disk I/O, and the worker pool stalls waiting on it. The slowness is tightly bound to the backup window and disappears the moment the dump finishes.
Why WordPress is particularly susceptible
WordPress is uniquely good at turning small contention into visible slowness. Uncached pages build the full request path through PHP on every request, the plugin ecosystem routinely makes synchronous external API calls on the front end, WP-Cron is triggered by traffic rather than by a proper timer, and most hosts cap PHP workers at a low number because they share hardware across many sites. Each of these is fine in isolation. Together they mean any small fluctuation in load, external latency, or background work can push the worker pool over its ceiling for a few seconds at a time.
Practical implications
The first useful step is always to time-stamp the slow events. Note the exact minute, the page, and whether you were logged in. Two or three data points usually make the pattern obvious. Correlate against the times backups run, cron jobs fire, and traffic typically peaks. If nothing correlates, the next candidate is a neighbour on shared hosting, which is not something you can fix from inside WordPress.
The second step is to stop treating intermittent slowness as a single problem. The fix for a WP-Cron collision is moving WP-Cron to a system cron. The fix for a logged-in slowness is tuning the admin path. The fix for a worker-pool ceiling is raising pm.max_children or reducing the work each request does. None of these fixes apply to the others.
What intermittent slowness is NOT
Most of the frustration around this problem comes from collapsing it into something else. These are the conflations worth naming out loud.
- Not a hosting tier problem alone. "Upgrade the plan" is the default advice and it is wrong more often than it is right. A bigger plan buys more CPU and memory, but if the cause is a WP-Cron collision or a 3-second external API call on the product page, none of that extra capacity helps. You still spend 3 seconds waiting for the third party.
- Not solved by "more RAM". Memory pressure and intermittent slowness are different failure modes. A site that swaps out pages to disk under memory pressure is slow constantly, not intermittently. If the slowness is truly intermittent, adding memory rarely changes it.
- Not random. Every "random" slowness has a cause that produced it at that exact moment. The randomness is a measurement gap, not a property of the system. If you cannot find the pattern, you have not logged enough, or you are not looking at the right layer. The answer is never "the site is just weird sometimes".
- Not a theme issue. Themes produce constant slowness, not intermittent slowness. A slow theme is slow on every request. If your 2 PM requests are twice as slow as your 10 AM requests on the same page, the theme is not the variable.
- Not something a CDN automatically fixes. A CDN caches static assets and, with full-page caching, cached HTML. Cached requests are fast by definition. The slow requests during an intermittent-slowness event are the ones that miss the cache: logged-in users, the cart, the checkout, uncacheable endpoints. Those still travel to the origin and still hit the same contested worker pool. A CDN narrows the blast radius but does not remove it.
Where to go next
If the pattern looks like "slow during the day, fast at night", the next article is PHP workers and pool exhaustion, which explains the queueing model that produces it. If the pattern looks like "slow on the cart but fast on the homepage", the slow database article covers why uncached pages hit the database hard. If the pattern looks like "slow when I log in", the slow admin article walks through why the dashboard is uncacheable by design. And if you are still at the level of "the site is slow and I do not know why", the umbrella article on a slow WordPress site frames the full decision tree.