Skip to content
All case studies

Case study 092019

Storefront Performance Overhaul

A marketplace storefront rebuilt on server rendering, with performance budgets enforced in CI.

Role
Frontend lead
Team
4 engineers
Timeline
4 months
Focus
Frontend

5.2 → 1.7 s

mobile LCP

−64%

JavaScript shipped

+11%

mobile conversion

Pages render on the server behind an edge cache, while field data and CI budgets keep regressions out.Shopper to Edge cache; Edge cache to Next.js SSR (miss); Next.js SSR to Catalogue API; Shopper to Real-user metrics; Real-user metrics to CI budgets (thresholds)Shoppermobile-firstEdge cacheCDNNext.js SSRstreamingCatalogue APIReal-user metricsCore Web VitalsCI budgetsbundle · LCP · CLSmissthresholds
Pages render on the server behind an edge cache, while field data and CI budgets keep regressions out.

The problem

Mobile conversion lagged desktop badly, and every new feature made the bundle heavier. Nobody owned performance, so it only ever got worse.

What I owned

  • The page-by-page migration plan to server-rendered Next.js with edge caching.
  • An accessible design system that removed duplicate components.
  • Real-user monitoring and CI performance budgets.

Key decisions

  1. 1

    Migrate by page, highest traffic first

    Product and category pages moved first because they carried most of the revenue, so the impact showed up within weeks.

  2. 2

    Make regressions fail the build

    Bundle and Core Web Vitals budgets run in CI, and a pull request that blows the budget doesn't merge.

Outcome

Mobile pages load three times faster, conversion followed, and budgets keep it that way without anyone policing it.

  • React
  • Next.js
  • TypeScript
  • Tailwind CSS
  • Playwright