Keeping a WooCommerce store online through its biggest sale of the year

Business context

An online outdoor gear store sells tents, packs and climbing kit to weekend and long-distance hikers. Seven people run it, and the store's two sales a year bring in a large share of annual revenue. A sale weekend can carry a normal month's worth of orders.

We handled WooCommerce performance optimization and a hosting move so the store could survive its next sale instead of falling over during it. It is a smaller version of the cloud optimization work we do for other teams; a cost-focused example is cutting a SaaS company's AWS bill.

The problem

The store sat on a shared hosting plan that cost little and showed its limits at the worst moment. During the spring sale the site returned errors for most of the first morning, and checkout timed out for some customers.

Pages were heavy. Product photos were full-resolution files straight from a camera, some larger than 4MB. There was no page caching and no CDN, so every visitor waited on the same single server to build the page from scratch.

Nobody had measured any of it. The team knew the site felt slow and knew it had gone down twice, but there was no record of load times, no uptime monitor, and no way to tell how many customers left at the payment step.

What we built

We moved the store off shared hosting onto managed containers that can grow during a sale. The new setup keeps WordPress and WooCommerce as they are, so the team kept the admin they already knew, and adds the pieces the site was missing.

A CDN from Cloudflare serves images and static files from locations near the customer. Page caching handles the product and category pages that do not change per visitor, and Redis caches the database queries behind them. Checkout and account pages bypass the cache, because a cached cart is a broken cart.

We shrank product images during upload and converted them to modern formats, keeping the originals on disk. A single product page dropped from several megabytes to a few hundred kilobytes without a visible change on screen. We also cleared thousands of stale rows from old plugin tables, which had been slowing every product query.

Uptime monitoring checks the store every minute and alerts the team on their phones. Hosting cost went up, which we told the owner before we started: the cheap plan was cheap because it was failing.

The migration itself

We built the new environment beside the old one, copied the database and files, and tested a full checkout with a real payment. Then we changed the DNS during a quiet weekday night and watched orders for 48 hours. The old server stayed ready for a week in case we needed to roll back. We did not.

Rollout

• Week 1: Auditing the current host, measuring load times and checking how large the images really were.
• Week 2: Building the new container environment, the CDN, caching and image handling.
• Week 3: Rehearsing the migration, then moving the live store on a weeknight with monitoring on.

Before and after

Measure	Before	After
Mobile load time	8.4 seconds	2.6 seconds
Uptime during a sale	Two outages in the spring sale	No outage in the autumn sale
Checkout completion	39%	58%
Product page weight	Up to 4.4MB	Under 400KB

Results

Mobile load time fell from 8.4 seconds to 2.6 seconds on a mid-range phone. The next sale ran on the new setup with no outage and no support tickets about the site being down. Checkout completion rose from 39% to 58% over the two sale weeks, which the owner attributes mostly to pages that finally load on a phone.

The site is faster because of several changes, not one. The CDN, the caching and the smaller images each removed part of the delay. We measured them separately so the owner could see which ones mattered before agreeing to pay for the new hosting.

Lessons learned

• The migration plan mattered more than the new server. We spent a day rehearsing the cutover on a copy, including a real payment, and that rehearsal caught a plugin that stored its license key against the old hostname. Without it, checkout would have broken on the first order after the move.
• We assumed the database was the slow part because it was the oldest piece. It was not. Images and missing caching caused most of the delay, and the database clean-up was a smaller win than expected.
• The owner had never seen an uptime number, only the two outages. Putting a monitor in place changed the conversation from a feeling to a graph everyone could read, which made the case for the cost increase easy.