Shopify speed work that actually changes conversion

They get conflated constantly, and it wastes whole projects.

Question one: is the site slow? Answered with measurement. Lab tools run a page in a controlled environment and give you a repeatable score. Field data records what real visitors on real devices and connections experienced. Both are valid, and they answer different things. Lab data is for debugging and catching regressions. Field data is for deciding whether a problem exists.

Question two: is slowness costing conversion? Answered with your own analytics, segmented by template and device. A store can be technically mediocre and convert fine because its traffic is desktop and patient. Another can be technically decent and bleed mobile conversion because the product page shifts under the buyer's thumb.

Answer question two first. If mobile product page conversion is half desktop and your mobile field metrics are poor, you have a case. If they are similar, your conversion problem is probably not speed, and speed work will not fix it.

Do not start with the homepage. Start where buying decisions happen.

Look at real-user metrics, split by device, for your product template, your collection template and your cart. These three carry the intent. The homepage gets the attention because it gets the traffic, but a slow product page costs more per visit.

The three metrics worth your time:

Layout shift is the one most teams underweight and customers hate most. A buyer who taps "Add to cart" and hits a review widget that just appeared does not come back.

In practice, most Shopify slowness traces to four causes. Fix them in this order.

1. Images. Shopify serves images through its own CDN and can resize them on request. Plenty of stores still deliver a 2000px image into a 400px slot. Request the size you are going to display, provide correct width and height attributes so the browser reserves space, lazy-load everything below the fold, and do not lazy-load your hero — that one wants priority.

2. Apps that load everywhere. The accumulated cost of installed apps is usually the largest single factor. Each one adds script weight, and most add it to every page whether or not it is used there. A reviews widget needed on the product page does not need to execute on the cart.

3. Code added over time. Custom scripts, old tracking pixels, abandoned A/B test snippets, a tag manager container nobody has audited in two years. This accumulates silently and nobody is accountable for removing it.

4. Fonts. Multiple families, multiple weights, each blocking text from appearing. Two weights of one family is usually enough. Make sure text is visible while fonts load rather than invisible.

Notice that three of the four are removal, not optimization.

This is the highest-value hour in the project. Do it as a spreadsheet.

1. List every installed app. Include ones nobody remembers installing.
2. For each, name the person who would complain if it disappeared. No name means it is a candidate for removal.
3. Note where its functionality is actually needed. Product page only, cart only, checkout only, everywhere.
4. Measure its cost. Load a key template with the app's scripts blocked, then without. Compare. Do one app at a time so you can attribute the difference.
5. Decide: remove, restrict to the templates that need it, or keep.
6. Check for overlap. Two apps doing similar jobs is common after a few years. Pick one.

Uninstalling an app in the admin does not always remove the code it added to your theme. Check the theme files for leftover snippets and references after any removal, and remove them deliberately.

Once the weight is out, a handful of theme changes do the rest.

• Give the hero priority. Preload the main above-the-fold image on your most important templates. Do not lazy-load it.
• Reserve space for anything injected late. Set explicit dimensions for banners, review stars, badges and widgets so they cannot push content down after it renders.
• Defer what is not needed to render. Chat, personalization, social embeds and anything analytics-related can load after the page is interactive.
• Load conditionally. Keep product-page-only assets on the product page.
• Stop shipping unused CSS and JS. Themes carry code for sections you removed years ago.
• Leave checkout alone. Checkout is Shopify's, and your opportunity there is limited to the supported extension points. Do not spend budget trying to re-engineer it.

Work on a duplicated theme, not the live one, and change one category of thing at a time so you can attribute results.

This is where most projects quietly skip the hard part.

1. Record a baseline before touching anything. Conversion rate and add-to-cart rate, split by device and by template, over a window long enough to be stable. Two to four weeks, avoiding any promotional period.
2. Note anything that could confound the comparison. Campaigns, price changes, seasonality, a new product launch, a traffic source shift. Write them down now, because you will forget by the time you compare.
3. Ship one coherent batch of changes. Not a steady trickle, which is impossible to attribute.
4. Watch field metrics for a few weeks. Real-user data is collected over a trailing window, so it moves slowly. Lab data moves immediately, which is why it feels more rewarding and tells you less.
5. Compare like for like. Same device, same template, same traffic mix, equivalent period. If mobile traffic share shifted, your site-wide number is not comparable.
6. Accept an honest result. Sometimes speed was not the constraint. Finding that out cheaply is a useful outcome, and it usually redirects the budget toward the product page experience itself.

Optimizing the homepage because that is where the score is measured. The money is on the product page.

Chasing a perfect lab score. Diminishing returns arrive early, and the last stretch usually requires breaking something a merchandiser relies on.

Removing an app without asking who uses it. You will find out on the day the marketing team runs a campaign that depends on it.

No baseline. The most common failure. Without it, you cannot claim anything, and you will be asked to.

Re-platforming the theme as the first move. It feels decisive and it reproduces the same accumulation unless you fix the app and image problems too.

Treating it as one-off. Weight comes back as apps and tags get added. Put a quarterly check on the calendar with one named owner.

This usually runs as a short, bounded piece of work: measure, audit apps, fix images and weight, ship one batch, verify. It frequently ends with a clearer finding than expected — that the product page itself is the constraint, not its load time. That is when it moves from Shopify and ecommerce into UX, UI and conversion design, where the question stops being how fast the page is and becomes whether it answers the buyer's objection.

Agree what better means before the work starts. A specific template, a specific device, a specific metric, measured the same way before and after.