What are the most common reasons a Shopify store has a slow mobile speed score even after optimizing images?
I am looking for an authentic, to-the-point and clear answer.
I’d really appreciate any practical advice. Thanks!
There is no to-the-point answer without a specific example of what it says.
There are apps, tracking pixels, Javascript, and blocking css. Even the images themselves if not preloaded or have a priority fetch can make fcp/lcp higher.
But chasing a score is not what you should be pursuing. It’s a good synthetic test on imaginary hardware with a throttled connection, but a functional and moderately featured store is always going to have some overhead. The most popular and best stores often have really bad speed scores.
Even with compressed images, Shopify stores can be slowed down by third-party apps, tracking scripts, and unnecessary JavaScript. I’d check the PageSpeed waterfall and focus on LCP/FCP first rather than chasing the overall score.
@olivianewuser123 On the images specifically, since thats what youve already done. Compressing the source file often changes nothing, because the problem usually isnt file size, its delivered size. If your theme requests a 2000px wide image into a 400px slot on a phone, the browser still downloads the big one. Shopifys CDN resizes on the fly through the width parameter on the image URL, so the fix is in the theme asking for the right size, not in the file you uploaded. Worth checking what width your hero and product images are actually being requested at on mobile.
Related own goal thats very common. Whatever image is your largest visible element on load, usually the hero or the first product photo, must not be lazy loaded. Themes often lazy load everything by default, which delays the exact image LCP is measuring. Set that one to eager and preload it, leave everything below the fold lazy. That single change moves LCP more than any amount of compression.
Second thing nobody has mentioned. Uninstalled apps frequently leave code behind. Check your app embeds in the theme editor and turn off anything belonging to an app you no longer use, then look through your theme code for leftover snippets and script tags from old apps. On a store thats tried a few apps this is often the biggest single win available, and its free.
Third, and this decides whether you should care at all. PageSpeed Insights shows two sets of numbers. Field data at the top from real visitors, and lab data underneath from a simulated mid range phone on a throttled connection. The score everyone quotes is the lab one. Googles actual ranking signal uses the field data. So look at whether your field data is passing before spending a week on the lab score. If real users are fine and the simulated phone says 40, you dont have a problem to solve, which is the point Maximus3 was making above.
Hi @olivianewuser123 Welcome To Shopify Community So Once images are handled, the next biggest culprits are almost always third-party apps, each app tends to inject its own script, and a lot of merchants install 10-15 apps without realizing every single one adds render-blocking JavaScript that loads on every page, even pages where that app isn’t even used. Auditing installed apps and removing unused ones is usually the single highest-impact fix after images.
Render-blocking scripts in general are the next factor, anything loading in the <head> without async or defer (tracking pixels, chat widgets, review app scripts) delays the page from becoming interactive even if the visual content loads fine, which tanks mobile scores specifically since mobile CPUs process JS slower than desktop.
Font loading is an underrated one too, custom web fonts that aren’t preloaded or that block text rendering until fully downloaded (no font-display: swap) cause a flash of invisible text, which hurts both perceived speed and actual Core Web Vitals scores.
Theme bloat matters as well, heavily customized themes (or ones with a lot of unused sections/CSS still loading globally) carry more CSS/JS weight than the page actually needs, and that compounds on mobile’s slower connections and processors.
Last one worth checking specifically: liquid render-heavy sections, sections that loop through large collections or run heavy filtering logic server-side can slow down time-to-first-byte even before any client-side JS or images come into play. Hope this helps, and if it does, don’t forget to like and mark it as the solution. Thank you!
Mobile speed typically decreases even after image optimization because of these primary causes:
Third-party apps that load excessive amounts of tracking scripts and background JavaScript are considered heavy or unused apps.
Unminified CSS or JS files that slow down the mobile page’s rendering speed are known as render-blocking code.
Widgets that operate on mobile views even when they are hidden are known as hidden app embeds.
If you like it please mark my comment as solution.Thanks!
The honest answer is Maximus3’s — you can’t pin it without testing the specific store — so let me add the part I’d focus on.
The mobile score everyone chases is a lab simulation on throttled hardware. The number that actually matters is what a real phone shows on a cold first load — cellular, empty cache. Open your own store that way and count the seconds until the main content actually appears. That figure often disagrees with the lab score in both directions, and it’s the one your shoppers feel. In PageSpeed, the field-data section (real Chrome users) is closer to that truth than the lab score above it.
For a little outside perspective: we scan Shopify storefronts from the outside at volume, and across about 2,900 in the current pass, roughly 1 in 15 were slow to show their main content on that kind of cold load. So you’re in good company — and it’s rarely one dramatic thing; usually the first paint is just waiting on something. MayraApps’ point about not lazy-loading your largest above-the-fold element is the highest-leverage fix I’d try first.
Short version: get the field number for your own store, fix whatever your first paint is waiting on, and re-check on an actual phone instead of the score. The score tends to follow the real load, not the other way around.
Thanks for the solid perspective.
Focusing on field data and LCP over synthetic scores really makes sense.