What's your first move when a store loads too slowly?

Speed talk :snail::right_arrow::high_voltage:

Whenever I get handed a slow store, I have a little mental checklist I run through — oversized images first, then apps I can cut, then theme code. But everyone seems to have their own “check this first” instinct.

What’s the very first thing YOU look at when a store feels sluggish? Curious if we all start in the same place or if I’m missing an obvious one :eyes:

For me it’s always Lighthouse/PageSpeed Insights first, before touching anything — not to get a score, but to see which specific element it flags as the LCP (Largest Contentful Paint). “Slow” is subjective, but LCP is the one number Google actually grades you on, and it’s usually one specific thing: a hero image that’s not lazy-loaded properly, webfonts blocking render, or an app injecting a render-blocking script in the head. Once I know what’s actually causing it, I know whether it’s an image problem, an app problem, or a theme code problem — instead of guessing which bucket to start with.

The other thing I check right after: whether it’s the same on mobile vs desktop, since Core Web Vitals is mobile-first indexing — a store that’s fast on your desktop and slow on 4G is failing the metric that actually matters for ranking, and that gap gets missed a lot.

Check your internet first…

Hi @Rasel

First of all, I look at apps, it happens quite often that stores experience issues with performance because of the apps that have scripts loaded on every page even though they need to be loaded only on one particular page.

Then, I normally investigate:

  • Theme Inspector or browser DevTools for render-blocking resources and slow requests.
  • Images sizes and formats (properly sized images and using WebP format, for example).
  • Unused JavaScript and CSS code that can be either removed or deferred.
  • Third-party scripts (such as analytics, chat widget, tracking pixels, etc.).
  • Customizations of the theme to check whether any duplicated or inefficient Liquid code is present.

Also, I always check if the website operates slower than a fresh version of the same theme. In case it does, this means that customizations or additional apps slow down your website.

Of course, all of these things depend on each particular store, but this approach normally works.

Good thread. One thing I’d add — first check if the store is actually slow, or just feels slow.

Sometimes the Lighthouse score is fine but the page still feels broken because content keeps jumping around while images and apps load in. That’s CLS, not load time. No amount of image compression fixes it.

Also, don’t judge speed from your own browser. Your cache is warm and your connection is good. Test on mobile with throttling on, or just look at the PageSpeed mobile score. The customer on 4G with an empty cache is seeing a very different store than you are.

Hi, @Rasel
For me, the first thing I look at when a Shopify store feels slow is what is actually causing the slowdown. I try not to jump straight into compressing images or changing theme code, because the cause can be different from store to store.

Start with the performance report

I usually run the store through PageSpeed Insights and check the mobile results first. I look at things like LCP, INP/TBT and which resources are taking the longest to load. That usually gives me a better starting point than guessing.

Check apps and scripts

Next, I look at the installed apps and third-party scripts. Sometimes an app is no longer being used but is still loading JavaScript or other resources. Removing anything unnecessary can make a noticeable difference.

Look at images

Large hero images, banners and product images are another common cause. I check their file sizes and dimensions and make sure they aren’t significantly larger than they need to be.

Then check the theme

If the main issues aren’t coming from images or apps, I move on to the theme code and look for unnecessary JavaScript, CSS or sections being loaded across the store.

I also like testing the homepage, collection pages and product pages separately, since sometimes only one type of page is slow.

For me, the main thing is finding the actual bottleneck first rather than trying to optimize everything at once. That usually leads to much better results.

For stores where images and third-party scripts are the main problem, you can also use tools such as Website Speedy used to help with image and script optimization. I’d treat it as an optional step though, and only use something like that after identifying what’s actually slowing the store down.

Disclaimer: I’m affiliated with Website Speedy.

Disclosure first: I work at Freeman NYC, so I look at slow stores for clients rather than as a hobby.

My first move is not a tool, it is a question: is the store slow for everyone, or slow on mobile 4G in the US? Those have different fixes, and the Shopify speed score averages them into something you cannot act on.

After that the order is:

1. Field data over lab data. Chrome UX Report / Web Vitals in Search Console tells you what real visitors experienced. Lighthouse tells you what one simulated Moto G experienced once. If they disagree, the field data wins.

2. LCP element identification, exactly as Patrick said. Nine times out of ten on a Shopify theme it is the hero image or a slider that renders above the fold, and the fix is a properly sized responsive image plus removing the carousel entirely rather than optimising it.

3. Third-party scripts, measured by blocking them. Not “which apps do I not use” but “what does the page do if this script is gone”. Chrome DevTools request blocking on each app domain for one page load is a 10 minute test that usually finds one review or popup app costing 700ms to 1.5s of main-thread time.

4. Theme code last. It is the most expensive to change and usually the smallest win, unless the theme is loading jQuery plus a full icon font for four icons.

One thing worth adding to the checklist: check whether the slow pages are collection pages with a lot of filtering. Storefront search and filtering on a large catalog can be slower than anything the theme is doing, and no amount of image compression touches it.

We wrote up how we sequence this work on our performance optimization page if it is useful as a template.

Hey!

I don’t think there’s one universal problem for slow speed, it actually depends on the store.

I usually open the Network tab and check which request is taking the longest before making any changes. It could be an image, app script, font, or server response.

That way, you fix the actual bottleneck instead of blindly compressing images or removing apps.

I skip the score.

View Source on the homepage. Count autoplay videos. Check whether the first image in the fold has loading=lazy (it should not). Check the html width on that file. That is the first paint a phone has to chew.

Then duplicate the theme, turn off app embeds, reload. If it gets fast, add them back one at a time. If it stays slow, it is the theme or the images.

PageSpeed is a report card. The HTML is the actual problem.

hi.

so, multiple things can affect store speed - like using many apps, heavy themes, etc.

others have already shared their views and i am aligned with them.

in my case, i eventually realized that heavy image files were the biggest culprits. thankfully, i used this app - Nabu Image Optimizer & SEO to automatically sync and bulk compress my store images, and since then my core web vitals have improved significantly.