Rebuilding a Bangladeshi fashion e-commerce site for speed: Next.js SSR, sub-1.5s LCP on mobile, and a 25% conversion lift from checkout optimization.

#Next.js #React #Material UI #E-commerce

The Problem

MIAH sells traditional and modern clothing to customers across Bangladesh, and the majority of their traffic comes from mobile devices on mobile data connections that fluctuate between 3G and unstable 4G. The previous site was built on an architecture that couldn't keep pace with real traffic: page loads exceeded 4 seconds on 3G, product images weren't optimized for mobile bandwidth, and the checkout flow added friction at exactly the point where customers were most likely to abandon their cart. The cart abandonment rate was high, and the drop-off was concentrated at the payment step where every additional second of load time translated directly into lost revenue. Performance wasn't a secondary concern — it was a primary product requirement, because the customer base was on connections where every kilobyte mattered.

The catalog complexity compounded the challenge. Hundreds of SKUs across menswear, womenswear, and kidswear, each with size charts, color variants, and seasonal collections. Inventory was synced from the ERP to the storefront on a scheduled batch job, which meant the storefront could show stock that had already been sold for up to an hour — and the first the customer knew about it was an "out of stock" email after they had already paid. Product search was a simple SQL LIKE query with no relevance ranking. These weren't exotic problems; they were the consequences of an architecture built quickly and never revisited as the business grew.

What We Built

We rebuilt the storefront on Next.js, using server-side rendering for instant first paint on product and category pages and incremental static regeneration for pages that update frequently. The choice between SSR and ISR was made per page type: product pages used SSR because their content can change at any moment and a stale page is a customer-service problem; category pages used ISR with a 60-second revalidation window because they're aggregations where a small staleness window is acceptable in exchange for CDN-edge caching performance. Styling combined Material UI and Bootstrap in a hybrid approach — Material UI for complex interactive components, Bootstrap's grid for layout — because the hybrid shipped faster than a forced migration to a single library would have.

Checkout was the hardest part to get right. Every retry had to be idempotent, meaning a customer's connection dropping and their browser silently retrying a request could never result in a double charge or a duplicate order. That required idempotency keys generated on each checkout attempt and tracked by the backend for 24 hours, so the payment gateway and order service could safely recognize and discard duplicate submissions. Formik handled the multi-step form state, Axios was configured with retry logic for network drops, and the form fields were reduced to only those strictly required to fulfill the order — every "nice to know" field was moved to an optional post-purchase survey.

The Outcome

The rebuilt site achieves sub-1.5 second Largest Contentful Paint on mobile, and it holds top-3 organic search rankings for the brand's core keywords — a direct consequence of the performance improvement, since Core Web Vitals are a ranking factor and the previous site's LCP was bad enough to actively suppress rankings. Checkout optimization delivered a 25% lift in conversion rate, largely by removing unnecessary form fields and giving customers clear, immediate feedback on validation errors. The site handles flash sale traffic spikes without falling over, which in practice is the real stress test — steady-state performance is one thing, but surviving a coordinated marketing push that sends a surge of concurrent shoppers to checkout at once is what actually proves the architecture.

The flash-sale resilience came from a combination of CDN-level caching of static assets, rate limiting on the checkout API, and a queue-based order processing backend that absorbs spikes rather than trying to process every order synchronously. That architecture decision — queue-based order processing — was the one I was most uncertain about, because it added latency to the order confirmation flow (the customer's order goes into a queue and is processed within seconds, not instantly). In practice, the added latency was invisible to customers and the resilience was invaluable, and the lesson I took from it was that perceived synchronicity is less important than actual reliability. Customers would rather have a 3-second order confirmation that always works than a 1-second confirmation that sometimes fails.