React Commerce at Scale: Rebuilding a Slow Fashion Marketplace Without a Full Rewrite

Project: React Performance Optimization, Front-End Architecture Refactoring, and Checkout Experience Improvement

Duration: 16 weeks

ModaNest is a fast-growing online fashion marketplace that sells clothing, shoes, accessories, seasonal collections, and limited-edition designer drops. The company began as a simple catalog website but quickly expanded into a complex React and Next.js application with personalized feeds, product recommendations, real-time stock indicators, advanced filters, wishlist features, loyalty rewards, size guidance, promotional banners, editorial content, and multi-step checkout. The product team had successfully added business features, but the front-end experience became increasingly heavy. Customers could browse thousands of products, but mobile users often experienced slow loading, delayed filter responses, unstable layouts, and lag during checkout. The business wanted a faster experience, but a full rebuild was considered too risky because the platform supported daily sales, seasonal campaigns, influencer launches, and paid acquisition traffic.

The application had become too client-side heavy. Product listing pages loaded too many interactive widgets upfront, global state providers caused wide re-render cascades, large third-party scripts competed with React during hydration, and product grids rendered too many items at once. Filtering by size, brand, color, price, discount, and availability caused expensive recalculations and unnecessary component updates. The checkout flow also suffered because validation, analytics, payment widgets, promo code logic, and shipping calculations were all running too close to user input events.

Business signals

• Mobile users were leaving product listing pages before applying filters.
• Paid campaign landing pages had weak performance scores, increasing acquisition waste.
• Checkout abandonment was higher on mobile than desktop.
• Customers complained that size selection and cart updates felt delayed.
• Merchandising teams wanted to add new recommendation sections, but engineering feared more JavaScript growth.
• Seasonal campaign pages performed inconsistently during high-traffic launches.
• Product managers lacked clear visibility into whether new features were hurting performance.
• SEO-focused category pages were losing ranking potential because loading performance was unstable.
• Customer support received repeated complaints about pages freezing during sale events.

Technical signals

• Initial JavaScript payload on product listing pages was too large.
• Product grid pages rendered hundreds of cards during initial load.
• Global React Context providers caused unrelated components to re-render together.
• Wishlist, cart, user session, currency, promotion, and recommendation state were placed too high in the component tree.
• Filtering and sorting logic ran synchronously on the main thread.
• Product recommendation modules loaded even when they appeared below the fold.
• The size guide modal was included in the default page bundle even when most users never opened it.
• Analytics and marketing scripts executed during hydration.
• Product image dimensions were inconsistent, causing layout shifts.
• Promotional banners loaded late and pushed product content down.
• Checkout validation ran too frequently during typing.
• Payment provider scripts loaded earlier than necessary.
• Bundle growth was not monitored in CI.
• React memoization was applied randomly instead of being guided by profiling.

Metrics C L S: 0.22 on product detail pages

I N P: 412ms at p75 on product listing pages

L C P: 5.2s at p75 on mobile category pages

Cart Update Delay: 450ms average delay after changing quantity on mobile

Checkout Input Delay: Noticeable lag during address entry and promo code validation

Average Hydration Time: 3.4s on mobile category and listing pages

Third Party Script Cost: Multiple long tasks during early page load and checkout

Filter Interaction Delay: 380ms to 760ms depending on product count

Product Card Render Count: Hundreds of product cards rendered during initial listing page load

Initial Java Script Payload: 1.04MB compressed on product listing pages

Pages Measured

• Homepage
• Category landing pages
• Product listing pages
• Product detail pages
• Wishlist page
• Cart page
• Checkout flow
• Campaign landing pages

Primary Audience: Mobile users on mid-range Android devices and iOS Safari

Measurement Window: 30 days before optimization

The team began by separating assumed backend problems from actual front-end bottlenecks. Real-user monitoring, browser traces, bundle analysis, and React profiling showed that the largest issues came from excessive JavaScript, broad state updates, expensive product grid rendering, and third-party scripts running at the wrong time.

What we inspected

• Title: Real-user performance monitoring

  Description: The team added route-level tracking for LCP, INP, CLS, hydration time, long tasks, cart update delay, checkout input delay, and filter interaction timing. This showed that product listing pages and checkout were the most damaging parts of the customer journey.

• Title: React Profiler review

  Description: Profiling showed that changing one filter caused large parts of the listing page to re-render, including product cards, recommendation panels, sticky headers, wishlist buttons, promotion banners, and tracking wrappers. Many updates were unrelated to the user's actual action.

• Title: Bundle and dependency audit

  Description: The bundle report revealed that several large modules were included too early. Size guide logic, review widgets, loyalty modals, recommendation carousels, icon sets, analytics tools, and payment helpers were all increasing first-load cost.

• Title: Checkout interaction tracing

  Description: Chrome performance traces showed long tasks while users typed shipping details, applied promo codes, selected delivery options, and updated cart quantities. Validation and analytics were running inside critical user interaction paths.

• Title: Image and layout stability review

  Description: The design relied heavily on product photography, but image containers did not consistently reserve space. Sale labels, stock badges, size warnings, and delivery messages often appeared late and caused layout shifts.

• Title: Third-party governance review

  Description: The team documented every external script, who owned it, which route required it, and whether it was essential before interaction. Several scripts had been added for short campaigns and never removed.

The main challenge was improving the performance and maintainability of the React application while the business continued to launch new collections every week. ModaNest could not freeze development, pause marketing campaigns, or rebuild the platform from the ground up. The engineering team needed to reduce JavaScript weight, improve Core Web Vitals, fix slow interactions, simplify state management, and protect checkout revenue without changing the entire technology stack. The work also had to support real mobile users, not only high-end desktop devices used by developers.

The solution focused on targeted architectural recovery rather than a risky rewrite. ModaNest kept React and Next.js but changed how pages loaded, hydrated, rendered, and updated. The team reduced JavaScript, isolated state, virtualized product grids, delayed non-critical modules, stabilized layouts, and moved expensive work away from urgent user interactions.

Strategy

• Reduce route-level JavaScript before optimizing individual components.
• Prioritize server-rendered content for SEO and first paint.
• Hydrate only components that need immediate interaction.
• Move state closer to the components that use it.
• Prevent product grid re-render cascades.
• Virtualize long product lists.
• Delay recommendation, loyalty, review, and size guide modules.
• Move analytics away from critical interaction paths.
• Stabilize product images, price blocks, and promotional layouts.
• Measure improvements with real-user data.
• Add performance budgets to prevent future regression.

Phase1 Title: Route-level architecture cleanup

Actions

• Moved static category content, editorial blocks, and campaign copy to server-rendered sections.
• Reduced client-side rendering for content that did not need immediate interaction.
• Split product listing page shells from interactive widgets.
• Delayed below-the-fold recommendation carousels.
• Added Suspense boundaries around non-critical modules.
• Separated campaign landing pages from heavy marketplace widgets.
• Removed unnecessary shared layout components from checkout routes.

Description: The team separated pages by business purpose. SEO-heavy category and editorial pages were made more server-rendered, while highly interactive listing and checkout routes kept client behavior only where needed.

Phase2 Title: JavaScript payload reduction

Actions

• Lazy-loaded the size guide modal only when opened.
• Moved review widgets out of the initial product detail page bundle.
• Replaced broad icon imports with direct icon imports.
• Split loyalty rewards logic from default product listing routes.
• Delayed recommendation engine hydration until after primary content became usable.
• Removed duplicate utility libraries for formatting price, currency, and dates.
• Loaded payment provider scripts only when users entered the payment step.
• Added route-level bundle reports to pull requests.
• Introduced CI bundle budgets for category, listing, product detail, cart, and checkout routes.

Description: The team reduced the amount of JavaScript shipped on first load. Features remained available, but they no longer loaded before users needed them.

Phase3 Title: React state ownership refactor

Actions

• Split large Context providers into smaller route-specific providers.
• Moved filter state closer to the filter panel and product grid.
• Separated cart summary state from full cart detail state.
• Moved wishlist button state into isolated product-card-level boundaries.
• Used memoized selectors for derived product counts and filtered result sets.
• Stabilized object references passed to product cards.
• Stabilized callback references passed to filter chips and sort controls.
• Removed unnecessary wrapper components that caused render cascades.
• Applied React.memo only to components proven expensive by profiling.

Description: The original application used large shared providers for cart, user session, wishlist, promotions, filters, currency, and recommendations. This made small state changes trigger wide rendering work.

Phase4 Title: Product grid virtualization

Actions

• Virtualized the product grid so only visible product cards rendered.
• Reduced DOM depth inside product cards.
• Moved secondary product information behind expandable sections.
• Lazy-loaded product images as they approached the viewport.
• Reserved fixed image ratios for product thumbnails.
• Separated quick-view functionality from the default card bundle.
• Deferred wishlist animation logic until user interaction.
• Reduced the number of dynamic badges rendered on initial load.

Description: Product listing pages often displayed hundreds or thousands of products. Rendering every card immediately created large DOM trees and unnecessary React work.

Phase5 Title: Filter and sorting interaction improvements

Actions

• Updated filter button UI immediately before recalculating product results.
• Debounced rapid filter changes on size, color, and price inputs.
• Moved expensive sort calculations away from urgent click handling.
• Precomputed common filter counts on the server.
• Cached derived filter data for repeated interactions.
• Reduced synchronous work after selecting size or brand filters.
• Separated visible filter state from committed query state.
• Moved analytics events outside the filter interaction path.

Description: The team focused on making filters feel instant. Users needed immediate visual feedback even when result recalculation required more work.

Phase6 Title: Checkout responsiveness recovery

Actions

• Changed address validation from every keystroke to blur and step submission.
• Deferred promo code validation until the user submitted the code.
• Moved cart analytics events into a lightweight queue.
• Loaded payment provider scripts only on the payment step.
• Split checkout validation rules by step.
• Reduced synchronous cart recalculation after quantity changes.
• Optimistically updated quantity controls before server confirmation.
• Separated shipping estimate updates from high-priority input events.
• Removed one unused fraud-check script from the cart step.

Description: Checkout performance directly affected revenue, so the team removed unnecessary work from typing, quantity updates, promo code entry, and delivery option selection.

Phase7 Title: Third-party script control

Actions

• Delayed non-essential analytics until after the page became interactive.
• Removed expired campaign scripts.
• Loaded affiliate tracking only on routes where attribution required it.
• Moved heatmap tools away from checkout.
• Created ownership records for every third-party script.
• Required product and engineering approval before adding new external scripts.
• Added monitoring for long tasks caused by third-party scripts.

Description: Marketing, analytics, heatmap, affiliate, and personalization tools were reviewed and governed. Scripts that were not essential to the first interaction were delayed or removed.

Phase8 Title: Image and layout stability improvements

Actions

• Used responsive image sizes for product cards and hero banners.
• Prioritized the actual LCP image on category and campaign pages.
• Reserved space for product images, sale badges, price blocks, and delivery messages.
• Compressed legacy campaign assets.
• Stopped late promotional banners from pushing content downward.
• Standardized product image aspect ratios.
• Prevented stock labels and discount badges from causing layout shifts.
• Reduced client-side layout changes after pricing data loaded.

Description: Fashion commerce depends on strong imagery, but the image system had to become predictable and performance-aware.

• INP improved from 412ms to 162ms at p75 on product listing pages.
• LCP improved from 5.2s to 2.5s at p75 on mobile category pages.
• CLS improved from 0.22 to 0.04 on product detail pages.
• Initial JavaScript payload on product listing pages dropped from 1.04MB to 398KB compressed.
• Average hydration time on mobile category and listing pages dropped from 3.4s to 1.4s.
• Filter interaction delay dropped from 380-760ms to mostly under 140ms.
• Product grid rendering became stable even with very large catalogs.
• Cart quantity update delay dropped from 450ms to under 160ms on average.
• Checkout typing lag was reduced by changing validation timing and delaying payment scripts.
• Recommendation and loyalty modules no longer blocked first interaction.
• Third-party script long tasks were reduced during early page load.
• Campaign landing pages became more predictable during traffic spikes.
• Performance regressions became easier to catch because bundle budgets were added to CI.
• Engineering teams gained clearer ownership of state, rendering, and third-party cost.

The optimization work improved both customer experience and internal product velocity. ModaNest did not just get better technical scores; the marketplace felt faster, more stable, and more trustworthy during browsing and checkout.

Outcomes

• Higher mobile engagement with product filters.
• Lower checkout frustration on mobile devices.
• Improved SEO readiness for category and campaign pages.
• Reduced abandonment during sale launches.
• More confidence when launching new merchandising sections.
• Fewer customer complaints about freezing pages.
• Better visibility into the performance cost of new features.
• A stronger engineering culture around measuring before and after releases.

• Avoid a full rewrite.

  A rewrite would have delayed business delivery and introduced major risk. Profiling showed that targeted architectural improvements could solve the most painful issues faster.

• Reduce JavaScript before adding more memoization.

  The application was shipping too much code too early. Memoization alone would not solve heavy hydration, oversized bundles, and third-party script pressure.

• Virtualize product listings.

  Rendering hundreds of product cards upfront created unnecessary DOM work, memory usage, and React updates.

• Move state closer to usage.

  Large shared providers made unrelated components update together. Smaller state boundaries reduced render cascades.

• Delay payment and marketing scripts.

  Third-party scripts were competing with React during loading and checkout interactions.

• Use real-user monitoring as the source of truth.

  Lab tests helped debugging, but real mobile data showed where customers were actually experiencing friction.

• React performance problems often come from architecture, not React itself.
• A page can appear visually complete while still being too busy to respond quickly.
• Large product grids should not render every item upfront.
• Broad Context providers can quietly create expensive render cascades.
• Checkout performance must be protected from analytics, validation, and payment script overhead.
• Third-party scripts need ownership, review, and removal rules.
• Image dimensions and reserved layout space are essential for visual stability.
• Performance budgets are necessary because JavaScript growth happens gradually.
• Memoization should be guided by profiling, not applied randomly.
• Real-user monitoring is more useful than relying only on developer devices.

Role: VP of Digital Product

Quote: The most important result was that we did not have to rebuild everything to make the marketplace feel fast again. The team found the real bottlenecks, reduced unnecessary JavaScript, and gave us a front-end process that protects future launches.

Person: Sofia Ricci

Company: ModaNest

ModaNest's React optimization project showed that a large e-commerce platform can become significantly faster without a full rewrite. By reducing JavaScript, improving route-level rendering, isolating state, virtualizing product grids, delaying non-critical modules, controlling third-party scripts, and protecting checkout interactions, the team transformed a heavy marketplace into a faster and more reliable shopping experience. The result was better Core Web Vitals, smoother mobile browsing, more stable checkout behavior, and a React architecture that could support future growth without repeating the same performance problems.