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.

Start a project like this See more of our work

Project overview

A rescue, not a rebuild — the constraint that shaped everything.

Industry: Mid-market retail
Client: Confidential
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

Expected business 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

Business challenges

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.

Proposed solution

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.

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.

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.

Project requirements

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

Key challenges & considerations

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.

What we hold to in performance work

Measure before assuming — the obvious culprit often is not
Change one thing at a time and watch conversion
Images are usually the largest single payload
Leave behind budgets, or it all comes back

Development process

We changed one thing at a time

Batched performance changes make it impossible to know what helped and what hurt conversion.

Stage 1
Measurement

Real user monitoring installed and left to gather a fortnight of field data before anything was changed.
Stage 2
App audit

Each app measured individually for its page-weight cost and its actual usage in analytics.
Stage 3
Sequenced removal

Apps removed one at a time with conversion monitored for a week between each.
Stage 4
Theme work

Imagery, critical path and layout stability addressed once the app layer was settled.
Stage 5
Budgets

Performance budgets and alerting put in place, with an app install review process agreed with the team.

Technology stack

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

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

01Theme workImagery, critical path and layout stability addressed once the app layer was settled.
02BudgetsPerformance budgets and alerting put in place, with an app install review process agreed with the team.
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 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.

Final deliverables

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

Talk about a project like this

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.

All Vitals passing
Every template
−61% JavaScript
Per page
12 Apps remaining
From 23
+23% Revenue per session
Against the baseline

How success is measured

Measure	Outcome	How it is measured
Revenue per session	+23%	Measured across sessions for 90 days before and after
Core Web Vitals passing, on every template	All	Field data at the 75th percentile across all templates
JavaScript shipped per page	−61%	Measured across transferred script bytes per page

Twenty-three apps, four seconds, and nobody knew which was which

App audit

App removal

Image pipeline

Critical path

Layout stability

Monitoring

App layer

Imagery

Critical path

Monitoring

Reversible changes

Conversion monitoring

Capability preservation

Performance budgets

Measure before you assume — twice we were wrong

Apps loading globally for one page's benefit

Images as the dominant payload

Third-party scripts blocking render

Layout shift from late-loading content

Measurement

App audit

Sequenced removal

Theme work

Budgets

Commerce

Performance

Media

Monitoring

Every way an order can go wrong, tested first

Revenue per session up 23%

Search positions recovering

A process for app installs

Passing on every template, from the same store

Performance Optimization

Shopify Development

eCommerce SEO

Have an idea? Let's turn it into AI-powered software.