DEV Community

GIRIDHAR DEV
GIRIDHAR DEV

Posted on

How Third-Party Apps Slow Down Shopify Stores

#shopify #webdev #performance #javascript

How Third-Party Apps Slow Down Shopify Stores

Reducing 1000ms of Total Blocking Time (TBT)

This article is part of my Shopify Performance Engineering Series.

In my previous articles:

I covered the overall optimization journey and LCP improvements.

In this post, we’ll focus on another critical metric:

👉 Total Blocking Time (TBT)

What is Total Blocking Time (TBT)

Total Blocking Time measures how long the browser’s main thread is blocked by JavaScript.

When the main thread is blocked:

  • user interactions are delayed
  • scrolling becomes janky
  • clicks feel unresponsive

Even if the page looks loaded, it doesn’t feel fast.

Identifying the Problem:

While analyzing performance using Lighthouse and DevTools, I noticed:

  • high Total Blocking Time
  • long JavaScript execution tasks
  • delayed interactivity

At first, I suspected Google Tag Manager (GTM).

But after deeper investigation, I found the real bottleneck.

The Real Bottleneck: Third-Party Apps

One Shopify app was responsible for:

  • loading a 4MB font file
  • injecting heavy JavaScript
  • triggering multiple network requests

As a result:

  • homepage size reached ~11MB
  • TBT increased by ~1000ms

Why Third-Party Apps Are Problematic?

Most Shopify apps:

  • inject scripts globally
  • run on every page
  • execute during initial load

This creates:

  • main thread blocking
  • delayed rendering
  • unnecessary work for the browser

Investigation Using DevTools

Using the Performance tab in Chrome DevTools, I observed:

  • long tasks (>50ms)
  • script execution blocking rendering
  • heavy main-thread activity

👉 The app scripts were clearly dominating execution time.

First Attempt: Let It Load Normally

Initially, the app was loading during page initialization.

This caused:

  • blocking during critical rendering phase
  • increased TBT
  • slower interactivity

Solution: Interaction-Based Loading

Instead of loading the app immediately, I changed the strategy.

👉 Load the app only when the user clicks the help icon

document.querySelector('.help-icon').addEventListener('click', () => {
  loadSupportIframe();
});
Enter fullscreen mode Exit fullscreen mode

This ensures:

  • no app scripts during initial load
  • no unnecessary blocking
  • better main-thread availability

Why This Works?

Instead of:

Load everything → then render page
We do:
Render page → load features when needed

This reduces:

  • Total Blocking Time
  • network congestion
  • CPU workload
  • Result After Optimization

After applying interaction-based loading:

  • TBT reduced significantly
  • performance score improved
  • page became more responsive
  • Additional Improvements for TBT

Beyond third-party apps, I implemented several optimizations.

1. Deferring Non-Critical JavaScript

Scripts that were not required immediately were deferred.

<script defer src="script.js"></script>
Enter fullscreen mode Exit fullscreen mode

This prevents blocking during HTML parsing.

2. Moving Scripts After Page Load

Some scripts were moved to run after:

window.addEventListener('load', () => {
  loadNonCriticalScripts();
});
Enter fullscreen mode Exit fullscreen mode

This ensures:

  • critical rendering is not blocked
  • scripts run only after page is usable

3. Splitting Large JavaScript Files

Instead of loading one large file I:

  • broke scripts into smaller modules
  • loaded only what was needed

This reduced:

  • execution time
  • blocking duration

4. Removing Unused App Code

When apps were removed, I ensured:

  • leftover JS was deleted
  • unused CSS was removed
  • Liquid code was cleaned

This reduced unnecessary execution.

5. Avoiding Heavy Inline Scripts

Large inline scripts were:

  • moved out of <head>
  • placed near the end of <body>

This reduced blocking during initial render.

Important Insight

TBT optimization is not about writing faster code.
It is about:
reducing the amount of JavaScript that runs during page load, especially large bundles that create long tasks (>50ms) and block the main thread.

Common Mistakes in Shopify TBT Optimization:

  1. Loading all apps on every page
    Many apps are not needed globally.

  2. Running scripts too early
    Non-critical scripts should not run during initial render.

  3. Keeping unused app code
    Uninstalled apps often leave scripts behind.

  4. Large JavaScript bundles
    Big files increase execution time and blocking.

Real-World Impact

After reducing TBT:

  • page felt more responsive
  • interactions became smoother
  • perceived performance improved

Even without changing visual load speed, the site felt significantly faster.

Key Takeaways

If you're optimizing TBT in Shopify:

  • reduce third-party scripts
  • load apps only when needed
  • defer non-critical JavaScript
  • split large JS files
  • remove unused code

Most improvements come from:
removing unnecessary work rather than optimizing existing code

Final Thought

Performance is not just about how fast a page loads.
It’s about how quickly a user can interact with it.

Question for Developers

Have you faced performance issues due to third-party scripts?
What strategies have worked best for you in reducing TBT?

What’s Next

In the next article, I’ll explore:

👉 Modern CSS techniques like content-visibility and how they improve rendering performance

Top comments (0)