How I took a Shopify store from 55 to 81 on mobile PageSpeed

A Shopify homepage I designed and built scored 55 on mobile in PageSpeed Insights. After a round of fixes it scores 81 on mobile and 97 on desktop. No apps were removed and the design did not change.

The store is The Sustainable Sequin Company, which I built during my MSc major project. This is what slowed it down on phones, what I changed, and why I stopped short of my goal of 90.

Measure what each suspect costs

The usual advice for a slow Shopify store is to remove apps. Removing apps also removes features the shop owner relies on, so I wanted to know the cost before suggesting it.

I ran the homepage through Lighthouse with optional third-party scripts blocked, one at a time and then all together, three runs each. The baseline scored 62. With all of them blocked it scored 66, and the time to load the main image barely moved: 4.2 seconds against 4.2 seconds.

That result ruled out the obvious answer. Four points was not worth losing working features, and the main image was being delayed by something else.

The delay hiding in the theme

The biggest cause was one tag in the theme's head:

<link rel="expect" href="#MainContent" blocking="render">

It tells the browser to hold the first paint until the main content has been parsed. The theme uses it so page transitions can run consistently. On a phone in a lab test, that hold cost about 2 seconds of blank screen.

I removed the hold on phones with a small inline script. Desktop keeps its behaviour. The mobile score went from 66 to 81, the largest gain from any single change. In the runs either side of that fix, the main image load went from 8.2 seconds to 4.5, and first content from 2.7 seconds to 1.5.

The lesson for me was about where to look. A long list of scripts is easy to spot in a report. A tag that delays rendering looks harmless when you read the code.

The smaller fixes

Each of these was applied and tested separately:

  • A lighter hero image on phones. An 832px version at a lower quality setting took it from 64 KB to 35 KB, about 45% lighter.

  • Preloading the hero image. The browser can start fetching it before it reaches the image in the page.

  • Skipping product-only scripts. Pages with no product form do not load the modules that only product pages need.

  • Lazy-loading lower images. Images in the testimonials, sustainability stats and footer wait until they are near the screen.

  • Deferring off-screen sections on phones. The browser skips rendering work for sections further down the page until they are needed.

Why I stopped at 81

My goal was 90 on mobile, and the store did not reach it. A test with no scripts at all reached about 91. Colour swatches, the wishlist, quick add and the cart all run on scripts, so getting the last 9 points would have meant breaking the things customers use to buy.

Scores also move between runs. I saw 81 and 82 on mobile, and 96 and 97 on desktop, so I treat them as lab estimates. PageSpeed had no real-user data for this store, which means these numbers describe a simulated phone and not actual customers.

How I kept a live store safe

The fixes went straight onto a store taking real orders, so the process mattered as much as the code.

I used Claude Code, an AI coding agent, to diagnose the problems and apply the fixes. I set the rules: no apps removed, no changes to design, copy or fonts, and desktop left alone. Before any edit there was a full backup theme that could be restored in one click. Every change had its own Git commit, so each one could be reverted individually.

After each fix I checked the live site on mobile, across the homepage, a collection page, a product page, the cart and the checkout button. Two attempts to send the preload as an HTTP header did not work on Shopify, so I reverted them.

What I'd do next

I would collect real-user data once the store has enough traffic, because that shows what customers on real phones experience. I would also review the remaining scripts with the store owner, one by one, and ask which ones they still use. Any further speed gains on this homepage will come from those decisions more than from the code.

If your own store is slow, measure what each script costs and check what delays the first paint before you cut anything. The full project is in my TSSC case study.

Next
Next

How to write usability test tasks: examples from a banking app study