Most stores that feel slow are not short of CPU. They are waiting — on a database that answers the same question forty times per page, on a cache that expires the moment traffic arrives, and on a third-party script that blocks the first paint. Here is the order we work through it.
Start by separating server time from browser time. Time to first byte tells you what the server owes you; everything after it belongs to the front end. On a healthy store, TTFB sits under 200ms for a cached page and under 600ms for a logged-in cart. If your numbers are far above that, no amount of image compression will save the page.
Request latency across three regions during a flash sale. The step at 14:20 is the cache warming, not new hardware.
Find the query that runs forty times
Enable the slow query log for an hour of real traffic, not a synthetic test. In almost every store we audit, the top three entries are the same shapes: an unindexed lookup on a meta table, a count query behind a filter widget, and a join that fans out over variants. Fixing those three usually returns more than doubling the instance size.
Once the log is quiet, add object caching in front of the queries that remain. The goal is not a perfect hit rate — it is making sure the queries that survive a cold cache are cheap.
A cache is a promise about what will be asked next. When traffic spikes, the promise breaks first and the database gets the whole bill.
Warm the cache before the sale, not during
A cold cache at the moment a campaign email lands is the most common cause of a checkout timeout. Crawl your top 500 URLs fifteen minutes ahead of send, hold the TTL long enough to cover the peak, and exclude only the paths that genuinely need to be personal: cart, account, checkout.
Measure at the edge you actually serve
Averages hide geography. Break response times down by region and you will often find one location carrying the mean — usually the one furthest from your primary database. Read replicas close to your buyers fix that far more cheaply than a bigger primary.
Work in that order — measure, fix the queries, cache deliberately, then move the data closer — and the number that moves is the one customers feel: the time between tapping buy and seeing confirmation.
