Yuvraj Raulji | Shopify optimisation
Shopify hands you a fast platform and then lets you spend that speed. Almost every slow Shopify store is slow for the same reasons: apps injecting scripts on every page, a theme carrying sections it no longer uses, and images shipped at the size they were uploaded. All three are recoverable, and none of them is a platform limitation.
Direct answer
On Shopify the server side is not yours to tune, so speed work is almost entirely about what the store adds on top of the platform. In order of usual impact: remove or consolidate apps that inject scripts into every page, cut the theme back to the sections it actually renders, serve images at the size they are displayed in modern formats, defer third-party tags that do not need to run before paint, and fix the layout shifts that make a fast page feel slow. Conversion work then sits on top of that, because a faster page raises the ceiling rather than the number on its own.
Best suited for
- Core Web Vitals failing in field data
- A store that got slower with every app added
- Paid traffic converting below its landing page benchmark
- Product and collection pages that feel heavy on mobile
What this page is not
This page is delivery work on a store that is staying on Shopify. If the question underneath is whether the theme should be rebuilt, whether Plus is worth it, or whether to leave the platform, that is a decision rather than a task.
The problem
The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.
Every app added a little, and now it is a lot
What it costs
Each app justified its own weight and none of them own the total. Scripts run on pages that do not need them, several apps duplicate one job, and the cumulative cost lands on the pages paid traffic arrives at.
Core Web Vitals fail in the field and pass in the lab
What it costs
The team optimises what the tool measures rather than what a customer on a mid-range phone experiences. Google ranks on the field data, and the customer leaves on it.
The page paints and then jumps
What it costs
Banners, app widgets and lazily loaded sections shift the layout after paint. It reads as a slow, unreliable store even when the timings are respectable, and it costs most on the tap that mattered.
Traffic is fine and conversion is not
What it costs
The spend keeps working and the store does not convert what it brings. Speed is usually part of it and rarely all of it, and treating the two as one project is why some speed engagements deliver nothing commercially.
Approach
In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.
Measure the field, by template
Real user data segmented by device and by template, because product, collection and cart pages fail in different ways. A single site-wide score hides which page is costing the money.
Audit the app and script layer first
What each app injects, on which pages, and whether anything still uses it. On Shopify this is where most of the recoverable time is, and removal is a stronger fix than optimisation.
Cut the theme back
Unused sections, duplicated assets, render-blocking includes and Liquid doing work in a loop that could be done once. Theme weight is the part teams assume is fixed, and it usually is not.
Fix the visible experience
Image sizing and format, the critical path, and layout stability. This is the part a customer actually perceives, and on a hosted platform it is where most of the remaining gain lives.
Then work the conversion path
Product page, cart and checkout entry, tested rather than assumed. Speed raises the ceiling; the conversion work is what collects it.
Scope
Speed
App and script auditTheme and Liquid performanceImage pipelineThird-party tag deferralCore Web Vitals
Experience
Layout stabilityMobile product pageCollection and filteringOn-site search behaviour
Conversion
Product page structureCart and checkout entryTrust and payment signalsA/B test design
Measurement
Field data by templateGA4 event modelFunnel instrumentationPost-change monitoring
Proof
Both are D2C catalogues where the product page and the checkout carried the result rather than the homepage.
Shopify · D2C
Online plant store
India’s most trusted online plant store on Shopify, with OTP login, GoKwik one-page checkout and custom product pages.
ShopifyGoKwik checkoutCustom PDP
E-commerce · Health & fitness
Sports nutrition store
Online fitness and supplement store delivering authentic sports nutrition at speed.
Commerce buildCatalogueCheckout
Outcome
A store that stops getting slower
The durable outcome is not a one-off score. It is an app list somebody owns, a theme small enough to reason about, and a measurement in place so the next three releases do not quietly give the gain back.
Conversion measured where it is decided
Instrumented at the product page, the cart and the checkout entry rather than as a single site-wide rate. A site-wide number tells you something changed; it does not tell you where or what to do next.
No percentage is published here. The measured speed and conversion figures on this site came from Magento work at B2B scale and belong to that platform, and a Shopify store that has never had an app audit has far more headroom than one that has, so a single number would mislead in both directions.
Questions
- Why is my Shopify store slow?
- Almost always apps, theme weight and images, in that order. Shopify runs the server side, so the platform is rarely the constraint. What is left is what the store adds on top: injected scripts on every page, sections the theme no longer renders but still ships, and images served far larger than they display.
- Do Shopify apps really slow the store down?
- Many do, and the cost is cumulative rather than per app. An app that injects a script into every page pays that cost on every page, including the ones it does nothing on. The useful audit is not which apps are slow but which are still earning their place at all.
- How much of Core Web Vitals can I control on Shopify?
- More than most people expect. Server response is Shopify's, but LCP is usually a hero image you control, CLS is almost always your own layout, and the interaction delay is usually third-party JavaScript you added. The parts you cannot change are rarely the parts failing.
- Is speed or conversion work the better investment?
- They are sequential rather than competing. Speed raises the ceiling and conversion work collects it, so doing conversion work on a slow store means testing variants against a constraint neither variant removes. Fix the obvious speed cost first, then test.
- Will this survive our next theme update?
- Only if the work goes into the theme and the app list rather than into patches around them. That is why removal is preferred over optimisation here, and why the engagement ends with monitoring rather than with a report.
Next step
Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.