Case study · Retail & eCommerce
Twenty-three apps, four seconds, and nobody knew which was which
A Shopify store was failing Core Web Vitals on every template and losing search positions because of it. The fix was not a rebuild — it was finding out what the twenty-three installed apps were actually costing.
Engagement · Performance engagement
A rescue, not a rebuild — the constraint that shaped everything.
- Industry
- Mid-market retail
- Solution
- Storefront performance engineering
- Platform
- Shopify
- Engagement model
- Focused engagement
- Scope
- App audit, theme optimisation, imagery, monitoring
- Starting point
- Failing all Core Web Vitals
- Constraint
- No replatform, no redesign
- Target
- Pass on every template
Outcomes
What the performance work returned
Performance engagements should be judged commercially, not on a lab score.
-
+23%
Revenue per session
Faster pages convert better at every step, and the effect compounds across a funnel where each stage previously lost users to load time.
Measured across sessions for 90 days before and after
-
All
Core Web Vitals passing, on every template
Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift all within thresholds on home, collection, product and cart, measured on real users rather than in a lab.
Field data at the 75th percentile across all templates
-
−61%
JavaScript shipped per page
Eleven of twenty-three apps were removed or replaced with first-party implementations, and what remained was loaded after interactivity rather than before render.
Measured across transferred script bytes per page
Context
A store that got slow one app at a time
No single decision caused this. Forty reasonable ones did.
The business
A mid-market retailer on Shopify with a healthy catalogue and a theme customised over several years.
The starting point
Twenty-three installed apps, a heavily modified theme, and failing Core Web Vitals on every template.
The trigger
Search positions were slipping on competitive terms, and analytics showed measurable drop-off correlating with load time on mobile.
What they wanted
Passing Core Web Vitals without a replatform or a redesign, both of which had been quoted and rejected.
Constraints
No replatform and no redesign · several apps are genuinely needed by the business · the merchandising team must not lose any capability · changes must be reversible if conversion moves the wrong way.
System
What it runs at today
The storefront as it runs today.
-
All
Vitals passing
Every template
-
−61%
JavaScript
Per page
-
12
Apps remaining
From 23
-
+23%
Revenue per session
Against the baseline
The engineering problem
Four causes, in order of how much they cost
We measured before assuming, which changed the order considerably.
-
Apps loading globally for one page's benefit
Most app scripts load on every page regardless of where the feature appears, so a product-page widget costs the home page too.
What we did
Every app measured for its cost and its actual usage. Eleven removed or replaced; the rest scoped to the templates that need them.
-
Images as the dominant payload
Unoptimised, oversized imagery was the single largest contributor to Largest Contentful Paint across every template.
What we did
Responsive image handling with modern formats and correct sizing per breakpoint, plus explicit dimensions to eliminate layout shift.
-
Third-party scripts blocking render
Analytics, tag managers and chat widgets loading in the critical path delay first paint for functionality nobody needs immediately.
What we did
Everything non-essential deferred until after interactivity, with the tag manager configuration rationalised rather than merely moved.
-
Layout shift from late-loading content
Banners, badges and recommendation blocks inserting themselves after render move the page under the customer, which is both a metric failure and genuinely annoying.
What we did
Space reserved for every dynamically inserted element, so late content appears without moving anything.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
App layer
- Audit
- Removal
- Template scoping
Apps assessed on measured cost against measured usage.
-
Imagery
- Modern formats
- Responsive sizing
- Explicit dimensions
The largest payload, handled properly.
-
Critical path
- Inline critical CSS
- Deferred scripts
- Font loading
Only what the first screen needs, before the first screen.
-
Monitoring
- Real user monitoring
- Regression budgets
- Alerting
So the store does not slowly return to where it started.
Performance budgets with alerting were part of the deliverable. Without them, a store in this condition is back where it started within eighteen months.
Solutions
What we did
A rescue, done in order of measured cost.
-
App audit
Measured cost against usage for all 23.
-
App removal
Eleven removed or replaced.
-
Image pipeline
Modern formats and responsive sizing.
-
Critical path
Inline critical CSS, deferred scripts.
-
Layout stability
Space reserved for late content.
-
Monitoring
Real user monitoring with budgets and alerts.
Key capabilities
What it does day to day
Six workstreams in the engagement.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| App audit | One-off | Per app | Measured cost against measured usage for all 23 apps |
| App removal | One-off | Per app | Eleven removed or replaced with first-party code |
| Image pipeline | Ongoing | On upload | Modern formats, responsive sizing, explicit dimensions |
| Critical path | Ongoing | Per template | Inline critical CSS, deferred non-essential scripts |
| Layout stability | Ongoing | Per template | Space reserved for all late-inserted content |
| Monitoring | Ongoing | Continuous | Real user monitoring with performance budgets and alerts |
Integrations
How the moving parts plug in
Measure, remove, optimise, protect.
Measure
- Real user dataNot lab scores
- Per-app costMeasured
- Per-templateWhere the loss is
Remove & optimise
- 11 apps removedOr replaced
- Images handledProperly
- Critical pathTrimmed
Protect
- Performance budgets
- Regression alerts
- App install reviewA process now
The app install review process was the least technical part of the engagement and probably the most durable — most of the original problem arrived one well-intentioned install at a time.
Security & data
What made the work safe
Removing apps from a live revenue-generating store is not risk-free.
-
Reversible changes
Every change deployed independently and revertible in minutes.
-
Conversion monitoring
Conversion watched alongside performance at every step, not just at the end.
-
Capability preservation
Each removed app's function either genuinely unused or replaced before removal.
-
Performance budgets
Regressions alerted on, so the gains persist.
The brief
Measure before you assume — twice we were wrong
Both we and the retailer assumed the theme was the problem. Measurement showed the theme was a modest contributor and the app layer was dominant, with imagery close behind.
Two apps we expected to remove turned out to be cheap and well-implemented, and one we expected to keep was costing more than the next four combined.
- Every app measured for cost and usage
- Imagery handled as the largest payload
- Non-essential scripts deferred past interactivity
- Performance budgets to keep the gains
What the engagement had to work within
- 01No replatform and no redesign
- 02Apps the business genuinely needs
- 03No loss of merchandising capability
- 04Changes that must be reversible
Process
We changed one thing at a time
Batched performance changes make it impossible to know what helped and what hurt conversion.
-
Measurement
Real user monitoring installed and left to gather a fortnight of field data before anything was changed.
-
App audit
Each app measured individually for its page-weight cost and its actual usage in analytics.
-
Sequenced removal
Apps removed one at a time with conversion monitored for a week between each.
-
Theme work
Imagery, critical path and layout stability addressed once the app layer was settled.
-
Budgets
Performance budgets and alerting put in place, with an app install review process agreed with the team.
Technology
The existing Shopify store, made fast
No replatform. The store they had, working properly.
Commerce
- Shopify
- Existing theme
- Liquid
Performance
- Critical CSS
- Script deferral
- Font loading
Media
- Modern formats
- Responsive images
- Explicit dimensions
Monitoring
- Real user monitoring
- Performance budgets
- Regression alerts
Business impact
What changed for the retailer
Three outcomes within a quarter.
-
Revenue per session up 23%
From the same traffic.
-
Search positions recovering
Passing vitals removed a ranking handicap on competitive terms.
-
A process for app installs
So the store does not slowly refill with weight.
The result
Passing on every template, from the same store
All Core Web Vitals pass on every template in field data, JavaScript per page is down 61%, and revenue per session is up 23% from the same traffic.
There was no replatform and no redesign. The store the retailer already had simply stopped carrying eleven apps it was not using.
- All Core Web Vitals passing on every template
- JavaScript per page down 61%
- Revenue per session up 23%
- No replatform, no redesign
What we hold to in performance work
- 01Measure before assuming — the obvious culprit often is not
- 02Change one thing at a time and watch conversion
- 03Images are usually the largest single payload
- 04Leave behind budgets, or it all comes back
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