The wrong question that costs money
When an online store is slow, the most common decision is: "Let's upgrade the server." Sometimes it is correct — but frequently it is the answer to the wrong question. A new server would solve the problem if the problem were the server. If it is disabled cache, a query without an index or a third-party script loaded synchronously, the upgrade just redistributes the cost without eliminating the bottleneck.
The correct question is: where is time being spent? And that answer must be data-based — not intuition, not "the hosting plan is old", not "maybe it is the theme".
Core concept: TTFB (Time to First Byte) is the most direct indicator of server + backend performance. If TTFB is low and the page still loads slowly, the problem is frontend. If TTFB is high, the problem is in the server, backend code, or database.
Step 1: measure TTFB precisely
Use WebPageTest (webpagetest.org) or Chrome DevTools (Network tab, waterfall) to measure the TTFB of a real product page — not the homepage. Product pages have more complex queries and better reflect real behavior.
Reference values:
- TTFB below 200ms: server responding well. The problem, if any, is in the frontend.
- TTFB between 200ms and 600ms: attention zone. Check cache and queries.
- TTFB above 600ms: clear backend/infrastructure problem. Investigate before anything else.
Step 2: check if the cache is active
The most common cause of high TTFB in e-commerce is not the server — it is disabled or misconfigured cache. In Magento, a disabled Full Page Cache can raise TTFB from 80ms to 3s+ on the same infrastructure. In WooCommerce, the absence of object cache and full page cache produces the same effect.
Check the HTTP response headers: X-Cache: HIT indicates the cache is working. X-Cache: MISS on all requests means nothing is being cached.
What may be disabling the cache
- Personalization plugin or A/B test that forces cache bypass per session
- Persistent cart without cache separation by session state
- Affiliate or UTM cookie being treated as a cache variable
- Incorrect Varnish or Redis configuration expiring too quickly
Step 3: identify slow queries in the database
If TTFB is high and cache is working (or no cache is configured), the next step is the database. Enable the MySQL/MariaDB slow query log with a 1-second threshold and analyze the most frequent and slowest queries.
Common patterns in e-commerce:
- Product listing without index on
priceorstatus - Options table (wp_options in WordPress) scanned without
autoloadindex - Unnecessary JOINs in order queries with thousands of records
- N+1 queries in product rendering loops
How to separate server from code
| Symptom | Likely origin | Next step |
|---|---|---|
| High TTFB, cache HIT | Undersized server | Test with warm cache; compare plans |
| High TTFB, cache MISS | Disabled or misconfigured cache | Enable and configure cache correctly |
| Low TTFB, high LCP | Frontend — images, scripts | Audit assets, lazy load, sync scripts |
| Variable TTFB (sometimes fast) | Cache cold start or exhausted connections | Check database connection configuration |
| Slow only at peak hours | Insufficient resources (CPU/RAM) | Analyze server metrics during peak |
Practical rule: Before hiring a more expensive server plan, enable cache, analyze slow queries and disable unnecessary third-party scripts. In most cases, these three actions alone solve the problem without additional infrastructure cost.
Need a speed diagnosis for your store?
Complete analysis of TTFB, cache, slow queries and third-party scripts — with report identifying whether the problem is infrastructure, code or configuration.