In this guide 6 sections
Slow stores lose time in a short list of places: oversized images, plugin and tag weight, uncached catalogue queries, third party scripts and a cold database during traffic spikes. Measure with browser and server timings first. Then fix the largest delay before touching anything else.
Measure before you change anything
Open the product page in Chrome, press F12 and read the Network tab with the cache disabled. Note the time to first byte for the main document, then the total transfer size and the number of requests.
A high first byte means the server or database is slow. A low first byte with a long load means the browser is busy downloading or running files. These two cases need different fixes. Guessing wastes weeks.
Run Lighthouse or PageSpeed Insights on the product page and the cart page separately. Record Largest Contentful Paint and Total Blocking Time. Test on a mid range phone profile, because desktop numbers flatter you.
Images and front end weight come first
Unoptimised images are the most common cause. A supplier sends a 4000 pixel JPEG and the theme shows it in a 400 pixel box, yet the browser still downloads the whole file. Check the file sizes.
Convert to WebP or AVIF, serve sized variants with srcset, and lazy load everything below the first screen. Do not lazy load the main product photo, since that delays the paint you are trying to speed up.
Plugins add their own CSS and JavaScript to every page, even where unused. A review widget, a wishlist tool and a size chart can each add a file. The Network waterfall shows exactly which ones. Remove what you do not use.
- Image files above two hundred kilobytes
- Plugin scripts loaded on pages that never use them
- Web fonts requested in four weights
- Render blocking CSS in the head
Third party tags quietly eat the checkout
Analytics, remarketing pixels, live chat, heatmaps and A/B testing tools each load from another domain. One slow vendor holds up your page, and you cannot fix their server. Control is gone there.
Open the Network tab and group requests by domain. Count the domains outside your own. Remove tags nobody reads reports from, and load the rest after the page is interactive using a tag manager with consent rules.
Checkout needs special care. Every extra script there sits between a buyer and the payment button. Keep only the payment gateway, the fraud check and one analytics call.
Server side causes: queries, cache and cold starts
If the first byte exceeds about a second, look at the server. Category pages with filters often run heavy queries across attributes, prices and stock tables. Turn on the slow query log in MySQL or PostgreSQL and read the worst offenders.
Add database indexes for filter columns, cache rendered category and product fragments in Redis, and put a CDN in front for images and static files. Full page caching works for anonymous visitors; the cart and account pages need exceptions.
Traffic spikes expose a different fault. A cold database cache or too few application workers means the first wave of visitors waits while connections queue. Load test with k6 before the next sale. Test early.
- Slow query log entries over one second
- Cache hit ratio at the CDN and in Redis
- Worker and connection pool limits
- Warm up routines before campaigns
Fix one cause, then measure again
Alter a single factor per test. Resize the images and retest, then remove a tag and retest. If you touch five items together you cannot tell which one helped. Patience pays here.
Keep a log of each test with date, page, device profile and numbers. Share it with whoever manages hosting, so they see the same evidence.
Pick the single slowest page today, record its first byte and Largest Contentful Paint, and fix the biggest item on that waterfall.
Store speed diagnosis sheet
A one-page table that gives each key page its own line: home, category, product, cart and checkout. Columns hold time to first byte, Largest Contentful Paint, page weight, request count, third party domains and the suspected cause. The final column notes the fix applied and the retest result.
Open a blank worksheet to printQuestions owners ask
What is a good time to first byte?
Aim for well under a second on cached pages. If uncached product pages take longer, the cause is usually queries, missing indexes or an overloaded application server rather than the images.
Will a CDN fix a slow store?
It helps with images, scripts and cached pages, but it cannot speed up a slow cart or checkout that must run on your server. Use it alongside query and cache work, not instead of it.
Why is checkout slower than product pages?
Checkout cannot be fully cached. It calls shipping rate lookups, tax rules, stock checks and the payment gateway on every step, so each slow call adds directly to the wait.
How do I test for traffic spikes?
Run a load test with a tool like k6 or JMeter against a staging copy that has production sized data. Watch response times and error counts as virtual users rise, and fix what fails first.