How a major retailer lifted ecommerce performance without a big-bang rewrite

When a major Australian retailer saw page speed turning into customer drop-off and lost sales, they asked DiUS to modernise key product browsing journeys using Next.js, without risking trading or rewriting core backend systems. 

DiUS shipped the uplift in controlled increments, keeping new and legacy pages running side-by-side and using routing rules and feature switches to roll out safely. Behind the scenes, we reduced page blocking with a backend-for-frontend layer and caching, aligned delivery with a custom-built, performance-tested design system after off the shelf options revealed performance bottlenecks. This also set the foundations for multiple teams to keep modernising after launch. 

The result: improved  speed and search visibility under fixed platform and release constraints, without risking revenue.

When web page speed becomes a revenue problem

The retailer needed to speed up an ageing ecommerce experience because performance was starting to show up as a commercial issue: weaker search visibility, lower click-through, and higher drop-off right when customers were trying to browse and buy.

Website performance directly affects conversion. Google research shows 53% of mobile visits are abandoned if a page takes longer than three seconds to load. At scale, those seconds translate into lost demand, which is why the brief was explicitly commercial: protect and lift revenue through improved discoverability and faster journeys.

They had internal teams, but the program needed to move quickly under constraints that made this hard to deliver safely without external support. DiUS was brought in to plan and deliver the uplift end-to-end, reduce delivery risk, and set up foundations the client teams could continue building on after the initial release.

The biggest requirement was continuity: this couldn’t be a big-bang rewrite. New and legacy pages had to run side-by-side so customers could move between them seamlessly, with a controlled way to roll out changes, measure impact, and roll back quickly if anything affected revenue.

Next.js was mandated, and the solution needed to run within the client’s existing Kubernetes platform on AWS (ruling out a simpler Next.js hosting path). The legacy backend API was also out of scope for change, even though it was contributing to responsiveness and page-blocking issues through over-fetching.

On top of that, delivery ran on a two-week release cadence with code freezes and coordination overhead. And as key engineering leaders moved on mid-stream, the program needed to reduce key-person dependency through clearer documentation, better shared foundations, and a delivery approach that didn’t rely on tribal knowledge.

Finally, the CMS was tightly coupled to the frontend, with markup (and sometimes behaviour) being pushed into production outside version control, increasing both risk and inconsistency as the uplift progressed.

Kept the business trading while the uplift shipped

To protect revenue while improving performance, the team needed a way to test changes in production, compare behaviour across new and legacy experiences, and roll back quickly if anything degraded the customer journey.

DiUS delivered uplifted pages as a vertical slice and controlled access through edge routing rules and feature switches. This allowed business as usual to continue while changes shipped safely, with a clear path to revert if needed.

Proved impact early, then widened rollout with confidence

To avoid a long build-up followed by a risky launch, the focus was on proving impact quickly using real customer behaviour and live performance data.

Within the first month, DiUS shipped a production-ready alpha of the Next.js version of the product experience, shipping analytics alongside changes so customer behaviour and click-through could be measured from day one. The rollout then expanded to a beta across a curated set of whitelisted pages, using A/B testing to compare both technical performance and sales outcomes against the legacy experience before committing to wider uplift.

Improved speed without rewriting core backend systems

With backend changes out of scope, the goal was to reduce page blocking and improve responsiveness using the layers that could be safely evolved.

Next.js server-side rendering was used to reduce client-side work and improve how quickly pages became usable. To address blocking caused by legacy API calls without changing the backend itself, DiUS introduced a backend-for-frontend layer via a shared GraphQL API. This reshaped and aggregated data from the legacy API and third-party services where needed, improving key loading behaviour (including Time to First Byte and Largest Contentful Paint) by reducing server-side blocking. Caching was added at both the edge and GraphQL layers so repeat browsing was faster once customers were in the journey.

As delivery risk increased due to knowledge gaps, DiUS also supported areas like CDN management and documented previously undocumented systems and processes so the work could continue predictably and safely.

Reduced CMS-driven risk and improved experience consistency

To keep the experience consistent as the uplift progressed, and to reduce the risk of unversioned markup and behaviour being pushed directly into production, the UI was decoupled from the monolith and the CMS shifted back toward content rather than code injection.

DiUS introduced a design system and a CMS component library so page changes could move faster without breaking design consistency or increasing production risk. CMS data was exposed in a headless way so the frontend could evolve without being tightly bound to the CMS implementation.

Enabled multiple teams to ship safely, and set the client up to continue

As more teams joined delivery (including an offshore team), foundations were put in place to avoid duplication and regressions and to reduce reliance on a small number of people holding critical context.

DiUS introduced a monorepo (shared codebase) with improved CI/CD, shared components (including common elements like header and footer), and a clear onboarding and pairing approach, with documented practices and decision boundaries. Ways of working were also shifted from a scaled agile mindset to a more Kanban-driven delivery flow, helping ship more value inside the client’s fixed release cadence.

Faster product pages, stronger search visibility, measurable revenue uplift

The uplift delivered clear customer and commercial improvements, validated through an incremental rollout that included A/B testing and a whitelisted beta comparing performance and sales outcomes against the legacy experience.

Pages became usable much sooner. Total Blocking Time dropped by 3000ms or more, and desktop performance improved from 15 to 93. The uplift also achieved an SEO score of 100, improving the likelihood that customers find the new pages through search.

This matters commercially because responsiveness is tightly linked to conversion at scale. Research from Google shows that small performance improvements can have measurable commercial impact. Even a 0.1 second (100ms) change in mobile site speed can influence progression through the purchase funnel and conversion outcomes. A widely cited Amazon internal benchmark is directionally consistent: at that scale, small speed changes are material.

Taken together, the uplift translated into commercial impact: sales figures estimated a revenue increase of greater than 10 basis points, higher than expected gains.