The site feels slow on phones.
Lab scores look fine on a laptop and the store still drags on a phone on a real network. We test mobile first, throttled, on the pages customers actually use, and read the field data for the same pages.
Faster where customers notice
Storefront performance
Speed is a customer experience problem before it is a score. We measure what is slow on your storefront, fix it in the theme and the third party code around it, and report preview and field results separately, so you know what changed and what it did.
Most slow storefronts are slow for ordinary reasons: a theme that has grown one build step at a time, a carousel loading dozens of products, scripts firing on the first interaction, images with the wrong priority, retired assets still shipping. None of that shows up on a dashboard as a single cause, which is why we start by measuring rather than guessing.
We work inside your existing theme and design. The build, the loading order, the interactions and the third party features are where the time goes, and each can be changed without a redesign. Every change is made on a preview theme, measured against the baseline with the same tools, and released when you say so.
Sounds familiar?
Three reasons people call us
A store address and the page that feels slow are enough to start.
Every app made it a little heavier.
Reviews, loyalty, chat, measurement, consent, each with its own script and its own idea of when to load. We map what each one costs and give third party features a schedule instead of a free run at the first paint.
Core Web Vitals turned amber.
Search Console or the Chrome UX Report has flagged Largest Contentful Paint, Interaction to Next Paint or layout shift. We find which templates and interactions are responsible and fix those first.
What you get
Measured, fixed, and measured again
A baseline you can hold us to.
Lighthouse on mobile and desktop presets, several runs, medians for First Contentful Paint, Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift, and the public Chrome UX Report trend for the same pages, all recorded before we change anything.
A lighter theme, within the design.
Unused assets removed, fonts delivered efficiently, a repeatable build for JavaScript and stylesheets, and compiled files that keep the names the theme's templates use, so the storefront's structure and content workflow are untouched.
The right things first.
Image preloads that follow the mobile or desktop layout, images further down the page that wait their turn, features that load their assets where they are used, link prefetching for the pages a shopper is likely to open next, and only the components that need JavaScript getting it.
Third party code on a schedule.
Shared loading controls so apps and scripts are timed around the initial page load rather than competing with it, with each regional store keeping its own app configuration.
How it goes
Baseline. Preview. Release. Field.
Preview results and field results stay in separate columns of every report.
Measure before choosing.
We audit the live theme on the pages that matter, record the medians and the field trend, and read the build. The report says where the time goes and what we would change first.
Change it on a preview.
Each change goes on a preview theme with current products and settings, and the same audits run again. Anything that does not move the numbers does not ship.
Release, then watch the field.
We release when you say so, with a documented way back, and keep reading the Chrome UX Report for the weeks after. A smaller stylesheet is reported as a smaller stylesheet, not as a faster site.
Recent performance work
One theme, measured honestly
2XU · Theme architecture and performance
Same design, 40% less JavaScript
A theme rebuilt within its design: 40.2% less JavaScript in a controlled preview test, and mobile LCP of 1.61 seconds in the latest public field data.
Common questions
Before we start
Will this fix our Core Web Vitals?
Usually the lab numbers move first and the field numbers follow as real visitors reach the new build, but field data also depends on devices, networks and whatever else changes on the site. We report both separately and do not promise a field score.
Do we need a new theme?
Rarely. Most of the time the design is fine and the engineering underneath it is the problem: the build, the loading order and the third party code. We change those within the existing theme.
Can you work with our agency or in house developers?
Yes. We take a defined engineering scope, share the audits and the build, and agree who reviews and who publishes so there is one release path.
Which apps should we remove?
We measure before recommending. Some apps cost more than they return and some are cheap once they load at the right time; the report shows the cost of each so the decision is yours.
What will you need from us?
Access to a preview theme, the pages you care about, and a note of any promotions or launches in the calendar so we do not measure during a sale.
Work directly with Chris
Let's find the slow part
The store address, the page that feels slow, and anything in the calendar we should measure around.