Case study · Retail & eCommerce
A storefront fast enough that people finish buying
A fashion retailer had a beautiful theme that took five seconds to render a collection on a phone. We rebuilt the storefront headless on Shopify's Storefront API, and mobile conversion went up 34%.
Project overview
Headless done for a measurable reason, not for the architecture diagram.
- Industry
- Fashion retail
- Client
- Confidential
- Solution
- Headless commerce storefront
- Platform
- Shopify Plus
- Engagement model
- Dedicated product team
- Scope
- Storefront, search, checkout hand-off
- Stack
- Next.js, Storefront API
- Constraint
- Merchandisers keep control
- Target
- Sub-second product pages
Expected business outcomes
What the speed was actually worth
Performance work is only worth doing if it shows up in the commercial numbers. It did.
-
+34%
Mobile conversion rate
Product and collection pages render from cached, statically generated content with live inventory patched in, so the page is usable immediately rather than after the theme finishes assembling itself.
Measured across mobile sessions for 90 days after launch vs the same period prior
-
0.6 s
Largest Contentful Paint on product pages, from 4.8 s
The critical render path carries only what the first screen needs. Everything else — recommendations, reviews, recently viewed — loads after the page is interactive.
Field data from real user monitoring at the 75th percentile
-
+22%
Organic search traffic
Faster pages and clean server-rendered markup moved a large catalogue of collection pages up in search, which compounds monthly rather than resetting.
Measured across organic sessions over six months after launch
Business challenges
A good-looking store that nobody could use on a phone
The design was not the problem. The delivery of it was.
The business
A fashion retailer with a large seasonal catalogue, selling primarily direct to consumer, with most traffic arriving on mobile.
The starting point
A heavily customised Shopify theme with a decade of apps layered onto it, each adding scripts to every page.
The trigger
Mobile conversion was roughly half the desktop rate, and analytics showed most of the gap opening before the product page had finished loading.
What they wanted
A fast storefront without giving up the merchandising control the theme editor gave them, and without rebuilding checkout.
Constraints
Merchandisers publish collections daily and must not need a developer · inventory has to be accurate at the moment of display · checkout stays on Shopify · a large catalogue means build times matter.
Proposed solution
What we built
A storefront designed around the first screen.
-
Next.js storefront
Statically generated, served from the edge.
-
Commerce layer
Storefront API for product, price and stock.
-
Component system
Responsive imagery and critical CSS built in.
-
Merchandising
Collections and content via metaobjects.
-
Search & filtering
Faceted search across the full catalogue.
-
Deployment
Atomic deploys with one-minute rollback.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Storefront
- Next.js
- Static generation
- Edge delivery
Pages built ahead of time and served from the edge, revalidated on change.
-
Commerce data
- Storefront API
- Metaobjects
- Live inventory
Shopify remains the source of product, price and stock truth.
-
Merchandising
- Collections
- Content blocks
- Publishing
Driven from the Shopify admin so no developer sits in the publishing path.
-
Checkout
- Shopify checkout
- Cart hand-off
Checkout stays where it is proven. We did not rebuild it.
Keeping checkout on Shopify is the decision that makes headless sensible rather than reckless. The storefront is where the performance problem was; checkout was already converting.
Key capabilities
What it does day to day
Six capabilities in the storefront.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Product pages | Static + live | On change | Generated ahead of time, inventory and price patched live |
| Collections | Merchandiser | Daily | Published from the Shopify admin, storefront rebuilds automatically |
| Search & filtering | Storefront | Real time | Faceted search across the catalogue without a page reload |
| Imagery | Automatic | On upload | Responsive, modern formats, correctly sized per breakpoint |
| Cart | Storefront | Real time | Client cart synchronised to Shopify, handed to checkout |
| Content | Merchandiser | On publish | Editorial blocks via metaobjects, no deployment required |
Integrations
How the moving parts plug in
Fast because most of the work happened before the request.
Build time
- Pages generatedPer product and collection
- Images processedEvery breakpoint
- Deployed to edge
Request
- HTML immediatelyNo render wait
- Critical CSS inline
- First screen onlyRest loads after
After interactive
- InventoryCurrent stock
- PriceCurrent price
- Recommendations & reviewsLoaded last
Patching inventory and price client-side is what lets pages be cached aggressively without ever showing a customer a sold-out product as available.
Security & data
What protects the store
Headless adds surface area, so it has to add controls too.
-
Checkout unchanged
Payment stays inside Shopify's PCI-compliant checkout — we never touch card data.
-
Scoped API access
Storefront API tokens scoped to exactly what the storefront reads, with no admin access from the front end.
-
Stock accuracy
Live inventory patching, so a cached page cannot sell something that is gone.
-
Rollback
Every deployment is atomic and reversible in under a minute.
Project requirements
Headless is a means, and it needs a number attached
Plenty of headless rebuilds deliver a slower site and a merchandising team that cannot publish. We took the work on because the retailer had a specific, measured problem: mobile conversion at half the desktop rate, with the loss happening during page load.
That framing decided the architecture — cache aggressively, patch what must be live, and leave checkout alone.
- Static generation with live inventory patching
- Merchandising driven from the Shopify admin
- Checkout left on Shopify
- Apps audited rather than carried over
What the build had to preserve
- 01Daily merchandiser publishing without a developer
- 02Inventory accuracy at the moment of display
- 03Shopify checkout, untouched
- 04Build times that survive a large seasonal catalogue
Key challenges & considerations
Four reasons the old storefront was slow
None of them were the designer's fault.
-
A decade of apps on every page
Each app added its own scripts globally, so a product page carried tag managers, review widgets, upsell engines and chat before it rendered a photograph.
What we did
Apps audited and replaced with first-party implementations where they mattered, removed where they did not. What remained loads after interactivity.
-
Rendering everything on request
The theme assembled every page server-side on each request, so page speed tracked Shopify's theme rendering rather than the network.
What we did
Statically generated pages served from the edge, with inventory and price patched in client-side so nothing stale reaches the customer.
-
Images sized for desktop, served to phones
The catalogue shipped large images to every device, which is the single most common cause of a slow fashion storefront.
What we did
Responsive image pipeline with modern formats and correct sizing per breakpoint, built into the component rather than left to the merchandiser.
-
Merchandisers blocked by developers
Headless builds often take publishing control away from the merchandising team, which is why they get abandoned.
What we did
Collection and content structure driven by Shopify metaobjects, so merchandisers publish from the admin they already use and the storefront rebuilds itself.
What we hold to on headless builds
- Attach a measured number to the decision before you start
- Leave checkout alone unless it is the problem
- If merchandisers lose control, the build gets reverted
- Audit the apps — most of the weight is there
Development process
We measured before we rebuilt
A replatform without a baseline is a hope, not a project.
-
Baseline
Real user monitoring on the existing store to establish where the mobile loss actually happened.
-
App audit
Every installed app assessed for value against its page weight, before any code was written.
-
Storefront build
Product and collection templates first, because that is where the traffic and the loss were.
-
Merchandiser workflow
Publishing tested with the merchandising team before launch, not after.
-
Phased launch
Traffic shifted progressively with conversion monitored against the baseline at each step.
Technology stack
Next.js on Shopify Plus
A modern storefront over a commerce platform that already works.
Storefront
- Next.js
- React
- TypeScript
Commerce
- Shopify Plus
- Storefront API
- Metaobjects
Delivery
- Edge CDN
- Static generation
- Incremental revalidation
Quality
- Real user monitoring
- Lighthouse CI
- Visual regression
Quality assurance & deployment
Every way an order can go wrong, tested first
A defect in a store costs money directly. Payments, stock, promotions and tax were tested deliberately, including the failure paths, before the store took its first real order.
- A payment test matrix: success, decline, timeout, duplicate and refund
- Stock, pricing and promotion rules tested under concurrent use
- Speed measured on real phones over mobile connections
- Cross-browser and device checks on the full checkout
- Redirects and search rankings checked before and after launch
Deployment
- 01Merchandiser workflowPublishing tested with the merchandising team before launch, not after.
- 02Phased launchTraffic shifted progressively with conversion monitored against the baseline at each step.
- 03Launch outside trading peaksThe switch was made at a quiet time, with a rollback ready and orders watched live.
- 04Monitoring and warrantyConversion, errors and speed monitored from launch, and six months of free bug fixing.
Business impact
What changed for the retailer
Three outcomes across the first two seasons.
-
Mobile conversion up 34%
The gap between mobile and desktop conversion mostly closed.
-
Organic traffic up 22%
Speed and clean markup compounding across a large catalogue.
-
Merchandisers kept control
Daily publishing from the same admin, with no developer in the path.
Final deliverables
The gap between mobile and desktop mostly closed
Product pages render in 0.6 seconds at the 75th percentile on mobile, down from 4.8, and mobile conversion is up 34%.
Merchandisers publish daily from the same Shopify admin they used before, which is why the build is still in use rather than quietly reverted.
- Mobile conversion up 34%
- LCP 0.6s, down from 4.8s
- Organic traffic up 22%
- Merchandising unchanged for the team
Handed over to the client
- 01Live storefrontTheme, apps and integrations configured
- 02Source codeTheme and custom code in the client's repository
- 03Integration documentationWhat connects to what, and how
- 04Admin trainingFor the team that runs the store
- 05Six-month warrantyFree bug fixing after delivery
Success metrics
What it runs at today
The storefront as it runs today.
-
0.6s
LCP
At the 75th percentile, on mobile
-
+34%
Mobile conversion
Against the pre-launch baseline
-
Daily
Merchandiser publishing
Without a developer
-
Live
Inventory
Patched into cached pages
How success is measured
How success is measured
| Measure | Outcome | How it is measured |
|---|---|---|
| Mobile conversion rate | +34% | Measured across mobile sessions for 90 days after launch vs the same period prior |
| Largest Contentful Paint on product pages, from 4.8 s | 0.6 s | Field data from real user monitoring at the 75th percentile |
| Organic search traffic | +22% | Measured across organic sessions over six months after launch |
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate