Your Website Slows Down at Random. It Is Not You, It Is Shared Hosting.

Your website is not slow because of anything you did.

I want to say that plainly, because most business owners I speak to have already blamed themselves. They have deleted plugins. Compressed images. Read a dozen articles about caching and rewritten half their home page. The site still crawls at odd hours, for no reason they can find. The part their host will never volunteer is this: the problem is often not on their site at all. It is the site next door.

If you are on cheap shared hosting, your website does not live on its own machine. It shares one physical server with dozens, sometimes hundreds, of other websites. You share the processor. You share the memory. You share the same disk and the same network card. When one of those other sites has a busy moment, you feel it. That is the whole argument. Most mystery slowdowns are not a mystery. They are your neighbours.

The Word Nobody Uses on the Sales Page: Oversold

Shared hosting is cheap for one reason. The host packs a lot of customers onto each server and bets that not everyone gets busy at once. Engineers have a polite name for what happens when that bet fails. They call it the noisy neighbour problem.

Microsoft's own architecture guidance puts it cleanly: in any system where tenants share resources, "the activity of one tenant can negatively affect another tenant's use of the system." Pool the resources, drop the price, and you accept a risk. When one site consumes a disproportionate share of the machine, everyone else on that machine slows down or starts throwing errors.

In practice it looks like this. A bakery a few directories over on the same server fires off a big email campaign on a Tuesday morning. Two thousand people click through in ten minutes. Their surge eats the server's processor. Your booking page, sitting on the same box, suddenly takes six seconds to load for a customer who was ready to book. You did nothing. You changed nothing. You just had a bad neighbour on a bad morning.

Why It Always Feels Random

The cruel part of the noisy neighbour problem is the timing. It is intermittent. Your site is fine all morning, unusable at one o'clock, fine again by two. You cannot reproduce it. By the time you have rung anyone, it has cleared.

That randomness is not bad luck. It is the signature. Microsoft's guidance makes the same point from the technical side: if the same request "succeeds at other times and appears to fail randomly, there might be a noisy neighbor problem." A site that is slow because of its own bloated code is slow consistently, every visit, all day. A site that is fast except for unpredictable bad patches is usually sharing a server with someone who got busy.

So what does that mean for you? It means the hours you spent hunting for the fault on your own site were never going to find it. The fault was never yours to fix. It was two directories over, on a server you cannot see.

What Actually Gets Fought Over

When people hear "shared server" they picture disk space, and assume that as long as they are under their storage limit, they are fine. Storage is rarely the problem. The things that get contended are the things you cannot see.

• The processor (CPU). WordPress builds most pages on the fly, running PHP every time someone visits. Every visit to every site on the box competes for the same cores.
• Memory (RAM). WordPress needs real headroom to run. Its own defaults ask for 40MB just to render a front-end page, and the admin side reaches for 256MB, as the WordPress.org requirements spell out. Put a busy WooCommerce store next to you and memory gets tight fast.
• Disk input and output. Every database query, every image read, every log written joins the same disk queue.

Even hosts that advertise "guaranteed resources" cannot fully wall these off. The engineering write-ups on multi-tenant systems consistently note the same thing: some resources simply cannot be isolated by software alone. The deepest levels of processor cache, the lanes that move data around the machine, the disk queue itself. Software limits help. They do not make the wall soundproof.

This is a different problem from hitting your own plan's ceiling. I have written before about what happens when your own site outgrows its resource limits and starts throwing errors when you are busiest. That is your traffic, your cap, your fix. The noisy neighbour is the opposite: someone else's traffic, spending your performance.

The Evening the Bookings Went Quiet

Picture a physiotherapy clinic in Roscommon. Nothing fancy. A tidy WordPress site with an online booking form, which is how most of their new patients get in. For weeks the owner noticed the booking page felt sluggish around six in the evening, right when people finished work and sat down to sort out their week. She assumed it was her broadband, or the booking plugin, and moved on.

It was neither. Something else on her shared server, some business she will never know the name of, was hammering the machine every weekday evening. Her booking page was timing out for exactly the people most likely to book. She was not losing money to a broken site. She was losing it to a slow one, which is worse, because nothing looked broken. The enquiries just quietly went somewhere faster.

That is the real cost. Not downtime you can see. Customers you never hear about. The CSO reported that in 2025 roughly 29% of Irish enterprises were taking orders, reservations or bookings directly through their website. For any business in that group, a slow evening is not a technical annoyance. It is a lost evening.

What a Host That Takes This Seriously Actually Does

A proper host does not pretend the noisy neighbour problem away. It engineers around it. Three things separate a server you can trust from a box someone oversold and forgot.

First, headroom. The machine is not packed to the last drop of capacity, so one busy site does not tip the whole server over. Second, active management. Somebody is actually watching resource usage, with alerts when a site starts eating more than its share, and the means to act before it drags everyone down. Microsoft's guidance lists exactly this: monitor per-tenant usage, apply resource governance, and keep capacity in reserve. Third, a properly built stack, so each site does more with less. Good caching means a page is served from memory instead of being rebuilt by the processor on every single visit, which takes the pressure off the shared parts in the first place.

That last point is worth sitting with. Google's own performance guidance at web.dev puts a good server response, the time to first byte, at under 0.8 seconds, and a contended shared box routinely blows past that at peak. Everything the visitor sees afterwards, the text, the images, the button they came to click, arrives late as a result. If most of your pages are served straight from cache instead, your site barely touches the contended processor at all, and your neighbour's bad morning stops being your problem. It is worth knowing how fast a business website should actually load before you accept "usually fine" as an answer.

This is the standard the enterprise-grade Irish infrastructure behind Web60 was built to meet. Managed WordPress running an optimised stack, Nginx with Redis object caching and full-page caching, on sovereign Irish infrastructure watched by an Irish operations team rather than left to chance. The aim is boring, in the best way. Your site should behave the same at six in the evening as it does at six in the morning.

One honest caveat. Moving to a properly resourced host fixes the neighbour. It does not fix you. If your own site is carrying thirty plugins and a two-megabyte image on every page, it will still be slow on the best infrastructure in the country, just slow on its own terms instead of your neighbour's. Isolation from the crowd buys you a fair share of a fast machine. What you build on that share is still down to you, and the full performance guide for business owners covers the rest of the story.

Where Shared Hosting Is Genuinely Fine

I am not going to tell you shared hosting is always the wrong call. That is the kind of blanket claim I distrust when other people make it.

If you are running a simple, mostly static site, a one-page brochure for a business that gets its custom by phone and word of mouth, with light and steady traffic, cheap shared hosting is perfectly sufficient. You will likely never notice a noisy neighbour, because you are barely using the machine and, on a quiet server, neither is anyone else. Paying for managed infrastructure there is spending money to solve a problem you do not have.

The calculation changes the moment your website has a job to do. A booking form. A shop. A contact form that feeds real enquiries. Once a slow afternoon costs you actual customers, "usually fine" stops being good enough.

What To Do About It

Knowing whether this is you comes down to the pattern, not the moment. If your site is reliably slow, the fault is probably on your site, and that is fixable. If it is fast most of the time and mysteriously terrible in unpredictable bursts, you are very likely sharing a server with someone busier than you.

Two questions will tell you most of what you need before you commit to any host. Ask how many sites they put on a single server, and what happens when one of those sites gets busy. A host with a real operations team will give you a straight answer. A host that oversells will change the subject.

Your website is meant to be the one part of your business that works while you are asleep. It should not have an off day because a stranger three directories over had a good one.

Frequently Asked Questions

Why is my website slow at certain times of day only?

Intermittent slowness that comes and goes is the classic signature of the noisy neighbour problem on shared hosting. Your site shares one physical server with other websites, and when one of them gets busy it consumes the shared processor, memory and disk, slowing everyone else down. A site that is slow because of its own code is slow consistently. A site that is fast except for unpredictable bad patches is usually sharing a server with someone busier than you.

How do I know if my website is on shared hosting?

If you are paying a low monthly or yearly fee and were never told how many other sites sit on your server, you are almost certainly on shared hosting. The simplest check is to ask your provider two questions: how many websites do you put on a single server, and what happens when one gets busy? A managed host will give you a straight answer. A host that oversells its servers tends to change the subject.

Can a slow neighbouring website really affect my own site?

Yes. On shared hosting your site does not have its own machine. It shares the processor, memory, disk and network card with every other site on the box. When a neighbour has a traffic spike or runs a heavy job, it can monopolise those resources and leave your site crawling, even though nothing on your site changed. Engineers call this the noisy neighbour problem, and it is well documented in cloud architecture guidance.

Will moving to managed WordPress hosting fix random slowness?

It fixes the part caused by your neighbours. A properly managed host keeps headroom on each server, watches resource usage actively, and runs an optimised caching stack so each site does more with less. That removes the noisy neighbour as a cause. It will not fix slowness caused by your own site, such as too many plugins or oversized images, so it is worth ruling both out.

Does buying a bigger plan or more RAM fix the noisy neighbour problem?

Not reliably. A bigger allowance raises your own ceiling, but if you are still on a shared server, a busy neighbour can still contend for the physical processor and disk you both depend on. Some things simply cannot be walled off by software limits. The durable fix is a host that resources its servers properly and manages contention, not a larger slice of the same crowded machine.

Sources

Google, web.dev: Time to First Byte (TTFB)

Microsoft Learn: Noisy Neighbor antipattern, Azure Architecture Center

WordPress.org: Requirements

Central Statistics Office: E-Commerce, Information Society Statistics, Enterprises 2025