Why your shopping app feels slow, and where to look first
Speed in commerce apps is rarely one big problem. It's a stack of small ones across APIs, payloads, and screens. Here's the order we tackle them in.
Oct 26, 2026 · 2 min read
On Drops, one of Kuwait's leading grocery delivery apps, performance work across the shopping journey delivered API responses up to 3x faster. That kind of gain rarely comes from one heroic fix. It comes from measuring carefully and then working through a predictable list of usual suspects.
Here's the order we work in when a commerce app feels slow.
1. Measure the journey, not the server
Average server response time hides the problem. Users experience journeys: open app, see home, search, open product, add to cart, check out. Instrument each step end-to-end on real devices and track the slow tail (p95 and p99), not just the average.
You'll usually find that two or three screens account for most of the pain.
2. Kill request waterfalls
The most common culprit on a home screen is a waterfall: fetch the user, then fetch their store, then fetch banners for that store, then fetch the products in each banner. Every step waits for the one before it.
Fixes, in rough order of effort:
- Fire independent requests in parallel instead of in sequence.
- Add a single aggregated endpoint for screens that always need the same data together.
- Move data that rarely changes, like categories and store configuration, out of the critical path entirely.
3. Send less data
Catalog APIs tend to grow fields over time until a product list response carries everything needed to render a product detail page, for every product.
- Return only the fields each screen renders.
- Paginate long lists and load the next page before the user reaches it.
- Serve images at the size they're displayed, from a CDN, in modern formats.
4. Cache with intent
Not all commerce data is equally fresh. Prices and stock change; category trees and banners mostly don't. Give each kind of data an explicit freshness rule and cache accordingly, on the server and on the device.
5. Make the app feel fast while it works
Perceived speed matters as much as measured speed:
- Show skeleton layouts immediately instead of spinners.
- Update the cart optimistically and reconcile with the server in the background.
- Keep the last-known home screen on device so returning users see content instantly.
6. Don't weld the app to one backend
Commerce platforms change. On Drops, a modular data layer meant the app could switch core commerce platforms without a costly rewrite. Putting a clean boundary between your screens and your commerce platform makes performance work easier too, because you can optimize behind the boundary without touching UI code.
Measure the journey, fix the waterfall, trim the payload, cache with intent, and then polish perceived speed. In that order.
Performance isn't a one-time project. Add the journey metrics to your release checklist so the next feature doesn't quietly undo the last optimization.