Key Takeaways A legacy or custom-built site doesn't follow the same migration rules as WooCommerce...
|
Key Highlights
|
Merchants who migrate to Shopify usually expect performance to hold steady or improve. When it gets worse instead, the instinct is to blame the platform. On Shopify's own community forums, this is a familiar story: a merchant follows every recommended step, redirects mapped, product IDs preserved, and still watches performance and traffic slide with no obvious explanation. The platform isn't usually the problem. Shopify's server response time is consistently fast, typically well under 300 milliseconds. What's slow is almost always something that came along for the ride during the move.
A Different Kind of Slowdown Needs a Different Kind of Fix
Most Shopify speed content is written for stores that gradually accumulated bloat over years: one more app, one more script, one more banner, until the store feels heavier than it used to. That's a real problem, but it isn't the same problem as a store that was fine on its old platform and got slower within days of switching over.
A gradual slowdown has a gradual cause. A sudden one, tied directly to a migration, usually has a specific, findable cause sitting in what got moved or left behind. Knowing which situation applies changes where to actually look.
Matching the Symptom to the Cause
| What you're noticing | What it usually points to |
|---|---|
| Old URLs load slowly, new pages feel fine | Redirect chains from an incomplete migration map |
| The whole site feels heavier, even on brand-new pages | A theme that was ported over instead of rebuilt properly |
| Pages with tracking pixels or ads are the slowest | Old-platform scripts still running alongside their Shopify replacements |
| Product and collection pages are slow to load images | Images carried over at their original size, never re-optimized for Shopify's CDN |
| Things were fine at launch, then slowly got worse | New apps added after migration to replace features the old platform had built in |
The Redirect Chain Problem Nobody Budgets Time For
Every old URL needs somewhere to go once a store moves. Done properly, that's one clean hop: old URL straight to its Shopify equivalent. Done under a deadline, which most migrations are, it often isn't. A quick fix gets added to stop a 404, another rule gets layered on top later, and the URL ends up bouncing through two or three redirects before it resolves.
Each hop adds somewhere between 100 and 300 milliseconds. That sounds small until it's multiplied across every visit still arriving through an old bookmark, backlink, or search result, on every product in a catalog that might run into the thousands. It's invisible in a basic speed score too, since the score only reflects pages tested directly, not the layered redirects sitting behind older URLs still pulling in real traffic.
The fix isn't adding another redirect on top of the pile. It's going back to the original URL list and pointing each one directly at its final Shopify destination, so the chain collapses to a single hop.
When the Theme Moved but Never Actually Adapted
A common shortcut is recreating the old site's look as closely as possible inside a Shopify theme, sometimes by rebuilding old templates rather than starting from Shopify's own foundation. Visually, it can look like nothing changed. Underneath, it often behaves nothing like a proper Shopify theme should.
Shopify renders pages through Liquid on its own servers before anything reaches a browser, and theme code written to mimic a different platform's structure tends to run heavier logic than what Shopify's newer Online Store 2.0 templates expect. Loops running across entire collections unnecessarily, logic sitting in global layout files instead of individual sections, patterns copied over from a non-Shopify build: all of it adds real server response time before the page even starts painting.
The Scripts Running Twice Without Anyone Noticing
Every established store carries tracking: analytics, ad pixels, chat widgets, maybe a heatmap tool. These usually get reinstalled correctly during migration. What often doesn't happen is properly switching off the old versions.
- A pixel hardcoded into the old platform's template can survive a theme port and end up firing alongside its new Shopify equivalent.
- Two analytics snippets loading the same data adds pure overhead with zero added benefit.
- Chat widgets or review apps installed fresh on Shopify sometimes sit next to leftover embed code from the old platform that nobody remembered to remove.
None of this is dramatic on its own. Stacked together across every page load, it's exactly the kind of quiet weight that shows up as a sluggish store with no single obvious cause.
Images That Made the Trip, Not the Upgrade
Product photography almost always gets carried over as-is, which makes sense since re-shooting an entire catalog isn't realistic. What frequently gets skipped is re-optimizing those images for how Shopify actually serves them. A file sized correctly for the old platform's CDN isn't automatically right for Shopify's, and that shows up first on product and collection pages carrying dozens of images per view.
This is genuinely one of the more fixable causes on this list once it's actually identified, which is exactly why it's worth ruling in or out early rather than assuming the problem is something more complicated underneath.
It's Not Just Shoppers Who Notice
Site speed used to matter almost entirely for human visitors and search crawlers. That's shifting. AI-based shopping assistants and answer engines now fetch and evaluate pages on a time budget of their own, and a page that takes too long to respond can get skipped over the same way a slow-loading site loses an impatient shopper. A migration-related slowdown doesn't just cost conversions anymore. It can quietly cost visibility in the newer channels increasingly deciding what gets surfaced at all.
Actually Finding the Cause, Not Guessing at It
A single PageSpeed Insights or GTmetrix scan produces a score, but a score alone doesn't say whether the cause is migration-specific or ordinary accumulated bloat. A more useful check looks at three things side by side: whether slow pages cluster around URLs that existed on the old platform, whether server response time differs meaningfully between a brand-new page and a migrated one, and whether the page source shows duplicate tracking scripts rather than just counting installed apps.
Redirect chains, a ported theme, and duplicated scripts are three different problems requiring three different fixes, and mistaking one for another usually means spending time and budget on changes that don't touch the actual cause. Getting that diagnosis right first, ideally as part of the migration process itself rather than months afterward, is what keeps performance work from becoming an expensive guessing exercise. Store owners working through a Shopify migration tend to catch these issues far earlier when performance auditing is built into the move itself rather than treated as a separate cleanup project later.
Frequently Asked Questions
I migrated months ago and things were fine at first. Why would it suddenly get slow now?
A delayed slowdown usually isn't the migration itself, it's what's been added since. Post-migration apps installed to replace features the old platform had natively are a common cause, since each one adds its own scripts on top of whatever was already carried over.
My developer said the redirects were all set up correctly. Could they still be the problem?
Yes, and this is one of the most missed cases. โSet up correctlyโ often means every old URL resolves to something valid, not that it resolves in a single hop. A URL can technically work and still be running through two or three redirects behind the scenes, adding delay that never shows up unless someone checks the actual hop count.
Is this something I can check myself, or does it need a developer?
Spotting the pattern, old URLs being slower than new ones, for example, is something most store owners can do by comparing load times directly. Fixing the underlying cause, whether that's collapsing redirect chains, removing duplicate scripts, or rebuilding theme sections, usually does need development work to do safely.
Could this be a Shopify problem rather than something from my migration?
It's unlikely. Shopify's own server response time is consistently fast across regions, so the platform itself is rarely the bottleneck. When a store slows down right after migrating, the cause is almost always something that came along in the move rather than Shopify's infrastructure.
If I fix these issues, will my search rankings recover too, or just the speed?
Often both, since redirect chains and slow server response affect crawl efficiency as well as user experience. Recovery isn't always immediate, but fixing the underlying cause removes the drag on both fronts rather than just improving a speed score in isolation.