At ten in the morning the site is fine. You send the festival offer to your mailing list at noon, post it on Instagram, and within minutes people are messaging you to say the site will not load. By evening it is quick again, and your host says nothing is wrong. Next month, on the day of your sale, it happens again, only worse.
A website slow at peak times is not slow in the usual sense. With one visitor it may be perfectly quick. The problem is capacity: how many visitors it can serve at once before they start waiting for each other. That is a different question from page weight or image size, and it has different answers. If your site is slow all day, not only when busy, the general triage for a slow website is a better place to start.
Why a busy site slows down: the billing counter
Think of a shop with two billing counters. With three customers, nobody waits. With thirty, the counters are no slower at their job, but everyone queues. Your server works much the same way.
When a visitor asks for a page that is not already cached, the server has to run PHP to build it. It can only run so many of those jobs at the same time. On WordPress hosting the processes that do this are often called PHP workers, and the post on what PHP workers are and why they queue explains them properly. For this post, the counter picture is enough: when every worker is busy, new requests wait in line, and the wait is what your visitors feel.
Shared hosting adds a second layer. Your account is usually given a set share of processor time, memory and simultaneous processes. When you hit that ceiling, the host slows your account down or refuses some requests until the load falls. Your site is not broken; it is being held to the limits of the plan. How shared hosting limits work covers what those limits are called and where to see them.
Cached visitors are cheap, uncached visitors are expensive
The reason some sites cope with a rush and others fall over is mostly about how many visitors can be served from cache.
A cached page is a saved copy. Serving it is quick and uses very little of the server. A visitor reading your blog or browsing a cached product page barely registers. An uncached request is a full build: PHP runs, the database is queried, plugins do their work. That is where capacity goes.
Some pages cannot be cached for everyone, by design:
- The cart, checkout and account pages on a shop.
- Search results, and shop pages filtered by price, size or colour.
- Anything a logged-in customer or member sees.
- Forms that are processed on submit, booking calendars that check availability live, and stock checks.
- Background requests from the page, such as cart updates and live search suggestions.
So the question during a rush is not just “how many visitors” but “how many visitors doing uncached things”. A thousand people reading an article may be fine. A hundred people adding items to their carts and checking out at once can use far more of the server.
Is it really busy, and busy with whom?
Before blaming capacity, confirm the timing. Note when people complained, then compare with:
- Your analytics. Did visits genuinely jump at that time? Real-time reports are useful on the day itself.
- Your hosting panel. Most panels show processor, memory and process usage over time. Look for usage pressed against the limit at the same hour as the complaints.
- Error messages. On many shared hosts, a site that hits its limits shows errors such as 503 Service Unavailable or a “resource limit reached” page instead of loading slowly. If visitors saw an error rather than a long wait, that is strong evidence of a capacity limit.
- Access logs. They show every request with its time and source. A spike of human visitors after your email looks different from thousands of requests from a handful of addresses.
That last point matters. Sometimes the crowd is not customers at all but crawlers, scrapers or login attempts, and they can arrive at any hour. If the logs show the load coming from automated traffic, read how bot traffic eats server resources before buying more capacity for visitors who will never buy anything.
When a site slows down when busy, check these first
These are the usual reasons a site that is fine on a quiet day struggles on a busy one. Start at the top; the last item is the one people tend to jump to first.
- Page caching is missing or not covering enough. Without it, even ordinary pages are full builds. Make sure your public pages really are cached; check a response header or the caching plugin’s status.
- Something clears the whole cache in the middle of the rush. Editing a product, changing a price or publishing a post can purge the entire site cache on some setups. Now every visitor is uncached at the worst possible moment.
- A heavy uncached page everyone visits. A sale landing page with live stock counters, a search-driven shop page, or a page with a booking widget that queries the database for every visitor.
- Background requests multiplied by visitors. Cart updates, live chat checks, popups that call the server. Harmless with ten visitors, heavy with five hundred.
- Scheduled jobs running at the same time. Backups, imports, email sends and WordPress’s own scheduled tasks can compete with visitors for the same server.
- The plan really is too small for the number of uncached requests you now get. That is a real answer sometimes, but it should be the conclusion after the others, not the first guess.
Preparing for a day you know will be busy
The useful thing about sales, launches and campaigns is that you know the date. A little preparation goes a long way.
- Warm the cache on the pages you will promote, after you have made your last edits, so the first wave of visitors gets saved copies.
- Freeze changes. Do not update plugins, edit products or change prices during the peak if you can avoid it. Each change can clear caches and introduce surprises.
- Move scheduled jobs such as backups and big email sends away from the expected busy hours.
- Keep the landing page simple. One clear page that can be cached, rather than a live-updating countdown with stock counters that must be built for every visitor.
- Talk to your host in advance. Tell them the date and roughly what you expect. Some hosts can raise limits temporarily or advise on the plan; at the least they will not be surprised.
- Stagger your announcements if your audience is large: email in batches, social posts a little later, rather than every channel in the same minute.
For shops in particular, our checklist on preparing a WooCommerce store for a festival sale covers stock, payments and coupons alongside the speed side.
On the day, and afterwards
During the busy period, watch the hosting panel’s usage graphs and your analytics side by side. If the site starts to struggle, the quickest relief is usually to remove whatever uncached work you can: turn off a live widget, pause a heavy popup, delay a scheduled job.
Afterwards, write down what happened while it is fresh: the time of the peak, how many visitors you had, which pages they hit, what the server graphs showed and what errors appeared. That record is what tells you whether next time you need better caching, a lighter landing page or a bigger plan. Our website speed and performance guide links the hosting and caching sections you will need for each of those.
Mistakes that leave a website slow at peak times
- Testing the site at quiet times and concluding it is ready for a sale.
- Editing the sale page repeatedly once traffic has started, purging the cache each time.
- Upgrading the hosting plan without checking whether pages were cached in the first place.
- Running a large backup or product import during the campaign.
- Pointing every channel at an uncached search or filter page instead of a simple landing page.
Frequently asked questions
Why does my site show an error instead of just loading slowly when it is busy?
Many shared hosts enforce account limits by refusing extra requests once you reach them, which shows up as a 503 or a resource limit message. The server is protecting other accounts on the same machine. Seeing these errors at busy times is a strong sign you are hitting the plan’s limits rather than having a slow page.
Will a CDN let my site handle a big traffic spike?
A CDN takes images, styles and scripts off your server, which helps. Whether it takes the pages themselves depends on whether it caches HTML. Even then, carts, checkouts and logged-in pages still go to your server, so a shop under heavy load needs server capacity as well.
Can I test how many visitors my site can handle before a sale?
Load testing tools exist, but sending heavy artificial traffic to a shared hosting account can breach the host’s terms or affect other sites on the server. Ask your host first. A simpler check is to review last year’s peak in analytics and the server usage graphs from that day.
Why is my site slow every evening even without a campaign?
Evenings are a normal busy time for many audiences, and on shared hosting your neighbours may be busy too. Scheduled tasks such as backups sometimes run then as well. Compare your usage graphs with your analytics; if the server is not near its limits, look at what else runs at that hour.
Before a big sale, a second pair of eyes on caching and server response can be worth having. Our speed optimisation service includes a review of hosting server response time, and if the plan really is the limit, we will say so clearly rather than tuning around it.
Next in this series: Website Slow in Other Countries? Fixing Overseas Speed
