In 2020, much of daily life moved online within weeks. Shops, schools, clinics and cinemas needed websites or bigger ones. Hosting providers saw record signups, delivery companies saw traffic spikes, and many small sites learned how a flood of visitors feels.
It was a stress test for the infrastructure and a lesson in preparation. Sites with caching and a CDN coped. Sites without them discovered the limits of their plans at the worst time.
The support queue in March of that year looked like nothing before it. Tickets that normally read "how do I change my nameservers" became "my shop has to open for collection orders on Monday, can you help". This chapter looks at what broke, why, and which of the fixes turned out to be the dull, cheap ones.
Who needed what, overnight
The new demand came from three directions. First, businesses that had never needed a site: a local greengrocer taking orders by phone, a gym moving classes onto video, a hairdresser wanting bookings. Second, organisations that already had a website but had treated it as a brochure, such as schools and clinics, which now used it for notices, forms and timetables. Third, ordinary growth in visitors to sites that were useful in a crisis, from news pages to local council information.
Many of those owners chose a host in an afternoon and built the site in a weekend. That is understandable, and it often worked. The trouble was that "works when I test it" and "works when four hundred people open the page at ten to eight on a Monday" are different standards.
What actually fell over
When a small WordPress or shop site slows to a crawl, the cause is rarely bandwidth. It is almost always the work the server does per visitor. Every uncached page view runs PHP, queries the database, builds the page and sends it. A plan has a limited number of PHP processes and a limited slice of CPU and memory. Once all the processes are busy, new visitors wait in a queue, and past a point they see an error such as 503 or 508 instead of a page.
Other failure modes were less glamorous. Images straight from a phone camera, a few megabytes each, turned a light page into a heavy one; the page weight tool shows how quickly that adds up. Booking and shop plugins made database queries that were fine for ten users and hopeless for a hundred. Some sites ran out of disk space or mailbox quota because their owners suddenly emailed a lot more than before.
Why caching and a CDN worked
A page cache saves the finished HTML of a page and serves that file to the next visitor, skipping PHP and the database. A CDN does the same one step earlier, at a server close to the visitor, and also serves images and scripts. For a page that is the same for everyone, such as a menu, a news notice or a timetable, one request in several thousand needs to reach the origin.
It does not help with everything. Pages that differ per person, like a basket or a logged-in account, cannot be cached for everyone, and checkout is the part that falls over first. The better-prepared shops kept those few pages as light as they could and let the cache take the rest.
A preparation routine that costs almost nothing
None of the fixes that mattered needed a bigger budget. They needed an afternoon before the traffic arrived:
- Turn on a page cache and check, with
curl -I, that it is being hit. - Resize images before upload, and serve them at the size they are shown.
- Put a CDN in front, with reasonable cache rules for static files.
- Look at your plan's limits for PHP processes, memory and entry processes, and ask the host what happens when they are reached.
- Test the checkout or booking form separately, with several people at once.
What stuck afterwards
Many of the sites that appeared in 2020 stayed, and so did their lessons. Hosts began to put caching on by default in their managed plans. Owners learned to look at traffic graphs before an announcement and not after. Capacity became something to plan: if you know a mailing list goes out at nine, you can warm the cache first.
To check where you stand, load the busiest page with curl -I https://example.com/ and look for a cache header such as x-cache or cf-cache-status, then compare response times for the first request and the second. The uptime calculator shows what an hour of downtime means for a year, and Hosting Autopsy has composite stories of traffic spikes that went wrong.