How we took a mobile PageSpeed score from 26 to 70+ without losing traffic
Contents
A mobile PageSpeed score of 26/100 means a site losing sales on every single page load. That was the starting point of a recent migration: a sneaker and streetwear e-commerce site on a classic Shopify theme, weighed down by years of stacked apps. Here is how it went from 26 to 70+, without any traffic drop or SEO loss.
The diagnosis: where a score of 26 comes from
Before writing a single line of code, the audit drew on three sources: GA4 for user behaviour, Clarity for session replays (to see exactly where visitors were dropping off), and a full PageSpeed/Lighthouse audit, item by item.
Three causes accounted for most of the degradation:
Third-party apps piling up. Every app installed on a classic theme injects its own script, often render-blocking. On this store, around ten active apps (reviews, upsell, trust badges, chat) were loading synchronously right from first paint. None of them was heavy on its own: it’s the stacking that kills the score.
A Liquid theme not optimised for mobile. Non-responsive images, no structured lazy loading, non-critical CSS loading in a blocking way. Nothing exotic, this is the common state of themes bought and tweaked for years without a real overhaul.
No control over rendering. On a Liquid theme, optimisation happens within the limits the theme allows. There’s no way to control the load order of critical resources, or to strip out JS from apps that aren’t even used on certain pages.
This last point settled the decision. Staying on Shopify Liquid and optimising at the margins would have capped the gain around 45 to 50. Moving to Hydrogen headless meant starting from a blank slate with full control over rendering.
The technical decisions that made the difference
Server-side rendering on Oxygen, edge-first. Hydrogen runs on Oxygen (Shopify’s edge runtime), which removes the cold start time you get on classic hosting and brings content closer to the visitor geographically.
Replacing front-end apps with native code. The features that used to justify third-party apps (reviews, trust badges, cross-sell) were rewritten directly inside the Hydrogen storefront, connected to the Storefront API. Result: zero blocking third-party script on product and category pages, which carry most of the traffic.
A reactive cart with no page reload. The Hydrogen cart runs on an edge-side cart, updated without a full reload, which cuts both perceived time and network load on every interaction.
Images and fonts optimised at the source. Modern formats (WebP/AVIF), strict responsive sizing per breakpoint, and fonts set to font-display: swap to remove the invisible text flash that hurts CLS (Cumulative Layout Shift).
Prioritised critical loading. Only the CSS needed for the first screen loads in a blocking way; everything else is deferred until after First Contentful Paint.
Why Hydrogen is not automatically fast
It would be convenient to say the score improved because the site moved to Hydrogen. That isn’t what happened, and it’s worth being precise about, because plenty of headless storefronts perform no better than the theme they replaced.
Hydrogen doesn’t make a site fast. It removes the ceiling. On a Liquid theme, part of the loading behaviour isn’t yours to decide: the theme’s script order, what an app injects, when it injects it. On Hydrogen, all of that becomes a decision you make, which means it also becomes a decision you can get wrong.
A Hydrogen storefront can easily end up slow. Oversized client bundles, a heavy React component tree on the product page, third-party scripts reintroduced one by one for marketing, unoptimised images, data fetched client-side instead of on the server: none of those are prevented by the framework. Migrating a store and porting the same ten app scripts into the new storefront reproduces exactly the same problem in a more expensive codebase.
What produced the gain here was the combination of the migration and the deliberate choices listed above, in particular removing the third-party scripts rather than relocating them. The framework made those choices possible; it didn’t make them.
The switchover, without losing traffic
The number one risk in a migration isn’t technical, it’s SEO during the transition. The method followed:
- A full audit of existing URLs before any code was written: structure, structured data (schema.org), canonical tags.
- Exact reproduction of the URL structure on the new storefront: no broken URLs, so no redirects needed on most of the catalogue.
- A 301 redirect plan for pages that were genuinely removed or merged, tested before the switchover.
- DNS switchover during off-peak hours, with reinforced Search Console monitoring for the following 15 days to catch any indexing error immediately.
Does a PageSpeed gain automatically improve conversion?
No, and it’s worth resisting the shortcut, even in a case study where both numbers moved in the right direction.
Mobile checkout completion went from 28% to 40%+ on this project. Speed contributed to that: mobile is genuinely sensitive to every extra second of latency, and drop-off falls at every step of the funnel when pages stop stalling. But the migration also rebuilt the cart, the product page and the checkout journey at the same time. Attributing the entire gain to the score alone would be reading the data too generously.
Two more caveats. A PageSpeed score is a lab measurement on a simulated device; it correlates with real user experience but it isn’t the same thing, which is why field Core Web Vitals matter more for judging the effect on customers. And gains aren’t linear: going from 26 to 70 removes real friction that visitors were feeling, while going from 70 to 90 is usually a much smaller commercial win than the effort suggests.
The practical version: treat speed as removing a brake rather than adding an accelerator. If your store converts poorly because of price, product range or a confusing funnel, a better score won’t fix it. If visitors are abandoning because pages stall on mobile, it will, and the improvement shows up quickly.
The takeaway
A degraded PageSpeed score on Shopify is almost never a single-factor problem: it’s an accumulation of trade-offs made over time (an app here, a widget there) that stays invisible until it’s actually measured. The good news is it’s reversible, provided you have full control over rendering, something a classic Liquid theme will never fully allow.
If your store is in this situation, the Shopify to Hydrogen migration path details how the initial audit and the switchover are handled, stage by stage.