Ready for the spike: sale days and viral stories
The traffic you’ve worked for can be the thing that takes your site down. A sale email goes out to 20,000 people at 9am. A story gets picked up and shared across WhatsApp groups. Within minutes, ten times the usual number of visitors arrive at once, and a site that was fine yesterday starts timing out.
Spikes are predictable enough to prepare for, even the ones you can’t schedule. Here’s what we check.
Why sites fall over
A WordPress page is normally built fresh for each visitor: PHP runs, the database is queried and the HTML is put together. That takes a fraction of a second, but a server can only build a limited number of pages at once. When requests arrive faster than they’re finished, they queue, pages slow to a crawl, and eventually the server starts returning errors.
So the goal is simple: make most visitors cost the server almost nothing.
1. Cache whole pages
Page caching saves the finished HTML of a page and hands that copy to the next visitor, skipping PHP and the database entirely. A server that manages a few dozen freshly built pages a second can serve many times that from a cache.
It can happen at several layers: a caching plugin, the web server itself (such as Nginx’s FastCGI cache), or a CDN in front of the site. During a spike, the further out the better. A CDN like Cloudflare answers visitors from locations near them, and many requests never reach your server at all.
What must never be cached is anything personal. The cart, the checkout, account pages and pages for logged-in users all need to bypass the page cache. Get this wrong and one customer can see another’s cart, so test it carefully.
2. Make uncached requests cheaper
Some traffic can’t be cached, and during a sale that’s a lot of it: carts, checkouts and accounts. For those requests:
- Object caching with Redis or Memcached keeps the results of repeated database queries in memory.
- A tidy database helps. Clear out expired temporary data, old revisions and settings left behind by removed plugins.
- Enough PHP workers. Each worker handles one uncached request at a time. Check how many your hosting plan allows, because that’s often the real limit, not the processor.
- A current PHP version runs WordPress faster than old ones, with no change to your site’s code.
3. Test before the day
Don’t discover your limits live. A load-testing tool such as k6 or Loader.io can send a realistic mix of traffic to a staging copy on the same kind of hosting: mostly cached pages, plus searches, add-to-cart and checkout. Increase the load until response times climb, and note where that happens.
If the limit is below the traffic you expect, you’ve found out with time to fix it, or to upgrade the hosting for the event.
Only load-test servers you own or have permission to test, and warn your host first. A load test looks a lot like an attack.
4. Switch off what you don’t need
For the duration of the spike:
- Pause heavy scheduled jobs: backups, imports, stock syncs and bulk emails that normally run on the hour.
- Delay non-essential third-party scripts. Every chat widget, heatmap and tracker adds work for your visitors’ phones.
- Hold all updates. Nothing gets updated on sale day, or the day before.
5. Spread the arrivals
For a planned spike, you decide when people arrive. Send the sale email in batches over an hour rather than all at once. Put the offer live a little before the email goes out, so early visitors warm the cache. Point campaign links at a cached landing page, not at a search results page.
For news sites: when the story breaks
A viral story is a sale day with no warning. What helps most:
- Make sure article pages are cached at the CDN, and that a new article is cached from its first visit.
- When you update a developing story, clear the cache for that article only. Clearing the whole site’s cache sends every request back to the server at the worst possible moment.
- Keep ad and analytics scripts in check. A heavy ad setup slows the page for visitors even when the server is coping fine.
- Make sure comment spam protection is on, because a busy article attracts bots as well as readers.
6. Watch it live
Put uptime monitoring on a normal page and on a step that can’t be cached, like adding something to the cart. Make sure alerts reach someone who’s awake. Decide in advance who to call at your host, and what you’ll switch off first if things slow down. What 99.9% uptime really means covers monitoring that catches more than a dead homepage.
After the spike
Look at the numbers while they’re fresh: peak visitors, the slowest pages, and any errors in the server logs. Those tell you exactly what to fix before the next one.
Sizing and tuning servers for real traffic, including Redis, PHP and database tuning, is part of our server management work.