At DemoUp often see people implementing self made solutions for loading (our) scripts. In most cases those solutions work, but the custom attempts always remove loading optimizations. We believe that those changes are made to comply with page standards or old optimization patterns, which do more harm than good. Read about common patterns in script loading which should be avoided today.

This is the third part of a series. Read technical background about how to load and how to render fast in the previous parts.

Usage of Google Tag Manager


A huge amount of our customers are using the Google Tag Manager (GTM) to inject our scripts. Technically that approach may be sufficient for loading tags, but DemoUp is not a tag! DemoUp is part of the UI.

By using GTM our script is not loaded directly anymore, but will be at the end an infamous loading cascade. GTM is asynchronously loaded by script code and it will load our code after it has been loaded and some events has fired. There are not many slower ways of loading a script than using GTM.

Example of inefficient loading via GTM. GTM load is deferred by standard GTM integration code. After it is loaded, it starts loading some scripts. DemoUp’s stage1.js and stage2.js are fetched seconds after the webpage started loading.

Additional downside is that some ad-blockers block GTM, so people using them will not see the scripts you load with it. We see GTM being blocked with uBlock on Firefox and iBlocker in iOS.

Usage of a script loading script


Some shop systems use a custom script-loader in the form of a script which itself loads all other scripts. The approach is technically similar to the use of GTM (see above), but without problems with ad-blockers and Google spying. The usage of such script may have operational reasons, still it is much slower than the standard approach.

Usage of other module loaders


This is another way of actually delaying script load.


  var script = document.createElement("script");
  script.type = "text/javascript";
  script.src = "<shopid>/stage1.js?url="+encodeURI(document.URL);

  var script = document.createElement("script");
  script.async = true; ="demoup_stage2_script";
  script.type = "text/javascript";
  script.src = "<shopname>/stage2.min.js";


Here we see the usage of requireJS. What happens when the page loads is that requireJS code is loaded using a blocking script tag. After that has happened requireJS will wait until jQuery is loaded and afterwards it will start loading our script code. DemoUp is not depending on jQuery in any way, this dependency is therefore useless.

There is no technical reason to delay our scripts in that way.

Using $.ajax


<script type="text/javascript">
cache : true,
dataType: "script",
url : "//<shopid>/stage1.js?url=" + encodeURI(document.URL)
<script async id='demoup_stage2_script' src='//<shopname>/stage2.min.js'></script>

This is not much different from our standard code. Technically it is doing the same by using jQuery’s ajax method. Still, there is no reason to change the code like this. The downside is that there must be a blocking load of jQuery somewhere before, otherwise $.ajax would not be working.

Loading after DOMContentLoaded


$(document).ready(function() {

This example is not functional, because we need a specific ID on the script tag of the stage2. But the basic approach is to start loading our scripts not before the DOMContentLoaded event has been fired. This is an attempt to heavily prioritize rendering of the page against loading the script. You can do that for tracking pixels, but rather not for scripts rendering in your page.


You can find more technical background in the previous parts of this series:

Leave a Reply

Your email address will not be published. Required fields are marked *